From owner-mpls@UU.NET  Thu Jun  1 00:30:16 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04298
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 00:30:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirqo07675;
	Thu, 1 Jun 2000 04:30:09 GMT
Received: by mail-control.mail.uu.net 
	id QQirqn29602
	for mpls-outgoing; Thu, 1 Jun 2000 04:29:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirqn29597
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 04:29:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirqn13215
	for <mpls@uu.net>; Thu, 1 Jun 2000 00:29:00 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirqn06773
	for <mpls@uu.net>; Thu, 1 Jun 2000 04:28:59 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA23197
	for mpls@uu.net; Thu, 1 Jun 2000 00:28:59 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirqn29580
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 04:28:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirqn13138
	for <mpls@uu.net>; Thu, 1 Jun 2000 00:28:12 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQirqn06352
	for <mpls@uu.net>; Thu, 1 Jun 2000 04:28:11 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id VAA16704;
	Wed, 31 May 2000 21:28:10 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <LCLH69JV>; Wed, 31 May 2000 21:28:14 -0700
Message-ID: <E097FDA4F2FED311994000104B31A8610A5CB1@MONTEREY>
From: Bora Akyol <akyol@pluris.com>
To: mpls@UU.NET
Cc: diffserv@ietf.org
Subject: MPLS Diffserv Extensions related questions/comments
Date: Wed, 31 May 2000 21:28:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I have a few questions on the 4th revision of this draft. (Possibly with
more to follow)

1. Does this draft assume that an E-LSP is associated with only one prefix?
At least in our implementation, we can direct more than one prefix into a
single LSP.

2. What happens when penultimate hop popping is used for an E-LSP? The
penultimate hop really does not have knowledge about the EXP mappings in the
ultimate hop?

3. How does one tie the output of the policing element in the model to the
EXP bits on the output direction of the label. Even though the picture in
the draft shows this connection, the text does not cover this.

4. Why does the draft have so many forward references especially in Chapter
2. It would have been much better to first complete the discussion on E-LSPs
fully, then focus on L-LSPs. This makes the text difficult to follow.

5. The draft is vague on the following cases:
	a) IP to MPLS label push
	b) MPLS to IP label pop and route
	c) MPLS to IP pop, then IP to MPLS push.

6. For the people that are actually using MPLS with Diffserv rather than
just the CoS bits, how are you using it?

7. Is the terminology in the draft going to get updated to sync up with the
latest and greatest diffserv terminology ( I have to admit that I tuned out
that discussion about 3 weeks ago).

8. THIS IS A GRIPE. Did anyone consider hardware pipelining, etc while this
spec was being written? This actually is one of my biggest gripes about
Diffserv. It is so damn flexible which makes almost any HW implementation
leave out features, maybe we should have started something that was concrete
and implementable.

One suggestion, it may not be a bad idea at all to move at least one of the
examples to the front of the text to set some context.

Thanks

Bora Akyol



From owner-mpls@UU.NET  Thu Jun  1 02:04:37 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15146
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 02:04:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirqu27977;
	Thu, 1 Jun 2000 06:04:27 GMT
Received: by mail-control.mail.uu.net 
	id QQirqu22267
	for mpls-outgoing; Thu, 1 Jun 2000 06:04:12 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirqu22262
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 06:04:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirqu26807
	for <mpls@UU.NET>; Thu, 1 Jun 2000 02:03:51 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQirqu29547
	for <mpls@UU.NET>; Thu, 1 Jun 2000 06:03:05 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id LAA16076
	for <mpls@UU.NET>; Thu, 1 Jun 2000 11:28:02 -0600 (GMT)
Message-ID: <012201bfcb8f$2c2a6140$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: Ingress LER in LDP
Date: Thu, 1 Jun 2000 11:33:50 +0530
Organization: Daewoo Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_011F_01BFCBBD.42276A00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_011F_01BFCBBD.42276A00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi
    Can someone tell me how to decide if a router is supposed to act as =
an Ingress LER for some particular FEC in MPLS domain ?

Santosh Gupta



------=_NextPart_000_011F_01BFCBBD.42276A00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;&nbsp;&nbsp; Can someone tell me how to decide if a router is =

supposed to act as an Ingress LER for some particular FEC in MPLS domain =
?</DIV>
<DIV><BR>Santosh Gupta</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_011F_01BFCBBD.42276A00--



From owner-mpls@UU.NET  Thu Jun  1 09:06:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22400
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 09:06:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirrw17773;
	Thu, 1 Jun 2000 13:06:02 GMT
Received: by mail-control.mail.uu.net 
	id QQirrw15245
	for mpls-outgoing; Thu, 1 Jun 2000 13:05:32 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirrw14911
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 13:05:12 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirrw07416
	for <mpls@uu.net>; Thu, 1 Jun 2000 09:04:55 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQirrw22543
	for <mpls@uu.net>; Thu, 1 Jun 2000 13:04:55 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id IAA04491;
	Thu, 1 Jun 2000 08:04:50 -0500
Message-ID: <20000601080449.A4482@doit.wisc.edu>
Date: Thu, 1 Jun 2000 08:04:49 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: Santosh Gupta <santoshgupta@poboxes.com>
Cc: mpls@UU.NET
Subject: Re: Ingress LER in LDP
Reply-To: jleu@mindspring.com
References: <012201bfcb8f$2c2a6140$100d85a5@dti.daewoo.co.kr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <012201bfcb8f$2c2a6140$100d85a5@dti.daewoo.co.kr>; from Santosh Gupta on Thu, Jun 01, 2000 at 11:33:50AM +0530
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, Jun 01, 2000 at 11:33:50AM +0530, Santosh Gupta wrote:
> Hi
>     Can someone tell me how to decide if a router is supposed to act as an Ingress LER for some particular FEC in MPLS domain ?
> 
> Santosh Gupta

In general if the next hop for FEC is an LDP peer this LSR _may_ be ingress
for the FEC.  An LSR may be ingress for a FEC (if it initiates a label request
for it's own use) AND transit for a FEC (if an upstream neightbor made a label
request for FEC).

Hope this helps,

Jim
-- 
James R. Leu


From owner-mpls@UU.NET  Thu Jun  1 10:28:29 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24234
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 10:28:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirsb17745;
	Thu, 1 Jun 2000 14:28:29 GMT
Received: by mail-control.mail.uu.net 
	id QQirsb03499
	for mpls-outgoing; Thu, 1 Jun 2000 14:28:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirsb03481
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 14:27:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirsb01795
	for <mpls@UU.NET>; Thu, 1 Jun 2000 10:27:41 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQirsb17055
	for <mpls@UU.NET>; Thu, 1 Jun 2000 14:27:41 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA27846;
	Thu, 1 Jun 2000 07:27:50 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA23263; Thu, 1 Jun 2000 10:27:39 -0400 (EDT)
Message-Id: <200006011427.KAA23263@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: "Santosh Gupta" <santoshgupta@poboxes.com>
cc: mpls@UU.NET
Subject: Re: Ingress LER in LDP 
In-reply-to: Your message of Thu, 01 Jun 2000 11:33:50 +0530.
             <012201bfcb8f$2c2a6140$100d85a5@dti.daewoo.co.kr> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 01 Jun 2000 10:27:39 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Santosh> Can someone tell me how to decide if a router is supposed to act as
Santosh> an Ingress LER for some particular FEC in MPLS domain ?

People keep asking  this question, and I'm never quite sure  just what it is
they are asking, because there isn't much of a mystery here.

If a router received an unlabeled  packet which belongs to a particular FEC,
and the next hop for that packet supports MPLS, and the router is configured
such that it is allowed to do allow label imposition for packets in that FEC
with that next hop, then the router should impose the label assigned to that
FEC by that next hop.

Does that answer your question? 



From owner-mpls@UU.NET  Thu Jun  1 11:05:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25195
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 11:05:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirse13269;
	Thu, 1 Jun 2000 15:05:27 GMT
Received: by mail-control.mail.uu.net 
	id QQirse10847
	for mpls-outgoing; Thu, 1 Jun 2000 15:05:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirse10717
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 15:04:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirse08871
	for <mpls@UU.NET>; Thu, 1 Jun 2000 11:04:44 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQirse12735
	for <mpls@UU.NET>; Thu, 1 Jun 2000 15:04:44 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA20771;
	Thu, 1 Jun 2000 08:04:52 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA23314; Thu, 1 Jun 2000 11:04:41 -0400 (EDT)
Message-Id: <200006011504.LAA23314@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: bkumar@ennovatenetworks.com
cc: "'Sean Doran'" <smd@ebone.net>, "'Martin Cooper'" <mjc@cooper.org.uk>,
        mpls@UU.NET
Subject: Re: MPLS Performance analysis..... 
In-reply-to: Your message of Wed, 31 May 2000 16:09:31 -0400.
             <008f01bfcb3c$2243acc0$d001010a@tst.ennovatenetworks.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 01 Jun 2000 11:04:41 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This will be my  last message in this thread, as I don't  want to get into a
neverending discussion of MPLS vs. IP encapsulation.  

Brijesh> When MPLS work started the enhancing  the speed of IP route look up
Brijesh> was a key motivator behind the technology.  

I don't  recall anyone saying that there  was some upper bound  on the speed
with which IP lookups can be done.  

The performance motivators behind MPLS were the following:

- A piece  of hardware  that supported high-speed  MPLS forwarding,  but not
  high-speed native  forwarding of  protocol X, could  be made,  by suitable
  label imposition policies elsewhere, to forward protocol X at high speed. 

- If  changes in  the  criteria  used for  assigning  packets  to FECs  are
  implemented, high  speed forwarding could  still be provided  by existing,
  unmodified MPLS forwarders. 

Perhaps your position is that  the first point is irrelevant, either because
no one uses ATM anymore, or because  "IP over ATM" is fine and dandy the way
it is.   You might also  argue that the  second point holds equally  well if
MPLS is replaced by some form of IP encapsulation.

Well,  I'd  agree that  the  second  point by  itself  is  not a  sufficient
motivator for MPLS.  Not by itself.  But to argue in favor of a scheme which
does TE and VPN based solely  on IP encapsulation, you'd need to demonstrate
that  there is  no need  for MPLS-like  signalling to  dynamically associate
forwarding  information with the  destination addresses  that appear  in the
encapsulation header.  If this signalling is  needed, all you have is a more
complicated and less efficient form of  MPLS.  On the other hand, if one has
a religious  view that prohibits anything  but IP headers  from being looked
at, this might be considered a worthwhile tradeoff ;-)

Brijesh> it doesn't really matter if  you provision your source routes using
Brijesh> CR-LDP [sic] for certain traffic (or whatever else you have), or by
Brijesh> going to each  router in the network and  creating suitable entries
Brijesh> (manually or auto-magically  under the control of a  TE process) in
Brijesh> the routers 

You're saying it  doesn't matter whether configuring a  path requires you to
touch one router or ten?  I think that is a hard position to defend.

Brijesh> so  that a  particular  class  of traffic  goes  over a  statically
Brijesh> configured path.

This would seem to require either  that the encapsulation header has a field
to  explicitly identify  the class  of  traffic, or  that the  encapsulation
destination address  itself identifies not  merely the destination,  but the
combination of destination and traffic class.   I think that if you work out
the details of  this, you will simply  end up back with MPLS,  though with a
much longer header. 

You may agree or disagree with my position, but don't trivialize it as being
based on any absurd assumption about IP vs. MPLS performance. 











From owner-mpls@UU.NET  Thu Jun  1 12:25:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26765
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 12:25:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirsj07421;
	Thu, 1 Jun 2000 16:25:00 GMT
Received: by mail-control.mail.uu.net 
	id QQirsj29810
	for mpls-outgoing; Thu, 1 Jun 2000 16:24:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirsj29805
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 16:24:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirsj13332
	for <mpls@UU.NET>; Thu, 1 Jun 2000 12:24:03 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6])
	id QQirsj06702
	for <mpls@UU.NET>; Thu, 1 Jun 2000 16:24:02 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jun  1 12:23:04 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA26249;
	Thu, 1 Jun 2000 12:22:36 -0400 (EDT)
Message-ID: <39368EA4.7C1A25AF@dnrc.bell-labs.com>
Date: Thu, 01 Jun 2000 09:26:12 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: MPLS Performance analysis.....
References: <200006011504.LAA23314@erosen-sun.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Eric Rosen wrote:
	[..]
> Brijesh> When MPLS work started the enhancing  the speed of IP route look up
> Brijesh> was a key motivator behind the technology.
> 
> I don't  recall anyone saying that there  was some upper bound  on the speed
> with which IP lookups can be done.

This response doesn't seem to address the quoted text, since
there's no implication of an upper bound there either.

A claim that *was* heard in the early days of IP/label switching is
that it would make for faster per-hop forwarding lookups. You may
not have said it, it may not apply to the motives of ATM-turned-MPLS
switch designers, and you may wish it were never said, but it was.
Said claim has also been proven wrong, but that doesn't change
the fact that the claim was made in certain quarters.

Can we now stop trying to either ressurect the disproven claim
about lookup speeds, and also stop trying to pretend the claim
was never made? I'd like to fall asleep at my desk again.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Thu Jun  1 13:03:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27569
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 13:03:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirsm02531;
	Thu, 1 Jun 2000 17:03:48 GMT
Received: by mail-control.mail.uu.net 
	id QQirsm11496
	for mpls-outgoing; Thu, 1 Jun 2000 17:03:16 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirsm11482
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 17:03:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirsm19792
	for <mpls@UU.NET>; Thu, 1 Jun 2000 13:02:53 -0400 (EDT)
From: pasi.vaananen@nokia.com
Received: from mgw-x2.nokia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mgw-x2.nokia.com [131.228.20.22])
	id QQirsm27625
	for <mpls@UU.NET>; Thu, 1 Jun 2000 17:02:52 GMT
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id UAA16664;
	Thu, 1 Jun 2000 20:02:51 +0300 (EETDST)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id UAA19373;
	Thu, 1 Jun 2000 20:02:49 +0300 (EETDST)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0)
	id <MC3CM75N>; Thu, 1 Jun 2000 12:01:04 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46011ED84A@bseis01nok>
To: gja@dnrc.bell-labs.com, mpls@UU.NET
Subject: RE: MPLS Performance analysis.....
Date: Thu, 1 Jun 2000 11:59:02 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

> Can we now stop trying to either ressurect the disproven claim
> about lookup speeds, and also stop trying to pretend the claim
> was never made? I'd like to fall asleep at my desk again.
> 
I agree - sleep would be good. For those who need some motivations
for MPLS, read Traffic Engineering requirements and "Motivation" 
section in the framework document. There is some text on lookup 
performance, too.

Pasi


From owner-mpls@UU.NET  Thu Jun  1 13:25:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27960
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 13:25:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirsn16709;
	Thu, 1 Jun 2000 17:25:16 GMT
Received: by mail-control.mail.uu.net 
	id QQirsn12955
	for mpls-outgoing; Thu, 1 Jun 2000 17:24:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirsn12943
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 17:24:13 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirsn23587
	for <mpls@uu.net>; Thu, 1 Jun 2000 13:23:52 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirsn12432
	for <mpls@uu.net>; Thu, 1 Jun 2000 17:23:51 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA27216
	for mpls@uu.net; Thu, 1 Jun 2000 13:23:50 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirsn12922
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 17:23:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirsn23489
	for <mpls@UU.NET>; Thu, 1 Jun 2000 13:23:17 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQirsn12057
	for <mpls@UU.NET>; Thu, 1 Jun 2000 17:23:17 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA27160;
	Thu, 1 Jun 2000 10:22:44 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MA5TY>; Thu, 1 Jun 2000 10:22:44 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405A8@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Bora Akyol'" <akyol@pluris.com>, mpls@UU.NET
Cc: diffserv@ietf.org
Subject: RE: MPLS Diffserv Extensions related questions/comments
Date: Thu, 1 Jun 2000 10:19:51 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Bora,

Please see my comments below:

>-----Original Message-----
>From: Bora Akyol [mailto:akyol@pluris.com]
>Sent: Thursday, June 01, 2000 12:28 AM
>To: mpls@UU.NET
>Cc: diffserv@ietf.org
>Subject: MPLS Diffserv Extensions related questions/comments
>
>
>I have a few questions on the 4th revision of this draft. 
>(Possibly with
>more to follow)
>
>1. Does this draft assume that an E-LSP is associated with 
>only one prefix?
>At least in our implementation, we can direct more than one 
>prefix into a
>single LSP.

No. An E-LSP is associated with one FEC. That FEC may include one or more
prefixes (see section 3.1).

>
>2. What happens when penultimate hop popping is used for an E-LSP? The
>penultimate hop really does not have knowledge about the EXP 
>mappings in the
>ultimate hop?

Let me extend your question to the two cases in the draft, (i.e.,Pipe and
Uniform tunnels):

1) Pipe: in this model there is no need for the penultimate hop to convey
the top label's diffserv information (i.e., before popping) to the ultimate
hop. What happens is that the top label's diffserv information is used by
the penultimate hop only for the diffserv scheduling and queuing treatment
in that node, while the packet is sent to the ultimate hop, without
modifying the lower label (the label after pop). Therefore there is no need
for the penultimate hop to know anything about EXP <=>PHB mapping of the
lower label entry.

1) Uniform: In this case the penultimate hop must convey the top label's
diffserv information to the ultimate node by encoding the lower label entry.
Therefore the penultimate hop SHOULD know (either by configuration or other
means) about the EXP <=>PHB mapping of the lower label and/or the LSP type
(E-LSP or L-LSP), otherwise PHP can't be used. In fact this applies to both
E-LSPs and L-LSPs in the Uniform model with PHP. So you are correct in this
case, and if my co-authors have no objection , we could add this restriction
to the draft. 


>
>3. How does one tie the output of the policing element in the 
>model to the
>EXP bits on the output direction of the label. Even though the 
>picture in
>the draft shows this connection, the text does not cover this.
>

It is explained in section 3.5 and 4.5  "Encoding Diffserv information in to
encapsulation layer on outgoing E-LSP and L-LSP". Basically after policing a
packet belonging to a PHB you derive a new PHB and then you can encode this
new PHB in to the EXP field using procedures explained in these sections.


>4. Why does the draft have so many forward references 
>especially in Chapter
>2. It would have been much better to first complete the 
>discussion on E-LSPs
>fully, then focus on L-LSPs. This makes the text difficult to follow.

The reason is that section 2 applies to both E-LSPs and L-LSPs and if we
want to first completely describe E-LSPs then L-LSPs, we need to repeat a
lot of text.

>
>5. The draft is vague on the following cases:
>	a) IP to MPLS label push
>	b) MPLS to IP label pop and route
>	c) MPLS to IP pop, then IP to MPLS push.

These operations are fully explained in section 2.6.3 and 2.6.4 for Uniform
and Pipe model. In our model we have tried to break down the push, pop and
other operations individually without describing all the possible
combinations, this makes the text much shorter and any possible combination
can be figured out by replacing the individual operation in the flow
diagram. If there is anything specific that you think we have not covered
please specify in more details, so that we can add it to the draft. 

>
>6. For the people that are actually using MPLS with Diffserv 
>rather than
>just the CoS bits, how are you using it?
>
>7. Is the terminology in the draft going to get updated to 
>sync up with the
>latest and greatest diffserv terminology ( I have to admit 
>that I tuned out
>that discussion about 3 weeks ago).

The terminology is already updated. If you have any specific doubt please
let us know.

>
>8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
>etc while this
>spec was being written? This actually is one of my biggest gripes about
>Diffserv. It is so damn flexible which makes almost any HW 
>implementation
>leave out features, maybe we should have started something 
>that was concrete
>and implementable.
>
>One suggestion, it may not be a bad idea at all to move at 
>least one of the
>examples to the front of the text to set some context.
>

Thanks for your suggestions.

Regards,
Shahram


>Thanks
>
>Bora Akyol
>



From owner-mpls@UU.NET  Thu Jun  1 15:56:47 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02202
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 15:56:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirsx03893;
	Thu, 1 Jun 2000 19:56:06 GMT
Received: by mail-control.mail.uu.net 
	id QQirsx11425
	for mpls-outgoing; Thu, 1 Jun 2000 19:55:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirsx11418
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 19:55:12 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirsx20884
	for <mpls@uu.net>; Thu, 1 Jun 2000 15:54:07 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirsx06499
	for <mpls@uu.net>; Thu, 1 Jun 2000 19:54:07 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA18658
	for mpls@uu.net; Thu, 1 Jun 2000 15:54:06 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirsx11378
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 19:53:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirsx20692
	for <mpls@uu.net>; Thu, 1 Jun 2000 15:52:51 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQirsx05573
	for <mpls@uu.net>; Thu, 1 Jun 2000 19:52:46 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA00213;
	Thu, 1 Jun 2000 12:52:42 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <LCLH60J8>; Thu, 1 Jun 2000 12:52:42 -0700
Message-ID: <E097FDA4F2FED311994000104B31A86115E655@MONTEREY>
From: Bora Akyol <akyol@pluris.com>
To: "'Brian E Carpenter'" <brian@hursley.ibm.com>,
        Bora Akyol
	 <akyol@pluris.com>
Cc: diffserv@ietf.org, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension
	s related  questions/comments
Date: Thu, 1 Jun 2000 12:52:41 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Here is a specific problem:

Even though DS WG has defined specific codepoints (one of which is AF and is
quite generic in terms of applicability to services), the architecture also
allows for arbitrary codepoints and arbitrary remappings between codepoints.

Not only this, but it allows for arbitrary remappings that depend not only
the ingress port but also the egress port (since each ingress port can be
coming from a DS domain and each egress port can be going to another DS
domain). This causes an NxM multiplication problem where any HW that
actually implements these specs needs to tolerate a N ingress ports being
remapped to M egress ports in a fashion that could either depend on the
pre-configured DSCPs and policer outputs or completely be specified by the
user.

In addition, most HW that operates at OC48c/OC192c speeds does this by
streaming packets through and not using store and forward mechanisms (Just
check the specs for recent framers, network processors, etc). This means
that the packet length (especially for MPLS) is NOT available until the
packet has left the HW pipeline. This means that modification to the packet
headers can not be done at a single point in a system and need to be split
among egress and ingress.

I do realize that there are ways to overcome these problems, but HW cycle
times are unlike software. In this regard, the lack of standardized (and not
so flexible) mechanisms and the lack of definition of standardized services
(which are intentionally left out of the scope of the DS WG) is causing a
lot of heartaches for HW development.

So HW/system vendors then choose the mechanisms that make sense and
implement them, but this causes HW to not comply with certain aspects of
some internet drafts.

I am making these comments in a constructive manner hoping that it helps the
standardization problem, on the other hand, we don't have the luxury of time
to wait, so I am expecting people's experiences with DS to become available
for review sometime soon.

I also believe that the inherent flexibility of the DS documents are
hampering the deployment of a DS based architecture in the Internet, also
the confusion over terminology, and continuous introduction of new terms is
not helping this process either.

Regards

Bora Akyol



> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Thursday, June 01, 2000 11:08 AM
> To: Bora Akyol
> Cc: diffserv@ietf.org
> Subject: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv 
> Extensions
> related questions/comments
> 
> 
> Bora Akyol wrote:
> 
> [mpls list deleted from this reply]
> 
> > 8. THIS IS A GRIPE. Did anyone consider hardware 
> pipelining, etc while this
> > spec was being written? This actually is one of my biggest 
> gripes about
> > Diffserv. It is so damn flexible which makes almost any HW 
> implementation
> > leave out features, maybe we should have started something 
> that was concrete
> > and implementable.
> 
> I think there were plenty of people working at the 
> hardware/software boundary
> involved in the basic definition of diffserv; efficient 
> implementability
> was the main motivation for choosing a stateless model driven 
> by a 6 bit flag.
> 
> You generalized gripe is not much help. Can you be specific 
> about where
> you see the lack of implementability? 
> 
>   Brian
> 



From owner-mpls@UU.NET  Thu Jun  1 16:44:01 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03170
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 16:44:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirta18445;
	Thu, 1 Jun 2000 20:43:52 GMT
Received: by mail-control.mail.uu.net 
	id QQirta24642
	for mpls-outgoing; Thu, 1 Jun 2000 20:43:18 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirta24637
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 20:43:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirta13738
	for <mpls@uu.net>; Thu, 1 Jun 2000 16:43:01 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirta17750
	for <mpls@uu.net>; Thu, 1 Jun 2000 20:43:00 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA25496
	for mpls@uu.net; Thu, 1 Jun 2000 16:43:00 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirta24616
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 20:42:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirta13568
	for <mpls@UU.NET>; Thu, 1 Jun 2000 16:42:06 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQirta17204
	for <mpls@UU.NET>; Thu, 1 Jun 2000 20:42:06 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA01233;
	Thu, 1 Jun 2000 13:42:04 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <LCLH60MQ>; Thu, 1 Jun 2000 13:42:03 -0700
Message-ID: <E097FDA4F2FED311994000104B31A86115E657@MONTEREY>
From: Bora Akyol <akyol@pluris.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        Bora Akyol
	 <akyol@pluris.com>, mpls@UU.NET
Cc: diffserv@ietf.org
Subject: RE: MPLS Diffserv Extensions related questions/comments
Date: Thu, 1 Jun 2000 13:42:03 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


See Comments within:

By the way, I have version 04 of this draft from IETF web site, which
version do you have?

Thanks

Bora


> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Thursday, June 01, 2000 10:20 AM
> To: 'Bora Akyol'; mpls@UU.NET
> Cc: diffserv@ietf.org
> Subject: RE: MPLS Diffserv Extensions related questions/comments
> 
> 
> Hi Bora,
> 
> Please see my comments below:
> 
> >-----Original Message-----
> >From: Bora Akyol [mailto:akyol@pluris.com]
> >Sent: Thursday, June 01, 2000 12:28 AM
> >To: mpls@UU.NET
> >Cc: diffserv@ietf.org
> >Subject: MPLS Diffserv Extensions related questions/comments
> >
> >
> >I have a few questions on the 4th revision of this draft. 
> >(Possibly with
> >more to follow)
> >
> >1. Does this draft assume that an E-LSP is associated with 
> >only one prefix?
> >At least in our implementation, we can direct more than one 
> >prefix into a
> >single LSP.
> 
> No. An E-LSP is associated with one FEC. That FEC may include 
> one or more
> prefixes (see section 3.1).

I have read section 3.1 and it does not define what an FEC is. Which leads
me to believe that the FEC definition is the one that is used in LDP which
essentially is a prefix.

> 
> >
> >2. What happens when penultimate hop popping is used for an 
> E-LSP? The
> >penultimate hop really does not have knowledge about the EXP 
> >mappings in the
> >ultimate hop?
> 
> Let me extend your question to the two cases in the draft, 
> (i.e.,Pipe and
> Uniform tunnels):

I am sorry in the version that I have there is no discussion of "pipe" or
"uniform" tunnels. I have -04 version, is there a newer version available.


> 
> 1) Pipe: in this model there is no need for the penultimate 
> hop to convey
> the top label's diffserv information (i.e., before popping) 
> to the ultimate
> hop. What happens is that the top label's diffserv 
> information is used by
> the penultimate hop only for the diffserv scheduling and 
> queuing treatment
> in that node, while the packet is sent to the ultimate hop, without
> modifying the lower label (the label after pop). Therefore 
> there is no need
> for the penultimate hop to know anything about EXP <=>PHB 
> mapping of the
> lower label entry.
> 

Yes, but what happens if the penultimate hop pop exposes an IP packet, then
what do I put in the DSCP field of the IP packet?

> 1) Uniform: In this case the penultimate hop must convey the 
> top label's
> diffserv information to the ultimate node by encoding the 
> lower label entry.
> Therefore the penultimate hop SHOULD know (either by 
> configuration or other
> means) about the EXP <=>PHB mapping of the lower label and/or 
> the LSP type
> (E-LSP or L-LSP), otherwise PHP can't be used. In fact this 
> applies to both
> E-LSPs and L-LSPs in the Uniform model with PHP. So you are 
> correct in this
> case, and if my co-authors have no objection , we could add 
> this restriction
> to the draft. 
> 

Yes, thank you.

> 
> >
> >3. How does one tie the output of the policing element in the 
> >model to the
> >EXP bits on the output direction of the label. Even though the 
> >picture in
> >the draft shows this connection, the text does not cover this.
> >
> 
> It is explained in section 3.5 and 4.5  "Encoding Diffserv 
> information in to
> encapsulation layer on outgoing E-LSP and L-LSP". Basically 
> after policing a
> packet belonging to a PHB you derive a new PHB and then you 
> can encode this
> new PHB in to the EXP field using procedures explained in 
> these sections.
> 

Copied from draft verbatim:

---------------

3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
E-LSP

   This section defines the mandatory default method for encoding of
   Diff-Serv related information into the MPLS encapsulation Layer to
   be used when a packet is transmitted onto an E-LSP. This method
   requires that the `Set of PHB-->Encaps mappings' is populated as
   defined above in section 3.4.

   The LSR first determines the `Set of PHB-->Encaps Mapping'
   associated with the outer label of the NHLFE.

3.5.1 `PHB-->EXP mapping'

   For all the labels which are swapped or pushed, the LSR:
     - determines the PHB-->EXP mapping by looking up the
       `Set of PHB-->Encaps mapping' of the Diff-Serv context
       associated with the corresponding label in the NHLFE.
     - determines the value to be written in the EXP field of the
       corresponding level label entry by looking up the "outgoing PHB"
       in this PHB-->EXP mapping table.

3.5.2 `PHB-->802.1 mapping'

 Le Faucheur et. al                                                 13


                      MPLS Support of Diff-Serv               March 00


   If the `Set of PHB-->Encaps mapping' of the outer label contains a
   mapping of the form `PHB-->802.1 mapping', then the LSR:
     - determines the value to be written in the User_Priority field of
     the Tag Control Information of the 802.1 encapsulation header
     [IEEE_802.1], by looking up the "outgoing PHB" in this PHB-->802.1
     mapping table.
--------

Can you please show me where in the text above it is stated how to tie in
the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping?

 

> >4. Why does the draft have so many forward references 
> >especially in Chapter
> >2. It would have been much better to first complete the 
> >discussion on E-LSPs
> >fully, then focus on L-LSPs. This makes the text difficult to follow.
> 
> The reason is that section 2 applies to both E-LSPs and 
> L-LSPs and if we
> want to first completely describe E-LSPs then L-LSPs, we need 
> to repeat a
> lot of text.
> 

Unfortunately, makes it hard to follow.
> >
> >5. The draft is vague on the following cases:
> >	a) IP to MPLS label push
> >	b) MPLS to IP label pop and route
> >	c) MPLS to IP pop, then IP to MPLS push.
> 

Oops, my version does not have these sections.


> These operations are fully explained in section 2.6.3 and 
> 2.6.4 for Uniform
> and Pipe model. In our model we have tried to break down the 
> push, pop and
> other operations individually without describing all the possible
> combinations, this makes the text much shorter and any 
> possible combination
> can be figured out by replacing the individual operation in the flow
> diagram. If there is anything specific that you think we have 
> not covered
> please specify in more details, so that we can add it to the draft. 
> 
> >
> >6. For the people that are actually using MPLS with Diffserv 
> >rather than
> >just the CoS bits, how are you using it?
> >
> >7. Is the terminology in the draft going to get updated to 
> >sync up with the
> >latest and greatest diffserv terminology ( I have to admit 
> >that I tuned out
> >that discussion about 3 weeks ago).
> 
> The terminology is already updated. If you have any specific 
> doubt please
> let us know.
> 
> >
> >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
> >etc while this
> >spec was being written? This actually is one of my biggest 
> gripes about
> >Diffserv. It is so damn flexible which makes almost any HW 
> >implementation
> >leave out features, maybe we should have started something 
> >that was concrete
> >and implementable.
> >
> >One suggestion, it may not be a bad idea at all to move at 
> >least one of the
> >examples to the front of the text to set some context.
> >
> 
> Thanks for your suggestions.
> 
> Regards,
> Shahram
> 
> 
> >Thanks
> >
> >Bora Akyol
> >
> 



From owner-mpls@UU.NET  Thu Jun  1 17:14:00 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03934
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 17:14:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirtc08509;
	Thu, 1 Jun 2000 21:13:46 GMT
Received: by mail-control.mail.uu.net 
	id QQirtc05790
	for mpls-outgoing; Thu, 1 Jun 2000 21:13:15 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirtc05715
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 21:13:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirtc19414
	for <mpls@uu.net>; Thu, 1 Jun 2000 17:12:40 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirtc11697
	for <mpls@uu.net>; Thu, 1 Jun 2000 21:12:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA29746
	for mpls@uu.net; Thu, 1 Jun 2000 17:12:38 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirtc05691
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 21:12:03 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirtc05281
	for <mpls@uu.net>; Thu, 1 Jun 2000 17:11:50 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQirtc07239
	for <mpls@uu.net>; Thu, 1 Jun 2000 21:11:49 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA01922;
	Thu, 1 Jun 2000 14:11:19 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <LCLH6036>; Thu, 1 Jun 2000 14:11:19 -0700
Message-ID: <E097FDA4F2FED311994000104B31A86115E65B@MONTEREY>
From: Bora Akyol <akyol@pluris.com>
To: "'Brian E Carpenter'" <brian@hursley.ibm.com>,
        Bora Akyol
	 <akyol@pluris.com>
Cc: diffserv@ietf.org, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension
	s  related  questions/comments
Date: Thu, 1 Jun 2000 14:11:18 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


The comment about the backbone and ingress boxes is something that always
comes up. However, with the age of private peering, VPNS and customers of
ISPs getting hooked at OC48 speeds to the larger ISPs, there is no longer a
core box or an edge box. Most core boxes have almost edge box capabilities.
And at high speeds, it helps to have standard, and not very flexible
mechanisms.

Regarding the ISPs, is there a document somewhere that describes the current
experiences of any ISP that has deployed DS. I don't think that document
exists. I believe that the most widespread use of DS-like behavior is in
MPLS with the CoS (EXP) bits which are essentially used as priorities.

Thanks

Bora


> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Thursday, June 01, 2000 1:34 PM
> To: Bora Akyol
> Cc: diffserv@ietf.org
> Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv
> Extensions related questions/comments
> 

<< SNIPPED>>

> I have to say that my assumption has always been that the 
> hard problems
> would be solved by ingress boxes where scale is not such an 
> issue, so that
> very simple mechanisms would be sufficient in the backbone boxes. 
> 
>   Brian
> 
> 

<<SNIPPED>>



From owner-mpls@UU.NET  Thu Jun  1 18:17:59 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05558
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 18:17:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirth22830;
	Thu, 1 Jun 2000 22:17:34 GMT
Received: by mail-control.mail.uu.net 
	id QQirth19077
	for mpls-outgoing; Thu, 1 Jun 2000 22:16:55 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirth19066
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 22:16:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirth14809
	for <mpls@uu.net>; Thu, 1 Jun 2000 18:16:21 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirth21721
	for <mpls@uu.net>; Thu, 1 Jun 2000 22:16:21 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA07141
	for mpls@uu.net; Thu, 1 Jun 2000 18:16:20 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirth18829
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 22:15:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirth29414
	for <mpls@UU.NET>; Thu, 1 Jun 2000 18:15:27 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQirth21044
	for <mpls@UU.NET>; Thu, 1 Jun 2000 22:15:26 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id PAA16904;
	Thu, 1 Jun 2000 15:14:54 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MA0BL>; Thu, 1 Jun 2000 15:14:55 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405AF@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Bora Akyol'" <akyol@pluris.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
Cc: diffserv@ietf.org
Subject: RE: MPLS Diffserv Extensions related questions/comments
Date: Thu, 1 Jun 2000 15:12:01 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Bora,

Sorry my fault. I was answering your question from the Version -05 of the
draft, which will be released very soon. In any case I presented the Pipe
and Uniform model in Adelaide and we are currently finishing the final
details of this version. 

With this in mind, please see my comments:

>-----Original Message-----
>From: Bora Akyol [mailto:akyol@pluris.com]
>Sent: Thursday, June 01, 2000 4:42 PM
>To: 'Shahram Davari'; Bora Akyol; mpls@UU.NET
>Cc: diffserv@ietf.org
>Subject: RE: MPLS Diffserv Extensions related questions/comments
>
>
>
>See Comments within:
>
>By the way, I have version 04 of this draft from IETF web site, which
>version do you have?
>
>Thanks
>
>Bora
>
>
>> -----Original Message-----
>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>> Sent: Thursday, June 01, 2000 10:20 AM
>> To: 'Bora Akyol'; mpls@UU.NET
>> Cc: diffserv@ietf.org
>> Subject: RE: MPLS Diffserv Extensions related questions/comments
>> 
>> 
>> Hi Bora,
>> 
>> Please see my comments below:
>> 
>> >-----Original Message-----
>> >From: Bora Akyol [mailto:akyol@pluris.com]
>> >Sent: Thursday, June 01, 2000 12:28 AM
>> >To: mpls@UU.NET
>> >Cc: diffserv@ietf.org
>> >Subject: MPLS Diffserv Extensions related questions/comments
>> >
>> >
>> >I have a few questions on the 4th revision of this draft. 
>> >(Possibly with
>> >more to follow)
>> >
>> >1. Does this draft assume that an E-LSP is associated with 
>> >only one prefix?
>> >At least in our implementation, we can direct more than one 
>> >prefix into a
>> >single LSP.
>> 
>> No. An E-LSP is associated with one FEC. That FEC may include 
>> one or more
>> prefixes (see section 3.1).
>
>I have read section 3.1 and it does not define what an FEC is. 
>Which leads
>me to believe that the FEC definition is the one that is used 
>in LDP which
>essentially is a prefix.
>

This document is not the place to define FEC or other previously defined
terms. FEC is defined in Architecture and framework documents. They both
mention that although FEC is commonly associated with an address prefix,
this is not a requirement. In fact using CR-LDP FEC element you could
arbitrarily assign anything you want to an FEC.

>> 
>> >
>> >2. What happens when penultimate hop popping is used for an 
>> E-LSP? The
>> >penultimate hop really does not have knowledge about the EXP 
>> >mappings in the
>> >ultimate hop?
>> 
>> Let me extend your question to the two cases in the draft, 
>> (i.e.,Pipe and
>> Uniform tunnels):
>
>I am sorry in the version that I have there is no discussion 
>of "pipe" or
>"uniform" tunnels. I have -04 version, is there a newer 
>version available.
>
>
>> 
>> 1) Pipe: in this model there is no need for the penultimate 
>> hop to convey
>> the top label's diffserv information (i.e., before popping) 
>> to the ultimate
>> hop. What happens is that the top label's diffserv 
>> information is used by
>> the penultimate hop only for the diffserv scheduling and 
>> queuing treatment
>> in that node, while the packet is sent to the ultimate hop, without
>> modifying the lower label (the label after pop). Therefore 
>> there is no need
>> for the penultimate hop to know anything about EXP <=>PHB 
>> mapping of the
>> lower label entry.
>> 
>
>Yes, but what happens if the penultimate hop pop exposes an IP 
>packet, then
>what do I put in the DSCP field of the IP packet?
>

This is basically the same problem, which limits the use of PHP in Uniform
model. Some possible solutions:

1) Don't use PHP with uniform model
2) Configure the PHP router to know the EXP<=>PHB and/or DSCP<=>PHB mapping



>> 1) Uniform: In this case the penultimate hop must convey the 
>> top label's
>> diffserv information to the ultimate node by encoding the 
>> lower label entry.
>> Therefore the penultimate hop SHOULD know (either by 
>> configuration or other
>> means) about the EXP <=>PHB mapping of the lower label and/or 
>> the LSP type
>> (E-LSP or L-LSP), otherwise PHP can't be used. In fact this 
>> applies to both
>> E-LSPs and L-LSPs in the Uniform model with PHP. So you are 
>> correct in this
>> case, and if my co-authors have no objection , we could add 
>> this restriction
>> to the draft. 
>> 
>
>Yes, thank you.
>
>> 
>> >
>> >3. How does one tie the output of the policing element in the 
>> >model to the
>> >EXP bits on the output direction of the label. Even though the 
>> >picture in
>> >the draft shows this connection, the text does not cover this.
>> >
>> 
>> It is explained in section 3.5 and 4.5  "Encoding Diffserv 
>> information in to
>> encapsulation layer on outgoing E-LSP and L-LSP". Basically 
>> after policing a
>> packet belonging to a PHB you derive a new PHB and then you 
>> can encode this
>> new PHB in to the EXP field using procedures explained in 
>> these sections.
>> 
>
>Copied from draft verbatim:
>
>---------------
>
>3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
>E-LSP
>
>   This section defines the mandatory default method for encoding of
>   Diff-Serv related information into the MPLS encapsulation Layer to
>   be used when a packet is transmitted onto an E-LSP. This method
>   requires that the `Set of PHB-->Encaps mappings' is populated as
>   defined above in section 3.4.
>
>   The LSR first determines the `Set of PHB-->Encaps Mapping'
>   associated with the outer label of the NHLFE.
>
>3.5.1 `PHB-->EXP mapping'
>
>   For all the labels which are swapped or pushed, the LSR:
>     - determines the PHB-->EXP mapping by looking up the
>       `Set of PHB-->Encaps mapping' of the Diff-Serv context
>       associated with the corresponding label in the NHLFE.
>     - determines the value to be written in the EXP field of the
>       corresponding level label entry by looking up the "outgoing PHB"
>       in this PHB-->EXP mapping table.
>
>3.5.2 `PHB-->802.1 mapping'
>
> Le Faucheur et. al                                                 13
>
>
>                      MPLS Support of Diff-Serv               March 00
>
>
>   If the `Set of PHB-->Encaps mapping' of the outer label contains a
>   mapping of the form `PHB-->802.1 mapping', then the LSR:
>     - determines the value to be written in the User_Priority field of
>     the Tag Control Information of the 802.1 encapsulation header
>     [IEEE_802.1], by looking up the "outgoing PHB" in this PHB-->802.1
>     mapping table.
>--------
>
>Can you please show me where in the text above it is stated 
>how to tie in
>the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping?
>

Section 2.3 explains that Policer (traffic conditioner) or any Local policy
may be used to determine the outgoing PHB from the incoming PHB. This is
shown as block "B" in the first diagram. Then the outgoing PHB is encoded in
the packet using one of the procedures described above in section 3.5 or
4.5.

I hope that helps. We have done some additions and corrections which
probably will better answer your questions. We are trying to release the new
version ASAP.

Regards,

-Shahram

> 
>
>> >4. Why does the draft have so many forward references 
>> >especially in Chapter
>> >2. It would have been much better to first complete the 
>> >discussion on E-LSPs
>> >fully, then focus on L-LSPs. This makes the text difficult 
>to follow.
>> 
>> The reason is that section 2 applies to both E-LSPs and 
>> L-LSPs and if we
>> want to first completely describe E-LSPs then L-LSPs, we need 
>> to repeat a
>> lot of text.
>> 
>
>Unfortunately, makes it hard to follow.
>> >
>> >5. The draft is vague on the following cases:
>> >	a) IP to MPLS label push
>> >	b) MPLS to IP label pop and route
>> >	c) MPLS to IP pop, then IP to MPLS push.
>> 
>
>Oops, my version does not have these sections.
>
>
>> These operations are fully explained in section 2.6.3 and 
>> 2.6.4 for Uniform
>> and Pipe model. In our model we have tried to break down the 
>> push, pop and
>> other operations individually without describing all the possible
>> combinations, this makes the text much shorter and any 
>> possible combination
>> can be figured out by replacing the individual operation in the flow
>> diagram. If there is anything specific that you think we have 
>> not covered
>> please specify in more details, so that we can add it to the draft. 
>> 
>> >
>> >6. For the people that are actually using MPLS with Diffserv 
>> >rather than
>> >just the CoS bits, how are you using it?
>> >
>> >7. Is the terminology in the draft going to get updated to 
>> >sync up with the
>> >latest and greatest diffserv terminology ( I have to admit 
>> >that I tuned out
>> >that discussion about 3 weeks ago).
>> 
>> The terminology is already updated. If you have any specific 
>> doubt please
>> let us know.
>> 
>> >
>> >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
>> >etc while this
>> >spec was being written? This actually is one of my biggest 
>> gripes about
>> >Diffserv. It is so damn flexible which makes almost any HW 
>> >implementation
>> >leave out features, maybe we should have started something 
>> >that was concrete
>> >and implementable.
>> >
>> >One suggestion, it may not be a bad idea at all to move at 
>> >least one of the
>> >examples to the front of the text to set some context.
>> >
>> 
>> Thanks for your suggestions.
>> 
>> Regards,
>> Shahram
>> 
>> 
>> >Thanks
>> >
>> >Bora Akyol
>> >
>> 
>



From owner-mpls@UU.NET  Thu Jun  1 23:06:00 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11285
	for <mpls-archive@lists.ietf.org>; Thu, 1 Jun 2000 23:05:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirua20745;
	Fri, 2 Jun 2000 03:05:47 GMT
Received: by mail-control.mail.uu.net 
	id QQirua21780
	for mpls-outgoing; Fri, 2 Jun 2000 03:05:14 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirua21769
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 03:04:59 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirua17675
	for <mpls@UU.NET>; Thu, 1 Jun 2000 23:04:40 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQirua06358
	for <mpls@UU.NET>; Fri, 2 Jun 2000 03:04:39 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA12110;
	Thu, 1 Jun 2000 20:04:38 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <LCLH7AB6>; Thu, 1 Jun 2000 20:04:38 -0700
Message-ID: <E097FDA4F2FED311994000104B31A8611210BE@MONTEREY>
From: Puneet Agarwal <puneet@pluris.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        Bora Akyol
	 <akyol@pluris.com>, mpls@UU.NET
Cc: diffserv@ietf.org
Subject: RE: [Diffserv] RE: MPLS Diffserv Extensions related questions/com
	ments
Date: Thu, 1 Jun 2000 20:04:37 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


For the "IP to MPLS label push" case, section 2.1.2 of the -04 draft says
that we use the DS field as the Incoming PHB. However, if the incoming IPv4
packet's DS field is invalid (as the router is the ingress edge of a
diffserv domain), the packet needs to be first classified to determine the
DSCP for the packet. I think that it is this DSCP that should be used to
determine the Incoming PHB in the case outlined. The draft was not very
explicit in this regard.

Moreover, is it required that this newly computed DSCP be placed in the IP
packet's DS field before pushing the outgoing label(s)?

-Puneet

-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Thursday, June 01, 2000 3:12 PM
To: 'Bora Akyol'; Shahram Davari; mpls@UU.NET
Cc: diffserv@ietf.org
Subject: [Diffserv] RE: MPLS Diffserv Extensions related
questions/comments


Hi Bora,

Sorry my fault. I was answering your question from the Version -05 of the
draft, which will be released very soon. In any case I presented the Pipe
and Uniform model in Adelaide and we are currently finishing the final
details of this version. 

With this in mind, please see my comments:

>-----Original Message-----
>From: Bora Akyol [mailto:akyol@pluris.com]
>Sent: Thursday, June 01, 2000 4:42 PM
>To: 'Shahram Davari'; Bora Akyol; mpls@UU.NET
>Cc: diffserv@ietf.org
>Subject: RE: MPLS Diffserv Extensions related questions/comments
>
>
>
>See Comments within:
>
>By the way, I have version 04 of this draft from IETF web site, which
>version do you have?
>
>Thanks
>
>Bora
>
>
>> -----Original Message-----
>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>> Sent: Thursday, June 01, 2000 10:20 AM
>> To: 'Bora Akyol'; mpls@UU.NET
>> Cc: diffserv@ietf.org
>> Subject: RE: MPLS Diffserv Extensions related questions/comments
>> 
>> 
>> Hi Bora,
>> 
>> Please see my comments below:
>> 
>> >-----Original Message-----
>> >From: Bora Akyol [mailto:akyol@pluris.com]
>> >Sent: Thursday, June 01, 2000 12:28 AM
>> >To: mpls@UU.NET
>> >Cc: diffserv@ietf.org
>> >Subject: MPLS Diffserv Extensions related questions/comments
>> >
>> >
>> >I have a few questions on the 4th revision of this draft. 
>> >(Possibly with
>> >more to follow)
>> >
>> >1. Does this draft assume that an E-LSP is associated with 
>> >only one prefix?
>> >At least in our implementation, we can direct more than one 
>> >prefix into a
>> >single LSP.
>> 
>> No. An E-LSP is associated with one FEC. That FEC may include 
>> one or more
>> prefixes (see section 3.1).
>
>I have read section 3.1 and it does not define what an FEC is. 
>Which leads
>me to believe that the FEC definition is the one that is used 
>in LDP which
>essentially is a prefix.
>

This document is not the place to define FEC or other previously defined
terms. FEC is defined in Architecture and framework documents. They both
mention that although FEC is commonly associated with an address prefix,
this is not a requirement. In fact using CR-LDP FEC element you could
arbitrarily assign anything you want to an FEC.

>> 
>> >
>> >2. What happens when penultimate hop popping is used for an 
>> E-LSP? The
>> >penultimate hop really does not have knowledge about the EXP 
>> >mappings in the
>> >ultimate hop?
>> 
>> Let me extend your question to the two cases in the draft, 
>> (i.e.,Pipe and
>> Uniform tunnels):
>
>I am sorry in the version that I have there is no discussion 
>of "pipe" or
>"uniform" tunnels. I have -04 version, is there a newer 
>version available.
>
>
>> 
>> 1) Pipe: in this model there is no need for the penultimate 
>> hop to convey
>> the top label's diffserv information (i.e., before popping) 
>> to the ultimate
>> hop. What happens is that the top label's diffserv 
>> information is used by
>> the penultimate hop only for the diffserv scheduling and 
>> queuing treatment
>> in that node, while the packet is sent to the ultimate hop, without
>> modifying the lower label (the label after pop). Therefore 
>> there is no need
>> for the penultimate hop to know anything about EXP <=>PHB 
>> mapping of the
>> lower label entry.
>> 
>
>Yes, but what happens if the penultimate hop pop exposes an IP 
>packet, then
>what do I put in the DSCP field of the IP packet?
>

This is basically the same problem, which limits the use of PHP in Uniform
model. Some possible solutions:

1) Don't use PHP with uniform model
2) Configure the PHP router to know the EXP<=>PHB and/or DSCP<=>PHB mapping



>> 1) Uniform: In this case the penultimate hop must convey the 
>> top label's
>> diffserv information to the ultimate node by encoding the 
>> lower label entry.
>> Therefore the penultimate hop SHOULD know (either by 
>> configuration or other
>> means) about the EXP <=>PHB mapping of the lower label and/or 
>> the LSP type
>> (E-LSP or L-LSP), otherwise PHP can't be used. In fact this 
>> applies to both
>> E-LSPs and L-LSPs in the Uniform model with PHP. So you are 
>> correct in this
>> case, and if my co-authors have no objection , we could add 
>> this restriction
>> to the draft. 
>> 
>
>Yes, thank you.
>
>> 
>> >
>> >3. How does one tie the output of the policing element in the 
>> >model to the
>> >EXP bits on the output direction of the label. Even though the 
>> >picture in
>> >the draft shows this connection, the text does not cover this.
>> >
>> 
>> It is explained in section 3.5 and 4.5  "Encoding Diffserv 
>> information in to
>> encapsulation layer on outgoing E-LSP and L-LSP". Basically 
>> after policing a
>> packet belonging to a PHB you derive a new PHB and then you 
>> can encode this
>> new PHB in to the EXP field using procedures explained in 
>> these sections.
>> 
>
>Copied from draft verbatim:
>
>---------------
>
>3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
>E-LSP
>
>   This section defines the mandatory default method for encoding of
>   Diff-Serv related information into the MPLS encapsulation Layer to
>   be used when a packet is transmitted onto an E-LSP. This method
>   requires that the `Set of PHB-->Encaps mappings' is populated as
>   defined above in section 3.4.
>
>   The LSR first determines the `Set of PHB-->Encaps Mapping'
>   associated with the outer label of the NHLFE.
>
>3.5.1 `PHB-->EXP mapping'
>
>   For all the labels which are swapped or pushed, the LSR:
>     - determines the PHB-->EXP mapping by looking up the
>       `Set of PHB-->Encaps mapping' of the Diff-Serv context
>       associated with the corresponding label in the NHLFE.
>     - determines the value to be written in the EXP field of the
>       corresponding level label entry by looking up the "outgoing PHB"
>       in this PHB-->EXP mapping table.
>
>3.5.2 `PHB-->802.1 mapping'
>
> Le Faucheur et. al                                                 13
>
>
>                      MPLS Support of Diff-Serv               March 00
>
>
>   If the `Set of PHB-->Encaps mapping' of the outer label contains a
>   mapping of the form `PHB-->802.1 mapping', then the LSR:
>     - determines the value to be written in the User_Priority field of
>     the Tag Control Information of the 802.1 encapsulation header
>     [IEEE_802.1], by looking up the "outgoing PHB" in this PHB-->802.1
>     mapping table.
>--------
>
>Can you please show me where in the text above it is stated 
>how to tie in
>the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping?
>

Section 2.3 explains that Policer (traffic conditioner) or any Local policy
may be used to determine the outgoing PHB from the incoming PHB. This is
shown as block "B" in the first diagram. Then the outgoing PHB is encoded in
the packet using one of the procedures described above in section 3.5 or
4.5.

I hope that helps. We have done some additions and corrections which
probably will better answer your questions. We are trying to release the new
version ASAP.

Regards,

-Shahram

> 
>
>> >4. Why does the draft have so many forward references 
>> >especially in Chapter
>> >2. It would have been much better to first complete the 
>> >discussion on E-LSPs
>> >fully, then focus on L-LSPs. This makes the text difficult 
>to follow.
>> 
>> The reason is that section 2 applies to both E-LSPs and 
>> L-LSPs and if we
>> want to first completely describe E-LSPs then L-LSPs, we need 
>> to repeat a
>> lot of text.
>> 
>
>Unfortunately, makes it hard to follow.
>> >
>> >5. The draft is vague on the following cases:
>> >	a) IP to MPLS label push
>> >	b) MPLS to IP label pop and route
>> >	c) MPLS to IP pop, then IP to MPLS push.
>> 
>
>Oops, my version does not have these sections.
>
>
>> These operations are fully explained in section 2.6.3 and 
>> 2.6.4 for Uniform
>> and Pipe model. In our model we have tried to break down the 
>> push, pop and
>> other operations individually without describing all the possible
>> combinations, this makes the text much shorter and any 
>> possible combination
>> can be figured out by replacing the individual operation in the flow
>> diagram. If there is anything specific that you think we have 
>> not covered
>> please specify in more details, so that we can add it to the draft. 
>> 
>> >
>> >6. For the people that are actually using MPLS with Diffserv 
>> >rather than
>> >just the CoS bits, how are you using it?
>> >
>> >7. Is the terminology in the draft going to get updated to 
>> >sync up with the
>> >latest and greatest diffserv terminology ( I have to admit 
>> >that I tuned out
>> >that discussion about 3 weeks ago).
>> 
>> The terminology is already updated. If you have any specific 
>> doubt please
>> let us know.
>> 
>> >
>> >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
>> >etc while this
>> >spec was being written? This actually is one of my biggest 
>> gripes about
>> >Diffserv. It is so damn flexible which makes almost any HW 
>> >implementation
>> >leave out features, maybe we should have started something 
>> >that was concrete
>> >and implementable.
>> >
>> >One suggestion, it may not be a bad idea at all to move at 
>> >least one of the
>> >examples to the front of the text to set some context.
>> >
>> 
>> Thanks for your suggestions.
>> 
>> Regards,
>> Shahram
>> 
>> 
>> >Thanks
>> >
>> >Bora Akyol
>> >
>> 
>

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


From owner-mpls@UU.NET  Fri Jun  2 00:38:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12442
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 00:38:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirug08355;
	Fri, 2 Jun 2000 04:38:40 GMT
Received: by mail-control.mail.uu.net 
	id QQirug05701
	for mpls-outgoing; Fri, 2 Jun 2000 04:38:10 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirug05694
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 04:38:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirug14684
	for <mpls@UU.NET>; Fri, 2 Jun 2000 00:37:37 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQirug22658
	for <mpls@UU.NET>; Fri, 2 Jun 2000 04:37:37 GMT
Received: from oleary-lt (wcom-dial-01.juniper.net [172.16.14.66])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id VAA22932;
	Thu, 1 Jun 2000 21:37:05 -0700 (PDT)
Message-Id: <4.2.0.58.20000601190646.02b8aed0@garnet.juniper.net>
X-Sender: doleary@garnet.juniper.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 01 Jun 2000 19:10:35 -0700
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
From: "dave o'leary" <doleary@juniper.net>
Subject: RE: MPLS Diffserv Extensions related questions/comments
In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B405AF@nt-exchange-bby.p
 mc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 03:12 PM 6/1/00 -0700, Shahram Davari wrote:
> >> No. An E-LSP is associated with one FEC. That FEC may include
> >> one or more prefixes (see section 3.1).
>
>This document is not the place to define FEC or other previously defined
>terms. FEC is defined in Architecture and framework documents. They both 
>mention that although FEC is commonly associated with an address prefix, 
>this is not a requirement. In fact using CR-LDP FEC element you could 
>arbitrarily assign anything you want to an FEC.

Any particular reason that you have qualified this by indicating CR-LDP
specifically?  I can't think of any reason that an implementation using
RSVP to signal LSP establishment couldn't also use a variety of
criteria (including but definitely not limited to a destination prefix) for
mapping traffic into a given FEC and in turn onto an LSP.

Thanks,
                                                 dave



From owner-mpls@UU.NET  Fri Jun  2 03:17:26 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25933
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 03:17:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirur20378;
	Fri, 2 Jun 2000 07:16:59 GMT
Received: by mail-control.mail.uu.net 
	id QQirur10721
	for mpls-outgoing; Fri, 2 Jun 2000 07:16:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirur10694
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 07:16:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirur13152
	for <mpls@uu.net>; Fri, 2 Jun 2000 03:15:57 -0400 (EDT)
From: lijianping@mail.zte.com.cn
Received: from mail.zhongxing.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.103.147.133])
	id QQirur07525
	for <mpls@uu.net>; Fri, 2 Jun 2000 07:15:50 GMT
Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 482568F2.0027E48D ; Fri, 2 Jun 2000 15:15:44 +0800
X-Lotus-FromDomain: ZTE_LTD
To: mpls@UU.NET
Message-ID: <482568F2.00253438.00@mail.zhongxing.com>
Date: Fri, 2 Jun 2000 14:46:21 +0800
Subject: get rfc document from email
Sender: owner-mpls@UU.NET
Precedence: bulk




Hi
    Can someone tell me how to get rfc document from email?

thanks & regards.
lijianping.




From owner-mpls@UU.NET  Fri Jun  2 05:25:19 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26737
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 05:25:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiruz17051;
	Fri, 2 Jun 2000 09:24:57 GMT
Received: by mail-control.mail.uu.net 
	id QQiruz05245
	for mpls-outgoing; Fri, 2 Jun 2000 09:24:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiruz05240
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 09:24:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiruz25492
	for <mpls@UU.NET>; Fri, 2 Jun 2000 05:24:06 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQiruz16318
	for <mpls@UU.NET>; Fri, 2 Jun 2000 09:23:43 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id OAA29032;
	Fri, 2 Jun 2000 14:46:40 -0600 (GMT)
Message-ID: <00d901beacd9$7018b260$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <erosen@cisco.com>, "Santosh Gupta" <santoshgupta@poboxes.com>
Cc: <mpls@UU.NET>
References: <200006011427.KAA23263@erosen-sun.cisco.com>
Subject: Re: Ingress LER in LDP 
Date: Wed, 2 Jun 1999 14:52:12 +0530
Organization: Daewoo Telecom
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 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi
    Please see comments inline.

> Santosh> Can someone tell me how to decide if a router is supposed to act
as
> Santosh> an Ingress LER for some particular FEC in MPLS domain ?
>
> People keep asking  this question, and I'm never quite sure  just what it
is
> they are asking, because there isn't much of a mystery here.
>
> If a router received an unlabeled  packet which belongs to a particular
FEC,

There are 2 modes in which an ingress LSR could operate,
1. The LSP formed is made when an unlabelled packet comes to it
2. The LSP should be made in the very beginning as it anticipates that data
is bound to come.
If an LSR is running in the second mode and Ordered-DownstreamOnDemand mode
then how does decide that it should initiate an LSP for the particular FEC.
An LSR could very well act as an LSR for some FEC and LER for some other
FEC.

    A possible solution to this could be that it reads all routes from
Routing Table and if a route has been added by BGP then it knows that it is
supposed to act as an Ingress LER for the particular FEC into which the
Destination falls.
    Other possible solution could be to configure an SLA at each Ingress LER
(either manually or thru some centralized means like COPS) . If LDP finds
some SLA locally then it implies that it is supposed to act as an Ingress
LER and then it will initiate LSP for each FEC.

Is there any better method?

santosh

> and the next hop for that packet supports MPLS, and the router is
configured
> such that it is allowed to do allow label imposition for packets in that
FEC
> with that next hop, then the router should impose the label assigned to
that
> FEC by that next hop.
>
> Does that answer your question?
>
>



From owner-mpls@UU.NET  Fri Jun  2 05:30:34 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26772
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 05:30:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirva29938;
	Fri, 2 Jun 2000 09:30:25 GMT
Received: by mail-control.mail.uu.net 
	id QQirva05568
	for mpls-outgoing; Fri, 2 Jun 2000 09:30:01 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiruz05534
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 09:29:53 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiruz16214
	for <mpls@UU.NET>; Fri, 2 Jun 2000 05:29:38 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQiruz18959
	for <mpls@UU.NET>; Fri, 2 Jun 2000 09:27:58 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id OAA29089;
	Fri, 2 Jun 2000 14:51:47 -0600 (GMT)
Message-ID: <00dd01beacda$1d2710a0$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <jleu@mindspring.com>, "Santosh Gupta" <santoshgupta@poboxes.com>
Cc: <mpls@UU.NET>
References: <012201bfcb8f$2c2a6140$100d85a5@dti.daewoo.co.kr> <20000601080449.A4482@doit.wisc.edu>
Subject: Re: Ingress LER in LDP
Date: Wed, 2 Jun 1999 14:57:19 +0530
Organization: Daewoo Telecom
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 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi
    check the comments inline.


> On Thu, Jun 01, 2000 at 11:33:50AM +0530, Santosh Gupta wrote:
> > Hi
> >     Can someone tell me how to decide if a router is supposed to act as
an Ingress LER for some particular FEC in MPLS domain ?
> >
> > Santosh Gupta
>
> In general if the next hop for FEC is an LDP peer this LSR _may_ be
ingress

Actually an LSR needs to know if it is an Ingress LSR for the FEC or not.
Depending on this decision, it has to make a binding for forwarding
(FEC---->label) in the forwarding module. It would be very inefficient to
make this binding in core routers which never do any forwarding but just
switching. Hope you got my question.

Santosh

> for the FEC.  An LSR may be ingress for a FEC (if it initiates a label
request
> for it's own use) AND transit for a FEC (if an upstream neightbor made a
label
> request for FEC).
>
> Hope this helps,
>
> Jim
> --
> James R. Leu
>



From owner-mpls@UU.NET  Fri Jun  2 07:09:52 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28293
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 07:09:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirvg09392;
	Fri, 2 Jun 2000 11:09:38 GMT
Received: by mail-control.mail.uu.net 
	id QQirvg26476
	for mpls-outgoing; Fri, 2 Jun 2000 11:09:07 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirvg26349
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 11:08:59 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirvg05392
	for <mpls@uu.net>; Fri, 2 Jun 2000 07:08:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirvg08611
	for <mpls@uu.net>; Fri, 2 Jun 2000 11:08:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA20214
	for mpls@uu.net; Fri, 2 Jun 2000 07:08:38 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirvg25838
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 11:08:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirvg05312
	for <mpls@UU.NET>; Fri, 2 Jun 2000 07:08:05 -0400 (EDT)
Received: from qhars002.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19])
	id QQirvg08199
	for <mpls@UU.NET>; Fri, 2 Jun 2000 11:08:04 GMT
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qhars002.nortel.com; Fri, 2 Jun 2000 12:04:13 +0100
Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) 
          by zhard00m.europe.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id MCW0XMCL; Fri, 2 Jun 2000 12:04:04 +0100
Received: from nortelnetworks.com (LANDERSS [141.251.192.208]) 
          by zvb1c002.corpemea.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id L4PJH3A3; Fri, 2 Jun 2000 13:04:10 +0200
Message-ID: <393794E4.129981E6@nortelnetworks.com>
Date: Fri, 02 Jun 2000 13:05:08 +0200
X-Sybari-Space: 00000000 00000000 00000000
From: "Loa Andersson" <loa.andersson@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Grenville Armitage <gja@dnrc.bell-labs.com>
CC: mpls@UU.NET
Subject: Re: MPLS Performance analysis.....
References: <200006011504.LAA23314@erosen-sun.cisco.com> <39368EA4.7C1A25AF@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Grenville,

I'm sorry to send yet another mail on this thread, but I feel that 
there is two sides to this.

1. The claim of "improvement" was made. Remember the social realistic
introduction campaign for tag-switching. 

2. But there was also quite a bit of talk on the "uselessness of MPLS"
based on the fact that it is possible to do a IP lock up as fast as 
a label lookup. 

Trying to explain that there were some other things that we wanted 
from MPLS proved to very futile. I heard the argument "HW based lookup
and wire-speed forwarding" already at the MIT meeting (-96) all the way 
up to the IEEE conference in March this year. With the conclusion that
MPLS is useless - it doesn't give you any increase in forwarding 
capacity.

I might owe Sean a apology, but that was what I read in his text.

To my recollection there were at least 4 different motivations for 
developing MPLS

1. We needed TE-capabilities in IP networks (constraint based routing).

2. A tunnel mechanism for VPNs.

3. "Creating IP routers of ATM-switches"

4. Capacity increase.


Of these number 4 was dead before it ever got to fly, but was used as
an argument against MPLS.
The ATM argument is probably also dead, if for no other reason most
decent ATM switches has an IP capability of their own toady. It is 
no secret that it was from this angle I myself was approaching the 
MPLS at first, but was dropped well back in the end of -97.
The tunnel mechanism for VPNs is till valid, but only one of the
possible
solutions.
The TE argument is the one we are going after.

I vividly remember trying to explain this to a couple of people already
at the Munich IETF the summer of '97. Without much success, MPLS was 
useless because there was no capacity increase!

So, I would be glad to stop this discussion if it is mutual. I would be 
interested to discuss MPLS on it merits (mostly TE), but I won't accept
the "no capacity increase argument", if the conclusion is that MPLS
is useless. I will come back and tell you that you argue based on the 
wrong arguments.

/Loa




Grenville Armitage wrote:
> 

> 
> Can we now stop trying to either ressurect the disproven claim
> about lookup speeds, and also stop trying to pretend the claim
> was never made? I'd like to fall asleep at my desk again.
> 
> cheers,
> gja

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: loa.andersson@nortelnetworks.com



From owner-mpls@UU.NET  Fri Jun  2 08:48:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00908
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 08:48:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirvn07562;
	Fri, 2 Jun 2000 12:48:36 GMT
Received: by mail-control.mail.uu.net 
	id QQirvn15824
	for mpls-outgoing; Fri, 2 Jun 2000 12:48:04 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirvn15730
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 12:47:46 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirvn08747
	for <mpls@uu.net>; Fri, 2 Jun 2000 08:47:29 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQirvn06353
	for <mpls@uu.net>; Fri, 2 Jun 2000 12:47:29 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id HAA05257;
	Fri, 2 Jun 2000 07:47:27 -0500
Message-ID: <20000602074727.A5253@doit.wisc.edu>
Date: Fri, 2 Jun 2000 07:47:27 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: Santosh Gupta <santoshgupta@poboxes.com>
Cc: mpls@UU.NET
Subject: Re: Ingress LER in LDP
Reply-To: jleu@mindspring.com
References: <012201bfcb8f$2c2a6140$100d85a5@dti.daewoo.co.kr> <20000601080449.A4482@doit.wisc.edu> <00dd01beacda$1d2710a0$100d85a5@dti.daewoo.co.kr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <00dd01beacda$1d2710a0$100d85a5@dti.daewoo.co.kr>; from Santosh Gupta on Wed, Jun 02, 1999 at 02:57:19PM +0530
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Jun 02, 1999 at 02:57:19PM +0530, Santosh Gupta wrote:
> Hi
>     check the comments inline.
> 
> 
> > On Thu, Jun 01, 2000 at 11:33:50AM +0530, Santosh Gupta wrote:
> > > Hi
> > >     Can someone tell me how to decide if a router is supposed to act as
> an Ingress LER for some particular FEC in MPLS domain ?
> > >
> > > Santosh Gupta
> >
> > In general if the next hop for FEC is an LDP peer this LSR _may_ be
> ingress
> 
> Actually an LSR needs to know if it is an Ingress LSR for the FEC or not.
> Depending on this decision, it has to make a binding for forwarding
> (FEC---->label) in the forwarding module. It would be very inefficient to
> make this binding in core routers which never do any forwarding but just

The LDP spec only gives you guide lines as to what actions to take when and LSR
is acting as ingress for a FEC.  Acting as ingress for a FEC means that the
LSR has need of being an LER for traffic destinged to that FEC.  It is an
implementation detail as to what external information it uses to make that
descision. Your comments in the previous e-mail about using BGP or an SLA are
a testament to this.

Jim
-- 
James R. Leu

> switching. Hope you got my question.
> 
> Santosh
> 
> > for the FEC.  An LSR may be ingress for a FEC (if it initiates a label
> request
> > for it's own use) AND transit for a FEC (if an upstream neightbor made a
> label
> > request for FEC).
> >
> > Hope this helps,
> >
> > Jim
> > --
> > James R. Leu
> >



From owner-mpls@UU.NET  Fri Jun  2 10:20:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02905
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 10:20:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirvt08001;
	Fri, 2 Jun 2000 14:20:28 GMT
Received: by mail-control.mail.uu.net 
	id QQirvt11499
	for mpls-outgoing; Fri, 2 Jun 2000 14:20:00 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirvt11476
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 14:19:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirvt25180
	for <mpls@uu.net>; Fri, 2 Jun 2000 10:19:24 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirvt27261
	for <mpls@uu.net>; Fri, 2 Jun 2000 14:19:23 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA07550
	for mpls@uu.net; Fri, 2 Jun 2000 10:19:22 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirvt11451
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 14:18:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirvt02598
	for <mpls@UU.NET>; Fri, 2 Jun 2000 10:18:27 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQirvt26393
	for <mpls@UU.NET>; Fri, 2 Jun 2000 14:18:27 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA14622
	for <mpls@UU.NET>; Fri, 2 Jun 2000 07:18:26 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MB13H>; Fri, 2 Jun 2000 07:18:26 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405B3@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: mpls@UU.NET
Subject: RE: [Diffserv] RE: MPLS Diffserv Extensions related questions/com
	 ments
Date: Fri, 2 Jun 2000 07:15:33 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Puneet,

This draft explains MPLS operation over Diffserv. The change of DSCPs of
unlabeled IP packets, which are due to crossing boundaries, is something
which is done before this stage, with or without MPLS. That is why Section
2.1.2 says:

" For packets received unlabelled, this stage operates exactly as with
  a non-MPLS IP Diff-Serv Router and uses the DS field."

So whatever is done in non-MPLS IP Diffserv router is done also here, which
includes the DSCP conversion. I don't really think we need to write all this
operation here. 

Regards,
-Shahram

>-----Original Message-----
>From: Puneet Agarwal [mailto:puneet@pluris.com]
>Sent: Thursday, June 01, 2000 11:05 PM
>To: 'Shahram Davari'; Bora Akyol; mpls@UU.NET
>Cc: diffserv@ietf.org
>Subject: RE: [Diffserv] RE: MPLS Diffserv Extensions related
>questions/com ments
>
>
>
>For the "IP to MPLS label push" case, section 2.1.2 of the -04 
>draft says
>that we use the DS field as the Incoming PHB. However, if the 
>incoming IPv4
>packet's DS field is invalid (as the router is the ingress edge of a
>diffserv domain), the packet needs to be first classified to 
>determine the
>DSCP for the packet. I think that it is this DSCP that should 
>be used to
>determine the Incoming PHB in the case outlined. The draft was not very
>explicit in this regard.
>
>Moreover, is it required that this newly computed DSCP be 
>placed in the IP
>packet's DS field before pushing the outgoing label(s)?
>
>-Puneet
>
>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Thursday, June 01, 2000 3:12 PM
>To: 'Bora Akyol'; Shahram Davari; mpls@UU.NET
>Cc: diffserv@ietf.org
>Subject: [Diffserv] RE: MPLS Diffserv Extensions related
>questions/comments
>
>
>Hi Bora,
>
>Sorry my fault. I was answering your question from the Version 
>-05 of the
>draft, which will be released very soon. In any case I 
>presented the Pipe
>and Uniform model in Adelaide and we are currently finishing the final
>details of this version. 
>
>With this in mind, please see my comments:
>
>>-----Original Message-----
>>From: Bora Akyol [mailto:akyol@pluris.com]
>>Sent: Thursday, June 01, 2000 4:42 PM
>>To: 'Shahram Davari'; Bora Akyol; mpls@UU.NET
>>Cc: diffserv@ietf.org
>>Subject: RE: MPLS Diffserv Extensions related questions/comments
>>
>>
>>
>>See Comments within:
>>
>>By the way, I have version 04 of this draft from IETF web site, which
>>version do you have?
>>
>>Thanks
>>
>>Bora
>>
>>
>>> -----Original Message-----
>>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>>> Sent: Thursday, June 01, 2000 10:20 AM
>>> To: 'Bora Akyol'; mpls@UU.NET
>>> Cc: diffserv@ietf.org
>>> Subject: RE: MPLS Diffserv Extensions related questions/comments
>>> 
>>> 
>>> Hi Bora,
>>> 
>>> Please see my comments below:
>>> 
>>> >-----Original Message-----
>>> >From: Bora Akyol [mailto:akyol@pluris.com]
>>> >Sent: Thursday, June 01, 2000 12:28 AM
>>> >To: mpls@UU.NET
>>> >Cc: diffserv@ietf.org
>>> >Subject: MPLS Diffserv Extensions related questions/comments
>>> >
>>> >
>>> >I have a few questions on the 4th revision of this draft. 
>>> >(Possibly with
>>> >more to follow)
>>> >
>>> >1. Does this draft assume that an E-LSP is associated with 
>>> >only one prefix?
>>> >At least in our implementation, we can direct more than one 
>>> >prefix into a
>>> >single LSP.
>>> 
>>> No. An E-LSP is associated with one FEC. That FEC may include 
>>> one or more
>>> prefixes (see section 3.1).
>>
>>I have read section 3.1 and it does not define what an FEC is. 
>>Which leads
>>me to believe that the FEC definition is the one that is used 
>>in LDP which
>>essentially is a prefix.
>>
>
>This document is not the place to define FEC or other 
>previously defined
>terms. FEC is defined in Architecture and framework documents. 
>They both
>mention that although FEC is commonly associated with an 
>address prefix,
>this is not a requirement. In fact using CR-LDP FEC element you could
>arbitrarily assign anything you want to an FEC.
>
>>> 
>>> >
>>> >2. What happens when penultimate hop popping is used for an 
>>> E-LSP? The
>>> >penultimate hop really does not have knowledge about the EXP 
>>> >mappings in the
>>> >ultimate hop?
>>> 
>>> Let me extend your question to the two cases in the draft, 
>>> (i.e.,Pipe and
>>> Uniform tunnels):
>>
>>I am sorry in the version that I have there is no discussion 
>>of "pipe" or
>>"uniform" tunnels. I have -04 version, is there a newer 
>>version available.
>>
>>
>>> 
>>> 1) Pipe: in this model there is no need for the penultimate 
>>> hop to convey
>>> the top label's diffserv information (i.e., before popping) 
>>> to the ultimate
>>> hop. What happens is that the top label's diffserv 
>>> information is used by
>>> the penultimate hop only for the diffserv scheduling and 
>>> queuing treatment
>>> in that node, while the packet is sent to the ultimate hop, without
>>> modifying the lower label (the label after pop). Therefore 
>>> there is no need
>>> for the penultimate hop to know anything about EXP <=>PHB 
>>> mapping of the
>>> lower label entry.
>>> 
>>
>>Yes, but what happens if the penultimate hop pop exposes an IP 
>>packet, then
>>what do I put in the DSCP field of the IP packet?
>>
>
>This is basically the same problem, which limits the use of 
>PHP in Uniform
>model. Some possible solutions:
>
>1) Don't use PHP with uniform model
>2) Configure the PHP router to know the EXP<=>PHB and/or 
>DSCP<=>PHB mapping
>
>
>
>>> 1) Uniform: In this case the penultimate hop must convey the 
>>> top label's
>>> diffserv information to the ultimate node by encoding the 
>>> lower label entry.
>>> Therefore the penultimate hop SHOULD know (either by 
>>> configuration or other
>>> means) about the EXP <=>PHB mapping of the lower label and/or 
>>> the LSP type
>>> (E-LSP or L-LSP), otherwise PHP can't be used. In fact this 
>>> applies to both
>>> E-LSPs and L-LSPs in the Uniform model with PHP. So you are 
>>> correct in this
>>> case, and if my co-authors have no objection , we could add 
>>> this restriction
>>> to the draft. 
>>> 
>>
>>Yes, thank you.
>>
>>> 
>>> >
>>> >3. How does one tie the output of the policing element in the 
>>> >model to the
>>> >EXP bits on the output direction of the label. Even though the 
>>> >picture in
>>> >the draft shows this connection, the text does not cover this.
>>> >
>>> 
>>> It is explained in section 3.5 and 4.5  "Encoding Diffserv 
>>> information in to
>>> encapsulation layer on outgoing E-LSP and L-LSP". Basically 
>>> after policing a
>>> packet belonging to a PHB you derive a new PHB and then you 
>>> can encode this
>>> new PHB in to the EXP field using procedures explained in 
>>> these sections.
>>> 
>>
>>Copied from draft verbatim:
>>
>>---------------
>>
>>3.5 Encoding Diff-Serv information into Encapsulation Layer 
>On Outgoing
>>E-LSP
>>
>>   This section defines the mandatory default method for encoding of
>>   Diff-Serv related information into the MPLS encapsulation Layer to
>>   be used when a packet is transmitted onto an E-LSP. This method
>>   requires that the `Set of PHB-->Encaps mappings' is populated as
>>   defined above in section 3.4.
>>
>>   The LSR first determines the `Set of PHB-->Encaps Mapping'
>>   associated with the outer label of the NHLFE.
>>
>>3.5.1 `PHB-->EXP mapping'
>>
>>   For all the labels which are swapped or pushed, the LSR:
>>     - determines the PHB-->EXP mapping by looking up the
>>       `Set of PHB-->Encaps mapping' of the Diff-Serv context
>>       associated with the corresponding label in the NHLFE.
>>     - determines the value to be written in the EXP field of the
>>       corresponding level label entry by looking up the 
>"outgoing PHB"
>>       in this PHB-->EXP mapping table.
>>
>>3.5.2 `PHB-->802.1 mapping'
>>
>> Le Faucheur et. al                                                 13
>>
>>
>>                      MPLS Support of Diff-Serv               March 00
>>
>>
>>   If the `Set of PHB-->Encaps mapping' of the outer label contains a
>>   mapping of the form `PHB-->802.1 mapping', then the LSR:
>>     - determines the value to be written in the 
>User_Priority field of
>>     the Tag Control Information of the 802.1 encapsulation header
>>     [IEEE_802.1], by looking up the "outgoing PHB" in this 
>PHB-->802.1
>>     mapping table.
>>--------
>>
>>Can you please show me where in the text above it is stated 
>>how to tie in
>>the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping?
>>
>
>Section 2.3 explains that Policer (traffic conditioner) or any 
>Local policy
>may be used to determine the outgoing PHB from the incoming 
>PHB. This is
>shown as block "B" in the first diagram. Then the outgoing PHB 
>is encoded in
>the packet using one of the procedures described above in 
>section 3.5 or
>4.5.
>
>I hope that helps. We have done some additions and corrections which
>probably will better answer your questions. We are trying to 
>release the new
>version ASAP.
>
>Regards,
>
>-Shahram
>
>> 
>>
>>> >4. Why does the draft have so many forward references 
>>> >especially in Chapter
>>> >2. It would have been much better to first complete the 
>>> >discussion on E-LSPs
>>> >fully, then focus on L-LSPs. This makes the text difficult 
>>to follow.
>>> 
>>> The reason is that section 2 applies to both E-LSPs and 
>>> L-LSPs and if we
>>> want to first completely describe E-LSPs then L-LSPs, we need 
>>> to repeat a
>>> lot of text.
>>> 
>>
>>Unfortunately, makes it hard to follow.
>>> >
>>> >5. The draft is vague on the following cases:
>>> >	a) IP to MPLS label push
>>> >	b) MPLS to IP label pop and route
>>> >	c) MPLS to IP pop, then IP to MPLS push.
>>> 
>>
>>Oops, my version does not have these sections.
>>
>>
>>> These operations are fully explained in section 2.6.3 and 
>>> 2.6.4 for Uniform
>>> and Pipe model. In our model we have tried to break down the 
>>> push, pop and
>>> other operations individually without describing all the possible
>>> combinations, this makes the text much shorter and any 
>>> possible combination
>>> can be figured out by replacing the individual operation in the flow
>>> diagram. If there is anything specific that you think we have 
>>> not covered
>>> please specify in more details, so that we can add it to the draft. 
>>> 
>>> >
>>> >6. For the people that are actually using MPLS with Diffserv 
>>> >rather than
>>> >just the CoS bits, how are you using it?
>>> >
>>> >7. Is the terminology in the draft going to get updated to 
>>> >sync up with the
>>> >latest and greatest diffserv terminology ( I have to admit 
>>> >that I tuned out
>>> >that discussion about 3 weeks ago).
>>> 
>>> The terminology is already updated. If you have any specific 
>>> doubt please
>>> let us know.
>>> 
>>> >
>>> >8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
>>> >etc while this
>>> >spec was being written? This actually is one of my biggest 
>>> gripes about
>>> >Diffserv. It is so damn flexible which makes almost any HW 
>>> >implementation
>>> >leave out features, maybe we should have started something 
>>> >that was concrete
>>> >and implementable.
>>> >
>>> >One suggestion, it may not be a bad idea at all to move at 
>>> >least one of the
>>> >examples to the front of the text to set some context.
>>> >
>>> 
>>> Thanks for your suggestions.
>>> 
>>> Regards,
>>> Shahram
>>> 
>>> 
>>> >Thanks
>>> >
>>> >Bora Akyol
>>> >
>>> 
>>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>



From owner-mpls@UU.NET  Fri Jun  2 10:26:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03018
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 10:26:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirvt03130;
	Fri, 2 Jun 2000 14:26:10 GMT
Received: by mail-control.mail.uu.net 
	id QQirvt11889
	for mpls-outgoing; Fri, 2 Jun 2000 14:25:45 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirvt11880
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 14:25:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirvt03773
	for <mpls@uu.net>; Fri, 2 Jun 2000 10:25:23 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirvt11506
	for <mpls@uu.net>; Fri, 2 Jun 2000 14:25:22 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA08810
	for mpls@uu.net; Fri, 2 Jun 2000 10:25:21 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirvt11852
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 14:24:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirvt26141
	for <mpls@UU.NET>; Fri, 2 Jun 2000 10:24:38 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQirvt01789
	for <mpls@UU.NET>; Fri, 2 Jun 2000 14:24:38 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA14865
	for <mpls@UU.NET>; Fri, 2 Jun 2000 07:24:37 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MB1P6>; Fri, 2 Jun 2000 07:24:37 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405B5@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: mpls@UU.NET
Subject: RE: MPLS Diffserv Extensions related questions/comments
Date: Fri, 2 Jun 2000 07:21:43 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Dave,

CR-LDP FEC element was just an example. Same capability exist in RSVP too.

Regards,
-Shahram

>-----Original Message-----
>From: dave o'leary [mailto:doleary@juniper.net]
>Sent: Thursday, June 01, 2000 10:11 PM
>To: Shahram Davari; mpls@UU.NET
>Subject: RE: MPLS Diffserv Extensions related questions/comments
>
>
>At 03:12 PM 6/1/00 -0700, Shahram Davari wrote:
>> >> No. An E-LSP is associated with one FEC. That FEC may include
>> >> one or more prefixes (see section 3.1).
>>
>>This document is not the place to define FEC or other 
>previously defined
>>terms. FEC is defined in Architecture and framework 
>documents. They both 
>>mention that although FEC is commonly associated with an 
>address prefix, 
>>this is not a requirement. In fact using CR-LDP FEC element you could 
>>arbitrarily assign anything you want to an FEC.
>
>Any particular reason that you have qualified this by indicating CR-LDP
>specifically?  I can't think of any reason that an implementation using
>RSVP to signal LSP establishment couldn't also use a variety of
>criteria (including but definitely not limited to a 
>destination prefix) for
>mapping traffic into a given FEC and in turn onto an LSP.
>
>Thanks,
>                                                 dave
>



From owner-mpls@UU.NET  Fri Jun  2 11:16:50 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04374
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 11:16:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirvx10563;
	Fri, 2 Jun 2000 15:16:46 GMT
Received: by mail-control.mail.uu.net 
	id QQirvx23865
	for mpls-outgoing; Fri, 2 Jun 2000 15:16:13 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirvx23847
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 15:15:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirvx05664
	for <mpls@uu.net>; Fri, 2 Jun 2000 11:15:40 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQirvx16422
	for <mpls@uu.net>; Fri, 2 Jun 2000 15:15:39 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA28030
	for <mpls@uu.net>; Fri, 2 Jun 2000 08:15:46 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA27199 for mpls@uu.net; Fri, 2 Jun 2000 11:15:37 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirum28478
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 06:13:26 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirum06614
	for <mpls@UU.NET>; Fri, 2 Jun 2000 02:13:14 -0400 (EDT)
Received: from web1306.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web1306.mail.yahoo.com [128.11.23.156])
	id QQirum21428
	for <mpls@UU.NET>; Fri, 2 Jun 2000 06:13:14 GMT
Received: (qmail 12335 invoked by uid 60001); 2 Jun 2000 06:13:14 -0000
Message-ID: <20000602061314.12334.qmail@web1306.mail.yahoo.com>
Received: from [202.247.6.31] by web1306.mail.yahoo.com; Thu, 01 Jun 2000 23:13:14 PDT
Date: Thu, 1 Jun 2000 23:13:14 -0700 (PDT)
From: Vikram Venkataraghavan <vikramv25@yahoo.com>
Subject: RSVP/CR-LDP interoperability
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

I know that Cisco uses RSVP for its QoS on MPLS LSR
and Nortel uses CR-LDP (just for example).
Can you please tell me how we can interoperate between
these two protocols.
Do companies implement both protocols on their LSRs
for interoperability in the industry?

Thanks in advance,
Vikram Venkataraghavan
NEC America


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com



From owner-mpls@UU.NET  Fri Jun  2 11:18:41 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04407
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 11:18:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirvx18278;
	Fri, 2 Jun 2000 15:18:03 GMT
Received: by mail-control.mail.uu.net 
	id QQirvx23983
	for mpls-outgoing; Fri, 2 Jun 2000 15:17:19 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirvx23949
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 15:16:58 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirvx13160
	for <mpls@uu.net>; Fri, 2 Jun 2000 11:15:20 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQirvx09490
	for <mpls@uu.net>; Fri, 2 Jun 2000 15:15:19 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA15961
	for <mpls@uu.net>; Fri, 2 Jun 2000 08:15:28 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA27195 for mpls@uu.net; Fri, 2 Jun 2000 11:15:17 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirtf08396
	for <mpls@mail-control.mail.uu.net>; Thu, 1 Jun 2000 21:52:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirtf11252
	for <mpls@uu.net>; Thu, 1 Jun 2000 17:52:13 -0400 (EDT)
Received: from mail-gw.hursley.ibm.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-gw.hursley.ibm.com [194.196.110.15])
	id QQirtf03057
	for <mpls@uu.net>; Thu, 1 Jun 2000 21:52:12 GMT
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA24152; Thu, 1 Jun 2000 22:52:10 +0100
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA14904; Thu, 1 Jun 2000 22:52:09 +0100 (BST)
Message-ID: <3936D801.61A78C7C@hursley.ibm.com>
Date: Thu, 01 Jun 2000 16:39:13 -0500
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Bora Akyol <akyol@pluris.com>
CC: diffserv@ietf.org, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions  
 related  questions/comments
References: <E097FDA4F2FED311994000104B31A86115E65B@MONTEREY>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bora,

I don't think we will see reports of Diffserv deployment experience until
production releases from major router vendors support Diffserv.

The edge boxes that I'm thinking of will need to do MF classification and shaping
at LAN speeds (whatever that means in a particular year). Other boxes only need
to do BA classification and policing. 

But this is old ground that we settled in the early days of diffserv. And
I don't see what it has to do with MPLS.

  Brian

Bora Akyol wrote:
> 
> The comment about the backbone and ingress boxes is something that always
> comes up. However, with the age of private peering, VPNS and customers of
> ISPs getting hooked at OC48 speeds to the larger ISPs, there is no longer a
> core box or an edge box. Most core boxes have almost edge box capabilities.
> And at high speeds, it helps to have standard, and not very flexible
> mechanisms.
> 
> Regarding the ISPs, is there a document somewhere that describes the current
> experiences of any ISP that has deployed DS. I don't think that document
> exists. I believe that the most widespread use of DS-like behavior is in
> MPLS with the CoS (EXP) bits which are essentially used as priorities.
> 
> Thanks
> 
> Bora
> 
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> > Sent: Thursday, June 01, 2000 1:34 PM
> > To: Bora Akyol
> > Cc: diffserv@ietf.org
> > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv
> > Extensions related questions/comments
> >
> 
> << SNIPPED>>
> 
> > I have to say that my assumption has always been that the
> > hard problems
> > would be solved by ingress boxes where scale is not such an
> > issue, so that
> > very simple mechanisms would be sufficient in the backbone boxes.
> >
> >   Brian
> >
> >
> 
> <<SNIPPED>>

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: brian@icair.org



From owner-mpls@UU.NET  Fri Jun  2 11:21:43 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04505
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 11:21:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirvx14435;
	Fri, 2 Jun 2000 15:21:28 GMT
Received: by mail-control.mail.uu.net 
	id QQirvx24228
	for mpls-outgoing; Fri, 2 Jun 2000 15:21:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirvx24211
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 15:20:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirvx06688
	for <mpls@UU.NET>; Fri, 2 Jun 2000 11:20:06 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQirvx13310
	for <mpls@UU.NET>; Fri, 2 Jun 2000 15:20:06 GMT
Received: from tworster (dhcp117.tst.ennovatenetworks.com [10.1.3.117])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA02720;
	Fri, 2 Jun 2000 11:19:34 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: "'Bora Akyol'" <akyol@pluris.com>, <mpls@UU.NET>
Subject: RE: MPLS Diffserv Extensions related questions/comments
Date: Fri, 2 Jun 2000 11:20:04 -0400
Message-ID: <000c01bfcca6$07841f80$7503010a@ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <E097FDA4F2FED311994000104B31A8610A5CB1@MONTEREY>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora Akyol
> 
> 8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
> etc while this
> spec was being written? This actually is one of my biggest 
> gripes about
> Diffserv. It is so damn flexible which makes almost any HW 
> implementation
> leave out features, maybe we should have started something 
> that was concrete
> and implementable.

speaking of hardware... the requirement in diff-ext-04 for 
support of exp->phb mappings on a per lsp basis set by 
signalling does not really seem to be "hardware cost
friendly," so to speak. does anyone really need an arbitrary
mapping for each lsp?

c u
tom


From owner-mpls@UU.NET  Fri Jun  2 11:37:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05175
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 11:37:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirvy01601;
	Fri, 2 Jun 2000 15:37:02 GMT
Received: by mail-control.mail.uu.net 
	id QQirvy25139
	for mpls-outgoing; Fri, 2 Jun 2000 15:36:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirvy25051
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 15:35:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirvy16093
	for <mpls@UU.NET>; Fri, 2 Jun 2000 11:32:31 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQirvy28350
	for <mpls@UU.NET>; Fri, 2 Jun 2000 15:32:31 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA10917;
	Fri, 2 Jun 2000 08:32:38 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA27259; Fri, 2 Jun 2000 11:32:29 -0400 (EDT)
Message-Id: <200006021532.LAA27259@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: "Santosh Gupta" <santoshgupta@poboxes.com>
cc: jleu@mindspring.com, mpls@UU.NET
Subject: Re: Ingress LER in LDP 
In-reply-to: Your message of Wed, 02 Jun 1999 14:57:19 +0530.
             <00dd01beacda$1d2710a0$100d85a5@dti.daewoo.co.kr> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 02 Jun 2000 11:32:28 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Santosh> Actually an LSR needs  to know if it is an Ingress  LSR for the FEC
Santosh> or not.  Depending  on this decision, it has to  make a binding for
Santosh> forwarding (FEC---->label)  in the  forwarding module. It  would be
Santosh> very inefficient to  make this binding in core  routers which never
Santosh> do any forwarding but just switching.

I think the only  case where this could possibly be an  issue is the case of
an ATM-LSR which doesn't support VC  merge.  Is that the case you're focused
on?  

Jim> It is an implementation detail  as to what external information it uses
Jim> to make that decision.

I think Jim  Leu's answer is correct.  I would  probably say "product design
decision" rather than "implementation detail".  





From owner-mpls@UU.NET  Fri Jun  2 12:03:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06078
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 12:03:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwa12899;
	Fri, 2 Jun 2000 16:03:16 GMT
Received: by mail-control.mail.uu.net 
	id QQirwa29869
	for mpls-outgoing; Fri, 2 Jun 2000 16:02:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirwa29611
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 16:02:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwa14446
	for <mpls@UU.NET>; Fri, 2 Jun 2000 12:02:02 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6])
	id QQirwa11848
	for <mpls@UU.NET>; Fri, 2 Jun 2000 16:02:02 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jun  2 12:01:30 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA08736;
	Fri, 2 Jun 2000 12:01:45 -0400 (EDT)
Message-ID: <3937DB3F.5C9E2B76@dnrc.bell-labs.com>
Date: Fri, 02 Jun 2000 09:05:19 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Loa Andersson <loa.andersson@nortelnetworks.com>
CC: mpls@UU.NET
Subject: Re: MPLS Performance analysis.....
References: <200006011504.LAA23314@erosen-sun.cisco.com> <39368EA4.7C1A25AF@dnrc.bell-labs.com> <393794E4.129981E6@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Loa Andersson wrote:
> 
> Grenville,
	[..]
> So, I would be glad to stop this discussion if it is mutual. I would be
> interested to discuss MPLS on it merits (mostly TE), but I won't accept
> the "no capacity increase argument", if the conclusion is that MPLS
> is useless. I will come back and tell you that you argue based on the
> wrong arguments.

Loa, you are reading way too much into my post. Please re-read
the para you quoted below. I acknowledge the speedup claim was
made, I believe it is irrelevant, and I make no statement either
way on whether this proves MPLS is useful or not. Please dont
attribute to me arguments you apparently are still hearing from
others. If you want confirmation of my belief in the use of
MPLS for TE, check IEEE Comms Jan2000 issue.

Can I go back to sleep now?

cheers,
gja

> Grenville Armitage wrote:
> >
> 
> >
> > Can we now stop trying to either ressurect the disproven claim
> > about lookup speeds, and also stop trying to pretend the claim
> > was never made? I'd like to fall asleep at my desk again.

________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Fri Jun  2 12:20:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06523
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 12:20:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwb01476;
	Fri, 2 Jun 2000 16:20:08 GMT
Received: by mail-control.mail.uu.net 
	id QQirwb07028
	for mpls-outgoing; Fri, 2 Jun 2000 16:19:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirwb07021
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 16:19:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirwb24165
	for <mpls@UU.NET>; Fri, 2 Jun 2000 12:19:11 -0400 (EDT)
Received: from mailhost.metro-optix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.metro-optix.com [63.91.47.254])
	id QQirwb00652
	for <mpls@UU.NET>; Fri, 2 Jun 2000 16:19:11 GMT
Received: by MAILHOST with Internet Mail Service (5.5.2650.21)
	id <LCAZVT97>; Fri, 2 Jun 2000 11:19:11 -0500
Message-ID: <D7F6115661E9D311834F006008F5C83C0963DA@MAILHOST>
From: David Wang <david.wang@metro-optix.com>
To: "'Vikram Venkataraghavan'" <vikramv25@yahoo.com>, mpls@UU.NET
Subject: RE: RSVP/CR-LDP interoperability
Date: Fri, 2 Jun 2000 11:19:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

One more detailed question:
We know that many service providers like UUnet already begin and plan to
begin to deploy MPLS into their network. Which technology has been actually
chosen by these service providers? RSVP or CR-LDP, or both? Especially what
UUnet choose?

Thanks for your information
David

-----Original Message-----
From: Vikram Venkataraghavan [mailto:vikramv25@yahoo.com]
Sent: Friday, June 02, 2000 1:13 AM
To: mpls@UU.NET
Subject: RSVP/CR-LDP interoperability


I know that Cisco uses RSVP for its QoS on MPLS LSR
and Nortel uses CR-LDP (just for example).
Can you please tell me how we can interoperate between
these two protocols.
Do companies implement both protocols on their LSRs
for interoperability in the industry?

Thanks in advance,
Vikram Venkataraghavan
NEC America


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Fri Jun  2 13:09:13 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07515
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 13:09:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwe28652;
	Fri, 2 Jun 2000 17:08:55 GMT
Received: by mail-control.mail.uu.net 
	id QQirwe18910
	for mpls-outgoing; Fri, 2 Jun 2000 17:08:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirwe18903
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 17:08:13 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwe25968
	for <mpls@UU.NET>; Fri, 2 Jun 2000 13:07:53 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQirwe27682
	for <mpls@UU.NET>; Fri, 2 Jun 2000 17:07:53 GMT
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Fri, 2 Jun 2000 12:50:11 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <L3HQBGP4>; Fri, 2 Jun 2000 12:50:13 -0400
Message-ID: <6DDA62170439D31185750000F80826AC02B58E7F@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Vishal.Sharma@tellabs.com, Ben.Mack-Crane@tellabs.com
Cc: "mpls@uu.net" <mpls@UU.NET>, Srinivas.Makam@tellabs.com,
        Changcheng.Huang@tellabs.com, Ken.Owens@tellabs.com
Subject: RE: draft-chang-mpls-path-protection Comments
Date: Fri, 2 Jun 2000 12:49:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCB2.9E18A626"
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_01BFCCB2.9E18A626
Content-Type: text/plain

	Vishal:

	One additional comment that I will throw out is that I cannot
distinguish in MPLS terminology between an LSP and the tree which it is
overlaid upon (I  see interchangable references in a number of documents). 

	I think it would be worthwhile making the explicit distinction
between an label switched tree (LST) and label switched path (LSP) (which is
these days is a unidirectional p2p path which may be overlaid on a merged
tree). So when we discuss restoration, we can distinguish between specific
per LSP strategies and dealing with the LST. I know much discussion on this
draft and others could have gone faster with this explicit distinction.
Re-routing, or having pre-planned fail over strategies for an LSP then would
have a distinct meaning.

	If we agree to this distinction, then next question is how do we
retrofit it ?....;-)

	cheers
	Dave




------_=_NextPart_001_01BFCCB2.9E18A626
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: draft-chang-mpls-path-protection Comments</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Vishal:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">One additional =
comment that I will throw out is that I cannot distinguish in MPLS =
terminology between an LSP and the tree which it is overlaid upon =
(I&nbsp; see interchangable references in a number of documents). =
</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I think it would be =
worthwhile making the explicit distinction between an label switched =
tree (LST) and label switched path (LSP) (which is these days is a =
unidirectional p2p path which may be overlaid on a merged tree). So =
when we discuss restoration, we can distinguish between specific per =
LSP strategies and dealing with the LST. I know much discussion on this =
draft and others could have gone faster with this explicit distinction. =
Re-routing, or having pre-planned fail over strategies for an LSP then =
would have a distinct meaning.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If we agree to this =
distinction, then next question is how do we retrofit it =
?....;-)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">cheers</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<BR>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCCB2.9E18A626--


From owner-mpls@UU.NET  Fri Jun  2 13:30:08 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07892
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 13:30:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwg17275;
	Fri, 2 Jun 2000 17:30:00 GMT
Received: by mail-control.mail.uu.net 
	id QQirwf21240
	for mpls-outgoing; Fri, 2 Jun 2000 17:29:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirwf21232
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 17:29:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwf29544
	for <mpls@UU.NET>; Fri, 2 Jun 2000 13:29:05 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQirwf14320
	for <mpls@UU.NET>; Fri, 2 Jun 2000 17:29:05 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA08012;
	Fri, 2 Jun 2000 10:29:03 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA26082; Fri, 2 Jun 2000 10:29:03 -0700 (PDT)
Date: Fri, 2 Jun 2000 10:29:03 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006021729.KAA26082@kummer.juniper.net>
To: david.wang@metro-optix.com, mpls@UU.NET, vikramv25@yahoo.com
Subject: RE: RSVP/CR-LDP interoperability
Sender: owner-mpls@UU.NET
Precedence: bulk

UUnet, Global Center, Level 3 and vBNS all use RSVP for signalling
MPLS.  To my knowledge, none of them use CR-LDP, but you'd have to
ask them.

There has been no interest from ISPs (as far as I know) in
RSVP-CRLDP interoperability.

Kireeti.


From owner-mpls@UU.NET  Fri Jun  2 13:41:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08160
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 13:41:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwg23507;
	Fri, 2 Jun 2000 17:41:13 GMT
Received: by mail-control.mail.uu.net 
	id QQirwg21736
	for mpls-outgoing; Fri, 2 Jun 2000 17:40:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirwg21727
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 17:40:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwg07251
	for <mpls@UU.NET>; Fri, 2 Jun 2000 13:40:18 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQirwg22755
	for <mpls@UU.NET>; Fri, 2 Jun 2000 17:40:17 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id MAA05467;
	Fri, 2 Jun 2000 12:35:09 -0500
Message-ID: <20000602123508.F5253@doit.wisc.edu>
Date: Fri, 2 Jun 2000 12:35:08 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: Kireeti Kompella <kireeti@juniper.net>, david.wang@metro-optix.com,
        mpls@UU.NET, vikramv25@yahoo.com
Subject: Re: RSVP/CR-LDP interoperability
Reply-To: jleu@mindspring.com
References: <200006021729.KAA26082@kummer.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <200006021729.KAA26082@kummer.juniper.net>; from Kireeti Kompella on Fri, Jun 02, 2000 at 10:29:03AM -0700
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, Jun 02, 2000 at 10:29:03AM -0700, Kireeti Kompella wrote:
> UUnet, Global Center, Level 3 and vBNS all use RSVP for signalling
> MPLS.  To my knowledge, none of them use CR-LDP, but you'd have to
> ask them.
> 
> There has been no interest from ISPs (as far as I know) in
> RSVP-CRLDP interoperability.
> 
> Kireeti.

No one is talking about because it tends to lead to religious wars.
I have heard of models where RSVP-TE is used for signaling in the core
and CR-LDP is used at the aggregation level.  This may not be popular
(yet) but it does have some benifits.

I'm supprised no one has mentioned:
draft-wright-mpls-crldp-rsvpte-iw-00.txt

Jim
-- 
James R. Leu


From owner-mpls@UU.NET  Fri Jun  2 13:45:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08235
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 13:45:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwg27382;
	Fri, 2 Jun 2000 17:44:55 GMT
Received: by mail-control.mail.uu.net 
	id QQirwg21956
	for mpls-outgoing; Fri, 2 Jun 2000 17:44:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirwg21943
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 17:44:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwg02043
	for <mpls@UU.NET>; Fri, 2 Jun 2000 13:43:34 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQirwg25288
	for <mpls@UU.NET>; Fri, 2 Jun 2000 17:43:33 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id MAA19878;
	Fri, 2 Jun 2000 12:43:30 -0500 (CDT)
Received: from vsharma ([172.31.101.68] (may be forged))
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA28671;
	Fri, 2 Jun 2000 12:43:31 -0500 (CDT)
Received: by localhost with Microsoft MAPI; Fri, 2 Jun 2000 13:47:58 -0400
Message-ID: <01BFCC99.2956F310.Vishal.Sharma@tellabs.com>
From: Vishal Sharma <Vishal.Sharma@tellabs.com>
Reply-To: "Vishal.Sharma@tellabs.com" <Vishal.Sharma@tellabs.com>
To: "'dallan@nortelnetworks.com'" <dallan@nortelnetworks.com>,
        "Ben.Mack-Crane@tellabs.com" <Ben.Mack-Crane@tellabs.com>
Cc: "mpls@UU.NET" <mpls@UU.NET>,
        "Srinivas.Makam@tellabs.com"
	 <Srinivas.Makam@tellabs.com>,
        "Changcheng.Huang@tellabs.com"
	 <Changcheng.Huang@tellabs.com>,
        "Ken.Owens@tellabs.com"
	 <Ken.Owens@tellabs.com>
Subject: RE: draft-chang-mpls-path-protection Comments
Date: Fri, 2 Jun 2000 13:47:57 -0400
Organization: Tellabs Research Center
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Dave,

I see your point, and the distinction could make things clearer.
Related to this train of thought, I'd like to point out the following.

You say that an LSP is p2p, and may be overlaid on a tree. There are
actually two cases here:

(i) A true multipoint-to-point LSP, which means traffic labeled with distinct
incoming labels on the ingress links is assigned the same label (one
label) on the egress link. In this case, the LSP and the tree it is overlaid
on are isomorphic.

(ii) A collection of p2p LSPs, all of which terminate at the same destination,
and happen to share a route from some point on (we call such LSPs
"virtually merged" (a term one of my co-authors came up with)). In this
case, any given LSP is overlaid upon a portion of the tree (where the "tree"
is an abstract entity consisting of all the links that all of these LSPs traverse).

In our mechanism draft, we were initially thinking only of (i), so we
though we did not need the distinction between the LSP and the tree (we know now
that (ii) is equally easily covered by our mechanism). Our thinking was that, depending 
on where the fault was, either all sources (more precisely PSLs) or some
of subset them would switch to a backup path (after the affected PSLs
were notified of the fault).

I realize now that there is a problem with the above reasoning as well, since,
for some types of faults, only a portion of the (point-to-multipoint) LSP could be switched 
to a protection path, and we did not have terminology to make this clear.

About the retrofitting... I guess we'd need to do that in the upcoming revision. If you
see some issues with doing that, please let us know.

-Vishal
On Friday, June 02, 2000 12:50 PM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] wrote:
> 	Vishal:
> 
> 	One additional comment that I will throw out is that I cannot
> distinguish in MPLS terminology between an LSP and the tree which it is
> overlaid upon (I  see interchangable references in a number of documents). 
> 
> 	I think it would be worthwhile making the explicit distinction
> between an label switched tree (LST) and label switched path (LSP) (which is
> these days is a unidirectional p2p path which may be overlaid on a merged
> tree). So when we discuss restoration, we can distinguish between specific
> per LSP strategies and dealing with the LST. I know much discussion on this
> draft and others could have gone faster with this explicit distinction.
> Re-routing, or having pre-planned fail over strategies for an LSP then would
> have a distinct meaning.
> 
> 	If we agree to this distinction, then next question is how do we
> retrofit it ?....;-)
> 
> 	cheers
> 	Dave



From owner-mpls@UU.NET  Fri Jun  2 14:11:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08843
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 14:11:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwi15609;
	Fri, 2 Jun 2000 18:11:14 GMT
Received: by mail-control.mail.uu.net 
	id QQirwi02584
	for mpls-outgoing; Fri, 2 Jun 2000 18:10:21 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirwi02576
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 18:10:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirwi06708
	for <mpls@UU.NET>; Fri, 2 Jun 2000 14:10:00 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQirwi14570
	for <mpls@UU.NET>; Fri, 2 Jun 2000 18:09:59 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Fri, 2 Jun 2000 13:09:25 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <LW2CBYML>; Fri, 2 Jun 2000 13:09:11 -0500
Message-ID: <6DDA62170439D31185750000F80826AC02B58FF7@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Vishal.Sharma@tellabs.com, Ben.Mack-Crane@tellabs.com
Cc: mpls@UU.NET, Srinivas.Makam@tellabs.com, Changcheng.Huang@tellabs.com,
        Ken.Owens@tellabs.com
Subject: RE: draft-chang-mpls-path-protection Comments
Date: Fri, 2 Jun 2000 13:09:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCBD.A6DD31A4"
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_01BFCCBD.A6DD31A4
Content-Type: text/plain

Vishal:

I was thinking of decomposing (i). There needs to be a way to discuss the
constituent tributaries in what you call a "true multi-point LSP". The
abstract entity you refer to in (ii) would seem to be more akin to an I.630
VP/CG where a group of LSPs shares a common OAM trail (and which I think
doing that in a signalled fashion is somewhat intractable), this is a bit
different, in that they not only would share a trail, but label forwarding
space.

If I adopt the LST/LSP distinction for (i) then....

My motivation is that a failure in an LST (a.k.a. (i)) does not require that
all constituent LSPs switch, only those upstream of the failure. Most would
be unaffected and it would be desirable to leave them alone from the point
of view of network stability (if it aint broke....). Those that were
affected by the failure do not require a strategy that is in any way
coordinated with the other failed or still working LSPs as the natual LST
grouping really has no meaning once that particular topology configuration
has failed (the LSP/LST linkage broke). Currently this is difficult to
discuss clearly. That is what I would like to address...

regards
Dave

> -----Original Message-----
	<snip>
> There are actually two cases here:
> 
> (i) A true multipoint-to-point LSP, which means traffic labeled with
> distinct
> incoming labels on the ingress links is assigned the same label (one
> label) on the egress link. In this case, the LSP and the tree it is
> overlaid
> on are isomorphic.
> 
> (ii) A collection of p2p LSPs, all of which terminate at the same
> destination,
> and happen to share a route from some point on (we call such LSPs
> "virtually merged" (a term one of my co-authors came up with)). In this
> case, any given LSP is overlaid upon a portion of the tree (where the
> "tree"
> is an abstract entity consisting of all the links that all of these LSPs
> traverse).
> 
> In our mechanism draft, we were initially thinking only of (i), so we
> though we did not need the distinction between the LSP and the tree (we
> know now
> that (ii) is equally easily covered by our mechanism). Our thinking was
> that, depending 
> on where the fault was, either all sources (more precisely PSLs) or some
> of subset them would switch to a backup path (after the affected PSLs
> were notified of the fault).
> 
> I realize now that there is a problem with the above reasoning as well,
> since,
> for some types of faults, only a portion of the (point-to-multipoint) LSP
> could be switched 
> to a protection path, and we did not have terminology to make this clear.
> 
> About the retrofitting... I guess we'd need to do that in the upcoming
> revision. If you
> see some issues with doing that, please let us know.
> 
> -Vishal
> 
> 

------_=_NextPart_001_01BFCCBD.A6DD31A4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: draft-chang-mpls-path-protection Comments</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Vishal:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I was thinking of =
decomposing (i). There needs to be a way to discuss the constituent =
tributaries in what you call a &quot;true multi-point LSP&quot;. The =
abstract entity you refer to in (ii) would seem to be more akin to an =
I.630 VP/CG where a group of LSPs shares a common OAM trail (and which =
I think doing that in a signalled fashion is somewhat intractable), =
this is a bit different, in that they not only would share a trail, but =
label forwarding space.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If I adopt the =
LST/LSP distinction for (i) then....</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">My motivation is =
that a failure in an LST (a.k.a. (i)) does not require that all =
constituent LSPs switch, only those upstream of the failure. Most would =
be unaffected and it would be desirable to leave them alone from the =
point of view of network stability (if it aint broke....). Those that =
were affected by the failure do not require a strategy that is in any =
way coordinated with the other failed or still working LSPs as the =
natual LST grouping really has no meaning once that particular topology =
configuration has failed (the LSP/LST linkage broke). Currently this is =
difficult to discuss clearly. That is what I would like to =
address...</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">regards</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">There are</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">actually two cases here:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(i) A true multipoint-to-point LSP, =
which means traffic labeled with distinct</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">incoming labels on the ingress links =
is assigned the same label (one</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">label) on the egress link. In this =
case, the LSP and the tree it is overlaid</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">on are isomorphic.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(ii) A collection of p2p LSPs, all of =
which terminate at the same destination,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and happen to share a route from some =
point on (we call such LSPs</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;virtually merged&quot; (a term =
one of my co-authors came up with)). In this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">case, any given LSP is overlaid upon =
a portion of the tree (where the &quot;tree&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is an abstract entity consisting of =
all the links that all of these LSPs traverse).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In our mechanism draft, we were =
initially thinking only of (i), so we</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">though we did not need the =
distinction between the LSP and the tree (we know now</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that (ii) is equally easily covered =
by our mechanism). Our thinking was that, depending </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">on where the fault was, either all =
sources (more precisely PSLs) or some</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of subset them would switch to a =
backup path (after the affected PSLs</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">were notified of the fault).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I realize now that there is a problem =
with the above reasoning as well, since,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for some types of faults, only a =
portion of the (point-to-multipoint) LSP could be switched </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to a protection path, and we did not =
have terminology to make this clear.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">About the retrofitting... I guess we'd =
need to do that in the upcoming revision. If you</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">see some issues with doing that, =
please let us know.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-Vishal</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCCBD.A6DD31A4--


From owner-mpls@UU.NET  Fri Jun  2 14:14:57 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08925
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 14:14:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwi19161;
	Fri, 2 Jun 2000 18:14:37 GMT
Received: by mail-control.mail.uu.net 
	id QQirwi02827
	for mpls-outgoing; Fri, 2 Jun 2000 18:13:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirwi02819
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 18:13:43 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwi12725
	for <mpls@uu.net>; Fri, 2 Jun 2000 14:13:22 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQirwi18112
	for <mpls@uu.net>; Fri, 2 Jun 2000 18:13:21 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA12146;
	Fri, 2 Jun 2000 11:13:21 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id LAA26196; Fri, 2 Jun 2000 11:13:21 -0700 (PDT)
Date: Fri, 2 Jun 2000 11:13:21 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006021813.LAA26196@kummer.juniper.net>
To: jleu@mindspring.com
Subject: Re: RSVP/CR-LDP interoperability
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

> No one is talking about because it tends to lead to religious wars.

:-)

> I have heard of models where RSVP-TE is used for signaling in the core
> and CR-LDP is used at the aggregation level.  This may not be popular
> (yet) but it does have some benifits.

Actually, I haven't seen this, but I have seen interest in LDP on
the edge, RSVP in the core.  Given a desire for edge-to-edge MPLS
(e.g., for VPNs), RSVP edge-to-edge has 3 problems (as would CR-LDP):
1) an n^2 full mesh is a pain when n is large (edge as opposed to core);
2) edge-to-edge traffic is much more variable than core-to-core, making
   traffic engineering more meaningful in the core;
3) traffic engineering gets more interesting inter-pop than intra-pop
   (intra-pop paths are pretty straightforward).

Given that, LDP on the edge fits the bill.

Jim, I'd be interested in knowing what the benefits of CR-LDP at the
edge, RSVP in the core are.

> I'm supprised no one has mentioned:
> draft-wright-mpls-crldp-rsvpte-iw-00.txt

It would be interesting to know if the above draft was written in
response to an ISP requirement.

Kireeti.


From owner-mpls@UU.NET  Fri Jun  2 14:18:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08951
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 14:18:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwj22846;
	Fri, 2 Jun 2000 18:18:24 GMT
Received: by mail-control.mail.uu.net 
	id QQirwj03280
	for mpls-outgoing; Fri, 2 Jun 2000 18:17:43 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirwj03271
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 18:17:39 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirwj13410
	for <mpls@UU.NET>; Fri, 2 Jun 2000 14:17:19 -0400 (EDT)
Received: from smtprch2.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15])
	id QQirwj19851
	for <mpls@UU.NET>; Fri, 2 Jun 2000 18:17:19 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Fri, 2 Jun 2000 13:09:26 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <LW2CBYQF>; Fri, 2 Jun 2000 13:12:16 -0500
Message-ID: <F033F6FEF3F1D111BD150000F8CD1431040CCA7E@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: jleu@mindspring.com, Kireeti Kompella <kireeti@juniper.net>,
        david.wang@metro-optix.com, mpls@UU.NET, vikramv25@yahoo.com
Subject: RE: RSVP/CR-LDP interoperability
Date: Fri, 2 Jun 2000 13:12:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCBE.1502F592"
X-Orig: <dwfedyk@americasm01.nt.com>
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_01BFCCBE.1502F592
Content-Type: text/plain;
	charset="ISO-8859-1"

Thanks, James

Like James says you can read the archives on the relative 
merits of each protocol. What Kireeti says is true, but its 
not like the customers had much choice in the matter so far!
  
Some of our products will use RSVP-TE and some will use 
CR-LDP and some both.  Certainly LDP also figures into the 
plans and once you have LDP you might as well do CR-LDP. 
We have also been planning to support an interworking strategy.

As far as customers many have expressed interest in CR-LDP 
and interworking with RSVP-TE will have to figure into that 
equation given the circumstances.  

Don

> -----Original Message-----
> From: James R. Leu [mailto:jleu@mindspring.com]
> Sent: Friday, June 02, 2000 1:35 PM
> To: Kireeti Kompella; david.wang@metro-optix.com; mpls@UU.NET;
> vikramv25@yahoo.com
> Subject: Re: RSVP/CR-LDP interoperability
> 
> 
> On Fri, Jun 02, 2000 at 10:29:03AM -0700, Kireeti Kompella wrote:
> > UUnet, Global Center, Level 3 and vBNS all use RSVP for signalling
> > MPLS.  To my knowledge, none of them use CR-LDP, but you'd have to
> > ask them.
> > 
> > There has been no interest from ISPs (as far as I know) in
> > RSVP-CRLDP interoperability.
> > 
> > Kireeti.
> 
> No one is talking about because it tends to lead to religious wars.
> I have heard of models where RSVP-TE is used for signaling in the core
> and CR-LDP is used at the aggregation level.  This may not be popular
> (yet) but it does have some benifits.
> 
> I'm supprised no one has mentioned:
> draft-wright-mpls-crldp-rsvpte-iw-00.txt
> 
> Jim
> -- 
> James R. Leu
> 

------_=_NextPart_001_01BFCCBE.1502F592
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.2651.65">
<TITLE>RE: RSVP/CR-LDP interoperability</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Thanks, James</FONT>
</P>

<P><FONT SIZE=2>Like James says you can read the archives on the relative </FONT>
<BR><FONT SIZE=2>merits of each protocol. What Kireeti says is true, but its </FONT>
<BR><FONT SIZE=2>not like the customers had much choice in the matter so far!</FONT>
<BR><FONT SIZE=2>&nbsp; </FONT>
<BR><FONT SIZE=2>Some of our products will use RSVP-TE and some will use </FONT>
<BR><FONT SIZE=2>CR-LDP and some both.&nbsp; Certainly LDP also figures into the </FONT>
<BR><FONT SIZE=2>plans and once you have LDP you might as well do CR-LDP. </FONT>
<BR><FONT SIZE=2>We have also been planning to support an interworking strategy.</FONT>
</P>

<P><FONT SIZE=2>As far as customers many have expressed interest in CR-LDP </FONT>
<BR><FONT SIZE=2>and interworking with RSVP-TE will have to figure into that </FONT>
<BR><FONT SIZE=2>equation given the circumstances.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Don</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: James R. Leu [<A HREF="mailto:jleu@mindspring.com">mailto:jleu@mindspring.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, June 02, 2000 1:35 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kireeti Kompella; david.wang@metro-optix.com; mpls@UU.NET;</FONT>
<BR><FONT SIZE=2>&gt; vikramv25@yahoo.com</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: RSVP/CR-LDP interoperability</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Fri, Jun 02, 2000 at 10:29:03AM -0700, Kireeti Kompella wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; UUnet, Global Center, Level 3 and vBNS all use RSVP for signalling</FONT>
<BR><FONT SIZE=2>&gt; &gt; MPLS.&nbsp; To my knowledge, none of them use CR-LDP, but you'd have to</FONT>
<BR><FONT SIZE=2>&gt; &gt; ask them.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; There has been no interest from ISPs (as far as I know) in</FONT>
<BR><FONT SIZE=2>&gt; &gt; RSVP-CRLDP interoperability.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Kireeti.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No one is talking about because it tends to lead to religious wars.</FONT>
<BR><FONT SIZE=2>&gt; I have heard of models where RSVP-TE is used for signaling in the core</FONT>
<BR><FONT SIZE=2>&gt; and CR-LDP is used at the aggregation level.&nbsp; This may not be popular</FONT>
<BR><FONT SIZE=2>&gt; (yet) but it does have some benifits.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'm supprised no one has mentioned:</FONT>
<BR><FONT SIZE=2>&gt; draft-wright-mpls-crldp-rsvpte-iw-00.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Jim</FONT>
<BR><FONT SIZE=2>&gt; -- </FONT>
<BR><FONT SIZE=2>&gt; James R. Leu</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFCCBE.1502F592--


From owner-mpls@UU.NET  Fri Jun  2 14:20:36 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09008
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 14:20:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwj22210;
	Fri, 2 Jun 2000 18:20:30 GMT
Received: by mail-control.mail.uu.net 
	id QQirwj03356
	for mpls-outgoing; Fri, 2 Jun 2000 18:19:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirwj03347
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 18:19:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwj13704
	for <mpls@UU.NET>; Fri, 2 Jun 2000 14:19:11 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQirwj23684
	for <mpls@UU.NET>; Fri, 2 Jun 2000 18:19:11 GMT
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Fri, 2 Jun 2000 13:15:00 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <L3GPPLT5>; Fri, 2 Jun 2000 13:14:57 -0500
Message-ID: <BEF0F85DF631D311B1200000F80932F9010C5376@crchy28c.us.nortel.com>
From: "Badri Devalla" <bdevalla@nortelnetworks.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>, david.wang@metro-optix.com,
        mpls@UU.NET, vikramv25@yahoo.com
Subject: RE: RSVP/CR-LDP interoperability
Date: Fri, 2 Jun 2000 13:14:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCBE.74EC29B0"
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_01BFCCBE.74EC29B0
Content-Type: text/plain



> -----Original Message-----
> From:	Kireeti Kompella [SMTP:kireeti@juniper.net]
> UUnet, Global Center, Level 3 and vBNS all use RSVP for signalling
> MPLS.  To my knowledge, none of them use CR-LDP, but you'd have to
> ask them.
> 
> There has been no interest from ISPs (as far as I know) in
> RSVP-CRLDP interoperability.
> 
> Kireeti.
> 
	Please correct me if I am wrong as my intentions are not to start
religious wars:
	From San Diego MPLS Summit presentations by carriers, I thought that
the only implementations of MPLS were on networks with LSRs from a single
vendor - hence, inter-operability is probably not the right word here.

	So, how many carriers have say Vendor A's LSR using RSVP-TE talking
to Vendor B's LSR ?
	How may have CR-LDP in the same way (probably in Europe ?) ?

	And how many have RSVP-TE and CR-LDP on their networks ? (Probably
None)

	Thanks
	badri
-----
Badri Devalla, Ph.D.
IP & ATM Network Planning
Business & Network Consulting, Richardson
bdevalla@nortelnetworks.com
Tel: (972) 685 5174 (W)


------_=_NextPart_001_01BFCCBE.74EC29B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: RSVP/CR-LDP interoperability</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Kireeti Kompella =
[SMTP:kireeti@juniper.net]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">UUnet, Global Center, Level 3 and =
vBNS all use RSVP for signalling</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MPLS.&nbsp; To my knowledge, none of =
them use CR-LDP, but you'd have to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ask them.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There has been no interest from ISPs =
(as far as I know) in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RSVP-CRLDP interoperability.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Kireeti.</FONT><I></I><I></I>
</P>

<P><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Please correct me =
if I am wrong as my intentions are not to start religious =
wars:</FONT></I>
<BR><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">From San Diego =
MPLS Summit presentations by carriers, I thought that the only =
implementations of MPLS were on networks with LSRs from a single vendor =
- hence, inter-operability is probably not the right word =
here.</FONT></I></P>

<P><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So, how many =
carriers have say Vendor A's LSR using RSVP-TE talking to Vendor B's =
LSR ?</FONT></I>
<BR><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">How may have =
CR-LDP in the same way (probably in Europe ?) ?</FONT></I>
</P>

<P><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">And how many have =
RSVP-TE and CR-LDP on their networks ? (Probably None)</FONT></I>
</P>

<P><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Thanks</FONT></I>
<BR><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">badri</FONT></I>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Badri Devalla, Ph.D.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">IP &amp; ATM Network Planning</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Business &amp; Network Consulting, =
Richardson</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">bdevalla@nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Tel: (972) 685 5174 (W)</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFCCBE.74EC29B0--


From owner-mpls@UU.NET  Fri Jun  2 14:21:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09027
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 14:21:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwj23342;
	Fri, 2 Jun 2000 18:21:37 GMT
Received: by mail-control.mail.uu.net 
	id QQirwj03428
	for mpls-outgoing; Fri, 2 Jun 2000 18:20:59 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirwj03407
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 18:20:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirwj08839
	for <mpls@UU.NET>; Fri, 2 Jun 2000 14:20:29 -0400 (EDT)
Received: from mailhost.metro-optix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.metro-optix.com [63.91.47.254])
	id QQirwj22172
	for <mpls@UU.NET>; Fri, 2 Jun 2000 18:20:28 GMT
Received: by MAILHOST with Internet Mail Service (5.5.2650.21)
	id <LCAZV4FA>; Fri, 2 Jun 2000 13:20:34 -0500
Message-ID: <D7F6115661E9D311834F006008F5C83C0963DD@MAILHOST>
From: David Wang <david.wang@metro-optix.com>
To: "'erosen@cisco.com'" <erosen@cisco.com>,
        Santosh Gupta
	 <santoshgupta@poboxes.com>
Cc: mpls@UU.NET
Subject: RE: Ingress LER in LDP 
Date: Fri, 2 Jun 2000 13:20:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

One related question: How a LSR distinguishes a labeled packet from an
unlabeled packet? 

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com]
Sent: Thursday, June 01, 2000 9:28 AM
To: Santosh Gupta
Cc: mpls@UU.NET
Subject: Re: Ingress LER in LDP 


Santosh> Can someone tell me how to decide if a router is supposed to act as
Santosh> an Ingress LER for some particular FEC in MPLS domain ?

People keep asking  this question, and I'm never quite sure  just what it is
they are asking, because there isn't much of a mystery here.

If a router received an unlabeled  packet which belongs to a particular FEC,
and the next hop for that packet supports MPLS, and the router is configured
such that it is allowed to do allow label imposition for packets in that FEC
with that next hop, then the router should impose the label assigned to that
FEC by that next hop.

Does that answer your question? 


From owner-mpls@UU.NET  Fri Jun  2 14:43:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09539
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 14:43:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwk07771;
	Fri, 2 Jun 2000 18:42:49 GMT
Received: by mail-control.mail.uu.net 
	id QQirwk04548
	for mpls-outgoing; Fri, 2 Jun 2000 18:42:15 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirwk04543
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 18:41:59 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwk12487
	for <mpls@uu.net>; Fri, 2 Jun 2000 14:41:45 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQirwk11200
	for <mpls@uu.net>; Fri, 2 Jun 2000 18:41:44 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA20503
	for mpls@uu.net; Fri, 2 Jun 2000 14:41:43 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirwk04524
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 18:41:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwk12200
	for <mpls@uu.net>; Fri, 2 Jun 2000 14:40:21 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQirwk10006
	for <mpls@uu.net>; Fri, 2 Jun 2000 18:40:20 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24844; Fri, 2 Jun 2000 14:40:05 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAB16783;
	Fri, 2 Jun 2000 14:44:07 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000602142324.0467f5d0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 02 Jun 2000 14:39:21 -0400
To: mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Additional Index for TE-MIB: mplsTunnelTable
Cc: Cheenu Srinivasan <cheenu_s@yahoo.com>,
        arun Viswanathan <arun@force10networks.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_7281908==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_7281908==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


     Hi,
I would like to modify the mplsTunnelEntry to include
a few more objects as well as indexes. I wanted to
bring these changes to the list for discussion before
adding them to the TE MIB due to the fact that they
constitute a significant change, and we did not want to
surprise anyone. This change comes from my implementation
experience with the current version of the MIB, so it is
grounded in an actual implementation.

I would like to add five additional values to the mplsTunnelTable
as well as augment the current indexes with two more indexes:

mplsTunnelSrcAddrType     INTEGER,
mplsTunnelSrcAddrIPv4   InetAddresIPv4,
mplsTunnelSrcAddrIPv6   InetAddresIPv6,
      Now let me explain why. When you want to examine the tunnel
      entry at a midpoint, it is possible for tunnelId/tunnelInstance
      collisions to occur because the mplsTunnelId + mplsTunnelInstance
      variables are not guaranteed to be unique within an MPLS domain.
      A simple example of this occurs when LSR A has tunnelId = 1,
      tunnelInstance = 0 and LSR B has tunnelId = 1, tunnelInstance = 0
      which utilize the same next hop, LSR C. If one examines the
      tunnel table at LSR C, it is impossible to distinguish both tunnels;
      hence, the third index. A fourth index is required because we need
      to support V6 addresses.

      An additional benefit of the added indexes is that one can now
      sort tunnelEntries based on src address, which is quite useful
      at mid-points and tunnel tails. For this same reason, it might be
      useful to add the tunnel destination address to the indexes of
      this table as well.

      --Tom

--=====================_7281908==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
&nbsp;&nbsp;&nbsp; Hi,
<dl>
<dd>I would like to modify the mplsTunnelEntry to include 
<dd>a few more objects as well as indexes. I wanted to 
<dd>bring these changes to the list for discussion before 
<dd>adding them to the TE MIB due to the fact that they 
<dd>constitute a significant change, and we did not want to
<dd>surprise anyone. This change comes from my implementation 
<dd>experience with the current version of the MIB, so it is 
<dd>grounded in an actual implementation.<br>
<br>

<dd>I would like to add five additional values to the mplsTunnelTable
<dd>as well as augment the current indexes with two more indexes:<br>
<br>

<dd>mplsTunnelSrcAddrType&nbsp;&nbsp;&nbsp;&nbsp; INTEGER, 
<dd>mplsTunnelSrcAddrIPv4<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>InetAddresIPv4, 
<dd>mplsTunnelSrcAddrIPv6<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>InetAddresIPv6, 
</dl>&nbsp;&nbsp;&nbsp;&nbsp; Now let me explain why. When you want to
examine the tunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp; entry at a midpoint, it is possible for
tunnelId/tunnelInstance<br>
&nbsp;&nbsp;&nbsp;&nbsp; collisions to occur because the mplsTunnelId +
mplsTunnelInstance<br>
&nbsp;&nbsp;&nbsp;&nbsp; variables are not guaranteed to be unique within
an MPLS domain. <br>
&nbsp;&nbsp;&nbsp;&nbsp; A simple example of this occurs when LSR A has
tunnelId = 1, <br>
&nbsp;&nbsp;&nbsp;&nbsp; tunnelInstance = 0 and LSR B has tunnelId = 1,
tunnelInstance = 0<br>
&nbsp;&nbsp;&nbsp;&nbsp; which utilize the same next hop, LSR C. If one
examines the <br>
&nbsp;&nbsp;&nbsp;&nbsp; tunnel table at LSR C, it is impossible to
distinguish both tunnels;<br>
&nbsp;&nbsp;&nbsp;&nbsp; hence, the third index. A fourth index is
required because we need <br>
&nbsp;&nbsp;&nbsp;&nbsp; to support V6 addresses.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; An additional benefit of the added indexes is
that one can now<br>
&nbsp;&nbsp;&nbsp;&nbsp; sort tunnelEntries based on src address, which
is quite useful<br>
&nbsp;&nbsp;&nbsp;&nbsp; at mid-points and tunnel tails. For this same
reason, it might be<br>
&nbsp;&nbsp;&nbsp;&nbsp; useful to add the tunnel destination address to
the indexes of<br>
&nbsp;&nbsp;&nbsp;&nbsp; this table as well.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp; --Tom<br>
</html>

--=====================_7281908==_.ALT--




From owner-mpls@UU.NET  Fri Jun  2 14:44:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09562
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 14:44:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwk13214;
	Fri, 2 Jun 2000 18:44:20 GMT
Received: by mail-control.mail.uu.net 
	id QQirwk04590
	for mpls-outgoing; Fri, 2 Jun 2000 18:43:42 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirwk04574
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 18:43:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwk17877
	for <mpls@uu.net>; Fri, 2 Jun 2000 14:43:13 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQirwk12306
	for <mpls@uu.net>; Fri, 2 Jun 2000 18:43:13 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id NAA05632;
	Fri, 2 Jun 2000 13:43:11 -0500
Message-ID: <20000602134311.J5253@doit.wisc.edu>
Date: Fri, 2 Jun 2000 13:43:11 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: David Wang <david.wang@metro-optix.com>
Cc: mpls@UU.NET
Subject: Re: Ingress LER in LDP
Reply-To: jleu@mindspring.com
References: <D7F6115661E9D311834F006008F5C83C0963DD@MAILHOST>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <D7F6115661E9D311834F006008F5C83C0963DD@MAILHOST>; from David Wang on Fri, Jun 02, 2000 at 01:20:33PM -0500
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, Jun 02, 2000 at 01:20:33PM -0500, David Wang wrote:
> One related question: How a LSR distinguishes a labeled packet from an
> unlabeled packet? 

Depends on the medium:
-ATM the VCC will contain a protcol type (AAL5Null requires this)
-POS the ether type will be 0x8847 or 0x8848 (as oppsed to 0x0800 for IP)
-PPP has some PIDs assigned for MPLS as well (as does IP)

Hope this helps.

Jim

> 
> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Thursday, June 01, 2000 9:28 AM
> To: Santosh Gupta
> Cc: mpls@UU.NET
> Subject: Re: Ingress LER in LDP 
> 
> 
> Santosh> Can someone tell me how to decide if a router is supposed to act as
> Santosh> an Ingress LER for some particular FEC in MPLS domain ?
> 
> People keep asking  this question, and I'm never quite sure  just what it is
> they are asking, because there isn't much of a mystery here.
> 
> If a router received an unlabeled  packet which belongs to a particular FEC,
> and the next hop for that packet supports MPLS, and the router is configured
> such that it is allowed to do allow label imposition for packets in that FEC
> with that next hop, then the router should impose the label assigned to that
> FEC by that next hop.
> 
> Does that answer your question? 

-- 
James R. Leu


From owner-mpls@UU.NET  Fri Jun  2 15:07:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10029
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 15:07:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwm00505;
	Fri, 2 Jun 2000 19:07:13 GMT
Received: by mail-control.mail.uu.net 
	id QQirwm15204
	for mpls-outgoing; Fri, 2 Jun 2000 19:06:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirwm15193
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 19:06:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirwm21723
	for <mpls@UU.NET>; Fri, 2 Jun 2000 15:06:17 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQirwm23840
	for <mpls@UU.NET>; Fri, 2 Jun 2000 19:06:16 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Fri, 2 Jun 2000 14:02:04 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <LW2CB5MM>; Fri, 2 Jun 2000 14:01:52 -0500
Message-ID: <436B46B78BADD311A2280000F80829740BCAD2@zstld00a.ca.nortel.com>
From: "Ian Towers" <itowers@nortelnetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Recall:
Date: Fri, 2 Jun 2000 14:01:54 -0500
Expiry-Date: Sun, 4 Jun 2000 14:03:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCCC5.022352DA"
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_01BFCCC5.022352DA
Content-Type: text/plain

Towers, Ian [BAN:0966:EXCH] would like to recall the message, "".

------_=_NextPart_001_01BFCCC5.022352DA
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>Recall: </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Towers, Ian [BAN:0966:EXCH] would like to recall the message, &quot;&quot;.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFCCC5.022352DA--


From owner-mpls@UU.NET  Fri Jun  2 15:12:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10334
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 15:12:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwm27731;
	Fri, 2 Jun 2000 19:11:50 GMT
Received: by mail-control.mail.uu.net 
	id QQirwm15695
	for mpls-outgoing; Fri, 2 Jun 2000 19:11:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirwm15612
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 19:11:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwm22537
	for <mpls@UU.NET>; Fri, 2 Jun 2000 15:10:37 -0400 (EDT)
Received: from mailcarrier.snv1.gctr.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailcarrier.snv1.gctr.net [206.251.8.19])
	id QQirwm03231
	for <mpls@UU.NET>; Fri, 2 Jun 2000 19:10:37 GMT
Received: from pobox.snv1.gctr.net (pobox.snv1.gctr.net [204.71.194.242])
	by mailcarrier.snv1.gctr.net (8.9.3/8.9.0) with ESMTP id TAA12450;
	Fri, 2 Jun 2000 19:10:35 GMT
Received: (from dcooper@localhost)
	by pobox.snv1.gctr.net (8.9.3/8.9.3) id TAA08165;
	Fri, 2 Jun 2000 19:08:41 GMT
Date: Fri, 2 Jun 2000 19:08:41 +0000
From: Dave Cooper <dcooper@globalcenter.net>
To: Badri Devalla <bdevalla@nortelnetworks.com>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>, david.wang@metro-optix.com,
        mpls@UU.NET, vikramv25@yahoo.com
Subject: Re: RSVP/CR-LDP interoperability
Message-ID: <20000602190841.A6821@globalcenter.net>
References: <BEF0F85DF631D311B1200000F80932F9010C5376@crchy28c.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: Badri Devalla's message from Fri, Jun 02, 2000 at 01:14:53PM - ID <BEF0F85DF631D311B1200000F80932F9010C5376@crchy28c.us.nortel.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

GlobalCrossing (Globalcenter) has more than one vendor interoperating 
in the same MPLS domain, exchanging RSVP-TE extensions and acting as 
headend and midrole LSRs w/ thousands of LSPs in production.  

No RSVP-TE/CR-LDP yet.. but no reasons to...

dave

 

Badri Devalla expulged the following plethora of useful knowledge:
-> 
-> 
-> > -----Original Message-----
-> > From:	Kireeti Kompella [SMTP:kireeti@juniper.net]
-> > UUnet, Global Center, Level 3 and vBNS all use RSVP for signalling
-> > MPLS.  To my knowledge, none of them use CR-LDP, but you'd have to
-> > ask them.
-> > 
-> > There has been no interest from ISPs (as far as I know) in
-> > RSVP-CRLDP interoperability.
-> > 
-> > Kireeti.
-> > 
-> 	Please correct me if I am wrong as my intentions are not to start
-> religious wars:
-> 	From San Diego MPLS Summit presentations by carriers, I thought that
-> the only implementations of MPLS were on networks with LSRs from a single
-> vendor - hence, inter-operability is probably not the right word here.
-> 
-> 	So, how many carriers have say Vendor A's LSR using RSVP-TE talking
-> to Vendor B's LSR ?
-> 	How may have CR-LDP in the same way (probably in Europe ?) ?
-> 
-> 	And how many have RSVP-TE and CR-LDP on their networks ? (Probably
-> None)
-> 
-> 	Thanks
-> 	badri
-> -----
-> Badri Devalla, Ph.D.
-> IP & ATM Network Planning
-> Business & Network Consulting, Richardson
-> bdevalla@nortelnetworks.com
-> Tel: (972) 685 5174 (W)
-> 


From owner-mpls@UU.NET  Fri Jun  2 16:17:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12302
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 16:17:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwr16599;
	Fri, 2 Jun 2000 20:16:41 GMT
Received: by mail-control.mail.uu.net 
	id QQirwr00084
	for mpls-outgoing; Fri, 2 Jun 2000 20:16:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQirwr00048
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 20:15:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirwr29021
	for <mpls@UU.NET>; Fri, 2 Jun 2000 16:15:29 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQirwr13346
	for <mpls@UU.NET>; Fri, 2 Jun 2000 20:15:28 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id PAA00076;
	Fri, 2 Jun 2000 15:15:25 -0500 (CDT)
Received: from vsharma ([172.31.101.68] (may be forged))
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id PAA05704;
	Fri, 2 Jun 2000 15:15:26 -0500 (CDT)
Received: by localhost with Microsoft MAPI; Fri, 2 Jun 2000 16:19:53 -0400
Message-ID: <01BFCCAE.628EE150.Vishal.Sharma@tellabs.com>
From: Vishal Sharma <Vishal.Sharma@tellabs.com>
Reply-To: "Vishal.Sharma@tellabs.com" <Vishal.Sharma@tellabs.com>
To: "'dallan@nortelnetworks.com'" <dallan@nortelnetworks.com>,
        "Ben.Mack-Crane@tellabs.com" <Ben.Mack-Crane@tellabs.com>
Cc: "mpls@UU.NET" <mpls@UU.NET>,
        "Srinivas.Makam@tellabs.com"
	 <Srinivas.Makam@tellabs.com>,
        "Changcheng.Huang@tellabs.com"
	 <Changcheng.Huang@tellabs.com>,
        "Ken.Owens@tellabs.com"
	 <Ken.Owens@tellabs.com>
Subject: RE: draft-chang-mpls-path-protection Comments
Date: Fri, 2 Jun 2000 16:19:52 -0400
Organization: Tellabs Research Center
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Dave,

On Friday, June 02, 2000 2:09 PM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] wrote:
> Vishal:
> 
> I was thinking of decomposing (i). There needs to be a way to discuss the
> constituent tributaries in what you call a "true multi-point LSP". The
> abstract entity you refer to in (ii) would seem to be more akin to an I.630
> VP/CG where a group of LSPs shares a common OAM trail (and which I think
> doing that in a signalled fashion is somewhat intractable), this is a bit
> different, in that they not only would share a trail, but label forwarding
> space.

I see your point regarding (i), and agree that the additional terminology will
make it possible to talk of the tributaries separately from the LST.
I am not so sure about not being able to signal the virtually merged LSPs,
however, since we are in the process of writing a draft that extends 
RSVP-TE for path protection, and addresses the virtually merged LSP
case. (We'll send you a copy in a few days, once it's finalized, and would
appreciate your feedback. Perhaps, we have overlooked something.)

> If I adopt the LST/LSP distinction for (i) then....
> 
> My motivation is that a failure in an LST (a.k.a. (i)) does not require that
> all constituent LSPs switch, only those upstream of the failure. Most would
> be unaffected and it would be desirable to leave them alone from the point
> of view of network stability (if it aint broke....). Those that were
> affected by the failure do not require a strategy that is in any way
> coordinated with the other failed or still working LSPs as the natual LST
> grouping really has no meaning once that particular topology configuration
> has failed (the LSP/LST linkage broke). Currently this is difficult to
> discuss clearly. That is what I would like to address...

I agree. In fact,  spirit of our description also was the same, but we didn't get
the terminology pinned precisely.  I think adding this distinction will address your 
concern, and make it easier to refer to things unambiguously. In fact, I'd invite you to send
us some suggested text to add to our draft to take care of this, which we'll be happy
to include that our the revision.

-Vishal


> > -----Original Message-----
> 	<snip>
> > There are actually two cases here:
> > 
> > (i) A true multipoint-to-point LSP, which means traffic labeled with
> > distinct
> > incoming labels on the ingress links is assigned the same label (one
> > label) on the egress link. In this case, the LSP and the tree it is
> > overlaid
> > on are isomorphic.
> > 
> > (ii) A collection of p2p LSPs, all of which terminate at the same
> > destination,
> > and happen to share a route from some point on (we call such LSPs
> > "virtually merged" (a term one of my co-authors came up with)). In this
> > case, any given LSP is overlaid upon a portion of the tree (where the
> > "tree"
> > is an abstract entity consisting of all the links that all of these LSPs
> > traverse).
> > 
> > In our mechanism draft, we were initially thinking only of (i), so we
> > though we did not need the distinction between the LSP and the tree (we
> > know now
> > that (ii) is equally easily covered by our mechanism). Our thinking was
> > that, depending 
> > on where the fault was, either all sources (more precisely PSLs) or some
> > of subset them would switch to a backup path (after the affected PSLs
> > were notified of the fault).
> > 
> > I realize now that there is a problem with the above reasoning as well,
> > since,
> > for some types of faults, only a portion of the (point-to-multipoint) LSP
> > could be switched 
> > to a protection path, and we did not have terminology to make this clear.
> > 
> > About the retrofitting... I guess we'd need to do that in the upcoming
> > revision. If you
> > see some issues with doing that, please let us know.
> > 
> > -Vishal
> > 
> > 
>  << File: ATT00012.html >> 


From owner-mpls@UU.NET  Fri Jun  2 17:08:44 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14357
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 17:08:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirwu28176;
	Fri, 2 Jun 2000 21:08:39 GMT
Received: by mail-control.mail.uu.net 
	id QQirwu12588
	for mpls-outgoing; Fri, 2 Jun 2000 21:08:08 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQirwu12576
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 21:08:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirwu08230
	for <mpls@uu.net>; Fri, 2 Jun 2000 17:07:44 -0400 (EDT)
Received: from relay1.nce.smtp.psi.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: relay1.nce.smtp.psi.net [38.9.152.2])
	id QQirwu27249
	for <mpls@uu.net>; Fri, 2 Jun 2000 21:07:44 GMT
Received: from [38.170.20.5] (helo=postoffice.opticworks.com)
	by relay1.nce.smtp.psi.net with esmtp (Exim 3.13 #3)
	id 12xyfM-0001Cp-00
	for mpls@UU.net; Fri, 02 Jun 2000 17:07:40 -0400
Received: by opticworks.com with Internet Mail Service (5.5.2650.21)
	id <MA6KP6K1>; Fri, 2 Jun 2000 14:07:09 -0700
Message-ID: <5325CE3D64E3D31184B1009027DDD26F010C8F41@caems1.opticworks.com>
From: Anil Rao <ARao@oni.com>
To: "'mpls@UU.net'" <mpls@UU.NET>
Subject: draft-lang-mpls-lmp-00.txt
Date: Fri, 2 Jun 2000 14:07:06 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all,

	Is any work going on in the above draft ?  I am interested in
participating/contributing to that.  Please let me know.

thanks, anil.


From owner-mpls@UU.NET  Fri Jun  2 17:41:40 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15466
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 17:41:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirww24898;
	Fri, 2 Jun 2000 21:41:26 GMT
Received: by mail-control.mail.uu.net 
	id QQirww14703
	for mpls-outgoing; Fri, 2 Jun 2000 21:40:49 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQirww14691
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 21:40:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQirww16604
	for <mpls@UU.NET>; Fri, 2 Jun 2000 17:40:25 -0400 (EDT)
Received: from lux.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [207.71.195.17])
	id QQirww09540
	for <mpls@UU.NET>; Fri, 2 Jun 2000 21:40:24 GMT
Received: by LUX with Internet Mail Service (5.5.2448.0)
	id <M1T96S56>; Fri, 2 Jun 2000 14:40:22 -0700
Message-ID: <51DA0AB3D747D311832F005004827CC013E64B@LUX>
From: Jonathan Lang <jplang@calient.net>
To: "'Anil Rao'" <ARao@oni.com>, "'mpls@UU.net'" <mpls@UU.NET>
Subject: RE: draft-lang-mpls-lmp-00.txt
Date: Fri, 2 Jun 2000 14:40:21 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Anil,
  We are currently working on an updated version with more details including
message formats and FSMs.  I will be happy to send you a copy after its
quasi-stabilized (with modifications based on input from the other authors).
Comments are always appreciated.

Regards,
Jonathan

Jonathan P. Lang
Calient Networks
jplang@calient.net                   

> -----Original Message-----
> From: Anil Rao [mailto:ARao@oni.com]
> Sent: Friday, June 02, 2000 2:07 PM
> To: 'mpls@UU.net'
> Subject: draft-lang-mpls-lmp-00.txt
> 
> 
> Hi all,
> 
> 	Is any work going on in the above draft ?  I am interested in
> participating/contributing to that.  Please let me know.
> 
> thanks, anil.
> 


From owner-mpls@UU.NET  Fri Jun  2 21:27:28 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18209
	for <mpls-archive@lists.ietf.org>; Fri, 2 Jun 2000 21:27:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirxe06414;
	Fri, 2 Jun 2000 23:36:26 GMT
Received: by mail-control.mail.uu.net 
	id QQirxe13210
	for mpls-outgoing; Fri, 2 Jun 2000 23:36:09 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirxe13143
	for <mpls@mail-control.mail.uu.net>; Fri, 2 Jun 2000 23:35:57 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirxe29285
	for <mpls@UU.NET>; Fri, 2 Jun 2000 19:35:39 -0400 (EDT)
Received: from hork.mrv.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uunet-hork.mrv.com [208.195.192.3])
	id QQirxe05840
	for <mpls@UU.NET>; Fri, 2 Jun 2000 23:35:38 GMT
Received: from chris (ok.mrv.com [208.195.192.2])
	by hork.mrv.com (8.10.1/8.10.0) with SMTP id e52NSWr09636;
	Fri, 2 Jun 2000 16:28:32 -0700
X-Authentication-Warning: hork.mrv.com: Host ok.mrv.com [208.195.192.2] claimed to be chris
From: "Chris LaVallee" <clavallee@zumanetworks.com>
To: <jleu@mindspring.com>, "David Wang" <david.wang@metro-optix.com>
Cc: <mpls@UU.NET>
Subject: RE: Ingress LER in LDP
Date: Fri, 2 Jun 2000 16:29:09 -0700
Message-ID: <001801bfccea$5a6d7680$a701a8c0@internal.nbase.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <20000602134311.J5253@doit.wisc.edu>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> -POS the ether type will be 0x8847 or 0x8848 (as oppsed to 0x0800 for IP)

This might be off topic, but...

How do you get an ethertype over POS ? 
I'm guessing it's Cisco-HDLC (which I know nothing about)

PPP over POS has 2 other possibilities to carry MPLS
- Add a new CP (control proto) for MPLS
- Have BCP (PPP Bridging) carry MPLS

Anyone have a preference / opinion on what people should use ?

Chris




> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of James R.
> Leu
> Sent: Friday, June 02, 2000 11:43 AM
> To: David Wang
> Cc: mpls@UU.NET
> Subject: Re: Ingress LER in LDP
> 
> 
> On Fri, Jun 02, 2000 at 01:20:33PM -0500, David Wang wrote:
> > One related question: How a LSR distinguishes a labeled packet from an
> > unlabeled packet? 
> 
> Depends on the medium:
> -ATM the VCC will contain a protcol type (AAL5Null requires this)
> -POS the ether type will be 0x8847 or 0x8848 (as oppsed to 0x0800 for IP)
> -PPP has some PIDs assigned for MPLS as well (as does IP)
> 
> Hope this helps.
> 
> Jim
> 
> > 
> > -----Original Message-----
> > From: Eric Rosen [mailto:erosen@cisco.com]
> > Sent: Thursday, June 01, 2000 9:28 AM
> > To: Santosh Gupta
> > Cc: mpls@UU.NET
> > Subject: Re: Ingress LER in LDP 
> > 
> > 
> > Santosh> Can someone tell me how to decide if a router is 
> supposed to act as
> > Santosh> an Ingress LER for some particular FEC in MPLS domain ?
> > 
> > People keep asking  this question, and I'm never quite sure  
> just what it is
> > they are asking, because there isn't much of a mystery here.
> > 
> > If a router received an unlabeled  packet which belongs to a 
> particular FEC,
> > and the next hop for that packet supports MPLS, and the router 
> is configured
> > such that it is allowed to do allow label imposition for 
> packets in that FEC
> > with that next hop, then the router should impose the label 
> assigned to that
> > FEC by that next hop.
> > 
> > Does that answer your question? 
> 
> -- 
> James R. Leu
> 


From owner-mpls@UU.NET  Sat Jun  3 00:58:59 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22038
	for <mpls-archive@lists.ietf.org>; Sat, 3 Jun 2000 00:58:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQirxz22531;
	Sat, 3 Jun 2000 04:58:22 GMT
Received: by mail-control.mail.uu.net 
	id QQirxz20963
	for mpls-outgoing; Sat, 3 Jun 2000 04:57:49 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQirxz20950
	for <mpls@mail-control.mail.uu.net>; Sat, 3 Jun 2000 04:57:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQirxz00563
	for <mpls@uu.net>; Sat, 3 Jun 2000 00:57:21 -0400 (EDT)
Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQirxz10569
	for <mpls@uu.net>; Sat, 3 Jun 2000 04:57:09 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000603384@fsnt.future.futusoft.com>;
 Sat, 03 Jun 2000 10:38:09 +0530
Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA25916; Sat, 3 Jun 2000 10:28:47 +0530
Received: by localhost with Microsoft MAPI; Sat, 3 Jun 2000 10:20:19 +0530
Message-Id: <01BFCD45.519DD940.manis@future.futsoft.com>
From: manikantan <manis@future.futsoft.com>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>, "mpls@uu.net" <mpls@UU.NET>
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable
Date: Sat, 3 Jun 2000 10:20:19 +0530
Importance: high
X-Priority: 1 (Highest)
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Hello Thomas 

#Hi,
#I would like to modify the mplsTunnelEntry to include
#a few more objects as well as indexes. I wanted to
#bring these changes to the list for discussion before
#adding them to the TE MIB due to the fact that they
#constitute a significant change, and we did not want to
#surprise anyone. This change comes from my implementation
#experience with the current version of the MIB, so it is
#grounded in an actual implementation.
#
#I would like to add five additional values to the mplsTunnelTable
#as well as augment the current indexes with two more indexes:

mani> Hope you have not mentioned the five additional values in 
this mail, as I could not see it. Are you providing these five
additional values in an another mail?

#
#mplsTunnelSrcAddrType     INTEGER,
#mplsTunnelSrcAddrIPv4   InetAddresIPv4,
#mplsTunnelSrcAddrIPv6   InetAddresIPv6,

mani> You have listed here three objects, whereas above you 
have mentioned of two more indexes. Does the above three form
index to the TE Tunnel table or the "mplsTunnelSrcAddrIPv4" and
"mplsTunnelSrcAddrIpv6" are the two indexes in addition to the
earlier indexes of "mplsTunnelIndex" and "mplsTunnelInstance"?

#      Now let me explain why. When you want to examine the tunnel
#      entry at a midpoint, it is possible for tunnelId/tunnelInstance
#      collisions to occur because the mplsTunnelId + mplsTunnelInstance
#      variables are not guaranteed to be unique within an MPLS domain.
#      A simple example of this occurs when LSR A has tunnelId = 1,
#      tunnelInstance = 0 and LSR B has tunnelId = 1, tunnelInstance = 0
#      which utilize the same next hop, LSR C. If one examines the
#      tunnel table at LSR C, it is impossible to distinguish both tunnels;
#      hence, the third index. A fourth index is required because we need
#      to support V6 addresses.
#
#      An additional benefit of the added indexes is that one can now
#      sort tunnelEntries based on src address, which is quite useful
#      at mid-points and tunnel tails. For this same reason, it might be
#      useful to add the tunnel destination address to the indexes of
#      this table as well.
#
#      --Tom

mani> To me the added indexes of Source address is valid and acceptable
as we found during our implementation that the triplet < Tunnel index,
Tunnel Instance and Source address> alone forms/identifies a unique
tunnel and not just the <Tunnel index and the Tunnel Instance>

Regarding the Destination Address as an index, this is not required to 
be added as index but can be added as a value/field in the MplsTunnelEntry.
Reason: A tunnel can be uniquely identified with the triplet < Tunnel index,
Tunnel Instance and Source address>. The Destination address present
will give added information as to what is the end point of the Tunnel

Following are some of my thoughts/doubts, which I have when I apply
the TE MIB with respect to both RSVP-TE Tunnels and CRLDP (CRLSP Paths).

I feel that the TE MIB fits perfectly with the RSVP-TE Tunnel extensions.
Reasons being, The indexes to identify a unique Tunnel 
1) Tunnel ID
2) Tunnel Instance
3) Tunnel Ingress Address ( or Source address either IPv4 or IPv6) 
are available in the RSVP objects.

The LSP_TUNNEL_IPv4 Session Object helps carrying the Tunnel Id and the
Tunnel Ingress Address (IPv4 address)in the Extended Tunnel Id field.

The LSP_TUNNEL_IPv6 Session Object helps carrying the Tunnel ID and the 
Tunnel Ingress Address (IPv6 address) in the Extended Tunnel Id field.

The LSP_TUNNEL_IPv4 Sender Template object helps carrying the
Tunnel Instance in the LSP ID field In case of IPv4 Tunnel, similarly the 
LSP_TUNNEL_IPv6 Sender Template object helps carrying the Tunnel Instance 
in the LSPID field incase of IPv6 tunnels.
(Here I have assumed the Tunnel instance mapped to the LSP Id)

In case of CRLSP the values carried in the TLVs does not map to the TE MIB
directly ( Or I might be missing out something and not clear).

The LSPID-TLV helps carrying the Tunnel ID in the "Local CR-LSP ID" field
and the Ingress LSR Router ID helps carrying the Tunnel Ingress Address.
Current specifications does not deal with the "Tunnel Instances" that
is dealt in the TE MIB. 

Hence my doubts are:
1) Should the Tunnel Instance be always treated as "0" when CRLSP tunnels are 
made?

2) Is it that the LSPID-TLV has Action flag to indicate modification of the 
Tunnel, it is not required to identify instances in CRLSP? Reason : The usage
of instance (When the instance value is mapped to the LSP_ID of the Sender
Template object) is sending indication for reroutes in RSVP?.

3) Since the LSPID-TLV in <draft-ietf-mpls-crldp-03.txt> provides support
for only IPV4 node initiated tunnels, modification will/may be required 
as follows:

LSPID-TLV 1 : IPv4 Sender

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|  LSPID-TLV-IPV4 (0x0821)  |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved        |ActFlg |      Local CR-LSP ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Ingress LSR Router ID  - IPv4 Address           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
        A fourteen-bit field carrying the value of the  LSPID-TLV-IPV4 type
        which is 0x821.

   Length
        Specifies the length of the value field in bytes.

   ActFlg
        Action Indicator Flag: A 4-bit field that indicates explicitly
        the action that should be taken if the LSP already exists on
        the LSR receiving the message. A set of indicator code points
        is proposed as follows:

                0000: indicates initial LSP setup
                0001: indicates modify LSP
   Reserved
        Zero on transmission.  Ignored on receipt.

   Local CR-LSP ID
        The Local LSP ID is an identifier of the CR-LSP locally unique
        within the Ingress LSR originating the CR-LSP.

   Ingress LSR Router ID
        An LSR may use any of its own IPv4 addresses in this field.

 
LSPID-TLV 2 : IPv6 Sender

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|  LSPID-TLV-IPV6 (0x0822)  |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved        |ActFlg |      Local CR-LSP ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Ingress LSR Router ID  - IPv6 Address           |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
        A fourteen-bit field carrying the value of the  LSPID-TLV-IPV6 type
        which is 0x822.

   Length
        Specifies the length of the value field in bytes.

   ActFlg
        Action Indicator Flag: A 4-bit field that indicates explicitly
        the action that should be taken if the LSP already exists on
        the LSR receiving the message. A set of indicator code points
        is proposed as follows:

                0000: indicates initial LSP setup
                0001: indicates modify LSP
   Reserved
        Zero on transmission.  Ignored on receipt.

   Local CR-LSP ID
        The Local LSP ID is an identifier of the CR-LSP locally unique
        within the Ingress LSR originating the CR-LSP.

   Ingress LSR Router ID
        An LSR may use any of its own IPv6 addresses in this field.

4) The destination address (IPv4 or IPv6) can be carried in the RSVP-TE
objects - LSP_TUNNEL_SESSION_IPv4 or LSP_TUNNEL_SESSION_IPv6 respectively.
However in the case of CRLSP such a provision is not available. Hence 
support for this needs to be added in CRLDP too, to enable 
 a) TE MIB to be used for both CRLSP Tunnel and RSVP-TE tunnels
 b) Easy interworking of CRLSP and RSVP-TE Tunnels.

Above are my humble thoughts, 

thanks in advance
with best regards
mani
 
/*-------------------------------------------------------------------*/
S.Manikantan
Future Software Private Limited
480-481, Anna salai, Nandanam,
Chennai, Tamil Nadu, 600 035,
India.
Phone	: +91-44-4330550
Fax	: +91-44-4344157.
Email	: manis@future.futsoft.com
http://www.futsoft.com
/*--------------------------------------------------------------------*/


From owner-mpls@UU.NET  Sun Jun  4 21:33:49 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10941
	for <mpls-archive@lists.ietf.org>; Sun, 4 Jun 2000 21:33:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisew21320;
	Mon, 5 Jun 2000 01:33:39 GMT
Received: by mail-control.mail.uu.net 
	id QQisew07087
	for mpls-outgoing; Mon, 5 Jun 2000 01:33:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisew07080
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 01:33:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisew07143
	for <mpls@uu.net>; Sun, 4 Jun 2000 21:32:53 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisew19613
	for <mpls@uu.net>; Mon, 5 Jun 2000 01:32:51 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA11470
	for mpls@uu.net; Sun, 4 Jun 2000 21:32:51 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisew07050
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 01:32:16 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisew21210
	for <mpls@UU.NET>; Sun, 4 Jun 2000 21:32:11 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQisew19318
	for <mpls@UU.NET>; Mon, 5 Jun 2000 01:32:10 GMT
Received: from localhost (yakov@localhost)
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA19225;
	Sun, 4 Jun 2000 18:25:22 -0700 (PDT)
Message-Id: <200006050125.SAA19225@omega.cisco.com>
To: jleu@mindspring.com
cc: Kireeti Kompella <kireeti@juniper.net>, david.wang@metro-optix.com,
        mpls@UU.NET, vikramv25@yahoo.com
Subject: Re: RSVP/CR-LDP interoperability 
In-reply-to: Your message of "Fri, 02 Jun 2000 12:35:08 CDT."
             <20000602123508.F5253@doit.wisc.edu> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19223.960168321.1@cisco.com>
Date: Sun, 04 Jun 2000 18:25:21 -0700
From: Yakov Rekhter <yakov@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Jim,

> On Fri, Jun 02, 2000 at 10:29:03AM -0700, Kireeti Kompella wrote:
> > UUnet, Global Center, Level 3 and vBNS all use RSVP for signalling
> > MPLS.  To my knowledge, none of them use CR-LDP, but you'd have to
> > ask them.
> > 
> > There has been no interest from ISPs (as far as I know) in
> > RSVP-CRLDP interoperability.
> > 
> > Kireeti.
> 
> No one is talking about because it tends to lead to religious wars.
> I have heard of models where RSVP-TE is used for signaling in the core
> and CR-LDP is used at the aggregation level.  This may not be popular
> (yet) but it does have some benifits.

Would you please say more on what would be these benefits.

Yakov.



From owner-mpls@UU.NET  Mon Jun  5 00:45:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14030
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 00:45:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisfi09365;
	Mon, 5 Jun 2000 04:44:29 GMT
Received: by mail-control.mail.uu.net 
	id QQisfi17508
	for mpls-outgoing; Mon, 5 Jun 2000 04:44:10 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisfi17500
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 04:44:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisfi26933
	for <mpls@UU.NET>; Mon, 5 Jun 2000 00:43:41 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQisfi19542
	for <mpls@UU.NET>; Mon, 5 Jun 2000 04:42:55 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id KAA09064;
	Mon, 5 Jun 2000 10:04:02 -0600 (GMT)
Message-ID: <00b401bfcea8$0a9c3460$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <erosen@cisco.com>
Cc: <mpls@UU.NET>
References: <200006021532.LAA27259@erosen-sun.cisco.com>
Subject: Re: Ingress LER in LDP 
Date: Mon, 5 Jun 2000 10:09:25 +0530
Organization: Daewoo Telecom
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 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Eric
    Please see comments inline.
santosh

>
> Santosh> Actually an LSR needs  to know if it is an Ingress  LSR for the
FEC
> Santosh> or not.  Depending  on this decision, it has to  make a binding
for
> Santosh> forwarding (FEC---->label)  in the  forwarding module. It  would
be
> Santosh> very inefficient to  make this binding in core  routers which
never
> Santosh> do any forwarding but just switching.
>
> I think the only  case where this could possibly be an  issue is the case
of
> an ATM-LSR which doesn't support VC  merge.  Is that the case you're
focused
> on?

Actually this doesnt depend on VC merging capability of an ATM-LSR. The
issue is whether I should have any entry in the ATM-LSR for FEC->>Label
mapping. Let me depict it.

A---->B----->C----->D ....            E
                  /
                Customer

Suppose an LSP is formed from A to E with A as Ingress LER and E as Egress
LER. The LSP passes thru C. There is yet another customer who wishes to
connect at C and send data to for the same FEC. So there is a need for the
FEC--->Label mapping at A and C. Whether C merges the 2 LSPs or sets up
seperate LSP doesnt matter.


>It is an implementation detail  as to what external information it uses
> Jim> to make that decision.
>
> I think Jim  Leu's answer is correct.  I would  probably say "product
design
> decision" rather than "implementation detail".
>
>
>
>



From owner-mpls@UU.NET  Mon Jun  5 04:46:37 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27237
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 04:46:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisfz24670;
	Mon, 5 Jun 2000 08:46:23 GMT
Received: by mail-control.mail.uu.net 
	id QQisfz09837
	for mpls-outgoing; Mon, 5 Jun 2000 08:45:49 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisfz09829
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 08:45:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisfz07822
	for <mpls@UU.NET>; Mon, 5 Jun 2000 04:45:24 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQisfz24016
	for <mpls@UU.NET>; Mon, 5 Jun 2000 08:45:23 GMT
Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP;
          Mon, 5 Jun 2000 09:27:26 +0100
Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2651.88) 
          id <MCGW57SR>; Mon, 5 Jun 2000 09:27:31 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16002@mbddmknt01.hc.bt.com>
To: EGray@zaffire.com, swtan@mmu.edu.my, kireeti@juniper.net,
        dwilder@baynetworks.com, Shahram_Davari@pmc-sierra.com
Cc: mpls@UU.NET
Subject: RE: can egress know the ingress of a packet?
Date: Mon, 5 Jun 2000 09:27:31 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Here's one reason why a network operator might want to know the LSP
source..................

IP addresses must be absolute since a CNLS forwarding regime is 'memoryless'
on a link by link basis.  Further, when used in the Internet the absolute
addresses must also be globally unique (or in the case of private internets,
private-network-wide unique). 

Compare this now to label forwarding.  This requires an a priori set of
user-plane connections (not necessarily BW reservations) to be set up, ie
LSPs, as determined by the FEC/IGP control-plane for the basic LDP case, or
via some other route determination method outside the IGP for a TE case say.
Labels are relative addresses that by definition are not globally unique,
and indeed they only need to be unique per interface on a link basis.

With absolute addresses sent in some form of temporally deterministic
keepalive one can detect/diagnose all cases of connectivity defects, eg
breaks, swappped connections, mismerging between different connections, self
mismerging (aka looping).  So the IP layer is OK in handling these defects
to a large extent (there are some subtle issues of control-plane vs
user-plane defect detection and the span of the defect detection mechanisim,
which I don't want to get into here as they are 2nd order to the main
point).

The handing of all of these types of connectivity defect is not clear in
MPLS.  We do, however, have the TTL field in the MPLS OH, but this not a
defect detection/diagnosis tool but rather a "damage limitation mechanism".
Further, it is relevant only for the specific case of self mismerged LSPs in
the MPLS layer (*not* the IP layer please note).  So currently we have no
method for a network operator to detect/diagnose connectivity failures which
could, for example, result in one customer's traffic being mismerged into
another customer's traffic.  I would argue that this should be of concern to
those developing MPLS and those planning to use it.

It would seem that we need some form of 'Connectivity Verification'
keepalive that contains an absolute LSP source address, and which is was
sent periodically from the source of an LSP to its sink.  This would allow
all the types of connectivity defect to be detected and diagnosed by an
operator.  [There are also issues regarding consequent actions, and in
particular the downstream/upstream indication of defects that need to be
considered, eg for correct QoS/availability SLA measurement and correctly
targeted protection switching, especially in the case of nested LSPs.
Further, how such functions are processed at the LSP sink points is a matter
for local consideration wrt the importance of the LSP's traffic being
monitored/protected.]

Assuming we agreed on the above, then the problem we face is that there is
currently no method of identifying such a Connectivity Verification
keepalive pkt from within the normal user-plane traffic.  One possible
solution could be based on reducing TTL field from 8 to 7 bits (this would
still seem more than adequate) and use the 1 bit now spare as an indicator
that the next MPLS pkt was either normal user-plane data or a Connectivity
Verification pkt.

So.......to go back to the question that started this thread........one
reason an operator might want to know the source of an LSP is to protect its
customer's traffic from being incorrectly delivered (or interfered with) due
to network-based defects occuring in either the MPLS user-plane or
control-plane.  And in any case, operators will want some method of
detecting/diagnosing/correcting such defects.

In past mail exchanges (most off-line) I know some people are starting to
think about the OAM-type functions I am alluding to above (eg people
studying protection switching of LSPs, and especially those routed outside
the IGP).  Indeed, I am tempted to write a draft ID for consideration which
we can then hack about and decide whether to pursue or not.  However, before
I do so I would like to feel (i) there is sufficient support for such work
within the IETF MPLS community and (ii) that 'stealing' one of the TTL bits
from the MPLS OH would be OK.  Can I have some views please?

Regards, Neil

> -----Original Message-----
> From:	Eric Gray [SMTP:EGray@zaffire.com]
> Sent:	Wednesday, May 31, 2000 3:00 AM
> To:	'Tan Su Wei'; Kireeti Kompella; dwilder@baynetworks.com; Eric Gray;
> Shahram_Davari@pmc-sierra.com
> Cc:	mpls@UU.NET
> Subject:	RE: can egress know the ingress of a packet?
> 
> Tan,
> 
> 	No information is added to the IP header to
> aid in determining what LSP it is to be propagated
> on except for the MPLS label (which is prepended as
> part of the MPLS stack and is not part of the IP
> header).  When the last useful label is removed from 
> a data packet (either by popping it or by using an
> explicit NULL label), there is no longer any way to 
> positively identify the LSP that it was forwarded on.
> 
> 	I had the impression - because of the way that
> you asked your question - that you were trying to 
> find out how LSP information might be inferred from
> the label on a packet.  Again, (and as Kireeti already
> pointed out) it cannot be easily inferred from the IP
> packet once all useful label information is gone.  I
> doubt that it can be determined absolutely at that 
> point through much less than magic.
> 
> --
> Eric Gray
> 
> > -----Original Message-----
> > From: Tan Su Wei [mailto:swtan@mmu.edu.my]
> > Sent: Monday, May 29, 2000 7:33 PM
> > To: Kireeti Kompella; dwilder@baynetworks.com; EGray@zaffire.com;
> > Shahram_Davari@pmc-sierra.com
> > Cc: mpls@UU.NET
> > Subject: Re: can egress know the ingress of a packet?
> > 
> > 
> > Dear All,
> >     Thanks for answering my question.
> > As Kireeti wrote:
> >     > Perhaps we've gone off on an tangent here.  The question
> >     > as I understood it is "when a *data* packet arrives at
> >     > the egress, can we know which ingress and which LSP it
> >     > travelled on?" -- and the answer is, not without some
> >     > extracurricular work.
> >     >
> >     > Tan, can you clarify your question?
> > 
> > and my question is exactly as above. I'm sorry if there is any
> > misunderstanding.
> > For the posted answer from Mr. Eric Gray
> > 
> >     It is possible to know the LSP traversed, only if
> >     the LSP is "identified".  This is possible with either
> >     CR-LDP (using LSP-ID) or RSVP-TE (using SESSION).
> > 
> > Lets if the LSP is "identified" using either lspid or session 
> > object (during
> > the LSP setup time, right?) , to know the lsp and ingress the 
> > *data* packet
> > from, is that mean we need adding a field in the data packet on this
> > information? (Maybe ip header option field?).
> > Since information get from the incoming label and interface might be
> > incorrect when there is LSP merge.
> > Is my interpretation correct?
> > 
> >     Thank you for your reply.
> > 
> > Regards
> > Tan Su Wei
> > 
> > 


From owner-mpls@UU.NET  Mon Jun  5 05:53:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27487
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 05:53:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgd01527;
	Mon, 5 Jun 2000 09:53:11 GMT
Received: by mail-control.mail.uu.net 
	id QQisgd23544
	for mpls-outgoing; Mon, 5 Jun 2000 09:52:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisgd23536
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 09:52:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgd28380
	for <mpls@uu.net>; Mon, 5 Jun 2000 05:52:24 -0400 (EDT)
From: lijianping@mail.zte.com.cn
Received: from mail.zhongxing.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.103.147.133])
	id QQisgd19538
	for <mpls@uu.net>; Mon, 5 Jun 2000 09:51:58 GMT
Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 482568F5.00363952 ; Mon, 5 Jun 2000 17:52:16 +0800
X-Lotus-FromDomain: ZTE_LTD
To: mpls@UU.NET
Message-ID: <482568F5.002D9133.00@mail.zhongxing.com>
Date: Mon, 5 Jun 2000 16:17:42 +0800
Subject: About LDP PDU
Sender: owner-mpls@UU.NET
Precedence: bulk




I have a question about LDP that bother me :

Does an LDP PDU is tranfered in one TCP packet or
it may be separated to two or more TCP packet.
How can I guarantee to transfer a LDP PDU in one TCP
packet?


Thanks in advance,
lijianping.






From owner-mpls@UU.NET  Mon Jun  5 07:31:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28836
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 07:31:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgk26526;
	Mon, 5 Jun 2000 11:31:20 GMT
Received: by mail-control.mail.uu.net 
	id QQisgk18642
	for mpls-outgoing; Mon, 5 Jun 2000 11:30:49 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisgk18633
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 11:30:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgk08411
	for <mpls@uu.net>; Mon, 5 Jun 2000 07:30:21 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisgk12666
	for <mpls@uu.net>; Mon, 5 Jun 2000 11:30:20 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA06228
	for mpls@uu.net; Mon, 5 Jun 2000 07:30:20 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisgj18576
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 11:29:44 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgj25317
	for <mpls@UU.NET>; Mon, 5 Jun 2000 07:29:38 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQisgj25356
	for <mpls@UU.NET>; Mon, 5 Jun 2000 11:29:37 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA02719; Mon, 5 Jun 2000 07:29:28 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA00209;
	Mon, 5 Jun 2000 07:28:54 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000605071942.046937b0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 05 Jun 2000 07:28:54 -0400
To: manikantan <manis@future.futsoft.com>, "mpls@uu.net" <mpls@UU.NET>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable
Cc: Cheenu Srinivasan <cheenu_s@yahoo.com>,
        arun Viswanathan <arun@force10networks.com>
In-Reply-To: <01BFCD45.519DD940.manis@future.futsoft.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_37243126==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_37243126==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi Mani,

         My comments are inline and are highlighted in blue.


>Hello Thomas
>
>#Hi,
>#I would like to modify the mplsTunnelEntry to include
>#a few more objects as well as indexes. I wanted to
>#bring these changes to the list for discussion before
>#adding them to the TE MIB due to the fact that they
>#constitute a significant change, and we did not want to
>#surprise anyone. This change comes from my implementation
>#experience with the current version of the MIB, so it is
>#grounded in an actual implementation.
>#
>#I would like to add five additional values to the mplsTunnelTable
>#as well as augment the current indexes with two more indexes:
>
>mani> Hope you have not mentioned the five additional values in
>this mail, as I could not see it. Are you providing these five
>additional values in an another mail?

         No, that was a typo. There should only be two additional
indexes for the tunnelEntry: mplsTunnelSrcAddrIPv4 and
mplsTunnelSrcAddrIPv6.

>#
>#mplsTunnelSrcAddrType     INTEGER,
>#mplsTunnelSrcAddrIPv4   InetAddresIPv4,
>#mplsTunnelSrcAddrIPv6   InetAddresIPv6,
>
>mani> You have listed here three objects, whereas above you
>have mentioned of two more indexes. Does the above three form
>index to the TE Tunnel table or the "mplsTunnelSrcAddrIPv4" and
>"mplsTunnelSrcAddrIpv6" are the two indexes in addition to the
>earlier indexes of "mplsTunnelIndex" and "mplsTunnelInstance"?

         No, that was a typo. ;) There should only be two additional
indexes for the tunnelEntry: mplsTunnelSrcAddrIPv4 and
mplsTunnelSrcAddrIPv6.  They are both added to uniquely identify
a tunnel entry, in particular, at a midpoint where two tunnels
may converge on the same LSR.


>#      Now let me explain why. When you want to examine the tunnel
>#      entry at a midpoint, it is possible for tunnelId/tunnelInstance
>#      collisions to occur because the mplsTunnelId + mplsTunnelInstance
>#      variables are not guaranteed to be unique within an MPLS domain.
>#      A simple example of this occurs when LSR A has tunnelId = 1,
>#      tunnelInstance = 0 and LSR B has tunnelId = 1, tunnelInstance = 0
>#      which utilize the same next hop, LSR C. If one examines the
>#      tunnel table at LSR C, it is impossible to distinguish both tunnels;
>#      hence, the third index. A fourth index is required because we need
>#      to support V6 addresses.
>#
>#      An additional benefit of the added indexes is that one can now
>#      sort tunnelEntries based on src address, which is quite useful
>#      at mid-points and tunnel tails. For this same reason, it might be
>#      useful to add the tunnel destination address to the indexes of
>#      this table as well.
>#
>#      --Tom
>
>mani> To me the added indexes of Source address is valid and acceptable
>as we found during our implementation that the triplet < Tunnel index,
>Tunnel Instance and Source address> alone forms/identifies a unique
>tunnel and not just the <Tunnel index and the Tunnel Instance>

         Great. This is exactly what I have found. 8)

>Regarding the Destination Address as an index, this is not required to
>be added as index but can be added as a value/field in the MplsTunnelEntry.
>Reason: A tunnel can be uniquely identified with the triplet < Tunnel index,
>Tunnel Instance and Source address>. The Destination address present
>will give added information as to what is the end point of the Tunnel

         Great.

>Hence my doubts are:
>1) Should the Tunnel Instance be always treated as "0" when CRLSP tunnels are
>made?

         Yes.

>2) Is it that the LSPID-TLV has Action flag to indicate modification of the
>Tunnel, it is not required to identify instances in CRLSP? Reason : The usage
>of instance (When the instance value is mapped to the LSP_ID of the Sender
>Template object) is sending indication for reroutes in RSVP?.

         So what are you advocating here?

         --Tom

--=====================_37243126==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font color="#0000FF"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi
Mani,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>My
comments are inline and are highlighted in blue.<br>
<br>
<br>
</font><blockquote type=cite cite>Hello Thomas <br>
<br>
#Hi,<br>
#I would like to modify the mplsTunnelEntry to include<br>
#a few more objects as well as indexes. I wanted to<br>
#bring these changes to the list for discussion before<br>
#adding them to the TE MIB due to the fact that they<br>
#constitute a significant change, and we did not want to<br>
#surprise anyone. This change comes from my implementation<br>
#experience with the current version of the MIB, so it is<br>
#grounded in an actual implementation.<br>
#<br>
#I would like to add five additional values to the mplsTunnelTable<br>
#as well as augment the current indexes with two more indexes:<br>
<br>
mani&gt; Hope you have not mentioned the five additional values in <br>
this mail, as I could not see it. Are you providing these five<br>
additional values in an another mail?</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>No,
that was a typo. There should only be two additional<br>
indexes for the tunnelEntry: mplsTunnelSrcAddrIPv4 and<br>
mplsTunnelSrcAddrIPv6.<br>
<br>
</font><blockquote type=cite cite>#<br>
#mplsTunnelSrcAddrType&nbsp;&nbsp;&nbsp;&nbsp; INTEGER,<br>
#mplsTunnelSrcAddrIPv4&nbsp;&nbsp; InetAddresIPv4,<br>
#mplsTunnelSrcAddrIPv6&nbsp;&nbsp; InetAddresIPv6,<br>
<br>
mani&gt; You have listed here three objects, whereas above you <br>
have mentioned of two more indexes. Does the above three form<br>
index to the TE Tunnel table or the &quot;mplsTunnelSrcAddrIPv4&quot;
and<br>
&quot;mplsTunnelSrcAddrIpv6&quot; are the two indexes in addition to
the<br>
earlier indexes of &quot;mplsTunnelIndex&quot; and
&quot;mplsTunnelInstance&quot;?</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>No,
that was a typo. ;) There should only be two additional<br>
indexes for the tunnelEntry: mplsTunnelSrcAddrIPv4 and<br>
mplsTunnelSrcAddrIPv6.&nbsp; They are both added to uniquely
identify<br>
a tunnel entry, in particular, at a midpoint where two tunnels<br>
may converge on the same LSR.<br>
<br>
<br>
</font><blockquote type=cite cite>#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Now let
me explain why. When you want to examine the tunnel<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; entry at a midpoint, it is possible for
tunnelId/tunnelInstance<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; collisions to occur because the
mplsTunnelId + mplsTunnelInstance<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; variables are not guaranteed to be unique
within an MPLS domain.<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A simple example of this occurs when LSR
A has tunnelId = 1,<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tunnelInstance = 0 and LSR B has tunnelId
= 1, tunnelInstance = 0<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; which utilize the same next hop, LSR C.
If one examines the<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tunnel table at LSR C, it is impossible
to distinguish both tunnels;<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hence, the third index. A fourth index is
required because we need<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to support V6 addresses.<br>
#<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An additional benefit of the added
indexes is that one can now<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sort tunnelEntries based on src address,
which is quite useful<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at mid-points and tunnel tails. For this
same reason, it might be<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; useful to add the tunnel destination
address to the indexes of<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this table as well.<br>
#<br>
#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom<br>
<br>
mani&gt; To me the added indexes of Source address is valid and
acceptable<br>
as we found during our implementation that the triplet &lt; Tunnel
index,<br>
Tunnel Instance and Source address&gt; alone forms/identifies a
unique<br>
tunnel and not just the &lt;Tunnel index and the Tunnel
Instance&gt;</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Great.
This is exactly what I have found. 8)<br>
<br>
</font><blockquote type=cite cite>Regarding the Destination Address as an
index, this is not required to <br>
be added as index but can be added as a value/field in the
MplsTunnelEntry.<br>
Reason: A tunnel can be uniquely identified with the triplet &lt; Tunnel
index,<br>
Tunnel Instance and Source address&gt;. The Destination address
present<br>
will give added information as to what is the end point of the
Tunnel</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Great.<br>
<br>
</font><blockquote type=cite cite>Hence my doubts are:<br>
1) Should the Tunnel Instance be always treated as &quot;0&quot; when
CRLSP tunnels are <br>
made?</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes.<br>
<br>
</font><blockquote type=cite cite>2) Is it that the LSPID-TLV has Action
flag to indicate modification of the <br>
Tunnel, it is not required to identify instances in CRLSP? Reason : The
usage<br>
of instance (When the instance value is mapped to the LSP_ID of the
Sender<br>
Template object) is sending indication for reroutes in
RSVP?.</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>So
what are you advocating here?<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
</font></html>

--=====================_37243126==_.ALT--




From owner-mpls@UU.NET  Mon Jun  5 08:13:18 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29833
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 08:13:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgm07530;
	Mon, 5 Jun 2000 12:13:03 GMT
Received: by mail-control.mail.uu.net 
	id QQisgm28512
	for mpls-outgoing; Mon, 5 Jun 2000 12:12:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisgm28480
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 12:12:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgm00372
	for <mpls@UU.NET>; Mon, 5 Jun 2000 08:12:23 -0400 (EDT)
Received: from mtiwmhc25.worldnet.att.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mtiwmhc25.worldnet.att.net [204.127.131.50])
	id QQisgm20705
	for <mpls@UU.NET>; Mon, 5 Jun 2000 12:12:23 GMT
Received: from att.net ([12.78.98.248]) by mtiwmhc25.worldnet.att.net
          (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP
          id <20000605121222.KGFP1605.mtiwmhc25.worldnet.att.net@att.net>;
          Mon, 5 Jun 2000 12:12:22 +0000
Message-ID: <393B9998.A9D31F3B@att.net>
Date: Mon, 05 Jun 2000 08:14:16 -0400
From: Paul Bonenfant <pbonenfant@att.net>
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: qtl <qtl@263.net>
CC: "mpls@uu.net" <mpls@UU.NET>
Subject: Re: wave wrapper!
References: <200005261641.BAA15318@mail.cic.tsinghua.edu.cn>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

See comments, below...

Paul

Yangguang Xu wrote:
> 
> qtl wrote:
> >
> > hi:
> >         I am wondering about if digital wrapper has any relation with
> > digital wrapper?Anyone can help me about it?Thanks! Where can I find
> > the document about digital wrapper!
> >
> >             qtl
> >             qtl@263.net
> 
> If you mean wave wrapper and digital wrapper, they are the same. For more
> information, you can check ANSI T1X1 web site.
> 
> Yangguang

If you mean WaveWrapper and digital wrapper, they are not 
the same.

Digital wrapper is a generic term describing an out-of-band FEC 
based proposal to support optical channel overhead (in this context,
FEC = forward error correction).  WaveWrapper is a Lucent Trademark.

qtl wrote:
> 
> Hi:
>         How about digital wrapper(wave wrapper?) now?I want to know it!
> Where can I find the document about it?
>         Thank you!

The most recent _publicly_ available version of the draft standard 
for optical channel overhead using digital wrappers is:
- ANSI T1X1.5/2000-091, Draft ITU G.709 Network Node Interface
  for the OTN, Feb. 2000.
  ftp://ftp.t1.org/pub/t1x1/2000x15/0x150910.pdf


From owner-mpls@UU.NET  Mon Jun  5 09:11:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01502
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 09:11:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgq15585;
	Mon, 5 Jun 2000 13:11:36 GMT
Received: by mail-control.mail.uu.net 
	id QQisgq13541
	for mpls-outgoing; Mon, 5 Jun 2000 13:11:00 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisgq13523
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 13:10:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgq10350
	for <mpls@uu.net>; Mon, 5 Jun 2000 09:10:44 -0400 (EDT)
Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQisgq27114
	for <mpls@uu.net>; Mon, 5 Jun 2000 13:10:41 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000609377@fsnt.future.futusoft.com>;
 Mon, 05 Jun 2000 18:51:30 +0530
Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id SAA09863; Mon, 5 Jun 2000 18:42:05 +0530
Received: by localhost with Microsoft MAPI; Mon, 5 Jun 2000 18:33:41 +0530
Message-Id: <01BFCF1C.929A8FA0.manis@future.futsoft.com>
From: manikantan <manis@future.futsoft.com>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>,
        manikantan
	 <manis@kailash.future.futsoft.com>,
        "mpls@uu.net" <mpls@UU.NET>
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable
Date: Mon, 5 Jun 2000 18:33:40 +0530
Importance: high
X-Priority: 1 (Highest)
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Hello Thomas

#
#>Hence my doubts are:
#>1) Should the Tunnel Instance be always treated as "0" when CRLSP tunnels are
#>made?
#
#         Yes.

Mani> Thanks for the clarification.

#
#>2) Is it that the LSPID-TLV has Action flag to indicate modification of the
#>Tunnel, it is not required to identify instances in CRLSP? Reason : The usage
#>of instance (When the instance value is mapped to the LSP_ID of the Sender
#>Template object) is sending indication for reroutes in RSVP?.
#
#         So what are you advocating here?
#

Mani> Sorry for not being clear with the above question. I have raised the
above question when I try to compare RSVP-TE and CRLSP and look for the 
differences, issues for interworking if any etc.,

The concept of instances of Tunnels has been explained as follows
in the TE MIB <draft-03.txt - 10 March 2000>

  "Uniquely identifies an instance of a tunnel. It 
   is useful to identify multiple instances of
   tunnels for the purposes of backup and parallel
   tunnels."

When I think to apply the instance value as part of RSVP message and 
transmit downstream, the LSP ID in the sender Template object fits 
perfectly.

(Another question, IS this the way it is to be done?)

The usage of LSP ID is very helpful in the "make-before-break" situation
for a RSVP Tunnel re-route (i.e., tunnel modification). (Reference Section 
4.6.4 Reroute procedure in rsvp-mpls-tunnel-05.txt draft).

As the usage for the reroute can be done very well with the concept of instances,
i.e., tunnel instance id, (Scope for the utilization for backup and parallel tunnels not 
available, or I would have missed out), I attempt to apply the same
in the CRLSP case too.. i.e. instances -- used for re-routing. 

Hence my question is, since the CRLSP Draft - LSPID-TLV has the action flag
for modification ( reroutes), is it that the instances are not required or reroutes?

Now my understanding is that it is not required and the instance id will
be always the same and equals zero ( with the answer to my first question is "0". )

Hope I am clear now.

thanks in advance
with best regards
mani



From owner-mpls@UU.NET  Mon Jun  5 09:25:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01887
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 09:25:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgr06663;
	Mon, 5 Jun 2000 13:24:55 GMT
Received: by mail-control.mail.uu.net 
	id QQisgr14838
	for mpls-outgoing; Mon, 5 Jun 2000 13:24:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisgr14821
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 13:24:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgr25893
	for <mpls@UU.NET>; Mon, 5 Jun 2000 09:24:14 -0400 (EDT)
Received: from mail-out.globalone.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-out.globalone.net [199.184.38.11])
	id QQisgr06118
	for <mpls@UU.NET>; Mon, 5 Jun 2000 13:24:14 GMT
Received: from master.res.globalone.net (master.res.globalone.net [192.168.75.50])
	by mail-out.globalone.net (8.8.7/8.8.5) with ESMTP id JAA08717
	for <mpls@UU.NET>; Mon, 5 Jun 2000 09:26:24 -0400
Received: from master1.lon.globalone.net (master1.lon.globalone.net [160.81.138.21])
	by master.res.globalone.net (8.8.7/8.8.5) with ESMTP id JAA32108
	for <mpls@UU.NET>; Mon, 5 Jun 2000 09:24:09 -0400
Received: from pop1.br2.globalone.net (pop1.br2.globalone.net [160.81.159.5]) by master1.lon.globalone.net (8.8.5/8.6.9) with ESMTP id OAA00752 for <mpls@UU.NET>; Mon, 5 Jun 2000 14:24:05 +0100
Received: from GlobalOne.net ([160.81.159.41]) by pop1.br2.globalone.net
          (Netscape Messaging Server 3.62)  with ESMTP id 476
          for <mpls@UU.NET>; Mon, 5 Jun 2000 15:24:05 +0200
Message-ID: <393BA8E6.7DBD80B5@GlobalOne.net>
Date: Mon, 05 Jun 2000 15:19:34 +0200
From: "Francoise Beckers" <francoise.Beckers@globalone.net>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: symbols?
Content-Type: multipart/mixed;
 boundary="------------7EA5299725A3F89E0875377B"
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.
--------------7EA5299725A3F89E0875377B
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

Currently I'm making a thesis regarding MPLS. I've been searching for
the used symbols (pictures) for LSRs, ATM switches, etc..., on the
Internet, but I cannot select them.
Could somebody please provide me with these pictures so that I can use
them in Visio? Thanks for your help.

Kind regards,

Françoise Beckers

--------------7EA5299725A3F89E0875377B
Content-Type: text/x-vcard; charset=us-ascii;
 name="Francoise.Beckers.vcf"
Content-Description: Card for Francoise Beckers
Content-Disposition: attachment;
 filename="Francoise.Beckers.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Beckers;Françoise
tel;fax:+32-2-626-1357
tel;work:+32-2-626-1368
x-mozilla-html:FALSE
url:www.global-one.com
org:Global One;Post Sales
adr:;;Avenue Louise 326 Louizalaan;Brussels;;1050;Belgium
version:2.1
email;internet:Francoise.Beckers@GlobalOne.net
title:Junior Program Manager
fn:Françoise Beckers
end:vcard

--------------7EA5299725A3F89E0875377B--



From owner-mpls@UU.NET  Mon Jun  5 09:58:37 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02444
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 09:58:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgt17211;
	Mon, 5 Jun 2000 13:58:22 GMT
Received: by mail-control.mail.uu.net 
	id QQisgt16945
	for mpls-outgoing; Mon, 5 Jun 2000 13:57:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisgt16940
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 13:57:50 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgt18700
	for <mpls@uu.net>; Mon, 5 Jun 2000 09:57:40 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisgt28998
	for <mpls@uu.net>; Mon, 5 Jun 2000 13:57:39 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA21160
	for mpls@uu.net; Mon, 5 Jun 2000 09:57:39 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisgt16928
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 13:57:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgt18508
	for <mpls@UU.NET>; Mon, 5 Jun 2000 09:56:50 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisgt15992
	for <mpls@UU.NET>; Mon, 5 Jun 2000 13:56:49 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id GAA10663;
	Mon, 5 Jun 2000 06:54:22 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MBT3T>; Mon, 5 Jun 2000 06:54:22 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405C0@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>, EGray@zaffire.com,
        swtan@mmu.edu.my, kireeti@juniper.net, dwilder@baynetworks.com,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET
Subject: RE: can egress know the ingress of a packet?
Date: Mon, 5 Jun 2000 06:51:27 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Neil,

I also think we need some sort of OAM function at MPLS layer. And as you
said, to be able to process OAM cells, they must be recognized by LSRs. But
it might be hard to change the definition of TTL field at this point in
time. So I have a different proposal. Why don't we assign/reserve some Label
values to be used only by OAM packets. This is very analogous to ATM, in
which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI =0-15).
For example we could assign Label = 0 for the Keepalive messages that you
described.

I am interested in writing such an I-D, and in fact my company is expert in
ATM OAM, so we could leverage that knowledge for the MPLS OAM.

Regards,
Shahram Davari
Product Research
PMC-Sierra, Inc. (Ottawa) 
555 Legget drive,
Suit 834, Tower B,
Ottawa, ON K2K 2X3, Canada
Phone: +1 (613) 271-4018
Fax  : +1 (613) 271-7007
    
 


>-----Original Message-----
>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
>Sent: Monday, June 05, 2000 4:28 AM
>To: EGray@zaffire.com; swtan@mmu.edu.my; kireeti@juniper.net;
>dwilder@baynetworks.com; Shahram_Davari@pmc-sierra.com
>Cc: mpls@UU.NET
>Subject: RE: can egress know the ingress of a packet?
>
>
>Here's one reason why a network operator might want to know the LSP
>source..................
>
>IP addresses must be absolute since a CNLS forwarding regime 
>is 'memoryless'
>on a link by link basis.  Further, when used in the Internet 
>the absolute
>addresses must also be globally unique (or in the case of 
>private internets,
>private-network-wide unique). 
>
>Compare this now to label forwarding.  This requires an a priori set of
>user-plane connections (not necessarily BW reservations) to be 
>set up, ie
>LSPs, as determined by the FEC/IGP control-plane for the basic 
>LDP case, or
>via some other route determination method outside the IGP for 
>a TE case say.
>Labels are relative addresses that by definition are not 
>globally unique,
>and indeed they only need to be unique per interface on a link basis.
>
>With absolute addresses sent in some form of temporally deterministic
>keepalive one can detect/diagnose all cases of connectivity defects, eg
>breaks, swappped connections, mismerging between different 
>connections, self
>mismerging (aka looping).  So the IP layer is OK in handling 
>these defects
>to a large extent (there are some subtle issues of control-plane vs
>user-plane defect detection and the span of the defect 
>detection mechanisim,
>which I don't want to get into here as they are 2nd order to the main
>point).
>
>The handing of all of these types of connectivity defect is 
>not clear in
>MPLS.  We do, however, have the TTL field in the MPLS OH, but 
>this not a
>defect detection/diagnosis tool but rather a "damage 
>limitation mechanism".
>Further, it is relevant only for the specific case of self 
>mismerged LSPs in
>the MPLS layer (*not* the IP layer please note).  So currently 
>we have no
>method for a network operator to detect/diagnose connectivity 
>failures which
>could, for example, result in one customer's traffic being 
>mismerged into
>another customer's traffic.  I would argue that this should be 
>of concern to
>those developing MPLS and those planning to use it.
>
>It would seem that we need some form of 'Connectivity Verification'
>keepalive that contains an absolute LSP source address, and 
>which is was
>sent periodically from the source of an LSP to its sink.  This 
>would allow
>all the types of connectivity defect to be detected and diagnosed by an
>operator.  [There are also issues regarding consequent actions, and in
>particular the downstream/upstream indication of defects that 
>need to be
>considered, eg for correct QoS/availability SLA measurement 
>and correctly
>targeted protection switching, especially in the case of nested LSPs.
>Further, how such functions are processed at the LSP sink 
>points is a matter
>for local consideration wrt the importance of the LSP's traffic being
>monitored/protected.]
>
>Assuming we agreed on the above, then the problem we face is 
>that there is
>currently no method of identifying such a Connectivity Verification
>keepalive pkt from within the normal user-plane traffic.  One possible
>solution could be based on reducing TTL field from 8 to 7 bits 
>(this would
>still seem more than adequate) and use the 1 bit now spare as 
>an indicator
>that the next MPLS pkt was either normal user-plane data or a 
>Connectivity
>Verification pkt.
>
>So.......to go back to the question that started this thread........one
>reason an operator might want to know the source of an LSP is 
>to protect its
>customer's traffic from being incorrectly delivered (or 
>interfered with) due
>to network-based defects occuring in either the MPLS user-plane or
>control-plane.  And in any case, operators will want some method of
>detecting/diagnosing/correcting such defects.
>
>In past mail exchanges (most off-line) I know some people are 
>starting to
>think about the OAM-type functions I am alluding to above (eg people
>studying protection switching of LSPs, and especially those 
>routed outside
>the IGP).  Indeed, I am tempted to write a draft ID for 
>consideration which
>we can then hack about and decide whether to pursue or not.  
>However, before
>I do so I would like to feel (i) there is sufficient support 
>for such work
>within the IETF MPLS community and (ii) that 'stealing' one of 
>the TTL bits
>from the MPLS OH would be OK.  Can I have some views please?
>
>Regards, Neil
>
>> -----Original Message-----
>> From:	Eric Gray [SMTP:EGray@zaffire.com]
>> Sent:	Wednesday, May 31, 2000 3:00 AM
>> To:	'Tan Su Wei'; Kireeti Kompella; 
>dwilder@baynetworks.com; Eric Gray;
>> Shahram_Davari@pmc-sierra.com
>> Cc:	mpls@UU.NET
>> Subject:	RE: can egress know the ingress of a packet?
>> 
>> Tan,
>> 
>> 	No information is added to the IP header to
>> aid in determining what LSP it is to be propagated
>> on except for the MPLS label (which is prepended as
>> part of the MPLS stack and is not part of the IP
>> header).  When the last useful label is removed from 
>> a data packet (either by popping it or by using an
>> explicit NULL label), there is no longer any way to 
>> positively identify the LSP that it was forwarded on.
>> 
>> 	I had the impression - because of the way that
>> you asked your question - that you were trying to 
>> find out how LSP information might be inferred from
>> the label on a packet.  Again, (and as Kireeti already
>> pointed out) it cannot be easily inferred from the IP
>> packet once all useful label information is gone.  I
>> doubt that it can be determined absolutely at that 
>> point through much less than magic.
>> 
>> --
>> Eric Gray
>> 
>> > -----Original Message-----
>> > From: Tan Su Wei [mailto:swtan@mmu.edu.my]
>> > Sent: Monday, May 29, 2000 7:33 PM
>> > To: Kireeti Kompella; dwilder@baynetworks.com; EGray@zaffire.com;
>> > Shahram_Davari@pmc-sierra.com
>> > Cc: mpls@UU.NET
>> > Subject: Re: can egress know the ingress of a packet?
>> > 
>> > 
>> > Dear All,
>> >     Thanks for answering my question.
>> > As Kireeti wrote:
>> >     > Perhaps we've gone off on an tangent here.  The question
>> >     > as I understood it is "when a *data* packet arrives at
>> >     > the egress, can we know which ingress and which LSP it
>> >     > travelled on?" -- and the answer is, not without some
>> >     > extracurricular work.
>> >     >
>> >     > Tan, can you clarify your question?
>> > 
>> > and my question is exactly as above. I'm sorry if there is any
>> > misunderstanding.
>> > For the posted answer from Mr. Eric Gray
>> > 
>> >     It is possible to know the LSP traversed, only if
>> >     the LSP is "identified".  This is possible with either
>> >     CR-LDP (using LSP-ID) or RSVP-TE (using SESSION).
>> > 
>> > Lets if the LSP is "identified" using either lspid or session 
>> > object (during
>> > the LSP setup time, right?) , to know the lsp and ingress the 
>> > *data* packet
>> > from, is that mean we need adding a field in the data 
>packet on this
>> > information? (Maybe ip header option field?).
>> > Since information get from the incoming label and 
>interface might be
>> > incorrect when there is LSP merge.
>> > Is my interpretation correct?
>> > 
>> >     Thank you for your reply.
>> > 
>> > Regards
>> > Tan Su Wei
>> > 
>> > 
>



From owner-mpls@UU.NET  Mon Jun  5 10:05:37 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02633
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 10:05:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgu22482;
	Mon, 5 Jun 2000 14:05:31 GMT
Received: by mail-control.mail.uu.net 
	id QQisgu26412
	for mpls-outgoing; Mon, 5 Jun 2000 14:05:15 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisgu26407
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:05:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgu20222
	for <mpls@UU.NET>; Mon, 5 Jun 2000 10:04:52 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQisgu21832
	for <mpls@UU.NET>; Mon, 5 Jun 2000 14:04:52 GMT
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprch1.nortel.com; Mon, 5 Jun 2000 08:59:28 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id L8GTP8C3; Mon, 5 Jun 2000 09:59:14 -0400
Received: from americasm01.nt.com (wcars1cg.ca.nortel.com [47.14.96.106]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id LQHBLHQW; Mon, 5 Jun 2000 09:59:15 -0400
Message-ID: <393BB17C.F2AFA60C@americasm01.nt.com>
Date: Mon, 05 Jun 2000 09:56:18 -0400
From: "Philip Matthews" <philipma@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Vikram Venkataraghavan <vikramv25@yahoo.com>
CC: mpls@UU.NET
Subject: Re: RSVP/CR-LDP interoperability
References: <20000602061314.12334.qmail@web1306.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> I'm supprised no one has mentioned:
> draft-wright-mpls-crldp-rsvpte-iw-00.txt

Nortel plans to support RSVP-TE to CR-LDP interworking
in its products. We put out the above draft to
announce that. The -00 version is incomplete,
a -01 version is in the works.

- Philip


From owner-mpls@UU.NET  Mon Jun  5 10:19:19 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02934
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 10:19:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgv01823;
	Mon, 5 Jun 2000 14:19:09 GMT
Received: by mail-control.mail.uu.net 
	id QQisgv27419
	for mpls-outgoing; Mon, 5 Jun 2000 14:18:50 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisgv27414
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:18:45 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgv06247
	for <mpls@UU.NET>; Mon, 5 Jun 2000 10:18:29 -0400 (EDT)
Received: from sepahan.iut.ac.ir by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sepahan.iut.ac.ir [194.165.10.30])
	id QQisgv01193
	for <mpls@UU.NET>; Mon, 5 Jun 2000 14:18:22 GMT
Received: from localhost (s7627237@localhost)
	by sepahan.iut.ac.ir (8.9.3/8.9.3) with ESMTP id SAA02320;
	Mon, 5 Jun 2000 18:44:28 +0430
Date: Mon, 5 Jun 2000 18:44:28 +0430 (IRST)
From: Manshaee Mohammad-Hossein <s7627237@sepahan.iut.ac.ir>
To: Philip Matthews <philipma@nortelnetworks.com>
cc: Vikram Venkataraghavan <vikramv25@yahoo.com>, mpls@UU.NET
Subject: Re: RSVP/CR-LDP interoperability
In-Reply-To: <393BB17C.F2AFA60C@americasm01.nt.com>
Message-ID: <Pine.LNX.4.10.10006051842370.2274-100000@sepahan.iut.ac.ir>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I want to find this DRAFT:

 [ATMVP]     "MPLS using ATM VP Switching", N. Feldman, B.
               Jamoussi, S. Komandur, A. Viswanathan, T. Worster,
               work in progress, Internet Draft <draft-feldman-mpls-
               atmvp-00.txt>, February, 1999.
I couldn't find it in IETF web site.

Can anybody help me!

yours,

MH Manshaee

On Mon, 5 Jun 2000, Philip Matthews wrote:

> > I'm supprised no one has mentioned:
> > draft-wright-mpls-crldp-rsvpte-iw-00.txt
> 
> Nortel plans to support RSVP-TE to CR-LDP interworking
> in its products. We put out the above draft to
> announce that. The -00 version is incomplete,
> a -01 version is in the works.
> 
> - Philip
> 



From owner-mpls@UU.NET  Mon Jun  5 10:24:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03004
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 10:24:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgv18308;
	Mon, 5 Jun 2000 14:24:24 GMT
Received: by mail-control.mail.uu.net 
	id QQisgv27741
	for mpls-outgoing; Mon, 5 Jun 2000 14:23:49 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisgv27736
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:23:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgv07234
	for <mpls@uu.net>; Mon, 5 Jun 2000 10:23:19 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisgv17501
	for <mpls@uu.net>; Mon, 5 Jun 2000 14:23:18 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA25384
	for mpls@uu.net; Mon, 5 Jun 2000 10:23:17 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisgv27689
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:22:59 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgv23600
	for <mpls@UU.NET>; Mon, 5 Jun 2000 10:22:45 -0400 (EDT)
Received: from gorilla.mchh.siemens.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18])
	id QQisgv17190
	for <mpls@UU.NET>; Mon, 5 Jun 2000 14:22:44 GMT
Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged))
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA06737;
	Mon, 5 Jun 2000 16:22:00 +0200 (MET DST)
Received: from mchh247e.demchh201e.icn.siemens.de ([218.1.68.147])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA22381;
	Mon, 5 Jun 2000 16:19:40 +0200 (MET DST)
Received: by MCHH247E with Internet Mail Service (5.5.2448.0)
	id <K0CNQMJB>; Mon, 5 Jun 2000 16:24:55 +0200
Message-ID: <3B59676F9ADBD211B5360060086E64EECC0117@MCHH237E>
From: Theimer Thomas <Thomas.Theimer@icn.siemens.de>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Mon, 5 Jun 2000 16:24:53 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Actually, you may want to consider the router alert label as defined in the
label encapsulation document as follows:

There are several reserved label values:

              i. A value of 0 represents the "IPv4 Explicit NULL Label".
                 This label value is only legal when it is the sole
                 label stack entry.  It indicates that the label stack
                 must be popped, and the forwarding of the packet must
                 then be based on the IPv4 header.

             ii. A value of 1 represents the "Router Alert Label".  This
                 label value is legal anywhere in the label stack except
                 at the bottom.  When a received packet contains this
                 label value at the top of the label stack, it is
                 delivered to a local software module for processing.
                 The actual forwarding of the packet is determined by
                 the label beneath it in the stack.  However, if the
                 packet is forwarded further, the Router Alert Label
                 should be pushed back onto the label stack before
                 forwarding.  The use of this label is analogous to the
                 use of the "Router Alert Option" in IP packets [6].
                 Since this label cannot occur at the bottom of the
                 stack, it is not associated with a particular network
                 layer protocol.

You could use the router alert label to mark OAM packets. I am not sure if
this is compatible with
current implementations using the router alert label. So you may want to
define another OAM
alert label for marking OAM packets. Another issue is to work around the
uni-directional nature 
of LSPs which is not well suited for OAM. 

Some people may also be concerned how this maps to ATM LSRs.

Thomas Theimer
> -----Original Message-----
> From:	Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> Sent:	Monday, June 05, 2000 3:51 PM
> To:	'neil.2.harrison@bt.com'; EGray@zaffire.com; swtan@mmu.edu.my;
> kireeti@juniper.net; dwilder@baynetworks.com; Shahram Davari
> Cc:	mpls@UU.NET
> Subject:	RE: can egress know the ingress of a packet?
> 
> Hi Neil,
> 
> I also think we need some sort of OAM function at MPLS layer. And as you
> said, to be able to process OAM cells, they must be recognized by LSRs.
> But
> it might be hard to change the definition of TTL field at this point in
> time. So I have a different proposal. Why don't we assign/reserve some
> Label
> values to be used only by OAM packets. This is very analogous to ATM, in
> which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI
> =0-15).
> For example we could assign Label = 0 for the Keepalive messages that you
> described.
> 
> I am interested in writing such an I-D, and in fact my company is expert
> in
> ATM OAM, so we could leverage that knowledge for the MPLS OAM.
> 
> Regards,
> Shahram Davari
> Product Research
> PMC-Sierra, Inc. (Ottawa) 
> 555 Legget drive,
> Suit 834, Tower B,
> Ottawa, ON K2K 2X3, Canada
> Phone: +1 (613) 271-4018
> Fax  : +1 (613) 271-7007
>     
>  
> 
> 
> >-----Original Message-----
> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> >Sent: Monday, June 05, 2000 4:28 AM
> >To: EGray@zaffire.com; swtan@mmu.edu.my; kireeti@juniper.net;
> >dwilder@baynetworks.com; Shahram_Davari@pmc-sierra.com
> >Cc: mpls@UU.NET
> >Subject: RE: can egress know the ingress of a packet?
> >
> >
> >Here's one reason why a network operator might want to know the LSP
> >source..................
> >
> >IP addresses must be absolute since a CNLS forwarding regime 
> >is 'memoryless'
> >on a link by link basis.  Further, when used in the Internet 
> >the absolute
> >addresses must also be globally unique (or in the case of 
> >private internets,
> >private-network-wide unique). 
> >
> >Compare this now to label forwarding.  This requires an a priori set of
> >user-plane connections (not necessarily BW reservations) to be 
> >set up, ie
> >LSPs, as determined by the FEC/IGP control-plane for the basic 
> >LDP case, or
> >via some other route determination method outside the IGP for 
> >a TE case say.
> >Labels are relative addresses that by definition are not 
> >globally unique,
> >and indeed they only need to be unique per interface on a link basis.
> >
> >With absolute addresses sent in some form of temporally deterministic
> >keepalive one can detect/diagnose all cases of connectivity defects, eg
> >breaks, swappped connections, mismerging between different 
> >connections, self
> >mismerging (aka looping).  So the IP layer is OK in handling 
> >these defects
> >to a large extent (there are some subtle issues of control-plane vs
> >user-plane defect detection and the span of the defect 
> >detection mechanisim,
> >which I don't want to get into here as they are 2nd order to the main
> >point).
> >
> >The handing of all of these types of connectivity defect is 
> >not clear in
> >MPLS.  We do, however, have the TTL field in the MPLS OH, but 
> >this not a
> >defect detection/diagnosis tool but rather a "damage 
> >limitation mechanism".
> >Further, it is relevant only for the specific case of self 
> >mismerged LSPs in
> >the MPLS layer (*not* the IP layer please note).  So currently 
> >we have no
> >method for a network operator to detect/diagnose connectivity 
> >failures which
> >could, for example, result in one customer's traffic being 
> >mismerged into
> >another customer's traffic.  I would argue that this should be 
> >of concern to
> >those developing MPLS and those planning to use it.
> >
> >It would seem that we need some form of 'Connectivity Verification'
> >keepalive that contains an absolute LSP source address, and 
> >which is was
> >sent periodically from the source of an LSP to its sink.  This 
> >would allow
> >all the types of connectivity defect to be detected and diagnosed by an
> >operator.  [There are also issues regarding consequent actions, and in
> >particular the downstream/upstream indication of defects that 
> >need to be
> >considered, eg for correct QoS/availability SLA measurement 
> >and correctly
> >targeted protection switching, especially in the case of nested LSPs.
> >Further, how such functions are processed at the LSP sink 
> >points is a matter
> >for local consideration wrt the importance of the LSP's traffic being
> >monitored/protected.]
> >
> >Assuming we agreed on the above, then the problem we face is 
> >that there is
> >currently no method of identifying such a Connectivity Verification
> >keepalive pkt from within the normal user-plane traffic.  One possible
> >solution could be based on reducing TTL field from 8 to 7 bits 
> >(this would
> >still seem more than adequate) and use the 1 bit now spare as 
> >an indicator
> >that the next MPLS pkt was either normal user-plane data or a 
> >Connectivity
> >Verification pkt.
> >
> >So.......to go back to the question that started this thread........one
> >reason an operator might want to know the source of an LSP is 
> >to protect its
> >customer's traffic from being incorrectly delivered (or 
> >interfered with) due
> >to network-based defects occuring in either the MPLS user-plane or
> >control-plane.  And in any case, operators will want some method of
> >detecting/diagnosing/correcting such defects.
> >
> >In past mail exchanges (most off-line) I know some people are 
> >starting to
> >think about the OAM-type functions I am alluding to above (eg people
> >studying protection switching of LSPs, and especially those 
> >routed outside
> >the IGP).  Indeed, I am tempted to write a draft ID for 
> >consideration which
> >we can then hack about and decide whether to pursue or not.  
> >However, before
> >I do so I would like to feel (i) there is sufficient support 
> >for such work
> >within the IETF MPLS community and (ii) that 'stealing' one of 
> >the TTL bits
> >from the MPLS OH would be OK.  Can I have some views please?
> >
> >Regards, Neil
> >
> >> -----Original Message-----
> >> From:	Eric Gray [SMTP:EGray@zaffire.com]
> >> Sent:	Wednesday, May 31, 2000 3:00 AM
> >> To:	'Tan Su Wei'; Kireeti Kompella; 
> >dwilder@baynetworks.com; Eric Gray;
> >> Shahram_Davari@pmc-sierra.com
> >> Cc:	mpls@UU.NET
> >> Subject:	RE: can egress know the ingress of a packet?
> >> 
> >> Tan,
> >> 
> >> 	No information is added to the IP header to
> >> aid in determining what LSP it is to be propagated
> >> on except for the MPLS label (which is prepended as
> >> part of the MPLS stack and is not part of the IP
> >> header).  When the last useful label is removed from 
> >> a data packet (either by popping it or by using an
> >> explicit NULL label), there is no longer any way to 
> >> positively identify the LSP that it was forwarded on.
> >> 
> >> 	I had the impression - because of the way that
> >> you asked your question - that you were trying to 
> >> find out how LSP information might be inferred from
> >> the label on a packet.  Again, (and as Kireeti already
> >> pointed out) it cannot be easily inferred from the IP
> >> packet once all useful label information is gone.  I
> >> doubt that it can be determined absolutely at that 
> >> point through much less than magic.
> >> 
> >> --
> >> Eric Gray
> >> 
> >> > -----Original Message-----
> >> > From: Tan Su Wei [mailto:swtan@mmu.edu.my]
> >> > Sent: Monday, May 29, 2000 7:33 PM
> >> > To: Kireeti Kompella; dwilder@baynetworks.com; EGray@zaffire.com;
> >> > Shahram_Davari@pmc-sierra.com
> >> > Cc: mpls@UU.NET
> >> > Subject: Re: can egress know the ingress of a packet?
> >> > 
> >> > 
> >> > Dear All,
> >> >     Thanks for answering my question.
> >> > As Kireeti wrote:
> >> >     > Perhaps we've gone off on an tangent here.  The question
> >> >     > as I understood it is "when a *data* packet arrives at
> >> >     > the egress, can we know which ingress and which LSP it
> >> >     > travelled on?" -- and the answer is, not without some
> >> >     > extracurricular work.
> >> >     >
> >> >     > Tan, can you clarify your question?
> >> > 
> >> > and my question is exactly as above. I'm sorry if there is any
> >> > misunderstanding.
> >> > For the posted answer from Mr. Eric Gray
> >> > 
> >> >     It is possible to know the LSP traversed, only if
> >> >     the LSP is "identified".  This is possible with either
> >> >     CR-LDP (using LSP-ID) or RSVP-TE (using SESSION).
> >> > 
> >> > Lets if the LSP is "identified" using either lspid or session 
> >> > object (during
> >> > the LSP setup time, right?) , to know the lsp and ingress the 
> >> > *data* packet
> >> > from, is that mean we need adding a field in the data 
> >packet on this
> >> > information? (Maybe ip header option field?).
> >> > Since information get from the incoming label and 
> >interface might be
> >> > incorrect when there is LSP merge.
> >> > Is my interpretation correct?
> >> > 
> >> >     Thank you for your reply.
> >> > 
> >> > Regards
> >> > Tan Su Wei
> >> > 
> >> > 
> >



From owner-mpls@UU.NET  Mon Jun  5 10:38:52 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03414
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 10:38:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgw16083;
	Mon, 5 Jun 2000 14:38:44 GMT
Received: by mail-control.mail.uu.net 
	id QQisgw28810
	for mpls-outgoing; Mon, 5 Jun 2000 14:38:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisgw28801
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:38:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgw10067
	for <mpls@uu.net>; Mon, 5 Jun 2000 10:38:06 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQisgw15466
	for <mpls@uu.net>; Mon, 5 Jun 2000 14:38:06 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA13098
	for <mpls@uu.net>; Mon, 5 Jun 2000 07:38:14 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA07379 for mpls@uu.net; Mon, 5 Jun 2000 10:38:04 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisgb21453
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 09:22:37 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgb11886
	for <mpls@UU.NET>; Mon, 5 Jun 2000 05:22:31 -0400 (EDT)
Received: from mail.barak.net.il by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.barak.net.il [206.49.94.213])
	id QQisgb02971
	for <mpls@UU.NET>; Mon, 5 Jun 2000 09:22:30 GMT
Received: from yair-pc ([212.150.197.10])
	by mail.barak.net.il (8.9.3/8.9.1) with SMTP id MAA14562
	for <mpls@UU.NET>; Mon, 5 Jun 2000 12:22:21 +0300 (IDT)
Received: by localhost with Microsoft MAPI; Mon, 5 Jun 2000 12:35:29 -0000
Message-ID: <01BFCEEA.885C1B30.yair@trellis-photonics.com>
From: Yair <yair@trellis-photonics.com>
To: "MPLS (E-mail)" <mpls@UU.NET>
Subject: MPLS protection/restoration
Date: Mon, 5 Jun 2000 12:35:23 -0000
Organization: Trellis
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Sender: owner-mpls@UU.NET
Precedence: bulk


hi,
Is there something new regarding the draft of "Path Protection/Restoration 
Mechanism for MPLS Networks" -  <draft-chang-mpls-path-protection-00.txt. ?
Thanks,
Yair




From owner-mpls@UU.NET  Mon Jun  5 10:38:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03425
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 10:38:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgw29194;
	Mon, 5 Jun 2000 14:38:40 GMT
Received: by mail-control.mail.uu.net 
	id QQisgw28799
	for mpls-outgoing; Mon, 5 Jun 2000 14:38:12 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisgw28792
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:38:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgw26671
	for <mpls@uu.net>; Mon, 5 Jun 2000 10:37:52 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQisgw15311
	for <mpls@uu.net>; Mon, 5 Jun 2000 14:37:51 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA12993
	for <mpls@uu.net>; Mon, 5 Jun 2000 07:37:59 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA07375 for mpls@uu.net; Mon, 5 Jun 2000 10:37:50 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisew07686
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 01:41:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisew22127
	for <mpls@UU.NET>; Sun, 4 Jun 2000 21:41:18 -0400 (EDT)
Received: from mailserver-ng.cs.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailserver-ng.cs.umbc.edu [130.85.100.230])
	id QQisew25040
	for <mpls@UU.NET>; Mon, 5 Jun 2000 01:41:18 GMT
Received: from localhost (wrath@localhost)
	by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id VAA09826;
	Sun, 4 Jun 2000 21:41:06 -0400 (EDT)
Date: Sun, 4 Jun 2000 21:41:05 -0400 (EDT)
From: Vijay Gill <wrath@csee.umbc.edu>
To: Kireeti Kompella <kireeti@juniper.net>
cc: mpls@UU.NET
Subject: RE: RSVP/CR-LDP interoperability
In-Reply-To: <200006021729.KAA26082@kummer.juniper.net>
Message-ID: <Pine.SOL.3.95.1000604213828.9361B-100000@mailserver-ng.cs.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 2 Jun 2000, Kireeti Kompella wrote:

> UUnet, Global Center, Level 3 and vBNS all use RSVP for signalling
> MPLS.  To my knowledge, none of them use CR-LDP, but you'd have to
> ask them.
> 
> There has been no interest from ISPs (as far as I know) in
> RSVP-CRLDP interoperability.

There is a reason for that. It is hard enough to get RSVP and the MPLS
code bits to work properly, without trying to add yet another protocol
into the mix. 

/vijay





From owner-mpls@UU.NET  Mon Jun  5 10:43:17 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03501
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 10:43:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgw03018;
	Mon, 5 Jun 2000 14:43:11 GMT
Received: by mail-control.mail.uu.net 
	id QQisgw29104
	for mpls-outgoing; Mon, 5 Jun 2000 14:42:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisgw29093
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:42:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgw11032
	for <mpls@UU.NET>; Mon, 5 Jun 2000 10:42:13 -0400 (EDT)
Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: solen.ce.chalmers.se [129.16.20.244])
	id QQisgw02266
	for <mpls@UU.NET>; Mon, 5 Jun 2000 14:42:13 GMT
Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199])
	by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id QAA13545;
	Mon, 5 Jun 2000 16:40:58 +0200 (MET DST)
From: Florian-Daniel Otel <otel@ce.chalmers.se>
Received: (from otel@localhost)
	by rasputin.ce.chalmers.se (8.8.8/8.8.8) id QAA02271;
	Mon, 5 Jun 2000 16:40:58 +0200 (MEST)
MIME-Version: 1.0
Date: Mon,  5 Jun 2000 16:40:58 +0200 (MEST)
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>, EGray@zaffire.com,
        swtan@mmu.edu.my, kireeti@juniper.net, dwilder@baynetworks.com,
        mpls@UU.NET
Subject: OAM functionality (Was: RE: can egress know the ingress of a packet?)
In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B405C0@nt-exchange-bby.pmc-sierra.bc.ca>
References: <336ECDAFDF7DD311B9E30090277AEE4101B405C0@nt-exchange-bby.pmc-sierra.bc.ca>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14651.46549.647967.756959@rasputin.ce.chalmers.se>
Reply-To: otel@ce.chalmers.se
Content-Type: text/plain; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Sharam,

> Hi Neil,

> I also think we need some sort of OAM function at MPLS layer. And as you
> said, to be able to process OAM cells, they must be recognized by LSRs. But
> it might be hard to change the definition of TTL field at this point in
> time. So I have a different proposal. Why don't we assign/reserve some Label
> values to be used only by OAM packets. This is very analogous to ATM, in
> which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI =0-15).
> For example we could assign Label = 0 for the Keepalive messages that you
> described.

> I am interested in writing such an I-D, and in fact my company is expert in
> ATM OAM, so we could leverage that knowledge for the MPLS OAM.

As Neil already pointed out, there are several people intrested in O&M 
functionality in MPLS, and for several reasons (you can also check the
discussion between Neil and Vishal on TEwg mailing list on 17 Apr &
ff. I also had some off-list questions about it). 

But the impression i got (and please, someone correct me if I'm wrong) 
is that, as the Theimer OAM requirements draft clearly states:

"[..]we do not intend to simply adopt the OAM functions and procedures
previously defined  for other technologies (in particular ATM), as
this would probably lead to very complex and expensive implementations[..]"



Putting it bluntly, the way i read this is that "we simply don't want
to turn MPLS into ATM-2 by adding all possible types of OAM functions".


So, my take is (and, by all means, please correct me if i'm wrong)
that in addition to the (rather vague IMHO) Theimer draft there you
have all other proposals for recovery, protection, restoration and
loop prevention but no other general O&M spec than the above
draft. Why is that and how to solve (if ever need be) the OAM
needs...well, that's it's beyond my knowledge (and the reason I'm 
asking about it here).


My $0.02 worth.

With kind regards,

Florian.



From owner-mpls@UU.NET  Mon Jun  5 10:53:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03700
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 10:53:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgx10407;
	Mon, 5 Jun 2000 14:53:22 GMT
Received: by mail-control.mail.uu.net 
	id QQisgx00098
	for mpls-outgoing; Mon, 5 Jun 2000 14:53:02 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisgx00091
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:53:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgx13191
	for <mpls@uu.net>; Mon, 5 Jun 2000 10:52:47 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisgx26348
	for <mpls@uu.net>; Mon, 5 Jun 2000 14:52:47 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA00600
	for mpls@uu.net; Mon, 5 Jun 2000 10:52:46 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisgx00050
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:52:26 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgx29700
	for <mpls@UU.NET>; Mon, 5 Jun 2000 10:52:11 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisgx25915
	for <mpls@UU.NET>; Mon, 5 Jun 2000 14:52:10 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA12741;
	Mon, 5 Jun 2000 07:50:58 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MBT80>; Mon, 5 Jun 2000 07:50:58 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405C1@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'otel@ce.chalmers.se'" <otel@ce.chalmers.se>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>, EGray@zaffire.com,
        swtan@mmu.edu.my, kireeti@juniper.net, dwilder@baynetworks.com,
        mpls@UU.NET
Subject: RE: OAM functionality (Was: RE: can egress know the ingress of a 
	packet?)
Date: Mon, 5 Jun 2000 07:48:04 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Florian,

When I mentioned ATM, I didn't mean that we adopt and simply copy all the
ATM OAM for MPLS. What I meant was, since MPLS has lot of similarity to ATM,
probably we could leverage our knowledge of ATM OAM and design a set of OAM
functions which are tailored to MPLS. 

Regards,
-Shahram

>-----Original Message-----
>From: Florian-Daniel Otel [mailto:otel@ce.chalmers.se]
>Sent: Monday, June 05, 2000 10:41 AM
>To: Shahram Davari
>Cc: 'neil.2.harrison@bt.com'; EGray@zaffire.com; swtan@mmu.edu.my;
>kireeti@juniper.net; dwilder@baynetworks.com; mpls@UU.NET
>Subject: OAM functionality (Was: RE: can egress know the ingress of a
>packet?)
>
>
>
>Sharam,
>
>> Hi Neil,
>
>> I also think we need some sort of OAM function at MPLS 
>layer. And as you
>> said, to be able to process OAM cells, they must be 
>recognized by LSRs. But
>> it might be hard to change the definition of TTL field at 
>this point in
>> time. So I have a different proposal. Why don't we 
>assign/reserve some Label
>> values to be used only by OAM packets. This is very 
>analogous to ATM, in
>> which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 
>and VCI =0-15).
>> For example we could assign Label = 0 for the Keepalive 
>messages that you
>> described.
>
>> I am interested in writing such an I-D, and in fact my 
>company is expert in
>> ATM OAM, so we could leverage that knowledge for the MPLS OAM.
>
>As Neil already pointed out, there are several people intrested in O&M 
>functionality in MPLS, and for several reasons (you can also check the
>discussion between Neil and Vishal on TEwg mailing list on 17 Apr &
>ff. I also had some off-list questions about it). 
>
>But the impression i got (and please, someone correct me if I'm wrong) 
>is that, as the Theimer OAM requirements draft clearly states:
>
>"[..]we do not intend to simply adopt the OAM functions and procedures
>previously defined  for other technologies (in particular ATM), as
>this would probably lead to very complex and expensive 
>implementations[..]"
>
>
>
>Putting it bluntly, the way i read this is that "we simply don't want
>to turn MPLS into ATM-2 by adding all possible types of OAM functions".
>
>
>So, my take is (and, by all means, please correct me if i'm wrong)
>that in addition to the (rather vague IMHO) Theimer draft there you
>have all other proposals for recovery, protection, restoration and
>loop prevention but no other general O&M spec than the above
>draft. Why is that and how to solve (if ever need be) the OAM
>needs...well, that's it's beyond my knowledge (and the reason I'm 
>asking about it here).
>
>
>My $0.02 worth.
>
>With kind regards,
>
>Florian.
>



From owner-mpls@UU.NET  Mon Jun  5 10:57:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03792
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 10:57:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgx29445;
	Mon, 5 Jun 2000 14:57:17 GMT
Received: by mail-control.mail.uu.net 
	id QQisgx00475
	for mpls-outgoing; Mon, 5 Jun 2000 14:57:02 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisgx00455
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 14:56:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisgx13917
	for <mpls@UU.NET>; Mon, 5 Jun 2000 10:56:32 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQisgx28806
	for <mpls@UU.NET>; Mon, 5 Jun 2000 14:56:32 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA23793;
	Mon, 5 Jun 2000 07:56:35 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA07453; Mon, 5 Jun 2000 10:56:25 -0400 (EDT)
Message-Id: <200006051456.KAA07453@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: "Santosh Gupta" <santoshgupta@poboxes.com>
cc: mpls@UU.NET
Subject: Re: Ingress LER in LDP 
In-reply-to: Your message of Mon, 05 Jun 2000 10:09:25 +0530.
             <00b401bfcea8$0a9c3460$100d85a5@dti.daewoo.co.kr> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 05 Jun 2000 10:56:25 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In an ATM-LSR  without VC merge, ingress functionality  for a particular FEC
requires a cross-connect  table entry (i.e., hardware resource)  that is not
otherwise necessary.  In other  cases, an efficient implementation makes the
issue  moot, in  my  opinion.  In  any  event, the  answer  to the  original
question ("how does one decide whether label imposition for a particular FEC
is required?") is still the same. 




From owner-mpls@UU.NET  Mon Jun  5 11:00:52 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03920
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 11:00:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgy16334;
	Mon, 5 Jun 2000 15:00:40 GMT
Received: by mail-control.mail.uu.net 
	id QQisgy01794
	for mpls-outgoing; Mon, 5 Jun 2000 15:00:16 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisgy01650
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:00:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgx01222
	for <mpls@uu.net>; Mon, 5 Jun 2000 10:59:38 -0400 (EDT)
Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQisgx15348
	for <mpls@uu.net>; Mon, 5 Jun 2000 14:59:33 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000609957@fsnt.future.futusoft.com>;
 Mon, 05 Jun 2000 20:40:23 +0530
Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id UAA12183; Mon, 5 Jun 2000 20:30:59 +0530
Received: by localhost with Microsoft MAPI; Mon, 5 Jun 2000 20:22:31 +0530
Message-Id: <01BFCF2B.C69414C0.manis@future.futsoft.com>
From: manikantan <manis@future.futsoft.com>
To: "'Manshaee Mohammad-Hossein'" <s7627237@sepahan.iut.ac.ir>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: RSVP/CR-LDP interoperability
Date: Mon, 5 Jun 2000 20:22:30 +0530
Importance: high
X-Priority: 1 (Highest)
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFCF2B.C6AC7EC0"
Sender: owner-mpls@UU.NET
Precedence: bulk


------ =_NextPart_000_01BFCF2B.C6AC7EC0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Manshee

Please find enclosed the requested document
 
thanks in advance
with best regards
mani
 
/*-------------------------------------------------------------------*/
S.Manikantan
Future Software Private Limited
480-481, Anna salai, Nandanam,
Chennai, Tamil Nadu, 600 035,
India.
Phone	: +91-44-4330550
Fax	: +91-44-4344157.
Email	: manis@future.futsoft.com
http://www.futsoft.com
/*--------------------------------------------------------------------*/


-----Original Message-----
From:	Manshaee Mohammad-Hossein [SMTP:s7627237@sepahan.iut.ac.ir]
Sent:	Monday, June 05, 2000 7:44 PM
To:	Philip Matthews
Cc:	Vikram Venkataraghavan; mpls@uu.net
Subject:	Re: RSVP/CR-LDP interoperability

Hi,

I want to find this DRAFT:

 [ATMVP]     "MPLS using ATM VP Switching", N. Feldman, B.
               Jamoussi, S. Komandur, A. Viswanathan, T. Worster,
               work in progress, Internet Draft <draft-feldman-mpls-
               atmvp-00.txt>, February, 1999.
I couldn't find it in IETF web site.

Can anybody help me!

yours,

MH Manshaee

On Mon, 5 Jun 2000, Philip Matthews wrote:

> > I'm supprised no one has mentioned:
> > draft-wright-mpls-crldp-rsvpte-iw-00.txt
> 
> Nortel plans to support RSVP-TE to CR-LDP interworking
> in its products. We put out the above draft to
> announce that. The -00 version is incomplete,
> a -01 version is in the works.
> 
> - Philip
> 
------ =_NextPart_000_01BFCF2B.C6AC7EC0
Content-Type: text/plain; name="draft-feldman-mpls-atmvp-00.txt"
Content-Transfer-Encoding: 7bit







Internet-Draft                                         Nancy Feldman
Expiration Date: August 1999                                     IBM

                                                      Bilel Jamoussi
                                                     Nortel Networks

                                                    Sridhar Komandur
                                               Ascend Communications

                                                    Arun Viswanathan
                                                 Lucent Technologies

                                                         Tom Worster
                                                                 GDC

                                                       February 1999





                     MPLS using ATM VP Switching

                  <draft-feldman-mpls-atmvp-00.txt>




Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as "work
   in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.




Feldman et al              Expires August 1999               [Page 1]

Internet Draft       MPLS Using ATM VP Switching       February 1999




Abstract

   The MPLS Architecture [ARCH] discusses the way in which ATM
   switches may be used as Label Switching Routers.  The MPLS ATM VC
   switching document [ATMVC] details the way in which ATM-LSRs are
   used, specifically in the presence of non-merge and VC-merge
   capable switches.  This document is a companion document to
   [ATMVC]; it extends the ATM procedures for the support of VP-
   switching on ATM-LSRs.  It is assumed the reader is familiar with
   the contents of [ATMVC].


1. Introduction

   The MPLS Architecture [ARCH] discusses the way in which ATM
   switches may be used as Label Switching Routers.  The MPLS ATM VC
   Switching [ATMVC] document details the way in which ATM-LSRs are
   used, specifically in the presence of non-merge and VC-merge
   capable switches.  This document extends the ATM procedures in
   [ATMVC] for supporting the distribution of labels as VPI values.
   This document assumes the reader is familiar with the ATM terms
   and procedures as defined in [ATMVC].

   To connect all ingresses to all the egresses in a switched network
   requires O(n-squared) Label Switched Paths (LSPs).  In order to
   scale to O(n) (rather than O(n-squared)), MPLS makes use of the
   concept of stream merge.  This allows the creation of multipoint-
   to-point LSP trees, in which multiple incoming streams with the
   same FEC may be combined into a single outgoing stream.  To merge
   multiple incoming VCs to a single outgoing VC requires that ATM
   switching hardware have the capability of preventing cell
   interleaving [ARCH].  However, much of the legacy ATM switching
   hardware cannot support VC merging.

   Several legacy ATM switches support what is known as "VP-
   switching".  In ATM switches that support VP-switching, it is
   possible to create connections (cross-connects) that use only the
   VPI field in the ATM header to switch cells, and the VCI field is
   not used in the lookup that determines the outgoing label and/or
   the outgoing interface.  This capability is termed as VP-merge.
   VP-merge is the process by which a switch receives cells on
   several incoming VPIs and transmits them on a single outgoing VPI.
   In this merging style, each ingress LSR in a merged multipoint-to-
   point LSP use a unique VCI value when injecting packets (cells)
   into the multipoint-to-point connection.  At the merging nodes,
   where multiple upstream VPs are merged into a single outgoing VP,
   cells from different sources get interleaved, but the unique VCI
   values used by the sources help to maintain the identity of all
   PDUs so that they may be properly reassembled at the egress node.



Feldman et al              Expires August 1999               [Page 2]

Internet Draft       MPLS Using ATM VP Switching       February 1999




   Another use of VP-switching is in label stacking [LBLSTK].  The
   VPI/VCI label pair in ATM can be likened to be two separate
   labels, such that, the lower label is VCI and the top label is
   VPI.  The cells are switched based on the top label (VPI; that is
   VP-switching), till the top label is popped (that is, the VP
   switching ends), and the cells are switched based on the bottom
   label (that is VCI; or VPI/VCI together).

   Yet another use of VP-switching is in tunneling via ATM networks
   that aren't MPLS capable.  This procedure is described in [ATMVC],
   and is repeated in this document for completeness.

   This document provides procedures for exchanging VPIs as labels to
   create LSPs for use in the situations described above.


2. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
   in this document are to be interpreted as described in RFC 2119
   [RFC2119].


3. Definitions

   The following definitions are from [ATMVC], with appropriate
   modifications for the inclusion of VP-switching:

   A Label Switching Router (LSR) is a device which implements the
   label switching control and forwarding components described in
   [ARCH].

   A label switching controlled ATM (LC-ATM) interface is an ATM
   interface controlled by the label switching control component.
   When a packet traversing such an interface is received, it is
   treated as a labeled packet.  The packet

--0__=HMHuhIMHG1DD2XKsmZDmsmAiX7UaOk9QxAH1mQKJSw69tdNnfPmPkdrg
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=C6s top label is inferred
   from the contents of the VCI field only, the VPI field only, or
   the combined contents of the VPI and VCI fields.  Any two LDP
   peers which are connected via an LC-ATM interface will use LDP
   negotiations to determine which of these cases is applicable to
   that interface.  Moreover, only one of the above cases can be
   active at a time on an LC-ATM interface.

   An ATM-LSR is a LSR with a number of LC-ATM interfaces which
   forwards cells between these interfaces using labels carried in
   the VCI, VPI, or VPI/VCI field.





Feldman et al              Expires August 1999               [Page 3]

Internet Draft       MPLS Using ATM VP Switching       February 1999



4. Use of VPI/VCIs

   Label switching is accomplished by associating labels with
   Forwarding Equivalence Classes, and using the label value to
   forward packets.  An ATM-LSR that is performing VP switching
   carries the label in the VPI field.

   We say that two LSRs are "directly connected" over an LC-ATM
   interface if all cells transmitted out that interface by one LSR
   will reach the other, and there are no ATM switches between the
   two LSRs.

   When two LSRs are directly connected via an LC-ATM interface, they
   jointly control the allocation of VPIs/VCIs on the interface
   connecting them.  They may agree to use the VCI, VPI, or VPI/VCI
   field to encode a single label.

   The default VPI/VCI value for the non-MPLS connection is VPI 0,
   VCI 32.  Other values can be configured, as long as both parties
   are aware of the configured value.

   The VPI value 0 MUST NOT be used with VP switching.

   Any VCI value in the range 0-65535 inclusive MAY be used as a
   label with VP switching.

   With the exception of these reserved values, the VPI/VCI values
   used in the two directions of the link MAY be treated as
   independent spaces.

   The allowable ranges of VPIs and VCIs are communicated through
   LDP.


4.1.  VP-merge Connection

   Directly connected ATM-LSRs may use the VPI field to carry the
   MPLS label.  The choice of this mode of operation and the valid
   VPI ranges must be negotiated via LDP.  However, the VPI value of
   0 MUST NOT be used as an MPLS label indicator.  In addition, if
   two LDP peers using VP-merge are connected via a LC-ATM interface,
   the VPI value 0 is reserved for non-MPLS connections.  This non-
   MPLS connection is used to carry LDP packets between the two
   peers, and MAY also be used (but is not required to be used) for
   other unlabeled packets (such as OSPF packets, etc.).  The
   LLC/SNAP encapsulation of RFC 1483 [RFC1483] MUST be used on the
   non-MPLS connection.


4.2.  Connections via an ATM Virtual Path



Feldman et al              Expires August 1999               [Page 4]

Internet Draft       MPLS Using ATM VP Switching       February 1999




   Sometimes it can be useful to treat two LSRs as adjacent (in some
   LSP) across an LC-ATM interface, even though the connection
   between them is made through an ATM "cloud" via an ATM Virtual
   Path.  In this case, the VPI field is not available to MPLS, and
   the label MUST be encoded entirely within the VCI field.

   In this case, the default VCI value of the non-MPLS connection
   between the LSRs is 32.  The VPI is set to whatever is required to
   make use of the Virtual Path.

   A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
   NOT be used as the encoding of a label.

   With the exception of these reserved values, the VPI/VCI values
   used in the two directions of the link MAY be treated as
   independent spaces.

   The allowable ranges of VPI/VCIs are communicated through LDP.  If
   more than one VPI is used for label switching, the allowable range
   of VCIs may be different for each VPI, and each range is
   communicated through LDP.


5. Label Distribution and Maintenance Procedures

   In general, an ATM-LSR configured for VP-merge MAY use either
   "ordered control" OR "independent control" label distribution, as
   well as "unsolicited downstream" OR "downstream-on-demand" label
   allocation. (see [ARCH, LDP]).

   Due to the limited number of VPs that may be created in a VP-merge
   environment, there may be a shortage of VPs if the number of IP-
   prefixes in the domain is greater than the maximum number of VPs
   available (as determined by the allocated VPI bits).  This can be
   mitigated in the following ways:

       -  All ATM-LSRs in a domain may be configured for BGP or link st=
ate
          egress aggregation.  In this case, a single LSP is sustained =
for
          all prefixes which share a common egress point, thereby
          significantly reducing the number of necessary VPs.

       -  All ATM-LSRs in a domain may be configured for "ordered contr=
ol"
          label distribution and "unsolicited downstream" label allocat=
ion.
          This allows the egress nodes to control which LSPs are create=
d in
          the domain, thereby permitting a limited VP space to be alloc=
ated
          wisely.

       -  All ATM-LSRs in a domain SHOULD be configured for Conservativ=
e
          Label Retention (see [ARCH]).  This eliminates the use and
          maintenance of unnecessary labels.



Feldman et al              Expires August 1999               [Page 5]

Internet Draft       MPLS Using ATM VP Switching       February 1999





5.1.  VP-merge-capable ATM Switches

   VP-merge is the process by which a switch receives cells on
   several incoming VPIs and transmits them on a single outgoing VPI.
   The ATM-LSRs neither looks into the VCI field for switching the
   cells nor modify its content on the outgoing interface.  VP-merge
   MAY be used only when the ENTIRE ATM-LSR domain is capable of VP-
   merge.  If the entire ATM-LSR domain is not capable of VP-merge,
   then one of the applicable procedures described for either non-
   merge or VC-merge must be used (see [ATMVC]).

   To use VP-merge in an ATM-LSR domain, each of the LSRs in the Edge
   Set MUST be assigned a unique VCI value.  VP-Merge capable Ingress
   Edge LSRs MUST provide a means of configuring a unique VCI value.
   While other unique VCI allocation mechanisms may be possible, a
   description of such mechanisms is outside the scope of this
   document.  The egress  must be cognizant of the VCI ranges
   allocated at the ingresses, so that it aware of the VCI values it
   must reassemble on.


5.2.  Limitations of VP-merge

   VP-merge, besides its usefulness, comes with several limitations.
   These limitations must be carefully considered before deploying a
   network that uses VP-merge.

   All ATM-LSRs in an ATM-LSR domain must be capable of VP-merge.
   That is, VP-merge does not interoperate with VC-merge or non-merge
   ATM-LSRs.

     -  There should be sufficient number of VPI bits supported by the
        ATM-LSRs in use.  If hybrid mode (ships in the night mode) is u=
sed,
        some LC-ATM can have only a maximum of 8-bits for VPI.

     -  LSRs in an ATM-LSR domain using VP-merge must be directly
        connected.  That is, the LC-ATM interface of a VP-merge ATM-LSR=

must
        directly connect to another VP-merge ATM-LSR without any
intervening
        ATM switches.  Therefore, two VP-merge domains cannot be connec=
ted
        via a public ATM network except through the IP layer.

     -  To use VP-merge, each Ingress Edge ATM-LSR MUST be assigned a
        unique VCI value.  Currently, the only specified method to assi=
gn
        these VCI values is via configuration.


6. Egress aggregation with VP-merge




Feldman et al              Expires August 1999               [Page 6]

Internet Draft       MPLS Using ATM VP Switching       February 1999



   Aggregation is the concept of merging multiple FECs with a common
   destination into a single FEC, sharing the same LSP.  Aggregation
   may be achieved through information available in BGP or link-state
   routing protocols, where a set of IP destinations are known to
   traverse the same IP path to a common egress point.  However, some
   route protocols, such as RIP, do not provide knowledge of the
   egress point.  In these situations, if egress aggregation is
   desired, the egress LSR must be configured to advertise the same
   label for all (or a set of) IP prefixes reachable through that
   LSR.

   In the case of aggregation via BGP or a link-state routing
   protocol, the egress node is advertised in the FEC TLV "IP Prefix"
   with a mask of /32 [LDP].  In the other form of egress
   aggreg=

ation, hence referred to as "generic" egress aggregation,
   each prefix may be advertised individually as a separate FEC via
   the TLV "IP Prefix", yet given the same label.  However, when VP-
   merging is used, this latter form of generic egress aggregation
   could cause cell interleaving problems if each destination does
   not follow the exact same IP-path through the network.  Thus, an
   LSR desiring generic egress aggregation must use the FEC
   Aggregation-List TLV (see section 6.1).

   In the Aggregation-List TLV, each set of IP prefixes which are to
   share a common LSP are distinguished by a unique identifier.  The
   aggregating egress LSR transmits a Mapping Message with an
   Aggregation-List TLV containing a unique identifier, commonly the
   router-id of the egress LSR, as well as a list of IP prefixes that
   are to share the same label (as found in the Label TLV; see
   [LDP]).  Each LSR which receives the Aggregation-List from a peer
   verifies in the Forwarding Information Base (FIB) that each IP
   prefix in the given list uses that peer as its nexthop; any IP
   prefix which fails the test MUST be pruned off of the aggregation
   list.  The LSR then forwards the remaining list to its upstream
   neighbors.

   The Aggregation-List is tightly coupled with its peer and assigned
   label.  Once it has been received and accepted, any further
   Mapping Message containing that aggregation identifier MUST be
   received from the same peer, and MUST contain the same label.  An
   LSR MUST NOT accept an Aggregation-List with the same unique
   identifier from any other peer, or with a different label, until
   the original Aggregation-List has been cancelled via the Withdraw
   Message [LDP].  By constraining the Aggregation-List to associate
   with only one peer and label, it guarantees that all IP prefixes
   to a common egress LSR will share the same LSP, and thus avoids
   any cell interleaving problems.

   Note that a Withdraw Message containing an Aggregation-List TLV
   with zero prefixes is treated as a "wildcard", and removes ALL



Feldman et al              Expires August 1999               [Page 7]

Internet Draft       MPLS Using ATM VP Switching       February 1999



   prefixes associated with that aggregation list.

   Generic egress aggregation MUST be used in conjunction with
   "ordered" label distribution and SHOULD be used with "unsolicited
   downstream" label allocation.


6.1.  Aggregation-List Encoding

   The FEC TLV is defined in [LDP].  It is composed of FEC element
   types.  The following element is used for the Aggregation List:

         FEC Element       Type      Value
         type name

         Aggregation-List  0x04      Variable


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Agg-List (4)  |     Address Family            |     PreCount  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Aggregate Unique-Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix Len   |  Prefix ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .... (variable length)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................

      Address Family

          Two octet quantity containing a value from ADDRESS FAMILY
          NUMBERS in [RFC1700] that encodes the address family for
          the address prefix in the Prefix field.

      PreCount

          One octet number of address prefixes in this TLV, which
          comprise the set of prefixes that are to be aggregated
          together.

      Aggregate Unique-Id

          Four octet unique identifier assigned by the LSR
          initiating the aggregation.  This value MAY be the
          originating LSRs unique router-id.

      Prefix Len




Feldman et al              Expires August 1999               [Page 8]

Internet Draft       MPLS Using ATM VP Switching       February 1999



          One octet unsigned integer containing the length in bits
          of the address prefix that follows.

      Prefix

          A variable length field containing an address prefix whose
          length, in bits, was specified in the previous (Prefix
          Len) field.  The last prefix in this TLV must be padded to
          a byte boundary.


7. Stacking

   ATM switches typically support the use of the VPI and VCI fields
   as a two level hierarchy. This capability may be used to support
   label stacking in MPLS. In a VCI/VPI label stacking scenario,
   aggregation happens as LSPs in VCs in the outer cloud are
   multiplexed onto VPs to be sent across the inner cloud. When a VP
   reaches its egress from the inner cloud it is demultiplexed and
   the VC LSPs are segregated for distribution to their destinations.
   In this stacking model the VP LSPs are point-to-point and VC merge
   may be deployed in the outer cloud.

   Procedures for using VP switching in this mode will be discussed
   in a future revision.


8. Encapsulation

   The MPLS encapsulation to be used when sending labeled packets to
   or from ATM-LSRs is as specified in [ATMVC].


9. Optional Loop Detection: Distributing Path Vectors

   The optional loop detection procedures are as specified in
   [ATMVC].  Rules specific to VC-merge are also applicable to VP-
   merge.


10.   TTL Manipulation

   The TTL handling procedures are as specified in [ATMVC].


11.   Security Considerations

   The use of the procedures and encapsulations specified in this
   document does not have any security impact other than that which
   may generally be present in the use of any MPLS procedures or



Feldman et al              Expires August 1999               [Page 9]

Internet Draft       MPLS Using ATM VP Switching       February 1999



   encapsulations (see [ARCH]).


12.   Intellectual Property Considerations

   The IETF has been notified of intellectual property rights claimed
   in regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


13.   Acknowledgements

   This document shamelessly borrows from the ATM companion document
   [ATMVC].


14.   References

   [ARCH]    E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol
             Label Switching Architecture", Work in Progress,
             February 1999.

   [ATMVC]   B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E.
             Rosen, G. Swallow, P. Doolan, "MPLS using ATM VC
             Switching", Work in Progress, November, 1998.

   [LBLSTK]  E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G.
             Fedorkow, T. Li, A. Conta, "MPLS Label Stack Encoding",
             Work in Progress,   September 1998.

   [LDP]     L. Anderson, P. Doolan, N. Feldman, A. Fredette, B.
             Thomas, "LDP Specification", Work in Progress, January
             1999.

   [RFC1483] J. Heinanen, "Multiprotocol Encapsulation over ATM
             Adaptation Layer 5", RFC 1483, Telecom Finland, July
             1993.

   [RFC1700] J. Reynolds, J.Postel, "Assigned Numbers", October
             1994.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, BCP 14, March 1997.


15.   Authors' Addresses

   Nancy Feldman
   IBM Corp.



Feldman et al              Expires August 1999              [Page 10]

Internet Draft       MPLS Using ATM VP Switching       February 1999



   30 Saw Mill River Rd.
   Hawthorne, NY 10532
   Phone: +1 914-784-3254
   Email: nkf@us.ibm.com

   Bilel Jamoussi
   Nortel Networks
   P O Box 3511 Station C
   Ottawa, ON K1Y 4H7
   Canada
   Phone: +1 613 765-4814
   Email: jamoussi@NortelNetworks.com

   Sridhar Komandur
   Ascend Communications
   1 Robbins Rd
   Westford, MA 01886
   Phone: +1 978-952-7164
   Email: sridhar.komandur@ascend.com

   Arun Viswanathan
   Lucent Technologies
   101 Crawford Cornet Rd.
   Holmdel, NJ 07733
   Phone: +1 732-332-5163
   Email: arunv@lucent.com

   Tom Worster
   GDC
   199 W Newton St.
   Boston, MA 02116 USA
   Phone: +1 617 247 2624
   Email: tom.worster@gdc.com




















Feldman et al              Expires August 1999              [Page 11]


------ =_NextPart_000_01BFCF2B.C6AC7EC0--



From owner-mpls@UU.NET  Mon Jun  5 11:08:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04167
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 11:08:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisgy22834;
	Mon, 5 Jun 2000 15:08:17 GMT
Received: by mail-control.mail.uu.net 
	id QQisgy11003
	for mpls-outgoing; Mon, 5 Jun 2000 15:07:55 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisgy10996
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:07:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgy16318
	for <mpls@uu.net>; Mon, 5 Jun 2000 11:07:31 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisgy22115
	for <mpls@uu.net>; Mon, 5 Jun 2000 15:07:30 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA03637
	for mpls@uu.net; Mon, 5 Jun 2000 11:07:29 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisgy10836
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:07:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgy02742
	for <mpls@UU.NET>; Mon, 5 Jun 2000 11:06:51 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisgy21651
	for <mpls@UU.NET>; Mon, 5 Jun 2000 15:06:50 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA13327;
	Mon, 5 Jun 2000 08:03:41 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MB4B0>; Mon, 5 Jun 2000 08:03:41 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405C2@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>,
        "'neil.2.harrison@bt.com'"
	 <neil.2.harrison@bt.com>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Mon, 5 Jun 2000 08:00:24 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Thomas,

Good observation. Actually at the end of the label encapsulation document it
is mentioned that label values between 4-15 are reserved for future use,
which can be leveraged for these kind of operations.

Regards,
-Shahram 

>-----Original Message-----
>From: Theimer Thomas [mailto:Thomas.Theimer@icn.siemens.de]
>Sent: Monday, June 05, 2000 10:25 AM
>To: 'Shahram Davari'; 'neil.2.harrison@bt.com'
>Cc: mpls@UU.NET
>Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
>
>
>Actually, you may want to consider the router alert label as 
>defined in the
>label encapsulation document as follows:
>
>There are several reserved label values:
>
>              i. A value of 0 represents the "IPv4 Explicit 
>NULL Label".
>                 This label value is only legal when it is the sole
>                 label stack entry.  It indicates that the label stack
>                 must be popped, and the forwarding of the packet must
>                 then be based on the IPv4 header.
>
>             ii. A value of 1 represents the "Router Alert 
>Label".  This
>                 label value is legal anywhere in the label 
>stack except
>                 at the bottom.  When a received packet contains this
>                 label value at the top of the label stack, it is
>                 delivered to a local software module for processing.
>                 The actual forwarding of the packet is determined by
>                 the label beneath it in the stack.  However, if the
>                 packet is forwarded further, the Router Alert Label
>                 should be pushed back onto the label stack before
>                 forwarding.  The use of this label is analogous to the
>                 use of the "Router Alert Option" in IP packets [6].
>                 Since this label cannot occur at the bottom of the
>                 stack, it is not associated with a particular network
>                 layer protocol.
>
>You could use the router alert label to mark OAM packets. I am 
>not sure if
>this is compatible with
>current implementations using the router alert label. So you 
>may want to
>define another OAM
>alert label for marking OAM packets. Another issue is to work 
>around the
>uni-directional nature 
>of LSPs which is not well suited for OAM. 
>
>Some people may also be concerned how this maps to ATM LSRs.
>
>Thomas Theimer
>> -----Original Message-----
>> From:	Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
>> Sent:	Monday, June 05, 2000 3:51 PM
>> To:	'neil.2.harrison@bt.com'; EGray@zaffire.com; swtan@mmu.edu.my;
>> kireeti@juniper.net; dwilder@baynetworks.com; Shahram Davari
>> Cc:	mpls@UU.NET
>> Subject:	RE: can egress know the ingress of a packet?
>> 
>> Hi Neil,
>> 
>> I also think we need some sort of OAM function at MPLS 
>layer. And as you
>> said, to be able to process OAM cells, they must be 
>recognized by LSRs.
>> But
>> it might be hard to change the definition of TTL field at 
>this point in
>> time. So I have a different proposal. Why don't we 
>assign/reserve some
>> Label
>> values to be used only by OAM packets. This is very 
>analogous to ATM, in
>> which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI
>> =0-15).
>> For example we could assign Label = 0 for the Keepalive 
>messages that you
>> described.
>> 
>> I am interested in writing such an I-D, and in fact my 
>company is expert
>> in
>> ATM OAM, so we could leverage that knowledge for the MPLS OAM.
>> 
>> Regards,
>> Shahram Davari
>> Product Research
>> PMC-Sierra, Inc. (Ottawa) 
>> 555 Legget drive,
>> Suit 834, Tower B,
>> Ottawa, ON K2K 2X3, Canada
>> Phone: +1 (613) 271-4018
>> Fax  : +1 (613) 271-7007
>>     
>>  
>> 
>> 
>> >-----Original Message-----
>> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
>> >Sent: Monday, June 05, 2000 4:28 AM
>> >To: EGray@zaffire.com; swtan@mmu.edu.my; kireeti@juniper.net;
>> >dwilder@baynetworks.com; Shahram_Davari@pmc-sierra.com
>> >Cc: mpls@UU.NET
>> >Subject: RE: can egress know the ingress of a packet?
>> >
>> >
>> >Here's one reason why a network operator might want to know the LSP
>> >source..................
>> >
>> >IP addresses must be absolute since a CNLS forwarding regime 
>> >is 'memoryless'
>> >on a link by link basis.  Further, when used in the Internet 
>> >the absolute
>> >addresses must also be globally unique (or in the case of 
>> >private internets,
>> >private-network-wide unique). 
>> >
>> >Compare this now to label forwarding.  This requires an a 
>priori set of
>> >user-plane connections (not necessarily BW reservations) to be 
>> >set up, ie
>> >LSPs, as determined by the FEC/IGP control-plane for the basic 
>> >LDP case, or
>> >via some other route determination method outside the IGP for 
>> >a TE case say.
>> >Labels are relative addresses that by definition are not 
>> >globally unique,
>> >and indeed they only need to be unique per interface on a 
>link basis.
>> >
>> >With absolute addresses sent in some form of temporally 
>deterministic
>> >keepalive one can detect/diagnose all cases of connectivity 
>defects, eg
>> >breaks, swappped connections, mismerging between different 
>> >connections, self
>> >mismerging (aka looping).  So the IP layer is OK in handling 
>> >these defects
>> >to a large extent (there are some subtle issues of control-plane vs
>> >user-plane defect detection and the span of the defect 
>> >detection mechanisim,
>> >which I don't want to get into here as they are 2nd order 
>to the main
>> >point).
>> >
>> >The handing of all of these types of connectivity defect is 
>> >not clear in
>> >MPLS.  We do, however, have the TTL field in the MPLS OH, but 
>> >this not a
>> >defect detection/diagnosis tool but rather a "damage 
>> >limitation mechanism".
>> >Further, it is relevant only for the specific case of self 
>> >mismerged LSPs in
>> >the MPLS layer (*not* the IP layer please note).  So currently 
>> >we have no
>> >method for a network operator to detect/diagnose connectivity 
>> >failures which
>> >could, for example, result in one customer's traffic being 
>> >mismerged into
>> >another customer's traffic.  I would argue that this should be 
>> >of concern to
>> >those developing MPLS and those planning to use it.
>> >
>> >It would seem that we need some form of 'Connectivity Verification'
>> >keepalive that contains an absolute LSP source address, and 
>> >which is was
>> >sent periodically from the source of an LSP to its sink.  This 
>> >would allow
>> >all the types of connectivity defect to be detected and 
>diagnosed by an
>> >operator.  [There are also issues regarding consequent 
>actions, and in
>> >particular the downstream/upstream indication of defects that 
>> >need to be
>> >considered, eg for correct QoS/availability SLA measurement 
>> >and correctly
>> >targeted protection switching, especially in the case of 
>nested LSPs.
>> >Further, how such functions are processed at the LSP sink 
>> >points is a matter
>> >for local consideration wrt the importance of the LSP's 
>traffic being
>> >monitored/protected.]
>> >
>> >Assuming we agreed on the above, then the problem we face is 
>> >that there is
>> >currently no method of identifying such a Connectivity Verification
>> >keepalive pkt from within the normal user-plane traffic.  
>One possible
>> >solution could be based on reducing TTL field from 8 to 7 bits 
>> >(this would
>> >still seem more than adequate) and use the 1 bit now spare as 
>> >an indicator
>> >that the next MPLS pkt was either normal user-plane data or a 
>> >Connectivity
>> >Verification pkt.
>> >
>> >So.......to go back to the question that started this 
>thread........one
>> >reason an operator might want to know the source of an LSP is 
>> >to protect its
>> >customer's traffic from being incorrectly delivered (or 
>> >interfered with) due
>> >to network-based defects occuring in either the MPLS user-plane or
>> >control-plane.  And in any case, operators will want some method of
>> >detecting/diagnosing/correcting such defects.
>> >
>> >In past mail exchanges (most off-line) I know some people are 
>> >starting to
>> >think about the OAM-type functions I am alluding to above (eg people
>> >studying protection switching of LSPs, and especially those 
>> >routed outside
>> >the IGP).  Indeed, I am tempted to write a draft ID for 
>> >consideration which
>> >we can then hack about and decide whether to pursue or not.  
>> >However, before
>> >I do so I would like to feel (i) there is sufficient support 
>> >for such work
>> >within the IETF MPLS community and (ii) that 'stealing' one of 
>> >the TTL bits
>> >from the MPLS OH would be OK.  Can I have some views please?
>> >
>> >Regards, Neil
>> >
>> >> -----Original Message-----
>> >> From:	Eric Gray [SMTP:EGray@zaffire.com]
>> >> Sent:	Wednesday, May 31, 2000 3:00 AM
>> >> To:	'Tan Su Wei'; Kireeti Kompella; 
>> >dwilder@baynetworks.com; Eric Gray;
>> >> Shahram_Davari@pmc-sierra.com
>> >> Cc:	mpls@UU.NET
>> >> Subject:	RE: can egress know the ingress of a packet?
>> >> 
>> >> Tan,
>> >> 
>> >> 	No information is added to the IP header to
>> >> aid in determining what LSP it is to be propagated
>> >> on except for the MPLS label (which is prepended as
>> >> part of the MPLS stack and is not part of the IP
>> >> header).  When the last useful label is removed from 
>> >> a data packet (either by popping it or by using an
>> >> explicit NULL label), there is no longer any way to 
>> >> positively identify the LSP that it was forwarded on.
>> >> 
>> >> 	I had the impression - because of the way that
>> >> you asked your question - that you were trying to 
>> >> find out how LSP information might be inferred from
>> >> the label on a packet.  Again, (and as Kireeti already
>> >> pointed out) it cannot be easily inferred from the IP
>> >> packet once all useful label information is gone.  I
>> >> doubt that it can be determined absolutely at that 
>> >> point through much less than magic.
>> >> 
>> >> --
>> >> Eric Gray
>> >> 
>> >> > -----Original Message-----
>> >> > From: Tan Su Wei [mailto:swtan@mmu.edu.my]
>> >> > Sent: Monday, May 29, 2000 7:33 PM
>> >> > To: Kireeti Kompella; dwilder@baynetworks.com; 
>EGray@zaffire.com;
>> >> > Shahram_Davari@pmc-sierra.com
>> >> > Cc: mpls@UU.NET
>> >> > Subject: Re: can egress know the ingress of a packet?
>> >> > 
>> >> > 
>> >> > Dear All,
>> >> >     Thanks for answering my question.
>> >> > As Kireeti wrote:
>> >> >     > Perhaps we've gone off on an tangent here.  The question
>> >> >     > as I understood it is "when a *data* packet arrives at
>> >> >     > the egress, can we know which ingress and which LSP it
>> >> >     > travelled on?" -- and the answer is, not without some
>> >> >     > extracurricular work.
>> >> >     >
>> >> >     > Tan, can you clarify your question?
>> >> > 
>> >> > and my question is exactly as above. I'm sorry if there is any
>> >> > misunderstanding.
>> >> > For the posted answer from Mr. Eric Gray
>> >> > 
>> >> >     It is possible to know the LSP traversed, only if
>> >> >     the LSP is "identified".  This is possible with either
>> >> >     CR-LDP (using LSP-ID) or RSVP-TE (using SESSION).
>> >> > 
>> >> > Lets if the LSP is "identified" using either lspid or session 
>> >> > object (during
>> >> > the LSP setup time, right?) , to know the lsp and ingress the 
>> >> > *data* packet
>> >> > from, is that mean we need adding a field in the data 
>> >packet on this
>> >> > information? (Maybe ip header option field?).
>> >> > Since information get from the incoming label and 
>> >interface might be
>> >> > incorrect when there is LSP merge.
>> >> > Is my interpretation correct?
>> >> > 
>> >> >     Thank you for your reply.
>> >> > 
>> >> > Regards
>> >> > Tan Su Wei
>> >> > 
>> >> > 
>> >
>



From owner-mpls@UU.NET  Mon Jun  5 11:30:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04686
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 11:30:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisha23247;
	Mon, 5 Jun 2000 15:30:07 GMT
Received: by mail-control.mail.uu.net 
	id QQisgz12385
	for mpls-outgoing; Mon, 5 Jun 2000 15:29:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisgz12368
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:29:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgz21125
	for <mpls@uu.net>; Mon, 5 Jun 2000 11:29:05 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisgz07779
	for <mpls@uu.net>; Mon, 5 Jun 2000 15:29:03 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA07265
	for mpls@uu.net; Mon, 5 Jun 2000 11:29:02 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisgz12308
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:28:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisgz20925
	for <mpls@UU.NET>; Mon, 5 Jun 2000 11:28:20 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisgz07272
	for <mpls@UU.NET>; Mon, 5 Jun 2000 15:28:19 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA14626;
	Mon, 5 Jun 2000 08:25:26 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MB4LC>; Mon, 5 Jun 2000 08:25:27 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405C3@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Chris LaVallee'" <clavallee@zumanetworks.com>, jleu@mindspring.com,
        David Wang <david.wang@metro-optix.com>
Cc: mpls@UU.NET
Subject: RE: Ingress LER in LDP
Date: Mon, 5 Jun 2000 08:22:32 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Chris,

There is already a Control Protocol defined for MPLS, which is called
MPLSCP. Look at section 4 in:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt

So I don't see any point in using BCP for MPLS. Besides BCP is mostly
focused on LAN encapsulations.

MPLS Ethertypes are encapsulated in PPP packets in the PPP protocol field.

Regards,
-Shahram 

>-----Original Message-----
>From: Chris LaVallee [mailto:clavallee@zumanetworks.com]
>Sent: Friday, June 02, 2000 7:29 PM
>To: jleu@mindspring.com; David Wang
>Cc: mpls@UU.NET
>Subject: RE: Ingress LER in LDP
>
>
>> -POS the ether type will be 0x8847 or 0x8848 (as oppsed to 
>0x0800 for IP)
>
>This might be off topic, but...
>
>How do you get an ethertype over POS ? 
>I'm guessing it's Cisco-HDLC (which I know nothing about)
>
>PPP over POS has 2 other possibilities to carry MPLS
>- Add a new CP (control proto) for MPLS
>- Have BCP (PPP Bridging) carry MPLS
>
>Anyone have a preference / opinion on what people should use ?
>
>Chris
>
>
>
>
>> -----Original Message-----
>> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf 
>Of James R.
>> Leu
>> Sent: Friday, June 02, 2000 11:43 AM
>> To: David Wang
>> Cc: mpls@UU.NET
>> Subject: Re: Ingress LER in LDP
>> 
>> 
>> On Fri, Jun 02, 2000 at 01:20:33PM -0500, David Wang wrote:
>> > One related question: How a LSR distinguishes a labeled 
>packet from an
>> > unlabeled packet? 
>> 
>> Depends on the medium:
>> -ATM the VCC will contain a protcol type (AAL5Null requires this)
>> -POS the ether type will be 0x8847 or 0x8848 (as oppsed to 
>0x0800 for IP)
>> -PPP has some PIDs assigned for MPLS as well (as does IP)
>> 
>> Hope this helps.
>> 
>> Jim
>> 
>> > 
>> > -----Original Message-----
>> > From: Eric Rosen [mailto:erosen@cisco.com]
>> > Sent: Thursday, June 01, 2000 9:28 AM
>> > To: Santosh Gupta
>> > Cc: mpls@UU.NET
>> > Subject: Re: Ingress LER in LDP 
>> > 
>> > 
>> > Santosh> Can someone tell me how to decide if a router is 
>> supposed to act as
>> > Santosh> an Ingress LER for some particular FEC in MPLS domain ?
>> > 
>> > People keep asking  this question, and I'm never quite sure  
>> just what it is
>> > they are asking, because there isn't much of a mystery here.
>> > 
>> > If a router received an unlabeled  packet which belongs to a 
>> particular FEC,
>> > and the next hop for that packet supports MPLS, and the router 
>> is configured
>> > such that it is allowed to do allow label imposition for 
>> packets in that FEC
>> > with that next hop, then the router should impose the label 
>> assigned to that
>> > FEC by that next hop.
>> > 
>> > Does that answer your question? 
>> 
>> -- 
>> James R. Leu
>> 
>



From owner-mpls@UU.NET  Mon Jun  5 11:38:11 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04861
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 11:38:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisha29608;
	Mon, 5 Jun 2000 15:38:06 GMT
Received: by mail-control.mail.uu.net 
	id QQisha12989
	for mpls-outgoing; Mon, 5 Jun 2000 15:37:48 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisha12984
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:37:45 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisha22837
	for <mpls@UU.NET>; Mon, 5 Jun 2000 11:37:34 -0400 (EDT)
Received: from babelfish.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: babelfish.axion.bt.co.uk [132.146.17.20])
	id QQisha29097
	for <mpls@UU.NET>; Mon, 5 Jun 2000 15:37:33 GMT
Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) 
          by babelfish (local) with SMTP; Mon, 5 Jun 2000 16:37:17 +0100
Received: from ip-engineering.bt.com 
          by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id QAA22721;
          Mon, 5 Jun 2000 16:37:16 +0100 (BST)
Message-Id: <200006051537.QAA22721@celiborn.ip-engineering.bt.com>
X-Mailer: exmh version 2.0.3 9/28/98
To: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
In-reply-to: Your message of "Mon, 05 Jun 2000 06:51:27 PDT." <336ECDAFDF7DD311B9E30090277AEE4101B405C0@nt-exchange-bby.pmc-sierra.bc.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 05 Jun 2000 16:37:16 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


An LSR will be terminating many LSPs so will be terminating many OAM flows. 
How do you correctly diagnose LSPs with merged or corrupted labels if they all 
arrive on the same reserved label? The label the OAM flow arrives on has to 
match exactly the label used for the data (user plane) flow in order to be able
to detect faults caused by LSRs using broken label swapping tables.

So we need a bit somewhere in the MPLS header to identify an OAM payload but 
we need to keep the same label as used for the user plane data.

Peter.




From owner-mpls@UU.NET  Mon Jun  5 11:51:13 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04997
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 11:51:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishb23648;
	Mon, 5 Jun 2000 15:50:59 GMT
Received: by mail-control.mail.uu.net 
	id QQishb13956
	for mpls-outgoing; Mon, 5 Jun 2000 15:50:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQishb13949
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:50:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishb25159
	for <mpls@uu.net>; Mon, 5 Jun 2000 11:49:54 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQishb07631
	for <mpls@uu.net>; Mon, 5 Jun 2000 15:49:49 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA10945
	for mpls@uu.net; Mon, 5 Jun 2000 11:49:49 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQishb13911
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:49:14 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishb11515
	for <mpls@UU.NET>; Mon, 5 Jun 2000 11:49:05 -0400 (EDT)
Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQishb21968
	for <mpls@UU.NET>; Mon, 5 Jun 2000 15:49:04 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id SAA18579;
	Mon, 5 Jun 2000 18:48:52 +0300
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14651.52196.591746.497839@lohi.eng.telia.fi>
Date: Mon, 5 Jun 2000 18:48:52 +0300 (EEST)
To: "Loa Andersson" <loa.andersson@nortelnetworks.com>
Cc: Grenville Armitage <gja@dnrc.bell-labs.com>, mpls@UU.NET
Subject: Re: MPLS Performance analysis.....
In-Reply-To: <393794E4.129981E6@nortelnetworks.com>
References: <200006011504.LAA23314@erosen-sun.cisco.com>
	<39368EA4.7C1A25AF@dnrc.bell-labs.com>
	<393794E4.129981E6@nortelnetworks.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Loa Andersson writes:

 > To my recollection there were at least 4 different motivations for 
 > developing MPLS
 > 
 > 1. We needed TE-capabilities in IP networks (constraint based routing).
 > 
 > 2. A tunnel mechanism for VPNs.
 > 
 > 3. "Creating IP routers of ATM-switches"
 > 
 > 4. Capacity increase.

te became late to the table.  in the early ietf mlps bofs, cisco was
pushing mpls (ldp) as a means to automatically set up a full mesh of vcs
between routers in a more scalable way than what could be achieved by
atm (both in terms of number of routing peers and number of vcs legs).
forgot the silly ingress vs. egress control debates?  i tried to promote
mpls as a fourth generation general purpose connection oriented protocol
to replace fr and atm, but didn't get much support until the te
application poped up.

-- juha



From owner-mpls@UU.NET  Mon Jun  5 11:54:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05053
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 11:54:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishb26070;
	Mon, 5 Jun 2000 15:54:15 GMT
Received: by mail-control.mail.uu.net 
	id QQishb14207
	for mpls-outgoing; Mon, 5 Jun 2000 15:53:47 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQishb14202
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:53:43 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishb12449
	for <mpls@uu.net>; Mon, 5 Jun 2000 11:53:28 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQishb25463
	for <mpls@uu.net>; Mon, 5 Jun 2000 15:53:27 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA11712
	for mpls@uu.net; Mon, 5 Jun 2000 11:53:27 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQishb14174
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 15:52:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishb12332
	for <mpls@UU.NET>; Mon, 5 Jun 2000 11:52:45 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQishb25015
	for <mpls@UU.NET>; Mon, 5 Jun 2000 15:52:45 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA16253;
	Mon, 5 Jun 2000 08:52:41 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MB4W9>; Mon, 5 Jun 2000 08:52:42 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405C4@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Peter Willis'" <pjw@ip-engineering.bt.com>, mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Mon, 5 Jun 2000 08:49:48 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Peter,

But we can use two labels. The top label can be the reserved one, and the
second label can be the actual label, which is used for forwarding the OAM
packet. This is basically similar to the Router Alert Label = 1.

Regards,
-Shahram  

>-----Original Message-----
>From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
>Sent: Monday, June 05, 2000 11:37 AM
>To: mpls@UU.NET
>Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
>
>
>
>An LSR will be terminating many LSPs so will be terminating 
>many OAM flows. 
>How do you correctly diagnose LSPs with merged or corrupted 
>labels if they all 
>arrive on the same reserved label? The label the OAM flow 
>arrives on has to 
>match exactly the label used for the data (user plane) flow in 
>order to be able
>to detect faults caused by LSRs using broken label swapping tables.
>
>So we need a bit somewhere in the MPLS header to identify an 
>OAM payload but 
>we need to keep the same label as used for the user plane data.
>
>Peter.
>
>



From owner-mpls@UU.NET  Mon Jun  5 12:29:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05644
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 12:29:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishd04639;
	Mon, 5 Jun 2000 16:28:18 GMT
Received: by mail-control.mail.uu.net 
	id QQishd25512
	for mpls-outgoing; Mon, 5 Jun 2000 16:27:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishd25505
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 16:27:49 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishd02312
	for <mpls@UU.NET>; Mon, 5 Jun 2000 12:27:30 -0400 (EDT)
Received: from arthur.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: arthur.axion.bt.co.uk [132.146.5.4])
	id QQishd18086
	for <mpls@UU.NET>; Mon, 5 Jun 2000 16:27:29 GMT
Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) 
          by arthur (local) with SMTP; Mon, 5 Jun 2000 17:27:02 +0100
Received: from ip-engineering.bt.com 
          by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id RAA23571;
          Mon, 5 Jun 2000 17:27:01 +0100 (BST)
Message-Id: <200006051627.RAA23571@celiborn.ip-engineering.bt.com>
X-Mailer: exmh version 2.0.3 9/28/98
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?) 
In-reply-to: Your message of "Mon, 05 Jun 2000 08:49:48 PDT." <336ECDAFDF7DD311B9E30090277AEE4101B405C4@nt-exchange-bby.pmc-sierra.bc.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 05 Jun 2000 17:27:01 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

 Wouldn't it be better to have the top label
as the one that is used for forwarding the OAM & user data and the second 
label the one that identifies an OAM flow within a particular LSP? This way 
the OAM
data gets treated exactly the same as the user data by the non-edge LSRs.
Obviously the problem with this approach is that the terminating LSR does not
know it has an OAM packet until it has popped the outer label; this may cause
implementation problems (Does it?).

If the OAM data is treated differently from the user data then any faults in
the user data plane may not be detected correctly. The trouble with the
Route Alert Label =1 type approach is that it is effectively out-of-band;
LSRs will treat this differently from user data which is not what we want.

Peter.

> Peter,
> 
> But we can use two labels. The top label can be the reserved one, and the
> second label can be the actual label, which is used for forwarding the OAM
> packet. This is basically similar to the Router Alert Label = 1.
> 
> Regards,
> -Shahram  
> 
> >-----Original Message-----
> >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> >Sent: Monday, June 05, 2000 11:37 AM
> >To: mpls@UU.NET
> >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> >
> >
> >
> >An LSR will be terminating many LSPs so will be terminating 
> >many OAM flows. 
> >How do you correctly diagnose LSPs with merged or corrupted 
> >labels if they all 
> >arrive on the same reserved label? The label the OAM flow 
> >arrives on has to 
> >match exactly the label used for the data (user plane) flow in 
> >order to be able
> >to detect faults caused by LSRs using broken label swapping tables.
> >
> >So we need a bit somewhere in the MPLS header to identify an 
> >OAM payload but 
> >we need to keep the same label as used for the user plane data.
> >
> >Peter.
> >
> >




From owner-mpls@UU.NET  Mon Jun  5 12:38:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05861
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 12:38:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishe12147;
	Mon, 5 Jun 2000 16:37:31 GMT
Received: by mail-control.mail.uu.net 
	id QQishe26337
	for mpls-outgoing; Mon, 5 Jun 2000 16:37:13 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQishe26327
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 16:37:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishe20379
	for <mpls@uu.net>; Mon, 5 Jun 2000 12:37:02 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQishe11667
	for <mpls@uu.net>; Mon, 5 Jun 2000 16:37:01 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA18355
	for mpls@uu.net; Mon, 5 Jun 2000 12:37:01 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishe26260
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 16:36:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishe03958
	for <mpls@UU.NET>; Mon, 5 Jun 2000 12:36:14 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQishe23873
	for <mpls@UU.NET>; Mon, 5 Jun 2000 16:36:14 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA19049;
	Mon, 5 Jun 2000 09:36:11 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MBVL2>; Mon, 5 Jun 2000 09:36:11 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405C5@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Peter Willis'" <pjw@ip-engineering.bt.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?) 
Date: Mon, 5 Jun 2000 09:33:17 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Peter,

Sometimes OAM packets may need to be processed by intermediate nodes as
well. By having the top label to be the forwarding label for OAM packets, we
are forced to processing them only at the egress node.

BTW, if the second label is OAM label, I don't think it will cause any
implementation problem. Because the egress node before popping the top
label, by looking at the S bit, knows that there is still another label.


Regards,
-Shahram

>-----Original Message-----
>From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
>Sent: Monday, June 05, 2000 12:27 PM
>To: Shahram Davari
>Cc: mpls@UU.NET
>Subject: Re: OAM labels (was: can egress know the ingress of a 
>packet?) 
>
>
>Shahram,
>
> Wouldn't it be better to have the top label
>as the one that is used for forwarding the OAM & user data and 
>the second 
>label the one that identifies an OAM flow within a particular 
>LSP? This way 
>the OAM
>data gets treated exactly the same as the user data by the 
>non-edge LSRs.
>Obviously the problem with this approach is that the 
>terminating LSR does not
>know it has an OAM packet until it has popped the outer label; 
>this may cause
>implementation problems (Does it?).
>
>If the OAM data is treated differently from the user data then 
>any faults in
>the user data plane may not be detected correctly. The trouble with the
>Route Alert Label =1 type approach is that it is effectively 
>out-of-band;
>LSRs will treat this differently from user data which is not 
>what we want.
>
>Peter.
>
>> Peter,
>> 
>> But we can use two labels. The top label can be the reserved 
>one, and the
>> second label can be the actual label, which is used for 
>forwarding the OAM
>> packet. This is basically similar to the Router Alert Label = 1.
>> 
>> Regards,
>> -Shahram  
>> 
>> >-----Original Message-----
>> >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
>> >Sent: Monday, June 05, 2000 11:37 AM
>> >To: mpls@UU.NET
>> >Subject: RE: OAM labels (was: can egress know the ingress 
>of a packet?)
>> >
>> >
>> >
>> >An LSR will be terminating many LSPs so will be terminating 
>> >many OAM flows. 
>> >How do you correctly diagnose LSPs with merged or corrupted 
>> >labels if they all 
>> >arrive on the same reserved label? The label the OAM flow 
>> >arrives on has to 
>> >match exactly the label used for the data (user plane) flow in 
>> >order to be able
>> >to detect faults caused by LSRs using broken label swapping tables.
>> >
>> >So we need a bit somewhere in the MPLS header to identify an 
>> >OAM payload but 
>> >we need to keep the same label as used for the user plane data.
>> >
>> >Peter.
>> >
>> >
>
>



From owner-mpls@UU.NET  Mon Jun  5 12:46:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06053
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 12:46:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishf00225;
	Mon, 5 Jun 2000 16:45:50 GMT
Received: by mail-control.mail.uu.net 
	id QQishf27369
	for mpls-outgoing; Mon, 5 Jun 2000 16:45:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQishf27362
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 16:45:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishe05328
	for <mpls@uu.net>; Mon, 5 Jun 2000 12:44:59 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQishe29550
	for <mpls@uu.net>; Mon, 5 Jun 2000 16:44:58 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA20021
	for mpls@uu.net; Mon, 5 Jun 2000 12:44:58 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQishe27102
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 16:44:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishe05241
	for <mpls@UU.NET>; Mon, 5 Jun 2000 12:44:19 -0400 (EDT)
Received: from gorilla.mchh.siemens.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18])
	id QQishe29168
	for <mpls@UU.NET>; Mon, 5 Jun 2000 16:44:18 GMT
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA27686;
	Mon, 5 Jun 2000 18:43:40 +0200 (MET DST)
Received: from mchh201e.demchh201e.icn.siemens.de ([218.1.68.104])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA00202;
	Mon, 5 Jun 2000 18:44:00 +0200 (MET DST)
Received: by MCHH201E with Internet Mail Service (5.5.2448.0)
	id <L0XGW9K8>; Mon, 5 Jun 2000 18:46:37 +0200
Message-ID: <3B59676F9ADBD211B5360060086E64EECC011A@MCHH237E>
From: Theimer Thomas <Thomas.Theimer@icn.siemens.de>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Peter Willis'"
	 <pjw@ip-engineering.bt.com>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Mon, 5 Jun 2000 18:46:26 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Actually, there are at least two ways to use such a reserved OAM label:

- end-end OAM packets would have a label stack where the reserved 
  label is inserted below the original top label. After the top label is
  popped at the egress node, the reserved label is processed by 
  forwarding the packet to OAM handling. Thus, all packets are
  forwarded using the original top label. OAM packets are visible
  only to ingress and egress nodes, and use exactly the same
  path as user packets.

- hop-by-hop OAM packets would have the reserved label pushed
  on top of the original top label. Each LSR along the LSP would
  then recognise the reserved top label, forward the packet to 
  OAM handling, and then forward the packet using the label
  second on the label stack (the original top label).

It may simplify things if two different reserved labels are defined
for end-end and hop-by-hop OAM packets, if people feel that
both are needed. The hop-hop case is really very similar to
the router alert label.

A dedicated OAM header bit would serve a similar purpose, but is
not strictly required.

Regards,

Thomas Theimer
> -----Original Message-----
> From:	Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> Sent:	Monday, June 05, 2000 5:50 PM
> To:	'Peter Willis'; mpls@UU.NET
> Subject:	RE: OAM labels (was: can egress know the ingress of a
> packet?)
> 
> Peter,
> 
> But we can use two labels. The top label can be the reserved one, and the
> second label can be the actual label, which is used for forwarding the OAM
> packet. This is basically similar to the Router Alert Label = 1.
> 
> Regards,
> -Shahram  
> 
> >-----Original Message-----
> >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> >Sent: Monday, June 05, 2000 11:37 AM
> >To: mpls@UU.NET
> >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> >
> >
> >
> >An LSR will be terminating many LSPs so will be terminating 
> >many OAM flows. 
> >How do you correctly diagnose LSPs with merged or corrupted 
> >labels if they all 
> >arrive on the same reserved label? The label the OAM flow 
> >arrives on has to 
> >match exactly the label used for the data (user plane) flow in 
> >order to be able
> >to detect faults caused by LSRs using broken label swapping tables.
> >
> >So we need a bit somewhere in the MPLS header to identify an 
> >OAM payload but 
> >we need to keep the same label as used for the user plane data.
> >
> >Peter.
> >
> >



From owner-mpls@UU.NET  Mon Jun  5 12:57:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06280
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 12:57:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishf07488;
	Mon, 5 Jun 2000 16:56:21 GMT
Received: by mail-control.mail.uu.net 
	id QQishf28308
	for mpls-outgoing; Mon, 5 Jun 2000 16:55:55 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishf28295
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 16:55:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishf07221
	for <mpls@UU.NET>; Mon, 5 Jun 2000 12:55:42 -0400 (EDT)
Received: from arthur.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: arthur.axion.bt.co.uk [132.146.5.4])
	id QQishf24284
	for <mpls@UU.NET>; Mon, 5 Jun 2000 16:55:42 GMT
Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) 
          by arthur (local) with SMTP; Mon, 5 Jun 2000 17:55:20 +0100
Received: from ip-engineering.bt.com 
          by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id RAA23895;
          Mon, 5 Jun 2000 17:55:18 +0100 (BST)
Message-Id: <200006051655.RAA23895@celiborn.ip-engineering.bt.com>
X-Mailer: exmh version 2.0.3 9/28/98
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?) 
In-reply-to: Your message of "Mon, 05 Jun 2000 09:33:17 PDT." <336ECDAFDF7DD311B9E30090277AEE4101B405C5@nt-exchange-bby.pmc-sierra.bc.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 05 Jun 2000 17:55:18 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> Peter,
> 
> Sometimes OAM packets may need to be processed by intermediate nodes as
> well. By having the top label to be the forwarding label for OAM packets, we
> are forced to processing them only at the egress node.

	OK can we do both? For most OAM functions I'm only interested in
	OAM processing at the edge. Besides which if we require intermediate
	LSRs to process all OAM then this will not scale. However I do
	admit in some circumstances I may like an intermediate node
	to do something e.g. a LSP traceroute function.

	Its just from experience I know that if the OAM/test tools available
	use packets that are not treated the same as the users data packets
	then the results are often doubtful (for example see the misleading
	results caused by using ping).
> 
> BTW, if the second label is OAM label, I don't think it will cause any
> implementation problem. Because the egress node before popping the top
> label, by looking at the S bit, knows that there is still another label.

	I was more thinking along the lines of; pop the outer label,
	find its an OAM label, NOW I need to know the outer label to
	process the OAM packet correctly but I've already used it and
	lost it! 

	Setting the S bit could also cause a minor problem. Presumably
	the S bit in the user data label will be set but not in the
	OAM data outer label. Hence if we have an implementation bug to
	do with the operation of the S bit it would not be detected by
	the OAM.

Peter.
> 
> 
> Regards,
> -Shahram
> 
> >-----Original Message-----
> >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> >Sent: Monday, June 05, 2000 12:27 PM
> >To: Shahram Davari
> >Cc: mpls@UU.NET
> >Subject: Re: OAM labels (was: can egress know the ingress of a 
> >packet?) 
> >
> >
> >Shahram,
> >
> > Wouldn't it be better to have the top label
> >as the one that is used for forwarding the OAM & user data and 
> >the second 
> >label the one that identifies an OAM flow within a particular 
> >LSP? This way 
> >the OAM
> >data gets treated exactly the same as the user data by the 
> >non-edge LSRs.
> >Obviously the problem with this approach is that the 
> >terminating LSR does not
> >know it has an OAM packet until it has popped the outer label; 
> >this may cause
> >implementation problems (Does it?).
> >
> >If the OAM data is treated differently from the user data then 
> >any faults in
> >the user data plane may not be detected correctly. The trouble with the
> >Route Alert Label =1 type approach is that it is effectively 
> >out-of-band;
> >LSRs will treat this differently from user data which is not 
> >what we want.
> >
> >Peter.
> >
> >> Peter,
> >> 
> >> But we can use two labels. The top label can be the reserved 
> >one, and the
> >> second label can be the actual label, which is used for 
> >forwarding the OAM
> >> packet. This is basically similar to the Router Alert Label = 1.
> >> 
> >> Regards,
> >> -Shahram  
> >> 
> >> >-----Original Message-----
> >> >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> >> >Sent: Monday, June 05, 2000 11:37 AM
> >> >To: mpls@UU.NET
> >> >Subject: RE: OAM labels (was: can egress know the ingress 
> >of a packet?)
> >> >
> >> >
> >> >
> >> >An LSR will be terminating many LSPs so will be terminating 
> >> >many OAM flows. 
> >> >How do you correctly diagnose LSPs with merged or corrupted 
> >> >labels if they all 
> >> >arrive on the same reserved label? The label the OAM flow 
> >> >arrives on has to 
> >> >match exactly the label used for the data (user plane) flow in 
> >> >order to be able
> >> >to detect faults caused by LSRs using broken label swapping tables.
> >> >
> >> >So we need a bit somewhere in the MPLS header to identify an 
> >> >OAM payload but 
> >> >we need to keep the same label as used for the user plane data.
> >> >
> >> >Peter.
> >> >
> >> >
> >
> >




From owner-mpls@UU.NET  Mon Jun  5 13:11:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06687
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 13:11:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishg05518;
	Mon, 5 Jun 2000 17:10:52 GMT
Received: by mail-control.mail.uu.net 
	id QQishg08678
	for mpls-outgoing; Mon, 5 Jun 2000 17:10:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQishg08660
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 17:10:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishg26401
	for <mpls@UU.NET>; Mon, 5 Jun 2000 13:09:49 -0400 (EDT)
Received: from hork.mrv.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uunet-hork.mrv.com [208.195.192.3])
	id QQishg04613
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:09:47 GMT
Received: from chris (ok.mrv.com [208.195.192.2])
	by hork.mrv.com (8.10.1/8.10.0) with SMTP id e55H8tr04119;
	Mon, 5 Jun 2000 10:08:59 -0700
X-Authentication-Warning: hork.mrv.com: Host ok.mrv.com [208.195.192.2] claimed to be chris
From: "Chris LaVallee" <clavallee@zumanetworks.com>
To: <lijianping@mail.zte.com.cn>, <mpls@UU.NET>
Subject: RE: About LDP PDU
Date: Mon, 5 Jun 2000 10:03:26 -0700
Message-ID: <000501bfcf0f$f6cc33a0$a701a8c0@internal.nbase.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-reply-to: <482568F5.002D9133.00@mail.zhongxing.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

lijianping,

The max PDU length is 4096, therefore it's possible to use multiple TCP
packets (over ethernet), if a message gets really big ( > 1500)

The Init message does allow you to inform your peer the max PDU you want to
receive. Although I don't think this guarantees that there will be only one
LDP PDU per TCP packet. TCP data is a stream and PDUs don't have to begin
and end at the boundary of the TCP packet.

Fortunately, I think it's unlikely that a PDU will ever get really big.

Chris



> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> lijianping@mail.zte.com.cn
> Sent: Monday, June 05, 2000 1:18 AM
> To: mpls@UU.NET
> Subject: About LDP PDU
>
>
>
>
>
> I have a question about LDP that bother me :
>
> Does an LDP PDU is tranfered in one TCP packet or
> it may be separated to two or more TCP packet.
> How can I guarantee to transfer a LDP PDU in one TCP
> packet?
>
>
> Thanks in advance,
> lijianping.
>
>
>
>



From owner-mpls@UU.NET  Mon Jun  5 13:48:36 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07414
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 13:48:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishj01199;
	Mon, 5 Jun 2000 17:47:41 GMT
Received: by mail-control.mail.uu.net 
	id QQishj11526
	for mpls-outgoing; Mon, 5 Jun 2000 17:47:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQishj11521
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 17:47:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishj16717
	for <mpls@uu.net>; Mon, 5 Jun 2000 13:47:06 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQishj00631
	for <mpls@uu.net>; Mon, 5 Jun 2000 17:47:05 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA29732
	for mpls@uu.net; Mon, 5 Jun 2000 13:47:05 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishj11510
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 17:46:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishj16664
	for <mpls@UU.NET>; Mon, 5 Jun 2000 13:46:42 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQishj00372
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:46:41 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA25510;
	Mon, 5 Jun 2000 10:46:38 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MBWW1>; Mon, 5 Jun 2000 10:46:37 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405C8@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Peter Willis'" <pjw@ip-engineering.bt.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?) 
Date: Mon, 5 Jun 2000 10:43:44 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

This looks like a good solution.

-Shahram

>-----Original Message-----
>From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
>Sent: Monday, June 05, 2000 12:55 PM
>To: Shahram Davari
>Cc: mpls@UU.NET
>Subject: Re: OAM labels (was: can egress know the ingress of a 
>packet?) 
>
>
>> Peter,
>> 
>> Sometimes OAM packets may need to be processed by 
>intermediate nodes as
>> well. By having the top label to be the forwarding label for 
>OAM packets, we
>> are forced to processing them only at the egress node.
>
>	OK can we do both? For most OAM functions I'm only interested in
>	OAM processing at the edge. Besides which if we require 
>intermediate
>	LSRs to process all OAM then this will not scale. However I do
>	admit in some circumstances I may like an intermediate node
>	to do something e.g. a LSP traceroute function.
>
>	Its just from experience I know that if the OAM/test 
>tools available
>	use packets that are not treated the same as the users 
>data packets
>	then the results are often doubtful (for example see 
>the misleading
>	results caused by using ping).
>> 
>> BTW, if the second label is OAM label, I don't think it will 
>cause any
>> implementation problem. Because the egress node before 
>popping the top
>> label, by looking at the S bit, knows that there is still 
>another label.
>
>	I was more thinking along the lines of; pop the outer label,
>	find its an OAM label, NOW I need to know the outer label to
>	process the OAM packet correctly but I've already used it and
>	lost it! 
>
>	Setting the S bit could also cause a minor problem. Presumably
>	the S bit in the user data label will be set but not in the
>	OAM data outer label. Hence if we have an implementation bug to
>	do with the operation of the S bit it would not be detected by
>	the OAM.
>
>Peter.
>> 
>> 
>> Regards,
>> -Shahram
>> 
>> >-----Original Message-----
>> >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
>> >Sent: Monday, June 05, 2000 12:27 PM
>> >To: Shahram Davari
>> >Cc: mpls@UU.NET
>> >Subject: Re: OAM labels (was: can egress know the ingress of a 
>> >packet?) 
>> >
>> >
>> >Shahram,
>> >
>> > Wouldn't it be better to have the top label
>> >as the one that is used for forwarding the OAM & user data and 
>> >the second 
>> >label the one that identifies an OAM flow within a particular 
>> >LSP? This way 
>> >the OAM
>> >data gets treated exactly the same as the user data by the 
>> >non-edge LSRs.
>> >Obviously the problem with this approach is that the 
>> >terminating LSR does not
>> >know it has an OAM packet until it has popped the outer label; 
>> >this may cause
>> >implementation problems (Does it?).
>> >
>> >If the OAM data is treated differently from the user data then 
>> >any faults in
>> >the user data plane may not be detected correctly. The 
>trouble with the
>> >Route Alert Label =1 type approach is that it is effectively 
>> >out-of-band;
>> >LSRs will treat this differently from user data which is not 
>> >what we want.
>> >
>> >Peter.
>> >
>> >> Peter,
>> >> 
>> >> But we can use two labels. The top label can be the reserved 
>> >one, and the
>> >> second label can be the actual label, which is used for 
>> >forwarding the OAM
>> >> packet. This is basically similar to the Router Alert Label = 1.
>> >> 
>> >> Regards,
>> >> -Shahram  
>> >> 
>> >> >-----Original Message-----
>> >> >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
>> >> >Sent: Monday, June 05, 2000 11:37 AM
>> >> >To: mpls@UU.NET
>> >> >Subject: RE: OAM labels (was: can egress know the ingress 
>> >of a packet?)
>> >> >
>> >> >
>> >> >
>> >> >An LSR will be terminating many LSPs so will be terminating 
>> >> >many OAM flows. 
>> >> >How do you correctly diagnose LSPs with merged or corrupted 
>> >> >labels if they all 
>> >> >arrive on the same reserved label? The label the OAM flow 
>> >> >arrives on has to 
>> >> >match exactly the label used for the data (user plane) flow in 
>> >> >order to be able
>> >> >to detect faults caused by LSRs using broken label 
>swapping tables.
>> >> >
>> >> >So we need a bit somewhere in the MPLS header to identify an 
>> >> >OAM payload but 
>> >> >we need to keep the same label as used for the user plane data.
>> >> >
>> >> >Peter.
>> >> >
>> >> >
>> >
>> >
>
>



From owner-mpls@UU.NET  Mon Jun  5 13:48:51 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07433
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 13:48:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishj11554;
	Mon, 5 Jun 2000 17:48:15 GMT
Received: by mail-control.mail.uu.net 
	id QQishj11535
	for mpls-outgoing; Mon, 5 Jun 2000 17:47:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQishj11530
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 17:47:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishj16798
	for <mpls@UU.NET>; Mon, 5 Jun 2000 13:47:23 -0400 (EDT)
Received: from bgslc02.TBG.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [199.104.68.2])
	id QQishj10920
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:47:23 GMT
Received: by bgslc02.tbg.com with Internet Mail Service (5.5.2448.0)
	id <MFRR6SXA>; Mon, 5 Jun 2000 11:40:51 -0600
Message-ID: <0C875DC28791D21192CD00104B95BFE76F6410@bgslc02.tbg.com>
From: Irwin Lazar <ILazar@tbg.com>
To: "'Manshaee Mohammad-Hossein'" <s7627237@sepahan.iut.ac.ir>
Cc: mpls@UU.NET
Subject: RE: RSVP/CR-LDP interoperability
Date: Mon, 5 Jun 2000 11:40:44 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-mpls@UU.NET
Precedence: bulk

We maintain a link to version 3 of that draft on the MPLS Resource Center.
See http://www.mplsrc.com/drafts.shtml


Irwin

-----Original Message-----
From: Manshaee Mohammad-Hossein [mailto:s7627237@sepahan.iut.ac.ir]
Sent: Monday, June 05, 2000 10:14 AM
To: Philip Matthews
Cc: Vikram Venkataraghavan; mpls@UU.NET
Subject: Re: RSVP/CR-LDP interoperability


Hi,

I want to find this DRAFT:

 [ATMVP]     "MPLS using ATM VP Switching", N. Feldman, B.
               Jamoussi, S. Komandur, A. Viswanathan, T. Worster,
               work in progress, Internet Draft <draft-feldman-mpls-
               atmvp-00.txt>, February, 1999.
I couldn't find it in IETF web site.

Can anybody help me!

yours,

MH Manshaee

On Mon, 5 Jun 2000, Philip Matthews wrote:

> > I'm supprised no one has mentioned:
> > draft-wright-mpls-crldp-rsvpte-iw-00.txt
> 
> Nortel plans to support RSVP-TE to CR-LDP interworking
> in its products. We put out the above draft to
> announce that. The -00 version is incomplete,
> a -01 version is in the works.
> 
> - Philip
> 


From owner-mpls@UU.NET  Mon Jun  5 13:54:44 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07576
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 13:54:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishj06130;
	Mon, 5 Jun 2000 17:54:03 GMT
Received: by mail-control.mail.uu.net 
	id QQishj12005
	for mpls-outgoing; Mon, 5 Jun 2000 17:53:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQishj11992
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 17:52:48 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishj04253
	for <mpls@uu.net>; Mon, 5 Jun 2000 13:52:32 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQishj14768
	for <mpls@uu.net>; Mon, 5 Jun 2000 17:52:31 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA01133
	for mpls@uu.net; Mon, 5 Jun 2000 13:52:30 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishj11860
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 17:51:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishj17638
	for <mpls@UU.NET>; Mon, 5 Jun 2000 13:51:38 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQishj04397
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:51:38 GMT
Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id MAA26251; Mon, 5 Jun 2000 12:50:57 -0500 (CDT)
Received: from tddny.fujitsu.com (pc185.tddny.fujitsu.com [167.254.242.185]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id M1SHT5Z2; Mon, 5 Jun 2000 12:50:59 -0500
Message-ID: <393BE880.EF82E775@tddny.fujitsu.com>
Date: Mon, 05 Jun 2000 13:50:56 -0400
From: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Willis <pjw@ip-engineering.bt.com>
CC: Shahram Davari <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <200006051627.RAA23571@celiborn.ip-engineering.bt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Peter:
I agree that OAM packets should not be forced to always
take the out-of-band path as in router alert.
In some PM applications (e.g., end-to-end transfer delay),
one may want to have OAM packets to be treated the same
way as data packets end-to-end.
indra


Peter Willis wrote:

> Shahram,
>
>  Wouldn't it be better to have the top label
> as the one that is used for forwarding the OAM & user data and the second
> label the one that identifies an OAM flow within a particular LSP? This way
> the OAM
> data gets treated exactly the same as the user data by the non-edge LSRs.
> Obviously the problem with this approach is that the terminating LSR does not
> know it has an OAM packet until it has popped the outer label; this may cause
> implementation problems (Does it?).
>
> If the OAM data is treated differently from the user data then any faults in
> the user data plane may not be detected correctly. The trouble with the
> Route Alert Label =1 type approach is that it is effectively out-of-band;
> LSRs will treat this differently from user data which is not what we want.
>
> Peter.
>
> > Peter,
> >
> > But we can use two labels. The top label can be the reserved one, and the
> > second label can be the actual label, which is used for forwarding the OAM
> > packet. This is basically similar to the Router Alert Label = 1.
> >
> > Regards,
> > -Shahram
> >
> > >-----Original Message-----
> > >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> > >Sent: Monday, June 05, 2000 11:37 AM
> > >To: mpls@UU.NET
> > >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> > >
> > >
> > >
> > >An LSR will be terminating many LSPs so will be terminating
> > >many OAM flows.
> > >How do you correctly diagnose LSPs with merged or corrupted
> > >labels if they all
> > >arrive on the same reserved label? The label the OAM flow
> > >arrives on has to
> > >match exactly the label used for the data (user plane) flow in
> > >order to be able
> > >to detect faults caused by LSRs using broken label swapping tables.
> > >
> > >So we need a bit somewhere in the MPLS header to identify an
> > >OAM payload but
> > >we need to keep the same label as used for the user plane data.
> > >
> > >Peter.
> > >
> > >




From owner-mpls@UU.NET  Mon Jun  5 14:02:49 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07765
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 14:02:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishk10906;
	Mon, 5 Jun 2000 18:00:39 GMT
Received: by mail-control.mail.uu.net 
	id QQishj12498
	for mpls-outgoing; Mon, 5 Jun 2000 17:59:45 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishj12491
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 17:59:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishj18944
	for <mpls@UU.NET>; Mon, 5 Jun 2000 13:59:22 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQishj09797
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:59:22 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id MAA13784;
	Mon, 5 Jun 2000 12:59:18 -0500 (CDT)
Received: from vsharma ([172.31.101.69] (may be forged))
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA10854;
	Mon, 5 Jun 2000 12:59:19 -0500 (CDT)
Received: by localhost with Microsoft MAPI; Mon, 5 Jun 2000 14:03:46 -0400
Message-ID: <01BFCEF6.DDCA90E0.Vishal.Sharma@tellabs.com>
From: Vishal Sharma <Vishal.Sharma@tellabs.com>
Reply-To: "Vishal.Sharma@tellabs.com" <Vishal.Sharma@tellabs.com>
To: "'yair@trellis-photonics.com'" <yair@trellis-photonics.com>,
        "mpls@UU.NET" <mpls@UU.NET>
Cc: "Ben Mack-Crane (E-mail)" <Ben.Mack-Crane@tellabs.fi>,
        "Chang Huang (E-mail)" <Changcheng.Huang@tellabs.com>,
        "Ken Owens (E-mail)" <ken.owens@tellabs.com>,
        "Srinivas Makam (E-mail)" <Srinivas.Makam@tellabs.com>
Subject: RE: MPLS protection/restoration
Date: Mon, 5 Jun 2000 14:03:44 -0400
Organization: Tellabs Research Center
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Hi Yair,

We currently have two drafts related to this one that we are working on.
The first is a revision of this draft, based on several comments and discussions
on the mailing list during May.
The second is a follow-on draft that specifies extensions to RSVP-TE to
implement the path protection mechanism specified in the first draft.

We hope to have the second draft out pretty soon, and a revision of the first one out within
the next 2-3 weeks.

Regards,
-Vishal

On Monday, June 05, 2000 8:35 AM, yair@trellis-photonics.com [SMTP:yair@trellis-photonics.com] 
wrote:
>
> hi,
> Is there something new regarding the draft of "Path Protection/Restoration
> Mechanism for MPLS Networks" -  <draft-chang-mpls-path-protection-00.txt. ?
> Thanks,
> Yair
>



From owner-mpls@UU.NET  Mon Jun  5 14:25:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08065
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 14:25:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishl07982;
	Mon, 5 Jun 2000 18:24:45 GMT
Received: by mail-control.mail.uu.net 
	id QQishl23701
	for mpls-outgoing; Mon, 5 Jun 2000 18:24:05 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQishl23696
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 18:23:57 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishl24074
	for <mpls@uu.net>; Mon, 5 Jun 2000 14:23:30 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQishl28402
	for <mpls@uu.net>; Mon, 5 Jun 2000 18:23:29 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA06421
	for mpls@uu.net; Mon, 5 Jun 2000 14:23:29 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQishl23649
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 18:22:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishl10474
	for <mpls@UU.NET>; Mon, 5 Jun 2000 14:22:28 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQishl27705
	for <mpls@UU.NET>; Mon, 5 Jun 2000 18:22:28 GMT
Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id NAA27755; Mon, 5 Jun 2000 13:14:49 -0500 (CDT)
Received: from tddny.fujitsu.com (pc185.tddny.fujitsu.com [167.254.242.185]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id M1SHT6FM; Mon, 5 Jun 2000 13:14:50 -0500
Message-ID: <393BEE17.7EE547D9@tddny.fujitsu.com>
Date: Mon, 05 Jun 2000 14:14:47 -0400
From: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Theimer Thomas <Thomas.Theimer@icn.siemens.de>
CC: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Peter Willis'" <pjw@ip-engineering.bt.com>, mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <3B59676F9ADBD211B5360060086E64EECC011A@MCHH237E>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thomas:
I think both end-to-end and hop-by-hop OAM packets as you mentioned
below should be supported.
A third possible way is segment OAM packets where you still want the
OAM packets to be treated the same way as data packets in the
segment connection. I believe this can be realized by using the first
approach plus a dedicated OAM bit. Is there a requirement for this?
indra


Theimer Thomas wrote:

> Actually, there are at least two ways to use such a reserved OAM label:
>
> - end-end OAM packets would have a label stack where the reserved
>   label is inserted below the original top label. After the top label is
>   popped at the egress node, the reserved label is processed by
>   forwarding the packet to OAM handling. Thus, all packets are
>   forwarded using the original top label. OAM packets are visible
>   only to ingress and egress nodes, and use exactly the same
>   path as user packets.
>
> - hop-by-hop OAM packets would have the reserved label pushed
>   on top of the original top label. Each LSR along the LSP would
>   then recognise the reserved top label, forward the packet to
>   OAM handling, and then forward the packet using the label
>   second on the label stack (the original top label).
>
> It may simplify things if two different reserved labels are defined
> for end-end and hop-by-hop OAM packets, if people feel that
> both are needed. The hop-hop case is really very similar to
> the router alert label.
>
> A dedicated OAM header bit would serve a similar purpose, but is
> not strictly required.
>
> Regards,
>
> Thomas Theimer
> > -----Original Message-----
> > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> > Sent: Monday, June 05, 2000 5:50 PM
> > To:   'Peter Willis'; mpls@UU.NET
> > Subject:      RE: OAM labels (was: can egress know the ingress of a
> > packet?)
> >
> > Peter,
> >
> > But we can use two labels. The top label can be the reserved one, and the
> > second label can be the actual label, which is used for forwarding the OAM
> > packet. This is basically similar to the Router Alert Label = 1.
> >
> > Regards,
> > -Shahram
> >
> > >-----Original Message-----
> > >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> > >Sent: Monday, June 05, 2000 11:37 AM
> > >To: mpls@UU.NET
> > >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> > >
> > >
> > >
> > >An LSR will be terminating many LSPs so will be terminating
> > >many OAM flows.
> > >How do you correctly diagnose LSPs with merged or corrupted
> > >labels if they all
> > >arrive on the same reserved label? The label the OAM flow
> > >arrives on has to
> > >match exactly the label used for the data (user plane) flow in
> > >order to be able
> > >to detect faults caused by LSRs using broken label swapping tables.
> > >
> > >So we need a bit somewhere in the MPLS header to identify an
> > >OAM payload but
> > >we need to keep the same label as used for the user plane data.
> > >
> > >Peter.
> > >
> > >




From owner-mpls@UU.NET  Mon Jun  5 17:32:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10869
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 17:32:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishy20098;
	Mon, 5 Jun 2000 21:31:13 GMT
Received: by mail-control.mail.uu.net 
	id QQishy03713
	for mpls-outgoing; Mon, 5 Jun 2000 21:30:46 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQishy03708
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 21:30:41 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishy16498
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:30:36 -0400 (EDT)
Received: from hawk.crescentnets.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.177.194.54])
	id QQishy04146
	for <mpls@UU.NET>; Mon, 5 Jun 2000 21:30:35 GMT
Received: from crescentnets.com (langille.in.crescentnets.com [192.168.29.105])
	by hawk.crescentnets.com (8.9.3/8.9.3) with ESMTP id RAA17045;
	Mon, 5 Jun 2000 17:30:31 -0400 (EDT)
Message-ID: <393C1C87.8EA9F261@crescentnets.com>
Date: Mon, 05 Jun 2000 17:32:55 -0400
From: Paul Langille <langille@crescentnets.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
CC: mpls@UU.NET, Cheenu Srinivasan <cheenu_s@yahoo.com>,
        arun Viswanathan <arun@force10networks.com>
Subject: Re: Additional Index for TE-MIB: mplsTunnelTable
References: <4.3.2.7.2.20000602142324.0467f5d0@bucket.cisco.com>
Content-Type: multipart/alternative;
 boundary="------------D8744A8354F98562BFAE16AC"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------D8744A8354F98562BFAE16AC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


    Hi Tom. I agree with you (and Mani) that you need the triplet <
Tunnel index, Tunnel Instance and Source address> to uniquely identify a
tunnel. Good catch.
    So now I am wondering, do you need the tunnel cookie (since it is
the source address and the tunnel index)? Could you also give some brief
examples as to how this would work with bi-directional tunnels. (I may
be a bit confused by the mplsTunnelDirection object.)

            Thanks
            Paul

"Thomas D. Nadeau" wrote:

>
>     Hi,
>
>      I would like to modify the mplsTunnelEntry to include
>      a few more objects as well as indexes. I wanted to
>      bring these changes to the list for discussion before
>      adding them to the TE MIB due to the fact that they
>      constitute a significant change, and we did not want to
>      surprise anyone. This change comes from my implementation
>      experience with the current version of the MIB, so it is
>      grounded in an actual implementation.
>
>      I would like to add five additional values to the mplsTunnelTable
>      as well as augment the current indexes with two more indexes:
>
>      mplsTunnelSrcAddrType     INTEGER,
>      mplsTunnelSrcAddrIPv4 InetAddresIPv4,
>      mplsTunnelSrcAddrIPv6 InetAddresIPv6,
>
>      Now let me explain why. When you want to examine the tunnel
>      entry at a midpoint, it is possible for tunnelId/tunnelInstance
>      collisions to occur because the mplsTunnelId + mplsTunnelInstance
>
>      variables are not guaranteed to be unique within an MPLS domain.
>      A simple example of this occurs when LSR A has tunnelId = 1,
>      tunnelInstance = 0 and LSR B has tunnelId = 1, tunnelInstance = 0
>
>      which utilize the same next hop, LSR C. If one examines the
>      tunnel table at LSR C, it is impossible to distinguish both
> tunnels;
>      hence, the third index. A fourth index is required because we
> need
>      to support V6 addresses.
>
>      An additional benefit of the added indexes is that one can now
>      sort tunnelEntries based on src address, which is quite useful
>      at mid-points and tunnel tails. For this same reason, it might be
>
>      useful to add the tunnel destination address to the indexes of
>      this table as well.
>
>      --Tom

--
Paul Langille                e-mail: langille@crescentnets.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824


--------------D8744A8354F98562BFAE16AC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>&nbsp;&nbsp;&nbsp; Hi Tom. I agree with you (and Mani) that you need
the triplet &lt; Tunnel index, Tunnel Instance and Source address> to uniquely
identify a tunnel. Good catch.
<br>&nbsp;&nbsp;&nbsp; So now I am wondering, do you need the tunnel cookie
(since it is the source address and the tunnel index)? Could you also give
some brief examples as to how this would work with bi-directional tunnels.
(I may be a bit confused by the mplsTunnelDirection object.)
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thanks
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Paul
<p>"Thomas D. Nadeau" wrote:
<blockquote TYPE=CITE>&nbsp;
<br>&nbsp;&nbsp;&nbsp; Hi,
<dl>
<dd>
I would like to modify the mplsTunnelEntry to include</dd>

<dd>
a few more objects as well as indexes. I wanted to</dd>

<dd>
bring these changes to the list for discussion before</dd>

<dd>
adding them to the TE MIB due to the fact that they</dd>

<dd>
constitute a significant change, and we did not want to</dd>

<dd>
surprise anyone. This change comes from my implementation</dd>

<dd>
experience with the current version of the MIB, so it is</dd>

<dd>
grounded in an actual implementation.</dd>

<br>&nbsp;
<dd>
I would like to add five additional values to the mplsTunnelTable</dd>

<dd>
as well as augment the current indexes with two more indexes:</dd>

<br>&nbsp;
<dd>
mplsTunnelSrcAddrType&nbsp;&nbsp;&nbsp;&nbsp; INTEGER,</dd>

<dd>
mplsTunnelSrcAddrIPv4<x-tab>&nbsp;</x-tab>InetAddresIPv4,</dd>

<dd>
mplsTunnelSrcAddrIPv6<x-tab>&nbsp;</x-tab>InetAddresIPv6,</dd>
</dl>
&nbsp;&nbsp;&nbsp;&nbsp; Now let me explain why. When you want to examine
the tunnel
<br>&nbsp;&nbsp;&nbsp;&nbsp; entry at a midpoint, it is possible for tunnelId/tunnelInstance
<br>&nbsp;&nbsp;&nbsp;&nbsp; collisions to occur because the mplsTunnelId
+ mplsTunnelInstance
<br>&nbsp;&nbsp;&nbsp;&nbsp; variables are not guaranteed to be unique
within an MPLS domain.
<br>&nbsp;&nbsp;&nbsp;&nbsp; A simple example of this occurs when LSR A
has tunnelId = 1,
<br>&nbsp;&nbsp;&nbsp;&nbsp; tunnelInstance = 0 and LSR B has tunnelId
= 1, tunnelInstance = 0
<br>&nbsp;&nbsp;&nbsp;&nbsp; which utilize the same next hop, LSR C. If
one examines the
<br>&nbsp;&nbsp;&nbsp;&nbsp; tunnel table at LSR C, it is impossible to
distinguish both tunnels;
<br>&nbsp;&nbsp;&nbsp;&nbsp; hence, the third index. A fourth index is
required because we need
<br>&nbsp;&nbsp;&nbsp;&nbsp; to support V6 addresses.
<p>&nbsp;&nbsp;&nbsp;&nbsp; An additional benefit of the added indexes
is that one can now
<br>&nbsp;&nbsp;&nbsp;&nbsp; sort tunnelEntries based on src address, which
is quite useful
<br>&nbsp;&nbsp;&nbsp;&nbsp; at mid-points and tunnel tails. For this same
reason, it might be
<br>&nbsp;&nbsp;&nbsp;&nbsp; useful to add the tunnel destination address
to the indexes of
<br>&nbsp;&nbsp;&nbsp;&nbsp; this table as well.
<p>&nbsp;&nbsp;&nbsp;&nbsp; --Tom</blockquote>
--
<br>Paul Langille&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
e-mail: langille@crescentnets.com
<br>Crescent Networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
phone: (978) 244-9002 x244
<br>201 Riverneck Road&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fax: (978) 244-9211
<br>Chelmsford, MA 01824
<br>&nbsp;</html>

--------------D8744A8354F98562BFAE16AC--



From owner-mpls@UU.NET  Mon Jun  5 17:39:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10923
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 17:39:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishy09676;
	Mon, 5 Jun 2000 21:38:57 GMT
Received: by mail-control.mail.uu.net 
	id QQishy04240
	for mpls-outgoing; Mon, 5 Jun 2000 21:38:33 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQishy04235
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 21:38:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQishy02048
	for <mpls@uu.net>; Mon, 5 Jun 2000 17:38:13 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQishy09053
	for <mpls@uu.net>; Mon, 5 Jun 2000 21:38:13 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA05781
	for mpls@uu.net; Mon, 5 Jun 2000 17:38:12 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishy04216
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 21:37:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishy01953
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:37:39 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQishy26557
	for <mpls@UU.NET>; Mon, 5 Jun 2000 21:37:39 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA24060; Mon, 5 Jun 2000 17:37:07 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAB01358;
	Mon, 5 Jun 2000 17:36:37 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000605173329.0753b0d0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 05 Jun 2000 17:35:25 -0400
To: Paul Langille <langille@crescentnets.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Additional Index for TE-MIB: mplsTunnelTable
Cc: mpls@UU.NET, Cheenu Srinivasan <cheenu_s@yahoo.com>,
        arun Viswanathan <arun@force10networks.com>
In-Reply-To: <393C1C87.8EA9F261@crescentnets.com>
References: <4.3.2.7.2.20000602142324.0467f5d0@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi Paul,

>     Hi Tom. I agree with you (and Mani) that you need the triplet < 
> Tunnel index, Tunnel Instance and Source address> to uniquely identify a 
> tunnel. Good catch.

         Thanks.

>     So now I am wondering, do you need the tunnel cookie (since it is the 
> source address and the tunnel index)?

         I believe that we are going to eliminate the cookies from the MIB.
There was some discussion about this a while back.

>Could you also give some brief examples as to how this would work with
>bi-directional tunnels. (I may be a bit confused by the
>mplsTunnelDirection object.)

         Do you still need the example now that you know that the
cookie is deleted, or were you referring to the addition of the
srcAddr to the index?

         --Tom





From owner-mpls@UU.NET  Mon Jun  5 17:45:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10999
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 17:45:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishy03639;
	Mon, 5 Jun 2000 21:44:58 GMT
Received: by mail-control.mail.uu.net 
	id QQishy04669
	for mpls-outgoing; Mon, 5 Jun 2000 21:44:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishy04656
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 21:44:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishy03098
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:43:55 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQishy02593
	for <mpls@UU.NET>; Mon, 5 Jun 2000 21:43:54 GMT
Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP;
          Mon, 5 Jun 2000 22:42:35 +0100
Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2651.88) 
          id <MCGW7269>; Mon, 5 Jun 2000 22:42:41 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16018@mbddmknt01.hc.bt.com>
To: Shahram_Davari@pmc-sierra.com, EGray@zaffire.com, swtan@mmu.edu.my,
        kireeti@juniper.net, dwilder@baynetworks.com
Cc: mpls@UU.NET
Subject: RE: can egress know the ingress of a packet?
Date: Mon, 5 Jun 2000 22:42:36 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Sharam and thanks for support,

You observed:
	>	Why don't we assign/reserve some Label
	values to be used only by OAM packets. This is very analogous to
ATM, in
	which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI
=0-15).
	For example we could assign Label = 0 for the Keepalive messages
that you
	described.

Before I looked at the TTL option, this was the basis of what I had
orginally planned.  In my orginal analysis I considered parsing the label
field into a 16 bit true label field and a 4 bit payload ID field.  But if
we assume the client layer protocol is temporally invariant we really don't
need a payload ID.......this is implied at label assignment time.  So 4 bits
is perhaps overkill and just 1 bit would do.  My orginal intention was to
use this codepoint(s) to identify the 1st octet of the payload as an OAM
pkt, and then the 1st octet would specify the specific OAM functionality.

Another option, which is what I think you and Thomas Theimer are suggesting,
is to assign a special OAM 'alert' label.  This seems OK, and the only
downside is that we get 2 stacked labels for each OAM pkt but only 1 label
for the traffic at LSP level N.......but that does not seem such a problem
(as the OAM BW should be kept small anyway).  After such an indentification
mechanism the OAM processing would be as above, ie look at 1st OAM pkt octet
to determine function.

Note - I have extensive experience of ATM OAM and I want to avoid all the
problems that happened with this.  In the work I have looked at for MPLS,
the OAM functions are pared to the absolute minmimum whilst delivering
maximum benefit.  I would need to show you my work though to explain better.

Many thanks for offer to help with drafting (are you any good at state
diagrams in ASCII?!!!).  

Regards, Neil



From owner-mpls@UU.NET  Mon Jun  5 17:45:44 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11021
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 17:45:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQishz13882;
	Mon, 5 Jun 2000 21:45:15 GMT
Received: by mail-control.mail.uu.net 
	id QQishy04672
	for mpls-outgoing; Mon, 5 Jun 2000 21:44:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQishy04657
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 21:44:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQishy03102
	for <mpls@UU.NET>; Mon, 5 Jun 2000 17:43:55 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQishy02598
	for <mpls@UU.NET>; Mon, 5 Jun 2000 21:43:55 GMT
Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP;
          Mon, 5 Jun 2000 22:42:36 +0100
Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWBDW2M>; Mon, 5 Jun 2000 22:42:38 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16019@mbddmknt01.hc.bt.com>
To: otel@ce.chalmers.se, Shahram_Davari@pmc-sierra.com
Cc: EGray@zaffire.com, swtan@mmu.edu.my, kireeti@juniper.net,
        dwilder@baynetworks.com, mpls@UU.NET
Subject: RE: OAM functionality 
         (Was: RE: can egress know the ingress of a packet?)
Date: Mon, 5 Jun 2000 22:42:38 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Florian,

I have been involved with much of the recent ATM OAM work.......but came in
late in the day when, unfortunately, it was too late to change the stds
(though believe me we tried).  Its a very complex story and I don't want to
waste people's time by going through its history here (speak to me privately
if you want the details).  But in essence, there are too many optional OAM
combinations and not enough thought was given early enough to the basic
architectural OAM functional relationships (especially harmonised defect
state handling at near-end and far-end of trails)......which is why after
many years (maybe 8 or so) we do not even have any agreement of how to
measure availability on ATM trails (and which also means, as a by-product,
that the up-state-only QoS measurements can become worthless).

Based on this experience, and working closely with my IP network design
colleagues, we have pared down our functional requirements (and their
manifestation as OAM pkts) to what we believe are the essential minimal in
order to (i) allow operations people to maintain and fault-find and (ii)
protect customer traffic from wrong delivery under various connectivity
failure scenarios.

I really ought to get something drafted so that other people can more
constructively criticise it......there may indeed be better ways to provide
the functionality we would like to see.   I will try and do something over
the next few weeks or so and circulate to those who have expressed an
interest so far. 

Regards, Neil

> -----Original Message-----
> From:	Florian-Daniel Otel [SMTP:otel@ce.chalmers.se]
> Sent:	Monday, June 05, 2000 3:41 PM
> To:	Shahram Davari
> Cc:	'neil.2.harrison@bt.com'; EGray@zaffire.com; swtan@mmu.edu.my;
> kireeti@juniper.net; dwilder@baynetworks.com; mpls@UU.NET
> Subject:	OAM functionality (Was: RE: can egress know the ingress of a
> packet?)
> 
> 
> Sharam,
> 
> > Hi Neil,
> 
> > I also think we need some sort of OAM function at MPLS layer. And as you
> > said, to be able to process OAM cells, they must be recognized by LSRs.
> But
> > it might be hard to change the definition of TTL field at this point in
> > time. So I have a different proposal. Why don't we assign/reserve some
> Label
> > values to be used only by OAM packets. This is very analogous to ATM, in
> > which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI
> =0-15).
> > For example we could assign Label = 0 for the Keepalive messages that
> you
> > described.
> 
> > I am interested in writing such an I-D, and in fact my company is expert
> in
> > ATM OAM, so we could leverage that knowledge for the MPLS OAM.
> 
> As Neil already pointed out, there are several people intrested in O&M 
> functionality in MPLS, and for several reasons (you can also check the
> discussion between Neil and Vishal on TEwg mailing list on 17 Apr &
> ff. I also had some off-list questions about it). 
> 
> But the impression i got (and please, someone correct me if I'm wrong) 
> is that, as the Theimer OAM requirements draft clearly states:
> 
> "[..]we do not intend to simply adopt the OAM functions and procedures
> previously defined  for other technologies (in particular ATM), as
> this would probably lead to very complex and expensive
> implementations[..]"
> 
> 
> 
> Putting it bluntly, the way i read this is that "we simply don't want
> to turn MPLS into ATM-2 by adding all possible types of OAM functions".
> 
> 
> So, my take is (and, by all means, please correct me if i'm wrong)
> that in addition to the (rather vague IMHO) Theimer draft there you
> have all other proposals for recovery, protection, restoration and
> loop prevention but no other general O&M spec than the above
> draft. Why is that and how to solve (if ever need be) the OAM
> needs...well, that's it's beyond my knowledge (and the reason I'm 
> asking about it here).
> 
> 
> My $0.02 worth.
> 
> With kind regards,
> 
> Florian.


From owner-mpls@UU.NET  Mon Jun  5 18:20:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11735
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 18:20:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisib08070;
	Mon, 5 Jun 2000 22:20:27 GMT
Received: by mail-control.mail.uu.net 
	id QQisib15949
	for mpls-outgoing; Mon, 5 Jun 2000 22:20:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisib15941
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 22:20:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisib09110
	for <mpls@UU.NET>; Mon, 5 Jun 2000 18:19:52 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQisib05640
	for <mpls@UU.NET>; Mon, 5 Jun 2000 22:19:51 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id SAA01455; Mon, 5 Jun 2000 18:19:42 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id SAA12866;
	Mon, 5 Jun 2000 18:19:37 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006052219.SAA12866@curtis-lt.avici.com>
To: "tom worster" <tom@ennovatenetworks.com>
cc: "'Bora Akyol'" <akyol@pluris.com>, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS Diffserv Extensions related questions/comments 
In-reply-to: Your message of "Fri, 02 Jun 2000 11:20:04 EDT."
             <000c01bfcca6$07841f80$7503010a@ennovatenetworks.com> 
Date: Mon, 05 Jun 2000 18:19:37 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <000c01bfcca6$07841f80$7503010a@ennovatenetworks.com>, "tom worster"
 writes:
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora Akyol
> > 
> > 8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
> > etc while this
> > spec was being written? This actually is one of my biggest 
> > gripes about
> > Diffserv. It is so damn flexible which makes almost any HW 
> > implementation
> > leave out features, maybe we should have started something 
> > that was concrete
> > and implementable.
> 
> speaking of hardware... the requirement in diff-ext-04 for 
> support of exp->phb mappings on a per lsp basis set by 
> signalling does not really seem to be "hardware cost
> friendly," so to speak. does anyone really need an arbitrary
> mapping for each lsp?
> 
> c u
> tom


IMHO this will be useful.

It isn't really that hard.  Implementations exist.  (At least one that
I know of).

Curtis



From owner-mpls@UU.NET  Mon Jun  5 18:43:54 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12120
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 18:43:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisic23928;
	Mon, 5 Jun 2000 22:43:13 GMT
Received: by mail-control.mail.uu.net 
	id QQisic17599
	for mpls-outgoing; Mon, 5 Jun 2000 22:42:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisic17594
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 22:42:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisic28243
	for <mpls@UU.NET>; Mon, 5 Jun 2000 18:42:19 -0400 (EDT)
Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63])
	id QQisic24588
	for <mpls@UU.NET>; Mon, 5 Jun 2000 22:42:19 GMT
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
	id <KG0FPRD8>; Mon, 5 Jun 2000 15:39:49 -0700
Message-ID: <337055FBC675D311A85D00508B5A9C4F2542DE@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
	 <sergio.catanzariti@rd.francetelecom.com>
To: "'curtis@avici.com'" <curtis@avici.com>
Cc: "'Bora Akyol'" <akyol@pluris.com>, mpls@UU.NET,
        tom worster
	 <tom@ennovatenetworks.com>
Subject: RE: MPLS Diffserv Extensions related questions/comments 
Date: Mon, 5 Jun 2000 15:39:48 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFCF3E.F48D82E0"
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_01BFCF3E.F48D82E0
Content-Type: text/plain

I agree that it would be actually very helpful. I would like to build
topology-driven LSPs and use EXP-PHBs stuff for differentiating CoS-like
traffic.
I do not understand the "hardware cost friendly" problem. The real issue
here is to have a flexible LSPs management/control plane (I do not
understand where the signalling problem is in all this) that would allow me
to do it in a simple, and semantically congruous manner.
It should not be that hard, at least at the provisioning level, and I guess
I saw it already but I do not recall now which vendor was it :-).

Sergio

> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com 
> --------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From:	Curtis Villamizar [SMTP:curtis@avici.com]
> Sent:	Monday, June 05, 2000 3:20 PM
> To:	tom worster
> Cc:	'Bora Akyol'; mpls@UU.NET
> Subject:	Re: MPLS Diffserv Extensions related questions/comments 
> 
> 
> In message <000c01bfcca6$07841f80$7503010a@ennovatenetworks.com>, "tom
> worster"
>  writes:
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora
> Akyol
> > > 
> > > 8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
> > > etc while this
> > > spec was being written? This actually is one of my biggest 
> > > gripes about
> > > Diffserv. It is so damn flexible which makes almost any HW 
> > > implementation
> > > leave out features, maybe we should have started something 
> > > that was concrete
> > > and implementable.
> > 
> > speaking of hardware... the requirement in diff-ext-04 for 
> > support of exp->phb mappings on a per lsp basis set by 
> > signalling does not really seem to be "hardware cost
> > friendly," so to speak. does anyone really need an arbitrary
> > mapping for each lsp?
> > 
> > c u
> > tom
> 
> 
> IMHO this will be useful.
> 
> It isn't really that hard.  Implementations exist.  (At least one that
> I know of).
> 
> Curtis

------_=_NextPart_001_01BFCF3E.F48D82E0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: MPLS Diffserv Extensions related questions/comments </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree that it would be actually very =
helpful. I would like to build topology-driven LSPs and use EXP-PHBs =
stuff for differentiating CoS-like traffic.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I do not understand the &quot;hardware =
cost friendly&quot; problem. The real issue here is to have a flexible =
LSPs management/control plane (I do not understand where the signalling =
problem is in all this) that would allow me to do it in a simple, and =
semantically congruous manner.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It should not be that hard, at least =
at the provisioning level, and I guess I saw it already but I do not =
recall now which vendor was it :-).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sergio</FONT>
</P>
<UL>
<P><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sergio =
Catanzariti</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Senior Project =
Manager, Technology Integration</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">France Telecom =
R&amp;D </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">1000 Marina =
Boulevard Suite 300 </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brisbane CA =
94005</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tel. =
650-875-1526</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Fax. =
650-875-1505</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">email:sergio.catanzariti@rd.francetelecom.com =
</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
</P>
<BR>

<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Curtis Villamizar =
[SMTP:curtis@avici.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Monday, June 05, 2000 3:20 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">tom worster</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'Bora Akyol'; mpls@UU.NET</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: MPLS Diffserv Extensions related =
questions/comments </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">In message =
&lt;000c01bfcca6$07841f80$7503010a@ennovatenetworks.com&gt;, &quot;tom =
worster&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;writes:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; From: owner-mpls@UU.NET =
[<U></U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New"><A =
HREF=3D"mailto:owner-mpls@UU.NET">mailto:owner-mpls@UU.NET</A>]On</FONT>=
</U><FONT SIZE=3D2 FACE=3D"Courier New"> Behalf Of Bora Akyol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; 8. THIS IS A GRIPE. =
Did anyone consider hardware pipelining, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; etc while this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; spec was being =
written? This actually is one of my biggest </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; gripes about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; Diffserv. It is so =
damn flexible which makes almost any HW </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; implementation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; leave out features, =
maybe we should have started something </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; that was =
concrete</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &gt; and =
implementable.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; speaking of hardware... =
the requirement in diff-ext-04 for </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; support of exp-&gt;phb =
mappings on a per lsp basis set by </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; signalling does not really =
seem to be &quot;hardware cost</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; friendly,&quot; so to =
speak. does anyone really need an arbitrary</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; mapping for each =
lsp?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; c u</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; tom</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">IMHO this will be useful.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">It isn't really that hard.&nbsp; =
Implementations exist.&nbsp; (At least one that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">I know of).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Curtis</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCF3E.F48D82E0--


From owner-mpls@UU.NET  Mon Jun  5 18:46:50 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12158
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 18:46:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisic25563;
	Mon, 5 Jun 2000 22:43:57 GMT
Received: by mail-control.mail.uu.net 
	id QQisic17618
	for mpls-outgoing; Mon, 5 Jun 2000 22:43:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisic17612
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 22:43:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisic28369
	for <mpls@UU.NET>; Mon, 5 Jun 2000 18:43:16 -0400 (EDT)
Received: from mail.krioukov.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cj114416-a.reston1.va.home.com [24.15.191.36])
	id QQisic24030
	for <mpls@UU.NET>; Mon, 5 Jun 2000 22:43:16 GMT
Received: from VA1ENG128 (fw-1.winstar.com [207.86.108.130])
	by mail.krioukov.net (8.9.3/8.9.3) with SMTP id SAA03147;
	Mon, 5 Jun 2000 18:25:43 -0400
From: "Dmitri Krioukov" <dima@krioukov.net>
To: "Juha Heinanen" <jh@lohi.eng.telia.fi>,
        "Loa Andersson" <loa.andersson@nortelnetworks.com>
Cc: "Grenville Armitage" <gja@dnrc.bell-labs.com>, <mpls@UU.NET>,
        <smd@ebone.net>, <akyol@pluris.com>
Subject: RE: MPLS Performance analysis.....
Date: Mon, 5 Jun 2000 18:57:46 -0400
Message-ID: <NCBBIKACLKNMKDHKKKNFKEBAELAA.dima@krioukov.net>
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 V5.00.2919.6700
Importance: Normal
In-Reply-To: <14651.52196.591746.497839@lohi.eng.telia.fi>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

i'd like to hear any points of view of the members
of this list on motivation #1 (te) accompanied
with some far going criticism to this reference:
http://smg.ulb.ac.be/Preprints/Fortz99_29.html
(it was brought up to discussion on nanog
mailing list recently).

i understand that the major assumption in this paper
(about the demand matrix availability) is too
brave, but this paper is a major indication
that the te-related research beyond the ever
lasting vc reinvention approach has not been
exhausted yet. clearly, you wouldn't need any
external signaling mechanism if all benefits
te brings you (congestion avoidance, qos, etc)
may be achieved by means of some (rather
futuristic at this point) routing protocol.

at the very general level, the packet switched
networks proved to provide much higher level of
adaptation to the new requirements. since the
packet switched networks are theoretically
more complex than circuit switched ones, the way
to adapt to a new requirement (te) may not be obvious
until some significant research effort is done. this
does not mean that we have to avoid this effort since
the easy way may not lead anywhere...

the interesting point would be that ip was created
as a result of significant, well-funded academic
research effort. i'm not sure if the same was true
with respect to the osi stack.
--
dima.

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha
> Heinanen
> Sent: Monday, June 05, 2000 11:49 AM
> To: Loa Andersson
> Cc: Grenville Armitage; mpls@UU.NET
> Subject: Re: MPLS Performance analysis.....
>
>
> Loa Andersson writes:
>
>  > To my recollection there were at least 4 different motivations for
>  > developing MPLS
>  >
>  > 1. We needed TE-capabilities in IP networks (constraint based routing).
>  >
>  > 2. A tunnel mechanism for VPNs.
>  >
>  > 3. "Creating IP routers of ATM-switches"
>  >
>  > 4. Capacity increase.
>
> te became late to the table.  in the early ietf mlps bofs, cisco was
> pushing mpls (ldp) as a means to automatically set up a full mesh of vcs
> between routers in a more scalable way than what could be achieved by
> atm (both in terms of number of routing peers and number of vcs legs).
> forgot the silly ingress vs. egress control debates?  i tried to promote
> mpls as a fourth generation general purpose connection oriented protocol
> to replace fr and atm, but didn't get much support until the te
> application poped up.
>
> -- juha



From owner-mpls@UU.NET  Mon Jun  5 19:53:58 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12766
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 19:53:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisih15256;
	Mon, 5 Jun 2000 23:53:05 GMT
Received: by mail-control.mail.uu.net 
	id QQisih00499
	for mpls-outgoing; Mon, 5 Jun 2000 23:52:51 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisih00494
	for <mpls@mail-control.mail.uu.net>; Mon, 5 Jun 2000 23:52:37 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisih08070
	for <mpls@UU.NET>; Mon, 5 Jun 2000 19:52:33 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQisih14687
	for <mpls@UU.NET>; Mon, 5 Jun 2000 23:52:33 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07340;
	Mon, 5 Jun 2000 16:51:36 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id QAA01279; Mon, 5 Jun 2000 16:51:36 -0700 (PDT)
Date: Mon, 5 Jun 2000 16:51:36 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006052351.QAA01279@kummer.juniper.net>
To: dwilder@baynetworks.com, EGray@zaffire.com, kireeti@juniper.net,
        neil.2.harrison@bt.com, Shahram_Davari@pmc-sierra.com,
        swtan@mmu.edu.my
Subject: Signalling O&M MPLS packets
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Neil,

> Before I looked at the TTL option, this was the basis of what I had
> orginally planned.  In my orginal analysis I considered parsing the label
> field into a 16 bit true label field and a 4 bit payload ID field.

Before we go too far down the "TTL option" path (or reinterpreting
the label bits), consider the fact that the format of a label is
pretty much fixed; there are MPLS networks carrying production
traffic with this label format, as well as various protocol stacks
and hardware designs that incorporate this label format.

A change in the interpretation of the TTL field (or any other bits
in a label) at this point is not something to be undertaken lightly.

> Another option, which is what I think you and Thomas Theimer are suggesting,
> is to assign a special OAM 'alert' label.

This is a much more acceptable approach.

Thanks,
Kireeti.


From owner-mpls@UU.NET  Mon Jun  5 20:31:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12966
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 20:31:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisik13429;
	Tue, 6 Jun 2000 00:31:03 GMT
Received: by mail-control.mail.uu.net 
	id QQisik11480
	for mpls-outgoing; Tue, 6 Jun 2000 00:30:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisik11475
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 00:30:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisik26231
	for <mpls@UU.NET>; Mon, 5 Jun 2000 20:30:07 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQisik12979
	for <mpls@UU.NET>; Tue, 6 Jun 2000 00:30:07 GMT
Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP;
          Tue, 6 Jun 2000 01:29:32 +0100
Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWBD5NT>; Tue, 6 Jun 2000 01:29:34 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B1601F@mbddmknt01.hc.bt.com>
To: kireeti@juniper.net
Cc: mpls@UU.NET
Subject: RE: Signalling O&M MPLS packets
Date: Tue, 6 Jun 2000 01:29:39 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Kireeti,

Thanks for this observation on backwards compatibility below.
	Before we go too far down the "TTL option" path (or reinterpreting
	the label bits), consider the fact that the format of a label is
	pretty much fixed; there are MPLS networks carrying production
	traffic with this label format, as well as various protocol stacks
	and hardware designs that incorporate this label format.

	A change in the interpretation of the TTL field (or any other bits
	in a label) at this point is not something to be undertaken lightly.

	> Another option, which is what I think you and Thomas Theimer are
suggesting,
	> is to assign a special OAM 'alert' label.

	This is a much more acceptable approach.

 I fully agree we should not do anything which is not essential for this
reason.

Regards, Neil



> Thanks,
> Kireeti.


From owner-mpls@UU.NET  Mon Jun  5 22:27:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14551
	for <mpls-archive@lists.ietf.org>; Mon, 5 Jun 2000 22:27:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisir05122;
	Tue, 6 Jun 2000 02:25:39 GMT
Received: by mail-control.mail.uu.net 
	id QQisir05411
	for mpls-outgoing; Tue, 6 Jun 2000 02:25:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisir05398
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 02:24:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisir09121
	for <mpls@UU.NET>; Mon, 5 Jun 2000 22:24:43 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQisir01889
	for <mpls@UU.NET>; Tue, 6 Jun 2000 02:24:43 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id WAA13647; Mon, 5 Jun 2000 22:23:31 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id WAA13395;
	Mon, 5 Jun 2000 22:23:48 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006060223.WAA13395@curtis-lt.avici.com>
To: "Dmitri Krioukov" <dima@krioukov.net>
cc: "Juha Heinanen" <jh@lohi.eng.telia.fi>,
        "Loa Andersson" <loa.andersson@nortelnetworks.com>,
        "Grenville Armitage" <gja@dnrc.bell-labs.com>, mpls@UU.NET,
        smd@ebone.net, akyol@pluris.com
Reply-To: curtis@avici.com
Subject: Re: MPLS Performance analysis..... 
In-reply-to: Your message of "Mon, 05 Jun 2000 18:57:46 EDT."
             <NCBBIKACLKNMKDHKKKNFKEBAELAA.dima@krioukov.net> 
Date: Mon, 05 Jun 2000 22:23:48 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <NCBBIKACLKNMKDHKKKNFKEBAELAA.dima@krioukov.net>, "Dmitri Krioukov" 
writes:
> i'd like to hear any points of view of the members
> of this list on motivation #1 (te) accompanied
> with some far going criticism to this reference:
> http://smg.ulb.ac.be/Preprints/Fortz99_29.html
> (it was brought up to discussion on nanog
> mailing list recently).
> 
> i understand that the major assumption in this paper
> (about the demand matrix availability) is too
> brave, but this paper is a major indication
> that the te-related research beyond the ever
> lasting vc reinvention approach has not been
> exhausted yet. clearly, you wouldn't need any
> external signaling mechanism if all benefits
> te brings you (congestion avoidance, qos, etc)
> may be achieved by means of some (rather
> futuristic at this point) routing protocol.
> 
> at the very general level, the packet switched
> networks proved to provide much higher level of
> adaptation to the new requirements. since the
> packet switched networks are theoretically
> more complex than circuit switched ones, the way
> to adapt to a new requirement (te) may not be obvious
> until some significant research effort is done. this
> does not mean that we have to avoid this effort since
> the easy way may not lead anywhere...
> 
> the interesting point would be that ip was created
> as a result of significant, well-funded academic
> research effort. i'm not sure if the same was true
> with respect to the osi stack.
> --
> dima.


Dima,

Since you've asked for a quick review ...

I've seen a paper related to this work by other AT&T authors
(unpublished) that produced a formal proof that for topologies with
given constraints OSPF costs could be set sufficiently well that there
was no benefit to MPLS-TE.  Unfortunately the constraints are violated
by too many topologies and building to them is impractical so that
other paper may remain unpublished.

Even where OSPF and MPLS perform nearly as well when everything is up,
when a link fails and the OSPF costs can be very suboptimal.  The
MPLS-TE might converge to a near optimal solution faster than the OSPF
weights could all be changed by an external system.  There was also
the very real possibility of multiple link failures which is always
troublesome for techniques which rely on precomputed costs for any
given single failure.

The AT&T approach outlined here may be very well suited for AT&T's
immediate needs.  OSPF is a very stable protocol whose behaviour is
well understood and implementations tend to be very reliable.  MPLS
may gain an efficiency advantage as a network topology become a more
of a dense mesh and this advantage becomes more important as a network
becomes very heavily utilized.  OTOH, a TE implementation may converge
to a result which is also quite poor and may be fairly unpredictable
(ie: layout efficiency depending on order in which LSPs are restored).

Given a relatively simple and well provisioned network topology and a
desire to stick with conservative design to acheive high reliability
this approach is a good choice.  As MPLS implementations mature, the
risk of deploying MPLS is lowered.  As risk lowers and if topology
becomes more complex and high utilizations raise efficiency concerns,
it may become advantageous to use MPLS TE.

There are some very smart people at AT&T.  This is both a good
acedemic paper and the practicality of the approach for many
circumstances makes it also a practical and relevant paper.

btw- Thanks for the pointer.  I wasn't aware that this was submitted
for publication.

Curtis

> the interesting point would be that ip was created
> as a result of significant, well-funded academic
> research effort. i'm not sure if the same was true
> with respect to the osi stack.

ps- Quite a bit of money was poured into OSI, much of it by commercial
interests including the US telcos and European PTTs.  IP and the
NSFNET was not all that well funded if you consider that most of the
funding went into operating a network.  NSF put $15M/year into the
T3NSFNET backbone at peak if my memory serves well.  I think that
exceeded even the IETF chocolate chip cookie expenses by a significant
margin.  It wasn't until a few years into commercialization that IP
networks began playing with real money by government standards.  Its
interesting to note that the whole NSFNET program was more than paid
for in taxes resulting from the commercialization of the Internet.  :-)


From owner-mpls@UU.NET  Tue Jun  6 02:24:56 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28975
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 02:24:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisjh21724;
	Tue, 6 Jun 2000 06:24:08 GMT
Received: by mail-control.mail.uu.net 
	id QQisjh23788
	for mpls-outgoing; Tue, 6 Jun 2000 06:23:45 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisjh23783
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 06:23:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisjh23015
	for <mpls@UU.NET>; Tue, 6 Jun 2000 02:23:36 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQisjh19285
	for <mpls@UU.NET>; Tue, 6 Jun 2000 06:20:24 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id LAA24804
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:45:07 -0600 (GMT)
Message-ID: <009d01bfcf7f$5392f780$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: Knowing Egress LER using LDP
Date: Tue, 6 Jun 2000 11:50:27 +0530
Organization: Daewoo Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009A_01BFCFAD.68171BE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_009A_01BFCFAD.68171BE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello
    I came across the following in "draft-ietf-mpls-arch-06.txt". In =
Section "4.1.6. Option: Egress-Targeted Label Assignment" page 43 it =
says

-------------------------------------------------------------------------=
---------------------------------------------------
     - It is possible to use the label distribution protocol to pass
       information about which address prefixes are "attached" to which
       egress LSRs.  This method has the advantage of not depending on
       the presence of link state routing.
-------------------------------------------------------------------------=
------------------------------------------------------

This implies Ingress LER can determine the Egress LER for each address =
prefix. Can someone point out how this could possibly be done using LDP =
?=20


santosh



------=_NextPart_000_009A_01BFCFAD.68171BE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hello</DIV>
<DIV>&nbsp;&nbsp;&nbsp; I came across the following in=20
"draft-ietf-mpls-arch-06.txt".&nbsp;In Section "4.1.6. Option: =
Egress-Targeted=20
Label Assignment" page 43 it&nbsp;says</DIV>
<DIV>&nbsp;</DIV>
<DIV>--------------------------------------------------------------------=
--------------------------------------------------------<BR>&nbsp;&nbsp;&=
nbsp;&nbsp;=20
- It is possible to use the label distribution protocol to=20
pass<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information about which =
address=20
prefixes are "attached" to which<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
egress=20
LSRs.&nbsp; This method has the advantage of not depending=20
on<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the presence of link state=20
routing.</DIV>
<DIV>--------------------------------------------------------------------=
-----------------------------------------------------------</DIV>
<DIV>&nbsp;</DIV>
<DIV>This implies&nbsp;Ingress LER can determine the Egress LER for each =
address=20
prefix. Can someone point out how this could possibly be done using LDP =
? </DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>santosh</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_009A_01BFCFAD.68171BE0--



From owner-mpls@UU.NET  Tue Jun  6 02:51:46 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29099
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 02:51:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisjj08017;
	Tue, 6 Jun 2000 06:49:54 GMT
Received: by mail-control.mail.uu.net 
	id QQisjj24958
	for mpls-outgoing; Tue, 6 Jun 2000 06:49:32 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisjj24953
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 06:49:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisjj09596
	for <mpls@UU.NET>; Tue, 6 Jun 2000 02:49:09 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQisjj06201
	for <mpls@UU.NET>; Tue, 6 Jun 2000 06:46:49 GMT
Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id MAA25242
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:11:28 -0600 (GMT)
Message-ID: <393C9E75.856D8FB6@daewoo.dti.daewoo.co.kr>
Date: Tue, 06 Jun 2000 12:17:18 +0530
From: Neetu Gupta <neetug@daewoo.dti.daewoo.co.kr>
Reply-To: neetug@daewoo.dti.daewoo.co.kr
Organization: Daewoo Telecom
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Applications running on RSVP Aware Host End
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,
    I've a doubt. Please clarify it.

    We are implementing both Integrated Signaling and Diff Serv LSPs
using RSVP in the MPLS Domain.

    Now, my question is: Do the Applications running on the Host machine
have to be RSVP Aware only or not? Can we run a general Application? If
we can, then how will the Type of Service byte in the IP Header be set
specifying the Class of Service with which the data packets of the
Application will be sent.

-neetu



From owner-mpls@UU.NET  Tue Jun  6 09:52:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03218
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 09:52:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskh27462;
	Tue, 6 Jun 2000 12:54:55 GMT
Received: by mail-control.mail.uu.net 
	id QQiskh10044
	for mpls-outgoing; Tue, 6 Jun 2000 12:54:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiskh10039
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 12:54:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskh21568
	for <mpls@UU.NET>; Tue, 6 Jun 2000 08:54:09 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQiskh21222
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:54:08 GMT
Received: from tworster ([208.227.99.12])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id IAA10853;
	Tue, 6 Jun 2000 08:51:52 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: "'CATANZARITI Sergio FTR&D/TI'" <sergio.catanzariti@rd.francetelecom.com>,
        <curtis@avici.com>
Cc: <mpls@UU.NET>
Subject: RE: MPLS Diffserv Extensions related questions/comments 
Date: Tue, 6 Jun 2000 08:51:52 -0400
Message-ID: <000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of CATANZARITI
Sergio FTR&D/TI
>
> I agree that it would be actually very helpful. I
> would like to build topology-driven LSPs and use
> EXP-PHBs stuff for differentiating CoS-like traffic.

i certainly see the utility of being able to control
the exp -> phb mapping. i just don't see (yet) that
every phb needs a unique mapping.


> I do not understand the "hardware cost friendly"
> problem.

the cost i'm referring to is that a system needs to
provide memory to store an exp -> phb mapping for
every lsp. in a fast implementation that may come
at a noticeable marginal hw memory cost.


> The real issue here is to have a flexible
> LSPs management/control plane (I do not understand
> where the signalling problem is in all this) that
> would allow me to do it in a simple, and semantically
> congruous manner.

yes. say you could establish several exp -> phb
mappings in your lsrs and each is given an index
unique within the domain. you could signal the
index per lsp. would not that give you the
flexibility you are looking for? how many such
mappings would you need?


> It should not be that hard, at least at the
> provisioning level, and I guess I saw it already but
> I do not recall now which vendor was it :-).

it's certainly doable. but it comes at a cost in
some designs. in designs in which the memory for
each lsp is reallocated, providing support for
random signalled mappings comes at a cost.

c u
tom



From owner-mpls@UU.NET  Tue Jun  6 09:55:56 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04134
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 09:55:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskh23757;
	Tue, 6 Jun 2000 12:56:42 GMT
Received: by mail-control.mail.uu.net 
	id QQiskh10170
	for mpls-outgoing; Tue, 6 Jun 2000 12:56:10 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiskh10099
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 12:55:57 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskh07568
	for <mpls@uu.net>; Tue, 6 Jun 2000 08:55:41 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiskh28093
	for <mpls@uu.net>; Tue, 6 Jun 2000 12:55:41 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA04931
	for mpls@uu.net; Tue, 6 Jun 2000 08:55:40 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiskh10062
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 12:55:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskh07466
	for <mpls@UU.NET>; Tue, 6 Jun 2000 08:55:01 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiskh21977
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:55:00 GMT
Received: from focal.cisco.com (focal.cisco.com [171.69.204.16]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA22795; Tue, 6 Jun 2000 08:55:00 -0400 (EDT)
Received: from localhost (rhthomas@localhost) by focal.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id IAA21404; Tue, 6 Jun 2000 08:55:00 -0400 (EDT)
Message-Id: <200006061255.IAA21404@focal.cisco.com>
X-Authentication-Warning: focal.cisco.com: rhthomas owned process doing -bs
To: "Santosh Gupta" <santoshgupta@poboxes.com>
cc: mpls@UU.NET
Subject: Re: Address Message in LDP 
In-reply-to: Your message of "Tue, 06 Jun 2000 18:06:04 +0530."
             <00dd01bfcfb3$dc0b7fe0$100d85a5@dti.daewoo.co.kr> 
Date: Tue, 06 Jun 2000 08:54:59 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Santosh,

>     In draft-ietf-mpls-ldp-06.txt, there is an Address Message and =
> Address Withdraw Message. I am not able to figure out what purpose does =
> it serve. In the Hello packet that an LSR sends, it can send the =
> Interface IP Address optionally. If it doesnt send then the receiving =
> LSR can make out when it receives from the particular socket. And what =
> do we gain if an LSR advertizes IP Addresses of other interfaces also ? =
> The connection between 2 LSRs is anyway thru some particular interface =
> and knowing the IP Address of other interfaces will be of no use.

See Section "LDP Identifiers and Next Hop Addresses".

Bob



From owner-mpls@UU.NET  Tue Jun  6 10:05:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05640
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:05:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskm20365;
	Tue, 6 Jun 2000 14:04:19 GMT
Received: by mail-control.mail.uu.net 
	id QQiskm27985
	for mpls-outgoing; Tue, 6 Jun 2000 14:03:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiskm27866
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:03:46 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskm04680
	for <mpls@uu.net>; Tue, 6 Jun 2000 10:03:34 -0400 (EDT)
Received: from corecom.it by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.corecom.it [131.175.40.11])
	id QQiskm19778
	for <mpls@uu.net>; Tue, 6 Jun 2000 14:03:29 GMT
Received: from [131.175.40.59] by corecom.it with
 ESMTP (Eudora Internet Mail Server 1.1.2); Tue, 6 Jun 2000 16:04:08 +0200
X-Sender: t00trini@mail.corecom.it (Unverified)
Message-Id: <l03130301b562b54f693e@[131.175.40.59]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 6 Jun 2000 16:05:54 +0200
To: mpls@UU.NET
From: Trini Jurado <t00trini@corecom.it>
Subject: MPLS flow detection and aggregation
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all!

I am started to study MPL(abel&ambda)S  a little time ago because I am
doing my final degree project on something related to this.

I would thank you any reply to the questions below:

- In MPLS, is there an FEC assignment only when a flow is detected?

If this is truth,

- the routing of the IP packets is still by means of traditonal IP routing
until the flow is detected? which are the criteria to detect a flow, i.e.,
when does a node determine that it has been created a new flow?

- Can anybody tell me which are the steps that a node would follow to do
flow aggregation in MPL(ambda)S ?

Thank you very much in advance.

  Trini Jurado.




From owner-mpls@UU.NET  Tue Jun  6 10:06:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05773
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:06:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskm19201;
	Tue, 6 Jun 2000 14:02:46 GMT
Received: by mail-control.mail.uu.net 
	id QQiskm26276
	for mpls-outgoing; Tue, 6 Jun 2000 14:02:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiskm26028
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:02:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskm04349
	for <mpls@UU.NET>; Tue, 6 Jun 2000 10:01:51 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQiskm22390
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:01:43 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id TAA01075;
	Tue, 6 Jun 2000 19:25:43 -0600 (GMT)
Message-ID: <015401bfcfbf$90dd7940$100d85a5@dti.daewoo.co.kr>
From: "Surekha Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: "Bob Thomas" <rhthomas@cisco.com>
Cc: <mpls@UU.NET>
References: <200006061255.IAA21404@focal.cisco.com>
Subject: Re: Address Message in LDP 
Date: Tue, 6 Jun 2000 19:30:19 +0530
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 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Bob
    I have gone thru the section but still have a doubt. Even in DownStream
unsolicited Mode of label distribution, according to the draft each LSR
keeps a list of address prefix and their associated  (LDP Identifier, label)

LDP Identifier = Interface IP Address : Label Space.

Actually the Next hop address in the routing table will exactly match the
"Interface IP Address" specified in the LDP Identifier. This "Interface IP
Address" is the one directly connected to the peer.
This is depicted below.

                                            C
                                      /
                                A   -----  | B |
                                      \
                                            D

If B,C,D are directly connected to A then the "Interface IP Address" that
will be specified in the Address Message will be the same as the Interface
which A concludes from the HELLO message exchange. So what is the need for a
seperate "Address Message" altogether ?

One more thing, what is the use of specifying some other "Interace IP
Address" to A by B (say the interface of B with C ) if that is not the
directly connected interface to A?



> Santosh,
>
> >     In draft-ietf-mpls-ldp-06.txt, there is an Address Message and =
> > Address Withdraw Message. I am not able to figure out what purpose does
=
> > it serve. In the Hello packet that an LSR sends, it can send the =
> > Interface IP Address optionally. If it doesnt send then the receiving =
> > LSR can make out when it receives from the particular socket. And what =
> > do we gain if an LSR advertizes IP Addresses of other interfaces also ?
=
> > The connection between 2 LSRs is anyway thru some particular interface =
> > and knowing the IP Address of other interfaces will be of no use.
>
> See Section "LDP Identifiers and Next Hop Addresses".
>
> Bob
>



From owner-mpls@UU.NET  Tue Jun  6 10:10:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06519
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:10:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskm29347;
	Tue, 6 Jun 2000 14:08:26 GMT
Received: by mail-control.mail.uu.net 
	id QQiskm01904
	for mpls-outgoing; Tue, 6 Jun 2000 14:07:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiskm01883
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:07:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskm05364
	for <mpls@UU.NET>; Tue, 6 Jun 2000 10:07:37 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQiskm23465
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:07:37 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id KAA18870; Tue, 6 Jun 2000 10:07:29 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA13699;
	Tue, 6 Jun 2000 10:07:38 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006061407.KAA13699@curtis-lt.avici.com>
To: "tom worster" <tom@ennovatenetworks.com>
cc: "'CATANZARITI Sergio FTR&D/TI'" <sergio.catanzariti@rd.francetelecom.com>,
        curtis@avici.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS Diffserv Extensions related questions/comments 
In-reply-to: Your message of "Tue, 06 Jun 2000 08:51:52 EDT."
             <000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com> 
Date: Tue, 06 Jun 2000 10:07:37 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com>, "tom wors
ter" writes:
> 
> > I do not understand the "hardware cost friendly"
> > problem.
> 
> the cost i'm referring to is that a system needs to
> provide memory to store an exp -> phb mapping for
> every lsp. in a fast implementation that may come
> at a noticeable marginal hw memory cost.

If the network provider is reasonably sane, then you will probalby
need to map a medium to large number of LSPs into a small number of
EXP to PHB mappings.

OTOH .. at least a few people built full mesh IGPs on ATM overlays so
assumptions of ISP sanity don't hold up universally.  :-(

Curtis


From owner-mpls@UU.NET  Tue Jun  6 10:12:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06722
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:12:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskm02197;
	Tue, 6 Jun 2000 14:10:45 GMT
Received: by mail-control.mail.uu.net 
	id QQiskm02374
	for mpls-outgoing; Tue, 6 Jun 2000 14:10:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiskm02363
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:10:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskm05834
	for <mpls@uu.net>; Tue, 6 Jun 2000 10:09:26 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiskm24713
	for <mpls@uu.net>; Tue, 6 Jun 2000 14:09:25 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA15099
	for mpls@uu.net; Tue, 6 Jun 2000 10:09:24 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiskm02289
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:08:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskm05652
	for <mpls@UU.NET>; Tue, 6 Jun 2000 10:08:40 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiskm28907
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:08:07 GMT
Received: from focal.cisco.com (focal.cisco.com [171.69.204.16]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA02167; Tue, 6 Jun 2000 10:07:54 -0400 (EDT)
Received: from localhost (rhthomas@localhost) by focal.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA28712; Tue, 6 Jun 2000 10:07:54 -0400 (EDT)
Message-Id: <200006061407.KAA28712@focal.cisco.com>
X-Authentication-Warning: focal.cisco.com: rhthomas owned process doing -bs
To: "Surekha Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
cc: mpls@UU.NET
Subject: Re: Address Message in LDP 
In-reply-to: Your message of "Tue, 06 Jun 2000 19:30:19 +0530."
             <015401bfcfbf$90dd7940$100d85a5@dti.daewoo.co.kr> 
Date: Tue, 06 Jun 2000 10:07:54 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Santosh,

> Hello Bob
>     I have gone thru the section but still have a doubt. Even in DownStream
> unsolicited Mode of label distribution, according to the draft each LSR
> keeps a list of address prefix and their associated  (LDP Identifier, label)
> 
> LDP Identifier = Interface IP Address : Label Space.

There is no guarantee/requirement that the first 4 octects of the
LDP Id is the IP address of the "Interface".


> Actually the Next hop address in the routing table will exactly match the
> "Interface IP Address" specified in the LDP Identifier. This "Interface IP

I think you cannot guarantee that this is always true.


> Address" is the one directly connected to the peer.
> This is depicted below.
> 
>                                             C
>                                       /
>                                 A   -----  | B |
>                                       \
>                                             D
> 
> If B,C,D are directly connected to A then the "Interface IP Address" that
> will be specified in the Address Message will be the same as the Interface
> which A concludes from the HELLO message exchange. So what is the need for a
> seperate "Address Message" altogether ?

Please see comments above.


Bob


> One more thing, what is the use of specifying some other "Interace IP
> Address" to A by B (say the interface of B with C ) if that is not the
> directly connected interface to A?
> 
> 
> > Santosh,
> >
> > >     In draft-ietf-mpls-ldp-06.txt, there is an Address Message and =
> > > Address Withdraw Message. I am not able to figure out what purpose does
> =
> > > it serve. In the Hello packet that an LSR sends, it can send the =
> > > Interface IP Address optionally. If it doesnt send then the receiving =
> > > LSR can make out when it receives from the particular socket. And what =
> > > do we gain if an LSR advertizes IP Addresses of other interfaces also ?
> =
> > > The connection between 2 LSRs is anyway thru some particular interface =
> > > and knowing the IP Address of other interfaces will be of no use.
> >
> > See Section "LDP Identifiers and Next Hop Addresses".
> >
> > Bob
> >
> 
> 




From owner-mpls@UU.NET  Tue Jun  6 10:18:34 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07625
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:18:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskn08749;
	Tue, 6 Jun 2000 14:17:08 GMT
Received: by mail-control.mail.uu.net 
	id QQiskn03189
	for mpls-outgoing; Tue, 6 Jun 2000 14:16:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiskn03165
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:16:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskn07013
	for <mpls@UU.NET>; Tue, 6 Jun 2000 10:15:51 -0400 (EDT)
Received: from shrimp.baynetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns4.BayNetworks.COM [192.32.253.7])
	id QQiskn07230
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:15:50 GMT
Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84])
	by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id KAA22703;
	Tue, 6 Jun 2000 10:09:37 -0400 (EDT)
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6])
	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA00657;
	Tue, 6 Jun 2000 10:19:52 -0400 (EDT)
Received: from ssurya (dhcp225-180 [192.32.225.180])
	by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP
	id KAA17581; Tue, 6 Jun 2000 10:14:57 -0400
	for 
Message-Id: <3.0.1.32.20000606100651.00e25d10@pobox.engeast.baynetworks.com>
X-Sender: ssuryapu@pobox.engeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 06 Jun 2000 10:06:51 -0400
To: Trini Jurado <t00trini@corecom.it>, mpls@UU.NET
From: Stephen Suryaputra <ssuryapu@nortelnetworks.com>
Subject: Re: MPLS flow detection and aggregation
In-Reply-To: <l03130301b562b54f693e@[131.175.40.59]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 04:05 PM 6/6/2000 +0200, Trini Jurado wrote:
>Hi all!
>
>I am started to study MPL(abel&ambda)S  a little time ago because I am
>doing my final degree project on something related to this.
>
>I would thank you any reply to the questions below:
>
>- In MPLS, is there an FEC assignment only when a flow is detected?

No, MPLS is more control-driven rather than data-driven. If you want to do
FEC assignment when a flow is detected, it will be more IP switching like.

>If this is truth,
>
>- the routing of the IP packets is still by means of traditonal IP routing
>until the flow is detected? which are the criteria to detect a flow, i.e.,
>when does a node determine that it has been created a new flow?

Some people use X/Y classifier and I believe there is no magic criteria
to detect a flow. It should be viewed as case per case basis.

>- Can anybody tell me which are the steps that a node would follow to do
>flow aggregation in MPL(ambda)S ?

There are some references regarding effort to do dynamic optical flow
assignment
using IP switching way. You might want to take a look at my final project:

http://www.isi.edu/~touch/pubs/bann-pfhsn99/
http://www.isi.edu/~touch/pubs/swap-99/



From owner-mpls@UU.NET  Tue Jun  6 10:28:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07918
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:28:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskj15805;
	Tue, 6 Jun 2000 13:19:14 GMT
Received: by mail-control.mail.uu.net 
	id QQiskj20616
	for mpls-outgoing; Tue, 6 Jun 2000 13:18:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiskj20611
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 13:18:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskj11690
	for <mpls@UU.NET>; Tue, 6 Jun 2000 09:18:33 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQiskj13452
	for <mpls@UU.NET>; Tue, 6 Jun 2000 13:18:32 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id IAA01411;
	Tue, 6 Jun 2000 08:18:24 -0500 (CDT)
Received: from tellabs.com (dhcp-90-119.lisle.tellabs.com [138.111.90.119])
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA20515;
	Tue, 6 Jun 2000 08:18:26 -0500 (CDT)
Message-ID: <393CF7D3.9338D95C@tellabs.com>
Date: Tue, 06 Jun 2000 08:08:36 -0500
From: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: otel@ce.chalmers.se, Shahram_Davari@pmc-sierra.com, EGray@zaffire.com,
        swtan@mmu.edu.my, kireeti@juniper.net, dwilder@baynetworks.com,
        mpls@UU.NET
Subject: Re: OAM functionality         (Was: RE: can egress know the ingressof a 
 packet?)
References: <B9571FDEBD3DD21181E500606DD5EE0507B16019@mbddmknt01.hc.bt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Neil,

I think a draft covering MPLS OAM that can set requirements and define
the essential minimal OAM functions and mechanisms would be extremely 
useful.  As Florian mentions, there are several drafts addressing 
various specific items and one general one so far.  This work needs 
to be progressed and some common mechanism(s) for carrying out the 
variety of OAM functions should be defined.

I have been thinking about this from the viewpoint of the recovery
framework and protection switching drafts to which I have contributed.
In looking at MPLS based recovery, it becomes clear that a simple
and reliable path continuity test would be very useful.  Also a fast
communication path to convey a fault indication is useful if rapid 
protection switching is required.

A simple way to identify OAM packets, while allowing them to
follow the same data path as user packets (when required), is
essential to these functions.  If this can be done without disruption
to the embedded MPLS base, as Kireeti has indicated, this would be 
ideal.  I think there are some promising possibliities being discussed
in the related thread on "OAM labels".

I would be happy to help out with your proposed draft, if needed (though
I can't claim to have any special talents for editing ASCII state diags.).

Regards,
Ben

neil.2.harrison@bt.com wrote:
> 
> Hi Florian,
> 
> I have been involved with much of the recent ATM OAM work.......but came in
> late in the day when, unfortunately, it was too late to change the stds
> (though believe me we tried).  Its a very complex story and I don't want to
> waste people's time by going through its history here (speak to me privately
> if you want the details).  But in essence, there are too many optional OAM
> combinations and not enough thought was given early enough to the basic
> architectural OAM functional relationships (especially harmonised defect
> state handling at near-end and far-end of trails)......which is why after
> many years (maybe 8 or so) we do not even have any agreement of how to
> measure availability on ATM trails (and which also means, as a by-product,
> that the up-state-only QoS measurements can become worthless).
> 
> Based on this experience, and working closely with my IP network design
> colleagues, we have pared down our functional requirements (and their
> manifestation as OAM pkts) to what we believe are the essential minimal in
> order to (i) allow operations people to maintain and fault-find and (ii)
> protect customer traffic from wrong delivery under various connectivity
> failure scenarios.
> 
> I really ought to get something drafted so that other people can more
> constructively criticise it......there may indeed be better ways to provide
> the functionality we would like to see.   I will try and do something over
> the next few weeks or so and circulate to those who have expressed an
> interest so far.
> 
> Regards, Neil
> 
> > -----Original Message-----
> > From: Florian-Daniel Otel [SMTP:otel@ce.chalmers.se]
> > Sent: Monday, June 05, 2000 3:41 PM
> > To:   Shahram Davari
> > Cc:   'neil.2.harrison@bt.com'; EGray@zaffire.com; swtan@mmu.edu.my;
> > kireeti@juniper.net; dwilder@baynetworks.com; mpls@UU.NET
> > Subject:      OAM functionality (Was: RE: can egress know the ingress of a
> > packet?)
> >
> >
> > Sharam,
> >
> > > Hi Neil,
> >
> > > I also think we need some sort of OAM function at MPLS layer. And as you
> > > said, to be able to process OAM cells, they must be recognized by LSRs.
> > But
> > > it might be hard to change the definition of TTL field at this point in
> > > time. So I have a different proposal. Why don't we assign/reserve some
> > Label
> > > values to be used only by OAM packets. This is very analogous to ATM, in
> > > which, some VPI/VCIs are reserved for OAM cells (e.g. VPI=0 and VCI
> > =0-15).
> > > For example we could assign Label = 0 for the Keepalive messages that
> > you
> > > described.
> >
> > > I am interested in writing such an I-D, and in fact my company is expert
> > in
> > > ATM OAM, so we could leverage that knowledge for the MPLS OAM.
> >
> > As Neil already pointed out, there are several people intrested in O&M
> > functionality in MPLS, and for several reasons (you can also check the
> > discussion between Neil and Vishal on TEwg mailing list on 17 Apr &
> > ff. I also had some off-list questions about it).
> >
> > But the impression i got (and please, someone correct me if I'm wrong)
> > is that, as the Theimer OAM requirements draft clearly states:
> >
> > "[..]we do not intend to simply adopt the OAM functions and procedures
> > previously defined  for other technologies (in particular ATM), as
> > this would probably lead to very complex and expensive
> > implementations[..]"
> >
> >
> >
> > Putting it bluntly, the way i read this is that "we simply don't want
> > to turn MPLS into ATM-2 by adding all possible types of OAM functions".
> >
> >
> > So, my take is (and, by all means, please correct me if i'm wrong)
> > that in addition to the (rather vague IMHO) Theimer draft there you
> > have all other proposals for recovery, protection, restoration and
> > loop prevention but no other general O&M spec than the above
> > draft. Why is that and how to solve (if ever need be) the OAM
> > needs...well, that's it's beyond my knowledge (and the reason I'm
> > asking about it here).
> >
> >
> > My $0.02 worth.
> >
> > With kind regards,
> >
> > Florian.


From owner-mpls@UU.NET  Tue Jun  6 10:38:01 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08215
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:38:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisko28895;
	Tue, 6 Jun 2000 14:36:27 GMT
Received: by mail-control.mail.uu.net 
	id QQisko04237
	for mpls-outgoing; Tue, 6 Jun 2000 14:35:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisko04230
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:35:49 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisko11147
	for <mpls@UU.NET>; Tue, 6 Jun 2000 10:35:25 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg15e1.nortelnetworks.com [47.234.0.36])
	id QQisko12363
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:35:25 GMT
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg15e1.nortelnetworks.com; Tue, 6 Jun 2000 10:34:36 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <L3HQDLLQ>; Tue, 6 Jun 2000 10:34:39 -0400
Message-ID: <6DDA62170439D31185750000F80826AC02BFC7F5@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: neil.2.harrison@bt.com, otel@ce.chalmers.se, Shahram_Davari@pmc-sierra.com
Cc: EGray@zaffire.com, swtan@mmu.edu.my, kireeti@juniper.net,
        dwilder@baynetworks.com, mpls@UU.NET
Subject: RE: OAM functionality (Was: RE: can egress know the ingress of a 
         packet?)
Date: Tue, 6 Jun 2000 10:34:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCFC4.5861DC32"
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_01BFCFC4.5861DC32
Content-Type: text/plain

Neil:

I, for one, would like to see the minimum set you refer to before we start
discuss fiddling with things.

Dave

> -----Original Message-----
	<snip>

> I really ought to get something drafted so that other people can more
> constructively criticise it......there may indeed be better ways to
> provide
> the functionality we would like to see.   I will try and do something over
> the next few weeks or so and circulate to those who have expressed an
> interest so far. 
> 
> Regards, Neil
> 
> 

------_=_NextPart_001_01BFCFC4.5861DC32
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: OAM functionality (Was: RE: can egress know the ingress of a =
 packet?)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Neil:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I, for one, would =
like to see the minimum set you refer to before we start discuss =
fiddling with things.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I really ought to get something =
drafted so that other people can more</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">constructively criticise =
it......there may indeed be better ways to provide</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the functionality we would like to =
see.&nbsp;&nbsp; I will try and do something over</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the next few weeks or so and =
circulate to those who have expressed an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">interest so far. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards, Neil</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCFC4.5861DC32--


From owner-mpls@UU.NET  Tue Jun  6 10:45:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08883
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:45:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskg11912;
	Tue, 6 Jun 2000 12:37:51 GMT
Received: by mail-control.mail.uu.net 
	id QQiskg08964
	for mpls-outgoing; Tue, 6 Jun 2000 12:37:25 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiskg08949
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 12:37:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskg18648
	for <mpls@UU.NET>; Tue, 6 Jun 2000 08:37:06 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQiskg09664
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:36:51 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id SAA00356
	for <mpls@UU.NET>; Tue, 6 Jun 2000 18:01:13 -0600 (GMT)
Message-ID: <00dd01bfcfb3$dc0b7fe0$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: Address Message in LDP
Date: Tue, 6 Jun 2000 18:06:04 +0530
Organization: Daewoo Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00DA_01BFCFE1.E1568C00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00DA_01BFCFE1.E1568C00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello
    In draft-ietf-mpls-ldp-06.txt, there is an Address Message and =
Address Withdraw Message. I am not able to figure out what purpose does =
it serve. In the Hello packet that an LSR sends, it can send the =
Interface IP Address optionally. If it doesnt send then the receiving =
LSR can make out when it receives from the particular socket. And what =
do we gain if an LSR advertizes IP Addresses of other interfaces also ? =
The connection between 2 LSRs is anyway thru some particular interface =
and knowing the IP Address of other interfaces will be of no use.

santosh


------=_NextPart_000_00DA_01BFCFE1.E1568C00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hello</DIV>
<DIV>&nbsp;&nbsp;&nbsp; In draft-ietf-mpls-ldp-06.txt, there is an =
Address=20
Message and Address Withdraw Message. I am not able to figure out what =
purpose=20
does it serve. In the Hello packet that an LSR sends, it can send the =
Interface=20
IP Address optionally. If it doesnt send then the receiving LSR can make =
out=20
when it receives from the particular socket. And what do we gain if an =
LSR=20
advertizes IP Addresses of other interfaces also ? The connection =
between 2 LSRs=20
is anyway thru some particular interface and knowing the IP Address of =
other=20
interfaces will be of no use.</DIV>
<DIV><BR>santosh</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00DA_01BFCFE1.E1568C00--



From owner-mpls@UU.NET  Tue Jun  6 10:46:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08902
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:46:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskg10930;
	Tue, 6 Jun 2000 12:37:05 GMT
Received: by mail-control.mail.uu.net 
	id QQiskg08917
	for mpls-outgoing; Tue, 6 Jun 2000 12:36:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiskg08911
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 12:36:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskg18485
	for <mpls@UU.NET>; Tue, 6 Jun 2000 08:35:58 -0400 (EDT)
Received: from hawk.crescentnets.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.177.194.54])
	id QQiskg09072
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:35:58 GMT
Received: from crescentnets.com (langille.in.crescentnets.com [192.168.29.105])
	by hawk.crescentnets.com (8.9.3/8.9.3) with ESMTP id IAA21581;
	Tue, 6 Jun 2000 08:35:46 -0400 (EDT)
Message-ID: <393CF0B0.86897FD1@crescentnets.com>
Date: Tue, 06 Jun 2000 08:38:08 -0400
From: Paul Langille <langille@crescentnets.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
CC: mpls@UU.NET, Cheenu Srinivasan <cheenu_s@yahoo.com>,
        arun Viswanathan <arun@force10networks.com>
Subject: Re: Additional Index for TE-MIB: mplsTunnelTable
References: <4.3.2.7.2.20000602142324.0467f5d0@bucket.cisco.com> <4.3.2.7.2.20000605173329.0753b0d0@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


    Hi (again!) Tom,


"Thomas D. Nadeau" wrote:

>          Hi Paul,
>
> >     Hi Tom. I agree with you (and Mani) that you need the triplet <
> > Tunnel index, Tunnel Instance and Source address> to uniquely identify a
> > tunnel. Good catch.
>
>          Thanks.
>
> >     So now I am wondering, do you need the tunnel cookie (since it is the
> > source address and the tunnel index)?
>
>          I believe that we are going to eliminate the cookies from the MIB.
> There was some discussion about this a while back.

Thanks. I don't recall the discussion. I will check the archives.

>
>
> >Could you also give some brief examples as to how this would work with
> >bi-directional tunnels. (I may be a bit confused by the
> >mplsTunnelDirection object.)
>
>          Do you still need the example now that you know that the
> cookie is deleted, or were you referring to the addition of the
> srcAddr to the index?

It is not clear to me how to represent a bi-directional tunnel with the MIB.
Some of my confusion may come from the fact that I don't understand the
mplsTunnelDirection object. For example, what does it mean to have this object
set to "bi-directional"? Does it mean that this row refers to a bi-directional
tunnel? Does the TunnelDirection (in, out) have any significance at the tunnel
midpoint? What role does the cookie (or the lack of one!) play in
bi-directional tunnels?

So rather than answer these questions one at a time, it might be faster to
catch them all with an example. I assume that you have a solution in mind but
you currently don't have the cycles to put it in the MIB. Have you implemented
bi-directional tunnels?

        Thanks Paul

>
>
>          --Tom

--
Paul Langille                e-mail: langille@crescentnets.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824




From owner-mpls@UU.NET  Tue Jun  6 10:57:41 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09150
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:57:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskp19437;
	Tue, 6 Jun 2000 14:56:33 GMT
Received: by mail-control.mail.uu.net 
	id QQiskp05280
	for mpls-outgoing; Tue, 6 Jun 2000 14:56:07 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiskp05273
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:56:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskp00846
	for <mpls@uu.net>; Tue, 6 Jun 2000 10:55:43 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQiskp26790
	for <mpls@uu.net>; Tue, 6 Jun 2000 14:55:42 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA11944
	for <mpls@uu.net>; Tue, 6 Jun 2000 07:55:50 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA09941 for mpls@uu.net; Tue, 6 Jun 2000 10:55:41 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisjn07508
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 07:56:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisjn18214
	for <mpls@uu.net>; Tue, 6 Jun 2000 03:56:35 -0400 (EDT)
From: Kimmo.Raatikainen@nokia.com
Received: from mgw-x2.nokia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mgw-x2.nokia.com [131.228.20.22])
	id QQisjn28678
	for <mpls@uu.net>; Tue, 6 Jun 2000 07:56:34 GMT
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id KAA04247;
	Tue, 6 Jun 2000 10:56:30 +0300 (EETDST)
Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id KAA21525;
	Tue, 6 Jun 2000 10:56:20 +0300 (EETDST)
Received: by esebh01nok with Internet Mail Service (5.5.2650.10)
	id <MM1AM0N0>; Tue, 6 Jun 2000 10:56:19 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE102975EBC@eseis04nok>
To: brian@hursley.ibm.com, akyol@pluris.com
Cc: diffserv@ietf.org, mpls@UU.NET
Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension
	s   related  questions/comments
Date: Tue, 6 Jun 2000 10:56:16 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk



> -----Original Message-----
> From: EXT Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: 02. June 2000 0:39
> To: Bora Akyol
> Cc: diffserv@ietf.org; 'mpls@uu.net'
> Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv
> Extensions related questions/comments
> 
> 
> Bora,
> 
> I don't think we will see reports of Diffserv deployment 
> experience until
> production releases from major router vendors support Diffserv.
> 
> The edge boxes that I'm thinking of will need to do MF 
> classification and shaping
> at LAN speeds (whatever that means in a particular year). 
> Other boxes only need
> to do BA classification and policing. 
> 
> But this is old ground that we settled in the early days of 
> diffserv. And
> I don't see what it has to do with MPLS.
> 
>   Brian
> 
Please keep in mind that gigabit cards are already available. In our
experiments we have found out that a high-end PC running Linux can send at a
rate of 250-300 megabits per second using TCP/UDP.

- Kimmo Raatikainen



From owner-mpls@UU.NET  Tue Jun  6 10:58:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09185
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:58:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskp27661;
	Tue, 6 Jun 2000 14:56:44 GMT
Received: by mail-control.mail.uu.net 
	id QQiskp05283
	for mpls-outgoing; Tue, 6 Jun 2000 14:56:10 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiskp05275
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:56:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskp00847
	for <mpls@UU.NET>; Tue, 6 Jun 2000 10:55:43 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQiskp26791
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:55:42 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id JAA10242;
	Tue, 6 Jun 2000 09:55:41 -0500 (CDT)
Received: from tellabs.com (dhcp-90-119.lisle.tellabs.com [138.111.90.119])
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA26724;
	Tue, 6 Jun 2000 09:54:54 -0500 (CDT)
Message-ID: <393D0E6F.4F91E367@tellabs.com>
Date: Tue, 06 Jun 2000 09:45:03 -0500
From: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Indra.Widjaja@tddny.fujitsu.com, Thomas.Theimer@icn.siemens.de,
        Shahram_Davari@pmc-sierra.com, pjw@ip-engineering.bt.com
CC: mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <3B59676F9ADBD211B5360060086E64EECC011A@MCHH237E> <393BEE17.7EE547D9@tddny.fujitsu.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

I have been thinking about OAM packet identification and I
think this evolving proposal looks promising.

There are several possible processing modes for OAM packets,
and I am interested in your thoughts on (a) which are needed, 
and (b) which can be supported by the current proposal.

For the sake of discussion I have given them numbers (with no
particular significance) and included my initial thoughts.

Mode 1: 
Packet transparently forwarded along user packet data path

This mode is needed for end-to-end OAM funcitons that depend
on following the user packet data path exactly (e.g., delay
measurement, as Indra mentioned, and path continuity tests).

Mode 2:
Packet transparently forwarded along user data path and also
passed to OAM processing (monitoring)

This mode can be easily combined with Mode 1, and is useful
for isolating faults and monitoring subnetwork connections.

Mode 3:
Packet forwarded to OAM processing, then forwarded along next
hop of user packet data path (possibly not following user packet
data path at all points within the LSR)

This mode may be useful for OAM packets that do not need to 
follow the user data path exactly within the LSR, need more 
flexible processing (i.e. are more suited to SW than HW 
processing), and are not too frequent.

Mode 4:
Packet forwarded to OAM processing and terminated

This is the common mode for termination points (LSP endpoints)
and segment endpoints (if segment OAM is supported).  The 
difficulty in the segment case is distinguishing which OAM
packets to terminate and which to pass if Mode 1 or 2 OAM packets
are also in use.  (Obviously Modes 3 and 4 can easily be combined.)

Mode 5:
Packet forwarded to previous hop on user packet data path 
(forwarding OAM packets following LSP upstream)

Same as Mode 1, but upstream so there is no "user packet data path"
per se.  This might be useful for end-to-end OAM funcitons that
require two way communication (are there any?) or funcitons
that require rapid communicaiton upstream (e.g., fault indication for
rapid protection switching).

Mode 6:
Packet forwarded to previous hop on user packet data path and also
passed to OAM processing (monitoring upstream OAM)

Same as mode 2, but upstream (do we detect a pattern here?).
As before, easily combined with Mode 5.  Might be good for subnetwork
connection protection switching, as long as the fault indication
does not cause any trouble passing further upstream.

Mode 7:
Packet forwarded to OAM processing, then forwarded to previous hop
on user packet data path

Same as Mode 3, but upstream.  Another option for upstream OAM
communication, possibly slower than Mode 5 or 6.

Mode 8:
Packet forwarded to AOM processing and terminated (upstream direction)

Same as Mode 4, but upstream.


Regarding OAM packet identification, it seems reasonable to use the
user packet label on top for Modes 1 and 2 so the packet will follow
the user data path downstream.  Mode 2 could rely on looking for a
reserved OAM label next on the stack.  Modes 3 and 4 are easily
supported with a reserved OAM label on top, or at the LSP endpoint
where the user packet label is popped anyway (though it might need
to be preserved as Peter mentioned).  However, supporting Modes 3 
or 4 at points within the path when the user label is on top is a 
problem (how to decide to forward only to OAM processing and not along
user packet path -- Indra: Is this the point you were making?)

In the upstream modes, the user label is not defined for forwarding
so perhaps this can always be done with an OAM reserved label on top.

So...  What do you think about this?  Can we identify a subset of
modes that are necessary and sufficient, or is it simpler to define
an OAM packet identification scheme that supports all of them and 
let folks decide later which mode to use in a particular OAM 
application?

Regards,
Ben Mack-Crane

Indra.Widjaja@tddny.fujitsu.com wrote:
> 
> Thomas:
> I think both end-to-end and hop-by-hop OAM packets as you mentioned
> below should be supported.
> A third possible way is segment OAM packets where you still want the
> OAM packets to be treated the same way as data packets in the
> segment connection. I believe this can be realized by using the first
> approach plus a dedicated OAM bit. Is there a requirement for this?
> indra
> 
> Theimer Thomas wrote:
> 
> > Actually, there are at least two ways to use such a reserved OAM label:
> >
> > - end-end OAM packets would have a label stack where the reserved
> >   label is inserted below the original top label. After the top label is
> >   popped at the egress node, the reserved label is processed by
> >   forwarding the packet to OAM handling. Thus, all packets are
> >   forwarded using the original top label. OAM packets are visible
> >   only to ingress and egress nodes, and use exactly the same
> >   path as user packets.
> >
> > - hop-by-hop OAM packets would have the reserved label pushed
> >   on top of the original top label. Each LSR along the LSP would
> >   then recognise the reserved top label, forward the packet to
> >   OAM handling, and then forward the packet using the label
> >   second on the label stack (the original top label).
> >
> > It may simplify things if two different reserved labels are defined
> > for end-end and hop-by-hop OAM packets, if people feel that
> > both are needed. The hop-hop case is really very similar to
> > the router alert label.
> >
> > A dedicated OAM header bit would serve a similar purpose, but is
> > not strictly required.
> >
> > Regards,
> >
> > Thomas Theimer
> > > -----Original Message-----
> > > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> > > Sent: Monday, June 05, 2000 5:50 PM
> > > To:   'Peter Willis'; mpls@UU.NET
> > > Subject:      RE: OAM labels (was: can egress know the ingress of a
> > > packet?)
> > >
> > > Peter,
> > >
> > > But we can use two labels. The top label can be the reserved one, and the
> > > second label can be the actual label, which is used for forwarding the OAM
> > > packet. This is basically similar to the Router Alert Label = 1.
> > >
> > > Regards,
> > > -Shahram
> > >
> > > >-----Original Message-----
> > > >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> > > >Sent: Monday, June 05, 2000 11:37 AM
> > > >To: mpls@UU.NET
> > > >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> > > >
> > > >
> > > >
> > > >An LSR will be terminating many LSPs so will be terminating
> > > >many OAM flows.
> > > >How do you correctly diagnose LSPs with merged or corrupted
> > > >labels if they all
> > > >arrive on the same reserved label? The label the OAM flow
> > > >arrives on has to
> > > >match exactly the label used for the data (user plane) flow in
> > > >order to be able
> > > >to detect faults caused by LSRs using broken label swapping tables.
> > > >
> > > >So we need a bit somewhere in the MPLS header to identify an
> > > >OAM payload but
> > > >we need to keep the same label as used for the user plane data.
> > > >
> > > >Peter.
> > > >
> > > >


From owner-mpls@UU.NET  Tue Jun  6 10:58:37 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09195
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 10:58:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskp28828;
	Tue, 6 Jun 2000 14:57:48 GMT
Received: by mail-control.mail.uu.net 
	id QQiskp05392
	for mpls-outgoing; Tue, 6 Jun 2000 14:57:14 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiskp05378
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:57:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskp15359
	for <mpls@uu.net>; Tue, 6 Jun 2000 10:56:18 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQiskp27209
	for <mpls@uu.net>; Tue, 6 Jun 2000 14:56:17 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA12570
	for <mpls@uu.net>; Tue, 6 Jun 2000 07:56:25 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA09949 for mpls@uu.net; Tue, 6 Jun 2000 10:56:16 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiskm26220
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 14:02:11 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskm19849
	for <mpls@uu.net>; Tue, 6 Jun 2000 10:02:02 -0400 (EDT)
Received: from mail-gw.hursley.ibm.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-gw.hursley.ibm.com [194.196.110.15])
	id QQiskm18598
	for <mpls@uu.net>; Tue, 6 Jun 2000 14:02:01 GMT
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA62672; Tue, 6 Jun 2000 15:01:58 +0100
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA22636; Tue, 6 Jun 2000 15:01:49 +0100 (BST)
Message-ID: <393D0426.6A3B8B80@hursley.ibm.com>
Date: Tue, 06 Jun 2000 09:01:10 -0500
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Kimmo.Raatikainen@nokia.com
CC: akyol@pluris.com, diffserv@ietf.org, mpls@UU.NET
Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions   
 related  questions/comments
References: <01D91AFB08B6D211BFD00008C7EABAE102975EBC@eseis04nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kimmo.Raatikainen@nokia.com wrote:
> 
> > -----Original Message-----
> > From: EXT Brian E Carpenter [mailto:brian@hursley.ibm.com]
> > Sent: 02. June 2000 0:39
> > To: Bora Akyol
> > Cc: diffserv@ietf.org; 'mpls@uu.net'
> > Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv
> > Extensions related questions/comments
> >
> >
> > Bora,
> >
> > I don't think we will see reports of Diffserv deployment
> > experience until
> > production releases from major router vendors support Diffserv.
> >
> > The edge boxes that I'm thinking of will need to do MF
> > classification and shaping
> > at LAN speeds (whatever that means in a particular year).
> > Other boxes only need
> > to do BA classification and policing.
> >
> > But this is old ground that we settled in the early days of
> > diffserv. And
> > I don't see what it has to do with MPLS.
> >
> >   Brian
> >
> Please keep in mind that gigabit cards are already available. In our
> experiments we have found out that a high-end PC running Linux can send at a
> rate of 250-300 megabits per second using TCP/UDP.

Of course. Edge boxes will need to support a gigabit. The server itself may
function as the diffserv edge box; this is already possible at 100 Mbit/s.
I would expect to see MF classifiers running at a gigabit soon enough.

My concern is to keep the job of core boxes that do IP direct over photons
as simple as possible, and I don't think we should ask them to do more than
BA classification.

  Brian

  Brian



From owner-mpls@UU.NET  Tue Jun  6 11:07:21 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09458
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 11:07:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskq27450;
	Tue, 6 Jun 2000 15:06:11 GMT
Received: by mail-control.mail.uu.net 
	id QQiskq14839
	for mpls-outgoing; Tue, 6 Jun 2000 15:05:50 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiskq14826
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:05:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskq17385
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:05:21 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQiskq06876
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:05:21 GMT
Received: from tworster ([208.227.99.12])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA16256;
	Tue, 6 Jun 2000 11:04:46 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: <curtis@avici.com>
Cc: "'CATANZARITI Sergio FTR&D/TI'" <sergio.catanzariti@rd.francetelecom.com>,
        <mpls@UU.NET>
Subject: RE: MPLS Diffserv Extensions related questions/comments 
Date: Tue, 6 Jun 2000 11:04:45 -0400
Message-ID: <001801bfcfc8$8d6ca660$6640a8c0@tst.ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <200006061407.KAA13699@curtis-lt.avici.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: Curtis Villamizar [mailto:curtis@avici.com]
> 
> In message 
> <000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com>, "tom wors
> ter" writes:
> > 
> > > I do not understand the "hardware cost friendly"
> > > problem.
> > 
> > the cost i'm referring to is that a system needs to
> > provide memory to store an exp -> phb mapping for
> > every lsp. in a fast implementation that may come
> > at a noticeable marginal hw memory cost.
> 
> If the network provider is reasonably sane, then you will probalby
> need to map a medium to large number of LSPs into a small number of
> EXP to PHB mappings.

that's what i imagined too. which is why i question the
design of a protocol that provides unnecessary resolution
with a non-trivial cost attached to that resolution.


> OTOH .. at least a few people built full mesh IGPs on ATM overlays so
> assumptions of ISP sanity don't hold up universally.  :-(

if the requirement for a different exp -> phb mapping for 
each of a medium to large number of lsps is considered
unreasonable then that should be taken into consideration
in the diff-ext protocol design.

i thought about a separation of ds semantics from mpls
signalling using an "exp -> phb mapping index" which would
be signalled in the new tlv instead of the mapping itself.
a set of mappings would be configured and referred to in 
the by the index in the signalling messages.

the technical benefits i see are reduced signalling 
bandwidth and processing and a reduced per lsp memory
budget.

but there are other advantages. the diff-ext draft could
be radically simplified since the distinction of e-lsp
and l-lsp disappears -- they are just different classes
of mappings. conceivable, the mappings could go into
experimental rfcs and a range of indexes could be reserved
for standardisation. such a separation of mpls signalling
and (perhaps more controversial) ds-related semantics could 
be expeditious.

c u
tom


From owner-mpls@UU.NET  Tue Jun  6 11:15:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09648
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 11:15:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskq15876;
	Tue, 6 Jun 2000 15:13:48 GMT
Received: by mail-control.mail.uu.net 
	id QQiskq15493
	for mpls-outgoing; Tue, 6 Jun 2000 15:13:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiskq15488
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:13:26 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskq18925
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:13:11 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQiskq03011
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:13:11 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id LAA23743; Tue, 6 Jun 2000 11:12:29 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA13982;
	Tue, 6 Jun 2000 11:12:17 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006061512.LAA13982@curtis-lt.avici.com>
To: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
cc: neil.2.harrison@bt.com, otel@ce.chalmers.se, Shahram_Davari@pmc-sierra.com,
        EGray@zaffire.com, swtan@mmu.edu.my, kireeti@juniper.net,
        dwilder@baynetworks.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-reply-to: Your message of "Tue, 06 Jun 2000 08:08:36 CDT."
             <393CF7D3.9338D95C@tellabs.com> 
Date: Tue, 06 Jun 2000 11:12:17 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <393CF7D3.9338D95C@tellabs.com>, Ben Mack-Crane writes:
> 
> I have been thinking about this from the viewpoint of the recovery
> framework and protection switching drafts to which I have contributed.
> In looking at MPLS based recovery, it becomes clear that a simple
> and reliable path continuity test would be very useful.  Also a fast
> communication path to convey a fault indication is useful if rapid 
> protection switching is required.

Pardon my ignorance but to what extent does ping and traceroute
implemented by the LSR meet these particular OAM needs?

It might help to start by identifying which features the OAM needs to
accomoddate that are currently missing (timestamp, record route,
other?).

For example, ping with record route doesn't work unless the MPLS
router alert and an ability to modify the underlying IP packet is
implemented (which hasn't even been suggested, and I am not implying
that it is a good idea).  Then we can consider whether a MPLS specific
ping with record route (or OAM packet) is needed to prevent DOS
attack, or whether one ping for all underlying layers is still OK (and
if one ping is better, then whether LSRs should provide configurable
ability to either rate limit or block setting of MPLS router alert
based on presence of RR IP options).

We might want to ask ISPs how valuable RR IP option on ping has been
and how valuable the equivalent ATM OAM cells have been.  We may find
that the former is used occasionally at most and the latter even less
or not at all for IP over ATM networks.

> A simple way to identify OAM packets, while allowing them to
> follow the same data path as user packets (when required), is
> essential to these functions.  If this can be done without disruption
> to the embedded MPLS base, as Kireeti has indicated, this would be 
> ideal.  I think there are some promising possibliities being discussed
> in the related thread on "OAM labels".

draft-ietf-mpls-icmp-01.txt ?

Lets not reinvent the wheel if we don't have to.

Curtis


From owner-mpls@UU.NET  Tue Jun  6 11:18:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09752
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 11:18:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskr07218;
	Tue, 6 Jun 2000 15:17:27 GMT
Received: by mail-control.mail.uu.net 
	id QQiskr15928
	for mpls-outgoing; Tue, 6 Jun 2000 15:17:10 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiskr15921
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:17:06 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskr05307
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:16:09 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQiskr05803
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:16:08 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id LAA24072; Tue, 6 Jun 2000 11:15:59 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA14021;
	Tue, 6 Jun 2000 11:16:15 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006061516.LAA14021@curtis-lt.avici.com>
To: Trini Jurado <t00trini@corecom.it>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS flow detection and aggregation 
In-reply-to: Your message of "Tue, 06 Jun 2000 16:05:54 +0200."
             <l03130301b562b54f693e@[131.175.40.59]> 
Date: Tue, 06 Jun 2000 11:16:15 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <l03130301b562b54f693e@[131.175.40.59]>, Trini Jurado writes:
> 
> - In MPLS, is there an FEC assignment only when a flow is detected?

Strictly speaking, it could be.  Practical reality is that it never is
and borders on infeasible at current traffic rates and diversity.

Curtis



From owner-mpls@UU.NET  Tue Jun  6 11:28:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10073
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 11:28:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskr20293;
	Tue, 6 Jun 2000 15:27:39 GMT
Received: by mail-control.mail.uu.net 
	id QQiskr16665
	for mpls-outgoing; Tue, 6 Jun 2000 15:27:07 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiskr16653
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:26:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskr21750
	for <mpls@uu.net>; Tue, 6 Jun 2000 11:26:13 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiskr18439
	for <mpls@uu.net>; Tue, 6 Jun 2000 15:26:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA00151
	for mpls@uu.net; Tue, 6 Jun 2000 11:26:11 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiskr16504
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:25:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskr07404
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:25:03 -0400 (EDT)
Received: from miranda.tx.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: miranda.tx.fnc.fujitsu.com [167.254.254.199])
	id QQiskr16964
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:25:02 GMT
Received: from tdd1028.tx.fnc.fujitsu.com (tdd1028.tddeng00.fnts.com [167.254.144.174])
	by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13476;
	Tue, 6 Jun 2000 10:25:01 -0500 (CDT)
Received: from fnc.fujitsu.com (localhost [127.0.0.1])
	by tdd1028.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id KAA22119;
	Tue, 6 Jun 2000 10:25:01 -0500 (CDT)
Message-ID: <393D17CB.FA27CB1B@fnc.fujitsu.com>
Date: Tue, 06 Jun 2000 10:24:59 -0500
From: Snigdho Bardalai <snigdho.bardalai@fnc.fujitsu.com>
Organization: Fujitsu Network Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: neetug@daewoo.dti.daewoo.co.kr
CC: mpls@UU.NET
Subject: Re: Applications running on RSVP Aware Host End
References: <393C9E75.856D8FB6@daewoo.dti.daewoo.co.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Neetu Gupta wrote:

> Hello,
>     I've a doubt. Please clarify it.
>
>     We are implementing both Integrated Signaling and Diff Serv LSPs
> using RSVP in the MPLS Domain.
>
>     Now, my question is: Do the Applications running on the Host machine
> have to be RSVP Aware only or not? Can we run a general Application? If
> we can, then how will the Type of Service byte in the IP Header be set
> specifying the Class of Service with which the data packets of the
> Application will be sent.
>

Hi Neetu,

If you expect to have a DiffServ compliant application the IP header TOS
bits should contain the DiffServ DSCP values like expedited, assured
services etc.

But if you expect to support Integrated Services the TOS bits in the IP
header may not have any significance.

Snigdho

>
> -neetu

--
Snigdho C. Bardalai
Phone - (972) 479-2951
Fax   - (972) 479-4724
Email - snigdho.bardalai@fnc.fujitsu.com






From owner-mpls@UU.NET  Tue Jun  6 11:40:28 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10454
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 11:40:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisks05705;
	Tue, 6 Jun 2000 15:38:46 GMT
Received: by mail-control.mail.uu.net 
	id QQisks17817
	for mpls-outgoing; Tue, 6 Jun 2000 15:38:18 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisks17763
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:38:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisks10213
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:37:49 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQisks09132
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:37:48 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69JAW>; Tue, 6 Jun 2000 08:43:39 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D78@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Chris LaVallee'" <clavallee@zumanetworks.com>, jleu@mindspring.com,
        David Wang <david.wang@metro-optix.com>
Cc: mpls@UU.NET
Subject: RE: Ingress LER in LDP
Date: Tue, 6 Jun 2000 08:43:38 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Chris,

	Please read the draft:

    http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt

I'm not sure where you got the quote below (I seem to
be getting mail messages from the MPLS mailing list 
in some sort of random ordering), but it is incorrect
- the numbers given are not ether types...

--
Eric Gray

> -----Original Message-----
> From: Chris LaVallee [mailto:clavallee@zumanetworks.com]
> Sent: Friday, June 02, 2000 4:29 PM
> To: jleu@mindspring.com; David Wang
> Cc: mpls@UU.NET
> Subject: RE: Ingress LER in LDP
> 
> 
> > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to 
> 0x0800 for IP)
> 
> This might be off topic, but...
> 
> How do you get an ethertype over POS ? 
> I'm guessing it's Cisco-HDLC (which I know nothing about)
> 
> PPP over POS has 2 other possibilities to carry MPLS
> - Add a new CP (control proto) for MPLS
> - Have BCP (PPP Bridging) carry MPLS
> 
> Anyone have a preference / opinion on what people should use ?
> 
> Chris
> 
> 
> 
> 
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf 
> Of James R.
> > Leu
> > Sent: Friday, June 02, 2000 11:43 AM
> > To: David Wang
> > Cc: mpls@UU.NET
> > Subject: Re: Ingress LER in LDP
> > 
> > 
> > On Fri, Jun 02, 2000 at 01:20:33PM -0500, David Wang wrote:
> > > One related question: How a LSR distinguishes a labeled 
> packet from an
> > > unlabeled packet? 
> > 
> > Depends on the medium:
> > -ATM the VCC will contain a protcol type (AAL5Null requires this)
> > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to 
> 0x0800 for IP)
> > -PPP has some PIDs assigned for MPLS as well (as does IP)
> > 
> > Hope this helps.
> > 
> > Jim
> > 
> > > 
> > > -----Original Message-----
> > > From: Eric Rosen [mailto:erosen@cisco.com]
> > > Sent: Thursday, June 01, 2000 9:28 AM
> > > To: Santosh Gupta
> > > Cc: mpls@UU.NET
> > > Subject: Re: Ingress LER in LDP 
> > > 
> > > 
> > > Santosh> Can someone tell me how to decide if a router is 
> > supposed to act as
> > > Santosh> an Ingress LER for some particular FEC in MPLS domain ?
> > > 
> > > People keep asking  this question, and I'm never quite sure  
> > just what it is
> > > they are asking, because there isn't much of a mystery here.
> > > 
> > > If a router received an unlabeled  packet which belongs to a 
> > particular FEC,
> > > and the next hop for that packet supports MPLS, and the router 
> > is configured
> > > such that it is allowed to do allow label imposition for 
> > packets in that FEC
> > > with that next hop, then the router should impose the label 
> > assigned to that
> > > FEC by that next hop.
> > > 
> > > Does that answer your question? 
> > 
> > -- 
> > James R. Leu
> > 
> 


From owner-mpls@UU.NET  Tue Jun  6 11:42:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10534
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 11:42:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisks12847;
	Tue, 6 Jun 2000 15:41:13 GMT
Received: by mail-control.mail.uu.net 
	id QQisks17944
	for mpls-outgoing; Tue, 6 Jun 2000 15:40:45 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisks17937
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:40:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisks10953
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:40:30 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQisks12107
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:40:29 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA21463;
	Tue, 6 Jun 2000 08:40:37 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA10091; Tue, 6 Jun 2000 11:40:26 -0400 (EDT)
Message-Id: <200006061540.LAA10091@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: "Santosh Gupta" <santoshgupta@poboxes.com>
cc: mpls@UU.NET
Subject: Re: Knowing Egress LER using LDP 
In-reply-to: Your message of Tue, 06 Jun 2000 11:50:27 +0530.
             <009d01bfcf7f$5392f780$100d85a5@dti.daewoo.co.kr> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 06 Jun 2000 11:40:26 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Santosh> I  came across the  following in  "draft-ietf-mpls-arch-06.txt". In
Santosh> Section "4.1.6.  Option: Egress-Targeted Label  Assignment" page 43
Santosh> it says

        - It  is possible  to use  the label  distribution protocol  to pass
          information about  which address prefixes are  "attached" to which
          egress LSRs.   This method has  the advantage of not  depending on
          the presence of link state routing.  

Santosh> This  implies Ingress  LER can  determine the  Egress LER  for each
Santosh> address prefix.  Can someone point  out how this could  possibly be
Santosh> done using LDP ?

This is  a "leftover"  from IBM's  old ARIS project.   I don't  believe that
protocol to support this was ever fully specified. 



From owner-mpls@UU.NET  Tue Jun  6 11:53:37 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10824
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 11:53:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskt22085;
	Tue, 6 Jun 2000 15:52:10 GMT
Received: by mail-control.mail.uu.net 
	id QQiskt18709
	for mpls-outgoing; Tue, 6 Jun 2000 15:51:46 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiskt18704
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:51:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskt13433
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:51:05 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQiskt20833
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:51:04 GMT
Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA18173;
	Tue, 6 Jun 2000 11:50:33 -0400 (EDT)
	(envelope-from bkumar@ennovatenetworks.com)
Reply-To: <bkumar@ennovatenetworks.com>
From: "Brijesh Kumar" <bkumar@ennovatenetworks.com>
To: "'Dmitri Krioukov'" <dima@krioukov.net>, <mpls@UU.NET>
Subject: RE: MPLS Performance analysis.....
Date: Tue, 6 Jun 2000 11:54:24 -0400
Message-ID: <001401bfcfcf$7d67d580$d001010a@tst.ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-reply-to: <NCBBIKACLKNMKDHKKKNFKEBAELAA.dima@krioukov.net>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Dmitri Krioukov writes:
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Dmitri
> Krioukov
> i'd like to hear any points of view of the members
> of this list on motivation #1 (te) accompanied
> with some far going criticism to this reference:
> http://smg.ulb.ac.be/Preprints/Fortz99_29.html
> (it was brought up to discussion on nanog
> mailing list recently).
>
> i understand that the major assumption in this paper
> (about the demand matrix availability) is too
> brave, but this paper is a major indication
> that the te-related research beyond the ever
> lasting vc reinvention approach has not been
> exhausted yet. clearly, you wouldn't need any
> external signaling mechanism if all benefits
> te brings you (congestion avoidance, qos, etc)
> may be achieved by means of some (rather
> futuristic at this point) routing protocol.

That is a very good case specific paper (also a good theoretical paper),
however the solution is  dependent on the demand matrix (demand between two
nodes s and t) D(s,t,T) remaining constant for a substantial period of time
(T). The authors recognize that the solution will be lot more harder to
implement when this assumption is not true. The overheads of Routing
protocols being directly dependent on the frequency  at which network states
must be updated in routers, makes the goal of supporting time variant
traffic demands without proportionally increasing routing and related
signaling overheads very hard, if not impossible, to achieve. On the other
hand, as you rightly said, the difficulty of designing routing protocols
that can naturally accommodate TE should not be precluded as an approach.
But that approach better match MPLS TE functionality and have less overheads
to be acceptable. Kind of hard task..

At this point, MPLS remains the best long term solution for TE.

> at the very general level, the packet switched
> networks proved to provide much higher level of
> adaptation to the new requirements. since the
> packet switched networks are theoretically
> more complex than circuit switched ones, the way
> to adapt to a new requirement (te) may not be obvious
> until some significant research effort is done. this
> does not mean that we have to avoid this effort since
> the easy way may not lead anywhere...

Good point. I am sure even MPLS design can benefit from those efforts.

--brijesh
Ennovate Networks Inc.



From owner-mpls@UU.NET  Tue Jun  6 11:56:51 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10857
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 11:56:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskt24785;
	Tue, 6 Jun 2000 15:55:29 GMT
Received: by mail-control.mail.uu.net 
	id QQiskt18904
	for mpls-outgoing; Tue, 6 Jun 2000 15:55:06 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiskt18899
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 15:55:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskt27325
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:49:56 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQiskt20488
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:49:56 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69JB6>; Tue, 6 Jun 2000 08:55:47 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D79@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'neetug@daewoo.dti.daewoo.co.kr'" <neetug@daewoo.dti.daewoo.co.kr>,
        mpls@UU.NET
Subject: RE: Applications running on RSVP Aware Host End
Date: Tue, 6 Jun 2000 08:55:39 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Neetu,

	Considering the primary application du jour
for MPLS is traffic engineering, only network 
elements would determine the treatment of host
packets in the network.  This could - for example
- be the result of a service level agreement or
a network domain local decision.

	In general, it would be nice if the network 
operators could rely on hosts to properly set bits
in the IP header according to how the packets will
be treated in competition with other packets in a
network.  But this is unlikely since "cheaters"
prosper only too well.

--
Eric Gray

> -----Original Message-----
> From: Neetu Gupta [mailto:neetug@daewoo.dti.daewoo.co.kr]
> Sent: Monday, June 05, 2000 11:47 PM
> To: mpls@UU.NET
> Subject: Applications running on RSVP Aware Host End
> 
> 
> Hello,
>     I've a doubt. Please clarify it.
> 
>     We are implementing both Integrated Signaling and Diff Serv LSPs
> using RSVP in the MPLS Domain.
> 
>     Now, my question is: Do the Applications running on the 
> Host machine
> have to be RSVP Aware only or not? Can we run a general 
> Application? If
> we can, then how will the Type of Service byte in the IP Header be set
> specifying the Class of Service with which the data packets of the
> Application will be sent.
> 
> -neetu
> 


From owner-mpls@UU.NET  Tue Jun  6 12:09:35 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11224
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 12:09:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisku07069;
	Tue, 6 Jun 2000 16:06:06 GMT
Received: by mail-control.mail.uu.net 
	id QQisku27662
	for mpls-outgoing; Tue, 6 Jun 2000 16:05:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisku27596
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 16:05:26 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisku29453
	for <mpls@uu.net>; Tue, 6 Jun 2000 12:01:23 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisku01683
	for <mpls@uu.net>; Tue, 6 Jun 2000 16:01:17 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA07036
	for mpls@uu.net; Tue, 6 Jun 2000 12:01:16 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisku21199
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 16:00:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskt14973
	for <mpls@UU.NET>; Tue, 6 Jun 2000 11:59:18 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQiskt29478
	for <mpls@UU.NET>; Tue, 6 Jun 2000 15:59:18 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA17798;
	Tue, 6 Jun 2000 08:56:51 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MCB49>; Tue, 6 Jun 2000 08:56:51 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405D7@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'tom worster'" <tom@ennovatenetworks.com>, curtis@avici.com
Cc: "'CATANZARITI Sergio FTR&D/TI'"
	 <sergio.catanzariti@rd.francetelecom.com>,
        mpls@UU.NET
Subject: RE: MPLS Diffserv Extensions related questions/comments 
Date: Tue, 6 Jun 2000 08:53:57 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

>-----Original Message-----
>From: tom worster [mailto:tom@ennovatenetworks.com]
>Sent: Tuesday, June 06, 2000 11:05 AM
>To: curtis@avici.com
>Cc: 'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET
>Subject: RE: MPLS Diffserv Extensions related questions/comments 
>
>
>From: Curtis Villamizar [mailto:curtis@avici.com]
>> 
>> In message 
>> <000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com>, "tom wors
>> ter" writes:
>> > 
>> > > I do not understand the "hardware cost friendly"
>> > > problem.
>> > 
>> > the cost i'm referring to is that a system needs to
>> > provide memory to store an exp -> phb mapping for
>> > every lsp. in a fast implementation that may come
>> > at a noticeable marginal hw memory cost.
>> 
>> If the network provider is reasonably sane, then you will probalby
>> need to map a medium to large number of LSPs into a small number of
>> EXP to PHB mappings.
>
>that's what i imagined too. which is why i question the
>design of a protocol that provides unnecessary resolution
>with a non-trivial cost attached to that resolution.
>

In the diff-ext draft, the EXP->PHB signaling is optional. If an operator
does not want to use more than 8 PHBs in his network, and wants to use
E-LSP, then the pre-configured EXP->PHB mapping can be used.

>
>> OTOH .. at least a few people built full mesh IGPs on ATM overlays so
>> assumptions of ISP sanity don't hold up universally.  :-(
>
>if the requirement for a different exp -> phb mapping for 
>each of a medium to large number of lsps is considered
>unreasonable then that should be taken into consideration
>in the diff-ext protocol design.
>
>i thought about a separation of ds semantics from mpls
>signalling using an "exp -> phb mapping index" which would
>be signalled in the new tlv instead of the mapping itself.
>a set of mappings would be configured and referred to in 
>the by the index in the signalling messages.
>
>the technical benefits i see are reduced signalling 
>bandwidth and processing and a reduced per lsp memory
>budget.

Signaling will be reduced a bit (but signaling BW is not an issue in MPLS),
but it creates another problem, which is that you need to configure your
EXP->PHB mappings (which are now more than 8) in each router. Remember, the
purpose of signaling was to eliminate the EXP->PHB configuration.

Regarding the reduction of per-LSP memory; well it all depends on what you
are comparing it to. One solution which will reduce the per-LSP memory and
still uses the signaled EXP->PHB mapping is to build a few general purpose
EXP->PHB mapping tables (in each LSR), from the first few LSP setup
messages, and use them as an index in per-LSP ILM/NHLFE tables.  Using this
method, the amount of per-LSP memory is less than  or equal to your
proposal.


>
>but there are other advantages. the diff-ext draft could
>be radically simplified since the distinction of e-lsp
>and l-lsp disappears -- they are just different classes
>of mappings. conceivable, the mappings could go into
>experimental rfcs and a range of indexes could be reserved
>for standardisation. such a separation of mpls signalling
>and (perhaps more controversial) ds-related semantics could 
>be expeditious.
>

Diff-ext-04 has been in circulation for quite a while. And we are releasing
diff-ext-05 by Thursday. Therefore I not only I don't think such a
seperation could be expeditious, but also that would delay the whole process
by months if not a year.


Regards,
Shahram


>c u
>tom
>



From owner-mpls@UU.NET  Tue Jun  6 12:11:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11277
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 12:11:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisku12370;
	Tue, 6 Jun 2000 16:10:46 GMT
Received: by mail-control.mail.uu.net 
	id QQisku28905
	for mpls-outgoing; Tue, 6 Jun 2000 16:09:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisku28883
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 16:09:43 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisku00116
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:04:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQisku01905
	for <mpls@UU.NET>; Tue, 6 Jun 2000 16:04:56 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02903
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:04:53 -0400 (EDT)
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 MAA06015
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:04:52 -0400 (EDT)
Message-ID: <393D2132.1DED9FB8@marconi.com>
Date: Tue, 06 Jun 2000 12:05:06 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Ingress LER in LDP
References: <9A564CC874B5D3118FB9009027B0A6622D7D78@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric Gray wrote:
> 
>         Please read the draft:
> 
>     http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt
> 
> I'm not sure where you got the quote below (I seem to be getting mail
> messages from the MPLS mailing list in some sort of random ordering),
> but it is incorrect - the numbers given are not ether types...

I just read it and it says the same thing Chris quoted.  Section 5:

    5. Transporting Labeled Packets over LAN Media

	Exactly one labeled packet is carried in each frame.

	The label stack entries immediately precede the network layer
	header, and follow any data link layer headers, including, e.g.,
	any 802.1Q headers that may exist.

	The ethertype value 8847 hex is used to indicate that a frame is
	carrying an MPLS unicast packet.

	The ethertype value 8848 hex is used to indicate that a frame is
	carrying an MPLS multicast packet.

	These ethertype values can be used with either the ethernet
	encapsulation or the 802.3 LLC/SNAP encapsulation to carry
	labeled packets.  The procedure for choosing which of these two
	encapsulations to use is beyond the scope of this document.

(I do note, however, that the draft doesn't specifically say anything
about POS.  It just says what I quoted above.)

-- David

>> -----Original Message-----
>> From: Chris LaVallee [mailto:clavallee@zumanetworks.com]
>> Sent: Friday, June 02, 2000 4:29 PM
>> To: jleu@mindspring.com; David Wang
>> Cc: mpls@UU.NET
>> Subject: RE: Ingress LER in LDP
>>
>>
>> > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to
>> 0x0800 for IP)
>>
>> This might be off topic, but...
>>
>> How do you get an ethertype over POS ?
>> I'm guessing it's Cisco-HDLC (which I know nothing about)
>>
>> PPP over POS has 2 other possibilities to carry MPLS
>> - Add a new CP (control proto) for MPLS
>> - Have BCP (PPP Bridging) carry MPLS
>>
>> Anyone have a preference / opinion on what people should use ?


From owner-mpls@UU.NET  Tue Jun  6 12:28:21 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13644
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 12:28:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskv22642;
	Tue, 6 Jun 2000 16:27:19 GMT
Received: by mail-control.mail.uu.net 
	id QQiskv00531
	for mpls-outgoing; Tue, 6 Jun 2000 16:26:58 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiskv00520
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 16:26:41 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskv19983
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:26:17 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQiskv21687
	for <mpls@UU.NET>; Tue, 6 Jun 2000 16:26:17 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69JF2>; Tue, 6 Jun 2000 09:32:08 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D7B@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Bob Thomas'" <rhthomas@cisco.com>,
        Surekha Gupta
	 <santoshg@daewoo.dti.daewoo.co.kr>
Cc: mpls@UU.NET
Subject: RE: Address Message in LDP 
Date: Tue, 6 Jun 2000 09:32:03 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Santosh/Surekha(?)

	Which is it? :-)

	To add to what Bob has said, one of your base
assumptions is not necessarily correct.  Two LSR peers
may be connected by more than one link.  Additional 
interface addresses may be assigned to any interface
of a router.  Also, an LSR that shares more than one
link with a peer LSR will most likely use its router
ID as its LDP ID (address portion) in order to avoid
losing its LDP session as a result of removing the
interface (from which it got the IP address) from
service (i.e. - pulling out the interface card, or
executing a "shut" command).  In any of these cases,
it is some advantage to know additional addresses
that apply to peer LSRs.

--
Eric Gray

> -----Original Message-----
> From: Bob Thomas [mailto:rhthomas@cisco.com]
> Sent: Tuesday, June 06, 2000 7:08 AM
> To: Surekha Gupta
> Cc: mpls@UU.NET
> Subject: Re: Address Message in LDP 
> 
> 
> Santosh,
> 
> > Hello Bob
> >     I have gone thru the section but still have a doubt. 
> Even in DownStream
> > unsolicited Mode of label distribution, according to the 
> draft each LSR
> > keeps a list of address prefix and their associated  (LDP 
> Identifier, label)
> > 
> > LDP Identifier = Interface IP Address : Label Space.
> 
> There is no guarantee/requirement that the first 4 octects of the
> LDP Id is the IP address of the "Interface".
> 
> 
> > Actually the Next hop address in the routing table will 
> exactly match the
> > "Interface IP Address" specified in the LDP Identifier. 
> This "Interface IP
> 
> I think you cannot guarantee that this is always true.
> 
> 
> > Address" is the one directly connected to the peer.
> > This is depicted below.
> > 
> >                                             C
> >                                       /
> >                                 A   -----  | B |
> >                                       \
> >                                             D
> > 
> > If B,C,D are directly connected to A then the "Interface IP 
> Address" that
> > will be specified in the Address Message will be the same 
> as the Interface
> > which A concludes from the HELLO message exchange. So what 
> is the need for a
> > seperate "Address Message" altogether ?
> 
> Please see comments above.
> 
> 
> Bob
> 
> 
> > One more thing, what is the use of specifying some other 
> "Interace IP
> > Address" to A by B (say the interface of B with C ) if that 
> is not the
> > directly connected interface to A?
> > 
> > 
> > > Santosh,
> > >
> > > >     In draft-ietf-mpls-ldp-06.txt, there is an Address 
> Message and =
> > > > Address Withdraw Message. I am not able to figure out 
> what purpose does
> > =
> > > > it serve. In the Hello packet that an LSR sends, it can 
> send the =
> > > > Interface IP Address optionally. If it doesnt send then 
> the receiving =
> > > > LSR can make out when it receives from the particular 
> socket. And what =
> > > > do we gain if an LSR advertizes IP Addresses of other 
> interfaces also ?
> > =
> > > > The connection between 2 LSRs is anyway thru some 
> particular interface =
> > > > and knowing the IP Address of other interfaces will be 
> of no use.
> > >
> > > See Section "LDP Identifiers and Next Hop Addresses".
> > >
> > > Bob
> > >
> > 
> > 
> 
> 


From owner-mpls@UU.NET  Tue Jun  6 12:36:55 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13921
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 12:36:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskw01433;
	Tue, 6 Jun 2000 16:36:14 GMT
Received: by mail-control.mail.uu.net 
	id QQiskw00996
	for mpls-outgoing; Tue, 6 Jun 2000 16:35:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiskw00991
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 16:35:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiskw05605
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:34:55 -0400 (EDT)
Received: from hork.mrv.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uunet-hork.mrv.com [208.195.192.3])
	id QQiskw00303
	for <mpls@UU.NET>; Tue, 6 Jun 2000 16:34:55 GMT
Received: from chris (ok.mrv.com [208.195.192.2])
	by hork.mrv.com (8.10.1/8.10.0) with SMTP id e56GYhr17250;
	Tue, 6 Jun 2000 09:34:43 -0700
X-Authentication-Warning: hork.mrv.com: Host ok.mrv.com [208.195.192.2] claimed to be chris
From: "Chris LaVallee" <clavallee@zumanetworks.com>
To: "Eric Gray" <EGray@zaffire.com>, <jleu@mindspring.com>,
        "David Wang" <david.wang@metro-optix.com>
Cc: <mpls@UU.NET>
Subject: RE: Ingress LER in LDP
Date: Tue, 6 Jun 2000 09:35:11 -0700
Message-ID: <000801bfcfd5$2f3bdfe0$a701a8c0@internal.nbase.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <9A564CC874B5D3118FB9009027B0A6622D7D78@ICARIAN>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I was already aware of the MPLSCP in the draft, so what I really meant to
ask was this:

1) Cisco-HDLC uses ethertypes, right ? Therefore MPLS will treat
POS/Cisco-HDLC as Ethernet.

2) Is there really a benefit to PPP-MPLSCP ?
Meaning, you could just use Cisco-HDLC or PPP-BCP. MPLSCP doesn't negotiate
anything.

I guess you do save a few bytes with PPP-MPLS data and if you're only MPLS
switching PPP to PPP, nothing has to be add/deleted or modified in the
packet.


Chris




> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Tuesday, June 06, 2000 8:44 AM
> To: 'Chris LaVallee'; jleu@mindspring.com; David Wang
> Cc: mpls@UU.NET
> Subject: RE: Ingress LER in LDP
>
>
> Chris,
>
> 	Please read the draft:
>
>
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt
>
> I'm not sure where you got the quote below (I seem to
> be getting mail messages from the MPLS mailing list
> in some sort of random ordering), but it is incorrect
> - the numbers given are not ether types...
>
> --
> Eric Gray
>
> > -----Original Message-----
> > From: Chris LaVallee [mailto:clavallee@zumanetworks.com]
> > Sent: Friday, June 02, 2000 4:29 PM
> > To: jleu@mindspring.com; David Wang
> > Cc: mpls@UU.NET
> > Subject: RE: Ingress LER in LDP
> >
> >
> > > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to
> > 0x0800 for IP)
> >
> > This might be off topic, but...
> >
> > How do you get an ethertype over POS ?
> > I'm guessing it's Cisco-HDLC (which I know nothing about)
> >
> > PPP over POS has 2 other possibilities to carry MPLS
> > - Add a new CP (control proto) for MPLS
> > - Have BCP (PPP Bridging) carry MPLS
> >
> > Anyone have a preference / opinion on what people should use ?
> >
> > Chris
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf
> > Of James R.
> > > Leu
> > > Sent: Friday, June 02, 2000 11:43 AM
> > > To: David Wang
> > > Cc: mpls@UU.NET
> > > Subject: Re: Ingress LER in LDP
> > >
> > >
> > > On Fri, Jun 02, 2000 at 01:20:33PM -0500, David Wang wrote:
> > > > One related question: How a LSR distinguishes a labeled
> > packet from an
> > > > unlabeled packet?
> > >
> > > Depends on the medium:
> > > -ATM the VCC will contain a protcol type (AAL5Null requires this)
> > > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to
> > 0x0800 for IP)
> > > -PPP has some PIDs assigned for MPLS as well (as does IP)
> > >
> > > Hope this helps.
> > >
> > > Jim
> > >
> > > >
> > > > -----Original Message-----
> > > > From: Eric Rosen [mailto:erosen@cisco.com]
> > > > Sent: Thursday, June 01, 2000 9:28 AM
> > > > To: Santosh Gupta
> > > > Cc: mpls@UU.NET
> > > > Subject: Re: Ingress LER in LDP
> > > >
> > > >
> > > > Santosh> Can someone tell me how to decide if a router is
> > > supposed to act as
> > > > Santosh> an Ingress LER for some particular FEC in MPLS domain ?
> > > >
> > > > People keep asking  this question, and I'm never quite sure
> > > just what it is
> > > > they are asking, because there isn't much of a mystery here.
> > > >
> > > > If a router received an unlabeled  packet which belongs to a
> > > particular FEC,
> > > > and the next hop for that packet supports MPLS, and the router
> > > is configured
> > > > such that it is allowed to do allow label imposition for
> > > packets in that FEC
> > > > with that next hop, then the router should impose the label
> > > assigned to that
> > > > FEC by that next hop.
> > > >
> > > > Does that answer your question?
> > >
> > > --
> > > James R. Leu
> > >
> >
>



From owner-mpls@UU.NET  Tue Jun  6 12:59:52 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14619
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 12:59:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiskx18408;
	Tue, 6 Jun 2000 16:58:31 GMT
Received: by mail-control.mail.uu.net 
	id QQiskx02185
	for mpls-outgoing; Tue, 6 Jun 2000 16:58:14 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiskx02180
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 16:58:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiskx09635
	for <mpls@UU.NET>; Tue, 6 Jun 2000 12:57:29 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQiskx22443
	for <mpls@UU.NET>; Tue, 6 Jun 2000 16:57:29 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69J2A>; Tue, 6 Jun 2000 10:03:19 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6622D7D7F@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Chris LaVallee'" <clavallee@zumanetworks.com>
Cc: mpls@UU.NET, jleu@mindspring.com,
        David Wang
	 <david.wang@metro-optix.com>
Subject: RE: Ingress LER in LDP
Date: Tue, 6 Jun 2000 10:03:12 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Chris,

	The "standard" approach - as far as I know -
is to use PPP for POS.  The ethertypes defined in
[ENCAPS] are for transmission of MPLS labeled data
over "LAN media".  It is arguable that some type of
HDLC framing of IP packets makes SONET a "LAN media"
but that may be a stretch - particularly if a pro-
prietary approach is used.  PPP protocol numbers 
0x0281 (unicast) and 0x0283 (multicast) are defined 
for PPP encapsulation of MPLS labeled packets.

	I am not familiar with whether or not the 
Cisco proprietary approach you describe (I will
take your word for it that it exists) is available
without licensing fees.  If it exists, is deployed
as the only Cisco supported POS approach and is not
available for licensing, then I think we can look 
forward to government regulation of the new Internet 
monopoly in the very near future. :-)

--
Eric Gray

> -----Original Message-----
> From: Chris LaVallee [mailto:clavallee@zumanetworks.com]
> Sent: Tuesday, June 06, 2000 9:35 AM
> To: Eric Gray; jleu@mindspring.com; David Wang
> Cc: mpls@UU.NET
> Subject: RE: Ingress LER in LDP
> 
> 
> I was already aware of the MPLSCP in the draft, so what I 
> really meant to
> ask was this:
> 
> 1) Cisco-HDLC uses ethertypes, right ? Therefore MPLS will treat
> POS/Cisco-HDLC as Ethernet.
> 
> 2) Is there really a benefit to PPP-MPLSCP ?
> Meaning, you could just use Cisco-HDLC or PPP-BCP. MPLSCP 
> doesn't negotiate
> anything.
> 
> I guess you do save a few bytes with PPP-MPLS data and if 
> you're only MPLS
> switching PPP to PPP, nothing has to be add/deleted or modified in the
> packet.
> 
> 
> Chris
> 
> 
> 
> 
> > -----Original Message-----
> > From: Eric Gray [mailto:EGray@zaffire.com]
> > Sent: Tuesday, June 06, 2000 8:44 AM
> > To: 'Chris LaVallee'; jleu@mindspring.com; David Wang
> > Cc: mpls@UU.NET
> > Subject: RE: Ingress LER in LDP
> >
> >
> > Chris,
> >
> > 	Please read the draft:
> >
> >
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-enca
> ps-07.txt
> >
> > I'm not sure where you got the quote below (I seem to
> > be getting mail messages from the MPLS mailing list
> > in some sort of random ordering), but it is incorrect
> > - the numbers given are not ether types...
> >
> > --
> > Eric Gray
> >
> > > -----Original Message-----
> > > From: Chris LaVallee [mailto:clavallee@zumanetworks.com]
> > > Sent: Friday, June 02, 2000 4:29 PM
> > > To: jleu@mindspring.com; David Wang
> > > Cc: mpls@UU.NET
> > > Subject: RE: Ingress LER in LDP
> > >
> > >
> > > > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to
> > > 0x0800 for IP)
> > >
> > > This might be off topic, but...
> > >
> > > How do you get an ethertype over POS ?
> > > I'm guessing it's Cisco-HDLC (which I know nothing about)
> > >
> > > PPP over POS has 2 other possibilities to carry MPLS
> > > - Add a new CP (control proto) for MPLS
> > > - Have BCP (PPP Bridging) carry MPLS
> > >
> > > Anyone have a preference / opinion on what people should use ?
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf
> > > Of James R.
> > > > Leu
> > > > Sent: Friday, June 02, 2000 11:43 AM
> > > > To: David Wang
> > > > Cc: mpls@UU.NET
> > > > Subject: Re: Ingress LER in LDP
> > > >
> > > >
> > > > On Fri, Jun 02, 2000 at 01:20:33PM -0500, David Wang wrote:
> > > > > One related question: How a LSR distinguishes a labeled
> > > packet from an
> > > > > unlabeled packet?
> > > >
> > > > Depends on the medium:
> > > > -ATM the VCC will contain a protcol type (AAL5Null 
> requires this)
> > > > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to
> > > 0x0800 for IP)
> > > > -PPP has some PIDs assigned for MPLS as well (as does IP)
> > > >
> > > > Hope this helps.
> > > >
> > > > Jim
> > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Eric Rosen [mailto:erosen@cisco.com]
> > > > > Sent: Thursday, June 01, 2000 9:28 AM
> > > > > To: Santosh Gupta
> > > > > Cc: mpls@UU.NET
> > > > > Subject: Re: Ingress LER in LDP
> > > > >
> > > > >
> > > > > Santosh> Can someone tell me how to decide if a router is
> > > > supposed to act as
> > > > > Santosh> an Ingress LER for some particular FEC in 
> MPLS domain ?
> > > > >
> > > > > People keep asking  this question, and I'm never quite sure
> > > > just what it is
> > > > > they are asking, because there isn't much of a mystery here.
> > > > >
> > > > > If a router received an unlabeled  packet which belongs to a
> > > > particular FEC,
> > > > > and the next hop for that packet supports MPLS, and the router
> > > > is configured
> > > > > such that it is allowed to do allow label imposition for
> > > > packets in that FEC
> > > > > with that next hop, then the router should impose the label
> > > > assigned to that
> > > > > FEC by that next hop.
> > > > >
> > > > > Does that answer your question?
> > > >
> > > > --
> > > > James R. Leu
> > > >
> > >
> >
> 


From owner-mpls@UU.NET  Tue Jun  6 13:08:29 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14832
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 13:08:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisky27818;
	Tue, 6 Jun 2000 17:05:48 GMT
Received: by mail-control.mail.uu.net 
	id QQisky11424
	for mpls-outgoing; Tue, 6 Jun 2000 17:05:12 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisky11410
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 17:05:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisky27439
	for <mpls@UU.NET>; Tue, 6 Jun 2000 13:04:41 -0400 (EDT)
Received: from arthur.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: arthur.axion.bt.co.uk [132.146.5.4])
	id QQisky27032
	for <mpls@UU.NET>; Tue, 6 Jun 2000 17:04:41 GMT
Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) 
          by arthur (local) with SMTP; Tue, 6 Jun 2000 18:04:16 +0100
Received: from ip-engineering.bt.com 
          by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id SAA24312;
          Tue, 6 Jun 2000 18:04:14 +0100 (BST)
Message-Id: <200006061704.SAA24312@celiborn.ip-engineering.bt.com>
X-Mailer: exmh version 2.0.3 9/28/98
To: curtis@avici.com
cc: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>, neil.2.harrison@bt.com,
        otel@ce.chalmers.se, Shahram_Davari@pmc-sierra.com, EGray@zaffire.com,
        swtan@mmu.edu.my, kireeti@juniper.net, dwilder@baynetworks.com,
        mpls@UU.NET
Subject: Re: OAM functionality 
         (Was: RE: can egress know the ingressof a packet?)
In-reply-to: Your message of "Tue, 06 Jun 2000 11:12:17 EDT." <200006061512.LAA13982@curtis-lt.avici.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 06 Jun 2000 18:04:13 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk



> We might want to ask ISPs how valuable RR IP option on ping has been
> and how valuable the equivalent ATM OAM cells have been.  We may find
> that the former is used occasionally at most and the latter even less
> or not at all for IP over ATM networks.

I have been network manager of BT's Internet services for 4 years. The RR
option on ping was used very rarely. ATM OAM is essential to the operation
of the network (we have an extensive ATM network). The ATM OAM is used
by the routers to detect failures in ATM VCs and raise SNMP traps. The
up/down status of the router interface is also dependent on ATM OAM so
we can run resilient ATM services to customers without running a routing
protocol to the customers' CPE/NTE.

As a network operator I have the following requirements:
- I need to detect failure of an LSP. (I don't want to wait for the
	customer to report a failure)
	There are more failure states of LSPs than standard destination
	based routing because relative labels are used for switching. For
	example we can have LSP traffic delivered to the wrong destination
	by a simple bug on a single LSR (it is far less likely to happen
	on an IP network using per hop routing because if
	a router sends it the wrong way the next router will probably
	send it back (get a routing loop) or send it the right way). How
	do I (as an operator) detect this failure?
	Sure I could use a remote ping function on the customer premises 
	equipment and when it fails raise an alarm. But I have to create
	a full mesh of addresses to ping to cover all the customers
	address space and sites (in the case of IP VPNs). This seems a bit
	clumsy to me. And for IP VPNs what happens if the customers are using
	the same 10.0.0.0 address space, chances are if my ping gets 
	misdelivered they'll still be a box in somebody else's network that
	will respond to the address I'm pinging (although we'll need 2 faults
	for that icmp echo-reply to get back).
	When MPLS is used for TE what do I ping from where? If the TE trunk
	fails won't I still get a response from ping because normal per-hop
	based routing will take over? So we need a TE tunnel liveness
	indicator. 
- I need tools to isolate where the fault is. Which LSR is causing the problem?
	It would be useful if when I get a failure in the network the alarms
	raised are a useful indicator of where the fault is. Then I can
	start using tools like ping and traceroute to narrow down where
	the fault is.

Peter.





From owner-mpls@UU.NET  Tue Jun  6 14:01:56 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15858
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 14:01:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQislc02956;
	Tue, 6 Jun 2000 18:00:02 GMT
Received: by mail-control.mail.uu.net 
	id QQislb14557
	for mpls-outgoing; Tue, 6 Jun 2000 17:59:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQislb14540
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 17:59:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQislb07871
	for <mpls@UU.NET>; Tue, 6 Jun 2000 13:58:54 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQislb01783
	for <mpls@UU.NET>; Tue, 6 Jun 2000 17:58:53 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id NAA11739; Tue, 6 Jun 2000 13:58:49 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id NAA14344;
	Tue, 6 Jun 2000 13:58:55 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006061758.NAA14344@curtis-lt.avici.com>
To: "tom worster" <tom@ennovatenetworks.com>
cc: curtis@avici.com,
        "'CATANZARITI Sergio FTR&D/TI'" <sergio.catanzariti@rd.francetelecom.com>,
        mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS Diffserv Extensions related questions/comments 
In-reply-to: Your message of "Tue, 06 Jun 2000 11:04:45 EDT."
             <001801bfcfc8$8d6ca660$6640a8c0@tst.ennovatenetworks.com> 
Date: Tue, 06 Jun 2000 13:58:54 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <001801bfcfc8$8d6ca660$6640a8c0@tst.ennovatenetworks.com>, "tom wors
ter" writes:
> 
> if the requirement for a different exp -> phb mapping for 
> each of a medium to large number of lsps is considered
> unreasonable then that should be taken into consideration
> in the diff-ext protocol design.


The BGP protocol specification doesn't need to limit the number of BGP
routes that need to be supported.  The OSPF protocol specification
doesn't need to limit the number of OSPF adjacencies or ASE routes and
most people know you can kill an OSPF implementation by feeding it a
grossly excessive number of ASE routes.

None of these protocols scale infinitely.  Yet they are all useful.

There is no need for diffserv or MPLS diffserv to specify similar
limits.  You need to find out what your customers are trying to build
in terms of number of routes, etc and build something that meets their
needs.  The IETF can't tell you that and it shouldn't try to.

Curtis


From owner-mpls@UU.NET  Tue Jun  6 14:18:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16144
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 14:18:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisld18253;
	Tue, 6 Jun 2000 18:17:03 GMT
Received: by mail-control.mail.uu.net 
	id QQisld24970
	for mpls-outgoing; Tue, 6 Jun 2000 18:16:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisld24965
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 18:16:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisld11608
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:15:25 -0400 (EDT)
Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63])
	id QQisld14327
	for <mpls@UU.NET>; Tue, 6 Jun 2000 18:15:24 GMT
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
	id <KG0FPSBC>; Tue, 6 Jun 2000 11:12:58 -0700
Message-ID: <337055FBC675D311A85D00508B5A9C4F2542DF@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
	 <sergio.catanzariti@rd.francetelecom.com>
To: "'tom worster'" <tom@ennovatenetworks.com>
Cc: CATANZARITI Sergio FTR&D/TI <sergio.catanzariti@rd.francetelecom.com>,
        mpls@UU.NET, "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        curtis@avici.com
Subject: RE: MPLS Diffserv Extensions related questions/comments 
Date: Tue, 6 Jun 2000 11:12:54 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFCFE2.D7CBEC4C"
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_01BFCFE2.D7CBEC4C
Content-Type: text/plain;
	charset="iso-8859-1"

	>the technical benefits i see are reduced signalling 
	>bandwidth and processing and a reduced per lsp memory
	>budget.

	Signaling will be reduced a bit (but signaling BW is not an issue in
MPLS),
	but it creates another problem, which is that you need to configure
your
	EXP->PHB mappings (which are now more than 8) in each router.
Remember, the
	purpose of signaling was to eliminate the EXP->PHB configuration.

	Yes, I meant that originally. Indeed, I was speaking as
configuration management duties as opposed to classical signalling tasks as
we know from the B-ISDN world. In this perspective, I guess that the power
of configuration flexibility  (optional) does not induce really a control
plane heavy weight.

	Sergio

> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com 
> --------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From:	Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> Sent:	Tuesday, June 06, 2000 8:54 AM
> To:	'tom worster'; curtis@avici.com
> Cc:	'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET
> Subject:	RE: MPLS Diffserv Extensions related questions/comments 
> 
> Hi,
> 
> >-----Original Message-----
> >From: tom worster [mailto:tom@ennovatenetworks.com]
> >Sent: Tuesday, June 06, 2000 11:05 AM
> >To: curtis@avici.com
> >Cc: 'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET
> >Subject: RE: MPLS Diffserv Extensions related questions/comments 
> >
> >
> >From: Curtis Villamizar [mailto:curtis@avici.com]
> >> 
> >> In message 
> >> <000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com>, "tom wors
> >> ter" writes:
> >> > 
> >> > > I do not understand the "hardware cost friendly"
> >> > > problem.
> >> > 
> >> > the cost i'm referring to is that a system needs to
> >> > provide memory to store an exp -> phb mapping for
> >> > every lsp. in a fast implementation that may come
> >> > at a noticeable marginal hw memory cost.
> >> 
> >> If the network provider is reasonably sane, then you will probalby
> >> need to map a medium to large number of LSPs into a small number of
> >> EXP to PHB mappings.
> >
> >that's what i imagined too. which is why i question the
> >design of a protocol that provides unnecessary resolution
> >with a non-trivial cost attached to that resolution.
> >
> 
> In the diff-ext draft, the EXP->PHB signaling is optional. If an operator
> does not want to use more than 8 PHBs in his network, and wants to use
> E-LSP, then the pre-configured EXP->PHB mapping can be used.
> 
> >
> >> OTOH .. at least a few people built full mesh IGPs on ATM overlays so
> >> assumptions of ISP sanity don't hold up universally.  :-(
> >
> >if the requirement for a different exp -> phb mapping for 
> >each of a medium to large number of lsps is considered
> >unreasonable then that should be taken into consideration
> >in the diff-ext protocol design.
> >
> >i thought about a separation of ds semantics from mpls
> >signalling using an "exp -> phb mapping index" which would
> >be signalled in the new tlv instead of the mapping itself.
> >a set of mappings would be configured and referred to in 
> >the by the index in the signalling messages.
> >
> >the technical benefits i see are reduced signalling 
> >bandwidth and processing and a reduced per lsp memory
> >budget.
> 
> Signaling will be reduced a bit (but signaling BW is not an issue in
> MPLS),
> but it creates another problem, which is that you need to configure your
> EXP->PHB mappings (which are now more than 8) in each router. Remember,
> the
> purpose of signaling was to eliminate the EXP->PHB configuration.
> 
> Regarding the reduction of per-LSP memory; well it all depends on what you
> are comparing it to. One solution which will reduce the per-LSP memory and
> still uses the signaled EXP->PHB mapping is to build a few general purpose
> EXP->PHB mapping tables (in each LSR), from the first few LSP setup
> messages, and use them as an index in per-LSP ILM/NHLFE tables.  Using
> this
> method, the amount of per-LSP memory is less than  or equal to your
> proposal.
> 
> 
> >
> >but there are other advantages. the diff-ext draft could
> >be radically simplified since the distinction of e-lsp
> >and l-lsp disappears -- they are just different classes
> >of mappings. conceivable, the mappings could go into
> >experimental rfcs and a range of indexes could be reserved
> >for standardisation. such a separation of mpls signalling
> >and (perhaps more controversial) ds-related semantics could 
> >be expeditious.
> >
> 
> Diff-ext-04 has been in circulation for quite a while. And we are
> releasing
> diff-ext-05 by Thursday. Therefore I not only I don't think such a
> seperation could be expeditious, but also that would delay the whole
> process
> by months if not a year.
> 
> 
> Regards,
> Shahram
> 
> 
> >c u
> >tom
> >

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: MPLS Diffserv Extensions related questions/comments </TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;the technical benefits i see =
are reduced signalling </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;bandwidth and processing =
and a reduced per lsp memory</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;budget.</FONT>
</P>

<P><I><FONT SIZE=3D2 FACE=3D"Courier New">Signaling will be reduced a =
bit (but signaling BW is not an issue in MPLS),</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Courier New">but it creates another =
problem, which is that you need to configure your</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Courier New">EXP-&gt;PHB mappings (which =
are now more than 8) in each router. Remember, the</FONT></I>
<BR><I><FONT SIZE=3D2 FACE=3D"Courier New">purpose of signaling was to =
eliminate the EXP-&gt;PHB configuration.</FONT></I>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Yes, I meant that originally. =
Indeed, I was speaking as configuration management duties as opposed to =
classical signalling tasks as we know from the B-ISDN world. In this =
perspective, I guess that the power of configuration flexibility&nbsp; =
(optional) does not induce really a control plane heavy =
weight.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Sergio</FONT>
</P>

<P><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sergio =
Catanzariti</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Senior Project =
Manager, Technology Integration</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">France Telecom =
R&amp;D </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">1000 Marina =
Boulevard Suite 300 </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brisbane CA =
94005</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tel. =
650-875-1526</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Fax. =
650-875-1505</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">email:sergio.catanzariti@rd.francetelecom.com =
</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
</P>
<BR>

<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Shahram Davari =
[SMTP:Shahram_Davari@pmc-sierra.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, June 06, 2000 8:54 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'tom worster'; curtis@avici.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'CATANZARITI Sergio FTR&amp;D/TI'; mpls@UU.NET</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: MPLS Diffserv Extensions related =
questions/comments </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;-----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;From: tom worster =
[<U></U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New"><A =
HREF=3D"mailto:tom@ennovatenetworks.com">mailto:tom@ennovatenetworks.com=
</A></FONT></U><FONT SIZE=3D2 FACE=3D"Courier New">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Sent: Tuesday, June 06, =
2000 11:05 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;To: curtis@avici.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Cc: 'CATANZARITI Sergio =
FTR&amp;D/TI'; mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Subject: RE: MPLS Diffserv =
Extensions related questions/comments </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;From: Curtis Villamizar =
[</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:curtis@avici.com">mailto:curtis@avici.com</A></FONT></U><=
FONT SIZE=3D2 FACE=3D"Courier New">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; In message </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&lt;000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com&gt;, =
&quot;tom wors</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; ter&quot; =
writes:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; &gt; I do not =
understand the &quot;hardware cost friendly&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; &gt; =
problem.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; the cost i'm =
referring to is that a system needs to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; provide memory to =
store an exp -&gt; phb mapping for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; every lsp. in a =
fast implementation that may come</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; at a noticeable =
marginal hw memory cost.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; If the network =
provider is reasonably sane, then you will probalby</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; need to map a medium =
to large number of LSPs into a small number of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; EXP to PHB =
mappings.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;that's what i imagined too. =
which is why i question the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;design of a protocol that =
provides unnecessary resolution</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;with a non-trivial cost =
attached to that resolution.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">In the diff-ext draft, the =
EXP-&gt;PHB signaling is optional. If an operator</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">does not want to use more than =
8 PHBs in his network, and wants to use</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">E-LSP, then the pre-configured =
EXP-&gt;PHB mapping can be used.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; OTOH .. at least a few =
people built full mesh IGPs on ATM overlays so</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; assumptions of ISP =
sanity don't hold up universally.&nbsp; :-(</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;if the requirement for a =
different exp -&gt; phb mapping for </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;each of a medium to large =
number of lsps is considered</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;unreasonable then that =
should be taken into consideration</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;in the diff-ext protocol =
design.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;i thought about a =
separation of ds semantics from mpls</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;signalling using an =
&quot;exp -&gt; phb mapping index&quot; which would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;be signalled in the new tlv =
instead of the mapping itself.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;a set of mappings would be =
configured and referred to in </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;the by the index in the =
signalling messages.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;the technical benefits i =
see are reduced signalling </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;bandwidth and processing =
and a reduced per lsp memory</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;budget.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Signaling will be reduced a bit =
(but signaling BW is not an issue in MPLS),</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">but it creates another problem, =
which is that you need to configure your</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">EXP-&gt;PHB mappings (which are =
now more than 8) in each router. Remember, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">purpose of signaling was to =
eliminate the EXP-&gt;PHB configuration.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regarding the reduction of =
per-LSP memory; well it all depends on what you</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">are comparing it to. One =
solution which will reduce the per-LSP memory and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">still uses the signaled =
EXP-&gt;PHB mapping is to build a few general purpose</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">EXP-&gt;PHB mapping tables (in =
each LSR), from the first few LSP setup</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">messages, and use them as an =
index in per-LSP ILM/NHLFE tables.&nbsp; Using this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">method, the amount of per-LSP =
memory is less than&nbsp; or equal to your</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">proposal.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;but there are other =
advantages. the diff-ext draft could</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;be radically simplified =
since the distinction of e-lsp</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;and l-lsp disappears -- =
they are just different classes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;of mappings. conceivable, =
the mappings could go into</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;experimental rfcs and a =
range of indexes could be reserved</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;for standardisation. such a =
separation of mpls signalling</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;and (perhaps more =
controversial) ds-related semantics could </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;be expeditious.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Diff-ext-04 has been in =
circulation for quite a while. And we are releasing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">diff-ext-05 by Thursday. =
Therefore I not only I don't think such a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">seperation could be =
expeditious, but also that would delay the whole process</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">by months if not a year.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Shahram</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;c u</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;tom</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCFE2.D7CBEC4C--


From owner-mpls@UU.NET  Tue Jun  6 14:35:14 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16613
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 14:35:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisle28696;
	Tue, 6 Jun 2000 18:33:58 GMT
Received: by mail-control.mail.uu.net 
	id QQisle25936
	for mpls-outgoing; Tue, 6 Jun 2000 18:33:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisle25928
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 18:33:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisle15418
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:33:05 -0400 (EDT)
Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63])
	id QQisle27972
	for <mpls@UU.NET>; Tue, 6 Jun 2000 18:33:04 GMT
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
	id <KG0FPSBT>; Tue, 6 Jun 2000 11:30:39 -0700
Message-ID: <337055FBC675D311A85D00508B5A9C4F2542E0@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
	 <sergio.catanzariti@rd.francetelecom.com>
To: "'tom worster'" <tom@ennovatenetworks.com>
Cc: mpls@UU.NET,
        CATANZARITI Sergio FTR&D/TI
	 <sergio.catanzariti@rd.francetelecom.com>,
        curtis@avici.com
Subject: RE: MPLS Diffserv Extensions related questions/comments 
Date: Tue, 6 Jun 2000 11:30:28 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFCFE5.4FC862FA"
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_01BFCFE5.4FC862FA
Content-Type: text/plain

	i certainly see the utility of being able to control
	the exp -> phb mapping. i just don't see (yet) that
	every phb needs a unique mapping.

Well, let me as an operator to decide if I want to or not that unique
mapping. When the ITU-T X/Y will define IP Diff Class Service Classes (ala
ITU-T I.362) with a defined PHB <-> service semantics mapping function, then
we can reduce our universe of configuration choices. But, at that point I
will be either dead or retired in Sicily enjoying beaches and pure Olive Oil
:-). The latter choice appeals me better, indeed.

	yes. say you could establish several exp -> phb
	mappings in your lsrs and each is given an index
	unique within the domain. you could signal the
	index per lsp. would not that give you the
	flexibility you are looking for? how many such
	mappings would you need?

I am not questioning the normalization aspect of the mapping, it is that
really all depends on what we want to achieve and how to implement an
LSP-supported differentiated services offerings environment.

Sergio

> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com 
> --------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From:	tom worster [SMTP:tom@ennovatenetworks.com]
> Sent:	Tuesday, June 06, 2000 5:52 AM
> To:	'CATANZARITI Sergio FTR&D/TI'; curtis@avici.com
> Cc:	mpls@UU.NET
> Subject:	RE: MPLS Diffserv Extensions related questions/comments 
> 
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of CATANZARITI
> Sergio FTR&D/TI
> >
> > I agree that it would be actually very helpful. I
> > would like to build topology-driven LSPs and use
> > EXP-PHBs stuff for differentiating CoS-like traffic.
> 
> i certainly see the utility of being able to control
> the exp -> phb mapping. i just don't see (yet) that
> every phb needs a unique mapping.
> 
> 
> > I do not understand the "hardware cost friendly"
> > problem.
> 
> the cost i'm referring to is that a system needs to
> provide memory to store an exp -> phb mapping for
> every lsp. in a fast implementation that may come
> at a noticeable marginal hw memory cost.
> 
> 
> > The real issue here is to have a flexible
> > LSPs management/control plane (I do not understand
> > where the signalling problem is in all this) that
> > would allow me to do it in a simple, and semantically
> > congruous manner.
> 
> yes. say you could establish several exp -> phb
> mappings in your lsrs and each is given an index
> unique within the domain. you could signal the
> index per lsp. would not that give you the
> flexibility you are looking for? how many such
> mappings would you need?
> 
> 
> > It should not be that hard, at least at the
> > provisioning level, and I guess I saw it already but
> > I do not recall now which vendor was it :-).
> 
> it's certainly doable. but it comes at a cost in
> some designs. in designs in which the memory for
> each lsp is reallocated, providing support for
> random signalled mappings comes at a cost.
> 
> c u
> tom

------_=_NextPart_001_01BFCFE5.4FC862FA
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: MPLS Diffserv Extensions related questions/comments </TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Courier New">i certainly see the utility of =
being able to control</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">the exp -&gt; phb mapping. i =
just don't see (yet) that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">every phb needs a unique =
mapping.</FONT>
</P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Well, let me as an operator to decide =
if I want to or not that unique mapping. When the ITU-T X/Y will define =
IP Diff Class Service Classes (ala ITU-T I.362) with a defined PHB =
&lt;-&gt; service semantics mapping function, then we can reduce our =
universe of configuration choices. But, at that point I will be either =
dead or retired in Sicily enjoying beaches and pure Olive Oil :-). The =
latter choice appeals me better, indeed.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Courier New">yes. say you could establish =
several exp -&gt; phb</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">mappings in your lsrs and each =
is given an index</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">unique within the domain. you =
could signal the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">index per lsp. would not that =
give you the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">flexibility you are looking =
for? how many such</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">mappings would you need?</FONT>
</P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I am not questioning the normalization =
aspect of the mapping, it is that really all depends on what we want to =
achieve and how to implement an LSP-supported differentiated services =
offerings environment.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sergio</FONT>
</P>
<UL>
<P><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sergio =
Catanzariti</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Senior Project =
Manager, Technology Integration</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">France Telecom =
R&amp;D </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">1000 Marina =
Boulevard Suite 300 </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brisbane CA =
94005</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tel. =
650-875-1526</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Fax. =
650-875-1505</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">email:sergio.catanzariti@rd.francetelecom.com =
</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
</P>
<BR>

<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">tom worster =
[SMTP:tom@ennovatenetworks.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, June 06, 2000 5:52 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'CATANZARITI Sergio FTR&amp;D/TI'; =
curtis@avici.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">mpls@UU.NET</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: MPLS Diffserv Extensions related =
questions/comments </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">From: owner-mpls@UU.NET =
[<U></U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New"><A =
HREF=3D"mailto:owner-mpls@UU.NET">mailto:owner-mpls@UU.NET</A>]On</FONT>=
</U><FONT SIZE=3D2 FACE=3D"Courier New"> Behalf Of CATANZARITI</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Sergio FTR&amp;D/TI</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; I agree that it would be =
actually very helpful. I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; would like to build =
topology-driven LSPs and use</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; EXP-PHBs stuff for =
differentiating CoS-like traffic.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">i certainly see the utility of =
being able to control</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">the exp -&gt; phb mapping. i =
just don't see (yet) that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">every phb needs a unique =
mapping.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt; I do not understand the =
&quot;hardware cost friendly&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; problem.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">the cost i'm referring to is =
that a system needs to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">provide memory to store an exp =
-&gt; phb mapping for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">every lsp. in a fast =
implementation that may come</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">at a noticeable marginal hw =
memory cost.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt; The real issue here is to =
have a flexible</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; LSPs management/control =
plane (I do not understand</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; where the signalling =
problem is in all this) that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; would allow me to do it in =
a simple, and semantically</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; congruous manner.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">yes. say you could establish =
several exp -&gt; phb</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">mappings in your lsrs and each =
is given an index</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">unique within the domain. you =
could signal the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">index per lsp. would not that =
give you the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">flexibility you are looking =
for? how many such</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">mappings would you need?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt; It should not be that hard, =
at least at the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; provisioning level, and I =
guess I saw it already but</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; I do not recall now which =
vendor was it :-).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">it's certainly doable. but it =
comes at a cost in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">some designs. in designs in =
which the memory for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">each lsp is reallocated, =
providing support for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">random signalled mappings comes =
at a cost.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">c u</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">tom</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCFE5.4FC862FA--


From owner-mpls@UU.NET  Tue Jun  6 14:40:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16736
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 14:40:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisle02784;
	Tue, 6 Jun 2000 18:39:08 GMT
Received: by mail-control.mail.uu.net 
	id QQisle26295
	for mpls-outgoing; Tue, 6 Jun 2000 18:38:36 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisle26289
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 18:38:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisle16453
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:38:09 -0400 (EDT)
Received: from smtprch2.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15])
	id QQisle04641
	for <mpls@UU.NET>; Tue, 6 Jun 2000 18:38:09 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Tue, 6 Jun 2000 13:31:36 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <LW2C1DQ2>; Tue, 6 Jun 2000 13:34:23 -0500
Message-ID: <6DDA62170439D31185750000F80826AC02BFCCE3@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Vishal.Sharma@tellabs.com, Ben.Mack-Crane@tellabs.com
Cc: mpls@UU.NET, Srinivas.Makam@tellabs.com, Changcheng.Huang@tellabs.com,
        Ken.Owens@tellabs.com
Subject: RE: draft-chang-mpls-path-protection Comments
Date: Tue, 6 Jun 2000 13:34:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFCFE5.D5B38C3C"
X-Orig: <dallan@americasm01.nt.com>
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_01BFCFE5.D5B38C3C
Content-Type: text/plain

I think I need to back this distinction up into the framework draft rather
than introducing it into the path-protection document. I'd rather get
agreement there first.

Dave

> -----Original Message-----
> From:	Vishal Sharma [SMTP:Vishal.Sharma@tellabs.com]
	<snip>
> I agree. In fact,  spirit of our description also was the same, but we
> didn't get
> the terminology pinned precisely.  I think adding this distinction will
> address your 
> concern, and make it easier to refer to things unambiguously. In fact, I'd
> invite you to send
> us some suggested text to add to our draft to take care of this, which
> we'll be happy
> to include that our the revision.
> 
> -Vishal
> 
> 

------_=_NextPart_001_01BFCFE5.D5B38C3C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: draft-chang-mpls-path-protection Comments</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I think I need to =
back this distinction up into the framework draft rather than =
introducing it into the path-protection document. I'd rather get =
agreement there first.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Vishal Sharma =
[SMTP:Vishal.Sharma@tellabs.com]</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I agree. In fact,&nbsp; spirit of our =
description also was the same, but we didn't get</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the terminology pinned =
precisely.&nbsp; I think adding this distinction will address your =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">concern, and make it easier to refer =
to things unambiguously. In fact, I'd invite you to send</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">us some suggested text to add to our =
draft to take care of this, which we'll be happy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to include that our the =
revision.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-Vishal</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFCFE5.D5B38C3C--


From owner-mpls@UU.NET  Tue Jun  6 14:50:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17011
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 14:50:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQislf10300;
	Tue, 6 Jun 2000 18:49:45 GMT
Received: by mail-control.mail.uu.net 
	id QQislf26995
	for mpls-outgoing; Tue, 6 Jun 2000 18:48:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQislf26990
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 18:48:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQislf18092
	for <mpls@uu.net>; Tue, 6 Jun 2000 14:46:44 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQislf08133
	for <mpls@uu.net>; Tue, 6 Jun 2000 18:46:43 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA06085
	for mpls@uu.net; Tue, 6 Jun 2000 14:46:42 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQislf26830
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 18:45:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisle29204
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:40:12 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQisle06280
	for <mpls@UU.NET>; Tue, 6 Jun 2000 18:40:12 GMT
Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id NAA22676; Tue, 6 Jun 2000 13:32:05 -0500 (CDT)
Received: from tddny.fujitsu.com (pc185.tddny.fujitsu.com [167.254.242.185]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id M1SH4KJN; Tue, 6 Jun 2000 13:32:05 -0500
Message-ID: <393D439B.4E9876C0@tddny.fujitsu.com>
Date: Tue, 06 Jun 2000 14:31:55 -0400
From: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
CC: Thomas.Theimer@icn.siemens.de, Shahram_Davari@pmc-sierra.com,
        pjw@ip-engineering.bt.com, mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <3B59676F9ADBD211B5360060086E64EECC011A@MCHH237E> <393BEE17.7EE547D9@tddny.fujitsu.com> <393D0E6F.4F91E367@tellabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ben:
Please see my comments below.
indra


Ben Mack-Crane wrote:

> Hello,
>
> I have been thinking about OAM packet identification and I
> think this evolving proposal looks promising.
>
> There are several possible processing modes for OAM packets,
> and I am interested in your thoughts on (a) which are needed,
> and (b) which can be supported by the current proposal.
>
> For the sake of discussion I have given them numbers (with no
> particular significance) and included my initial thoughts.
>
> Mode 1:
> Packet transparently forwarded along user packet data path
>
> This mode is needed for end-to-end OAM funcitons that depend
> on following the user packet data path exactly (e.g., delay
> measurement, as Indra mentioned, and path continuity tests).

OAM packet is inserted at an ingress LSR and is identified by an
OAM label located at the bottom of the stack. When all user labels
have been popped at an egress LSR, the OAM label directs the
packet to an OAM engine for processing.

>
>
> Mode 2:
> Packet transparently forwarded along user data path and also
> passed to OAM processing (monitoring)
>
> This mode can be easily combined with Mode 1, and is useful
> for isolating faults and monitoring subnetwork connections.

Do you assume that monitoring can be done at any intermediate LSR?
If the answer is yes, then since only OAM packets (and not user packets)
are to be selectively monitored, there is a need to identify an OAM packet
based on user label at the top. Therefore there is a need for another
OAM bit in the label stack entry.

>
>
> Mode 3:
> Packet forwarded to OAM processing, then forwarded along next
> hop of user packet data path (possibly not following user packet
> data path at all points within the LSR)
>
> This mode may be useful for OAM packets that do not need to
> follow the user data path exactly within the LSR, need more
> flexible processing (i.e. are more suited to SW than HW
> processing), and are not too frequent.
>
> Mode 4:
> Packet forwarded to OAM processing and terminated
>
> This is the common mode for termination points (LSP endpoints)
> and segment endpoints (if segment OAM is supported).  The
> difficulty in the segment case is distinguishing which OAM
> packets to terminate and which to pass if Mode 1 or 2 OAM packets
> are also in use.  (Obviously Modes 3 and 4 can easily be combined.)

Are OAM packets forwarded hop-by-hop or transparently along the data path?
If forwarding is hop-by-hop, then Mode 3 already takes care of this.
If forwarded along the user data path, then Mode 2 may be able
to take of this case.

>
>
> Mode 5:
> Packet forwarded to previous hop on user packet data path
> (forwarding OAM packets following LSP upstream)
>
> Same as Mode 1, but upstream so there is no "user packet data path"
> per se.  This might be useful for end-to-end OAM funcitons that
> require two way communication (are there any?) or funcitons
> that require rapid communicaiton upstream (e.g., fault indication for
> rapid protection switching).

Do you mean: packet forwarded to *the ingress* on user
packet data path rather than to previous hop?
One end-to-end application is for Mode 1 to do forward performance
monitoring, and this mode to do backward performance reporting.
However, I think we can use the same Mode 1 (or Mode 3) in the
backward direction in terms of forwarding OAM packets
(after processing at the egress).

>
>
> Mode 6:
> Packet forwarded to previous hop on user packet data path and also
> passed to OAM processing (monitoring upstream OAM)
>
> Same as mode 2, but upstream (do we detect a pattern here?).
> As before, easily combined with Mode 5.  Might be good for subnetwork
> connection protection switching, as long as the fault indication
> does not cause any trouble passing further upstream.
>
> Mode 7:
> Packet forwarded to OAM processing, then forwarded to previous hop
> on user packet data path
>
> Same as Mode 3, but upstream.  Another option for upstream OAM
> communication, possibly slower than Mode 5 or 6.
>
> Mode 8:
> Packet forwarded to AOM processing and terminated (upstream direction)
>
> Same as Mode 4, but upstream.
>
> Regarding OAM packet identification, it seems reasonable to use the
> user packet label on top for Modes 1 and 2 so the packet will follow
> the user data path downstream.  Mode 2 could rely on looking for a
> reserved OAM label next on the stack.  Modes 3 and 4 are easily
> supported with a reserved OAM label on top, or at the LSP endpoint
> where the user packet label is popped anyway (though it might need
> to be preserved as Peter mentioned).  However, supporting Modes 3
> or 4 at points within the path when the user label is on top is a
> problem (how to decide to forward only to OAM processing and not along
> user packet path -- Indra: Is this the point you were making?)

I was more thinking that in Mode 4, you want to forward OAM packets
along the user data path (if forwarding is hop-by-hop, then Mode 3
already takes care of this case). So the OAM label cannot be on top.
However, Mode 4 is different from Mode 1 in that OAM termination
at any node (including intermediate nodes) is allowed.
It seems that the OAM label can be located at any level between the
bottom (inclusieve) and top (exclusive) of the stack as long as the
OAM path is restricted within the same level of hierarchy.

>
>
> In the upstream modes, the user label is not defined for forwarding
> so perhaps this can always be done with an OAM reserved label on top.
>
> So...  What do you think about this?  Can we identify a subset of
> modes that are necessary and sufficient, or is it simpler to define
> an OAM packet identification scheme that supports all of them and
> let folks decide later which mode to use in a particular OAM
> application?

Sounds right.

>
>
> Regards,
> Ben Mack-Crane
>
> Indra.Widjaja@tddny.fujitsu.com wrote:
> >
> > Thomas:
> > I think both end-to-end and hop-by-hop OAM packets as you mentioned
> > below should be supported.
> > A third possible way is segment OAM packets where you still want the
> > OAM packets to be treated the same way as data packets in the
> > segment connection. I believe this can be realized by using the first
> > approach plus a dedicated OAM bit. Is there a requirement for this?
> > indra
> >
> > Theimer Thomas wrote:
> >
> > > Actually, there are at least two ways to use such a reserved OAM label:
> > >
> > > - end-end OAM packets would have a label stack where the reserved
> > >   label is inserted below the original top label. After the top label is
> > >   popped at the egress node, the reserved label is processed by
> > >   forwarding the packet to OAM handling. Thus, all packets are
> > >   forwarded using the original top label. OAM packets are visible
> > >   only to ingress and egress nodes, and use exactly the same
> > >   path as user packets.
> > >
> > > - hop-by-hop OAM packets would have the reserved label pushed
> > >   on top of the original top label. Each LSR along the LSP would
> > >   then recognise the reserved top label, forward the packet to
> > >   OAM handling, and then forward the packet using the label
> > >   second on the label stack (the original top label).
> > >
> > > It may simplify things if two different reserved labels are defined
> > > for end-end and hop-by-hop OAM packets, if people feel that
> > > both are needed. The hop-hop case is really very similar to
> > > the router alert label.
> > >
> > > A dedicated OAM header bit would serve a similar purpose, but is
> > > not strictly required.
> > >
> > > Regards,
> > >
> > > Thomas Theimer
> > > > -----Original Message-----
> > > > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> > > > Sent: Monday, June 05, 2000 5:50 PM
> > > > To:   'Peter Willis'; mpls@UU.NET
> > > > Subject:      RE: OAM labels (was: can egress know the ingress of a
> > > > packet?)
> > > >
> > > > Peter,
> > > >
> > > > But we can use two labels. The top label can be the reserved one, and the
> > > > second label can be the actual label, which is used for forwarding the OAM
> > > > packet. This is basically similar to the Router Alert Label = 1.
> > > >
> > > > Regards,
> > > > -Shahram
> > > >
> > > > >-----Original Message-----
> > > > >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> > > > >Sent: Monday, June 05, 2000 11:37 AM
> > > > >To: mpls@UU.NET
> > > > >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> > > > >
> > > > >
> > > > >
> > > > >An LSR will be terminating many LSPs so will be terminating
> > > > >many OAM flows.
> > > > >How do you correctly diagnose LSPs with merged or corrupted
> > > > >labels if they all
> > > > >arrive on the same reserved label? The label the OAM flow
> > > > >arrives on has to
> > > > >match exactly the label used for the data (user plane) flow in
> > > > >order to be able
> > > > >to detect faults caused by LSRs using broken label swapping tables.
> > > > >
> > > > >So we need a bit somewhere in the MPLS header to identify an
> > > > >OAM payload but
> > > > >we need to keep the same label as used for the user plane data.
> > > > >
> > > > >Peter.
> > > > >
> > > > >




From owner-mpls@UU.NET  Tue Jun  6 14:53:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17047
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 14:53:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQislf14189;
	Tue, 6 Jun 2000 18:51:11 GMT
Received: by mail-control.mail.uu.net 
	id QQislf27064
	for mpls-outgoing; Tue, 6 Jun 2000 18:50:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQislf27053
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 18:50:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQislf00715
	for <mpls@uu.net>; Tue, 6 Jun 2000 14:48:45 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQislf12099
	for <mpls@uu.net>; Tue, 6 Jun 2000 18:48:44 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA06416
	for mpls@uu.net; Tue, 6 Jun 2000 14:48:43 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQislf26981
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 18:48:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQislf18308
	for <mpls@UU.NET>; Tue, 6 Jun 2000 14:47:35 -0400 (EDT)
Received: from redd235.procket.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: flowpoint.procket.com [205.253.146.41])
	id QQislf08646
	for <mpls@UU.NET>; Tue, 6 Jun 2000 18:47:34 GMT
Received: (from tli@localhost)
	by redd235.procket.com (8.9.3/8.9.3) id LAA04252;
	Tue, 6 Jun 2000 11:47:28 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redd235.procket.com: tli set sender to tli@redd235.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14653.18240.259442.584925@redd235.procket.com>
Date: Tue, 6 Jun 2000 11:47:28 -0700 (PDT)
To: Eric Gray <EGray@zaffire.com>
Cc: "'Chris LaVallee'" <clavallee@zumanetworks.com>, mpls@UU.NET,
        jleu@mindspring.com
Subject: RE: Ingress LER in LDP
In-Reply-To: <127202508@toto.iv>
X-Mailer: VM 6.75 under Emacs 20.4.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


 | 	The "standard" approach - as far as I know -
 | is to use PPP for POS.  The ethertypes defined in
 | [ENCAPS] are for transmission of MPLS labeled data
 | over "LAN media".  It is arguable that some type of
 | HDLC framing of IP packets makes SONET a "LAN media"
 | but that may be a stretch - particularly if a pro-
 | prietary approach is used.  PPP protocol numbers 
 | 0x0281 (unicast) and 0x0283 (multicast) are defined 
 | for PPP encapsulation of MPLS labeled packets.
 | 
 | 	I am not familiar with whether or not the 
 | Cisco proprietary approach you describe (I will
 | take your word for it that it exists) is available
 | without licensing fees.  If it exists, is deployed
 | as the only Cisco supported POS approach and is not
 | available for licensing, then I think we can look 
 | forward to government regulation of the new Internet 
 | monopoly in the very near future. :-)


The Cisco serial link protocol (commonly known as Cisco HDLC) is not widely
known outside of the operational community but has been publically
published by Cisco and is implemented in certain BSD Unix variants as well
as certain other router implementations.

It does use Ethertypes for demuxing protocols, however, this should not be
misconstrued into thinking that the serial link is modeled as a LAN.

I believe that Cisco also supports PPP on POS.

Regards,
Tony



From owner-mpls@UU.NET  Tue Jun  6 16:27:24 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18688
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 16:27:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisll01492;
	Tue, 6 Jun 2000 20:26:46 GMT
Received: by mail-control.mail.uu.net 
	id QQisll22159
	for mpls-outgoing; Tue, 6 Jun 2000 20:26:16 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisll22129
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 20:25:58 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisll13975
	for <mpls@uu.net>; Tue, 6 Jun 2000 16:23:18 -0400 (EDT)
Received: from web5105.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5105.mail.yahoo.com [216.115.106.75])
	id QQisll23404
	for <mpls@uu.net>; Tue, 6 Jun 2000 20:23:17 GMT
Message-ID: <20000606202316.22740.qmail@web5105.mail.yahoo.com>
Received: from [169.144.16.187] by web5105.mail.yahoo.com; Tue, 06 Jun 2000 13:23:15 PDT
Date: Tue, 6 Jun 2000 13:23:15 -0700 (PDT)
From: chutur <chutur_b@yahoo.com>
Subject: Why so many label distribution protocols ?
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I am new to MPLS. And was wondering why there should 
be so many protocols for label distribution. You
have lDP, CR-LDP, RSVP-TE, BGP-TE and OSPF-TE etc.

Also which of these protocols is more likely to be
used in future ?

Any help will be greatly appreciated.

chatur braskowy

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Tue Jun  6 16:44:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18920
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 16:44:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQislm14511;
	Tue, 6 Jun 2000 20:44:01 GMT
Received: by mail-control.mail.uu.net 
	id QQislm23427
	for mpls-outgoing; Tue, 6 Jun 2000 20:43:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQislm23419
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 20:43:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQislm24761
	for <mpls@uu.net>; Tue, 6 Jun 2000 16:43:02 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQislm08739
	for <mpls@uu.net>; Tue, 6 Jun 2000 20:43:01 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA26071
	for mpls@uu.net; Tue, 6 Jun 2000 16:43:00 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQislm23362
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 20:42:26 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQislm24603
	for <mpls@UU.NET>; Tue, 6 Jun 2000 16:42:17 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQislm13229
	for <mpls@UU.NET>; Tue, 6 Jun 2000 20:42:17 GMT
Received: from 7UWVR.juniper.net (pptp-adm-14.juniper.net [172.17.17.14])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA05155;
	Tue, 6 Jun 2000 13:38:05 -0700 (PDT)
Message-Id: <4.3.2.20000606162554.00abe2a0@mail-eng.juniper.net>
X-Sender: rcallon@mail-eng.juniper.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Tue, 06 Jun 2000 16:36:50 -0400
To: Theimer Thomas <Thomas.Theimer@icn.siemens.de>,
        "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Peter Willis'" <pjw@ip-engineering.bt.com>
From: Ross Callon <rcallon@juniper.net>
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Cc: mpls@UU.NET
In-Reply-To: <3B59676F9ADBD211B5360060086E64EECC011A@MCHH237E>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 06:46 PM 6/5/00 +0200, Theimer Thomas wrote:
>Actually, there are at least two ways to use such a reserved OAM label:
>
>- end-end OAM packets would have a label stack where the reserved
>   label is inserted below the original top label. After the top label is
>   popped at the egress node, the reserved label is processed by
>   forwarding the packet to OAM handling. Thus, all packets are
>   forwarded using the original top label. OAM packets are visible
>   only to ingress and egress nodes, and use exactly the same
>   path as user packets.
>
>- hop-by-hop OAM packets would have the reserved label pushed
>   on top of the original top label. Each LSR along the LSP would
>   then recognise the reserved top label, forward the packet to
>   OAM handling, and then forward the packet using the label
>   second on the label stack (the original top label).
>
>It may simplify things if two different reserved labels are defined
>for end-end and hop-by-hop OAM packets, if people feel that
>both are needed. The hop-hop case is really very similar to
>the router alert label.

If the outer header carries the OAM label (and the inner label
carries the real label) then I don't see any problems. The MPLS
forwarding tables can be set up to send the special label to the
"process more carefully" stack.

If the outer label identifies the LSP, and the inner label is a
special OAM value, then I think that there is a problem with
penultimate hop label popping.

Personally I think that penultimate label popping is important
enough that it needs to be preserved.

Ross




From owner-mpls@UU.NET  Tue Jun  6 18:32:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20263
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 18:32:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQislu28461;
	Tue, 6 Jun 2000 22:31:31 GMT
Received: by mail-control.mail.uu.net 
	id QQislu17615
	for mpls-outgoing; Tue, 6 Jun 2000 22:30:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQislu17610
	for <mpls@mail-control.mail.uu.net>; Tue, 6 Jun 2000 22:30:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQislu08655
	for <mpls@UU.NET>; Tue, 6 Jun 2000 18:30:21 -0400 (EDT)
Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63])
	id QQislu21486
	for <mpls@UU.NET>; Tue, 6 Jun 2000 22:30:20 GMT
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
	id <KG0FPSJ3>; Tue, 6 Jun 2000 15:27:54 -0700
Message-ID: <337055FBC675D311A85D00508B5A9C4F2542E3@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
	 <sergio.catanzariti@rd.francetelecom.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'tom worster'"
	 <tom@ennovatenetworks.com>
Cc: CATANZARITI Sergio FTR&D/TI <sergio.catanzariti@rd.francetelecom.com>,
        mpls@UU.NET, curtis@avici.com
Subject: RE: MPLS Diffserv Extensions related questions/comments 
Date: Tue, 6 Jun 2000 15:27:47 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD006.7426691E"
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_01BFD006.7426691E
Content-Type: text/plain;
	charset="iso-8859-1"


>>but there are other advantages. the diff-ext draft could
>>be radically simplified since the distinction of e-lsp
>>and l-lsp disappears -- they are just different classes
>>of mappings. conceivable, the mappings could go into
>>experimental rfcs and a range of indexes could be reserved
>>for standardisation. such a separation of mpls signalling
>>and (perhaps more controversial) ds-related semantics could 
>>be expeditious.


>Diff-ext-04 has been in circulation for quite a while. And we are releasing
>diff-ext-05 by Thursday. Therefore I not only I don't think such a
>seperation could be expeditious, but also that would delay the whole
process
>by months if not a year.

Yes, I do not think that E-LSP and L-LSP distinction is an issue of data
structures representation, but it is an enabler of diff serv configuration
flexibility power per LSP that looks valuable to me. So, I ignore the strong
reason why we should eliminate it.

Sergio
> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com 
> --------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From:	Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> Sent:	Tuesday, June 06, 2000 8:54 AM
> To:	'tom worster'; curtis@avici.com
> Cc:	'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET
> Subject:	RE: MPLS Diffserv Extensions related questions/comments 
> 
> Hi,
> 
> >-----Original Message-----
> >From: tom worster [mailto:tom@ennovatenetworks.com]
> >Sent: Tuesday, June 06, 2000 11:05 AM
> >To: curtis@avici.com
> >Cc: 'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET
> >Subject: RE: MPLS Diffserv Extensions related questions/comments 
> >
> >
> >From: Curtis Villamizar [mailto:curtis@avici.com]
> >> 
> >> In message 
> >> <000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com>, "tom wors
> >> ter" writes:
> >> > 
> >> > > I do not understand the "hardware cost friendly"
> >> > > problem.
> >> > 
> >> > the cost i'm referring to is that a system needs to
> >> > provide memory to store an exp -> phb mapping for
> >> > every lsp. in a fast implementation that may come
> >> > at a noticeable marginal hw memory cost.
> >> 
> >> If the network provider is reasonably sane, then you will probalby
> >> need to map a medium to large number of LSPs into a small number of
> >> EXP to PHB mappings.
> >
> >that's what i imagined too. which is why i question the
> >design of a protocol that provides unnecessary resolution
> >with a non-trivial cost attached to that resolution.
> >
> 
> In the diff-ext draft, the EXP->PHB signaling is optional. If an operator
> does not want to use more than 8 PHBs in his network, and wants to use
> E-LSP, then the pre-configured EXP->PHB mapping can be used.
> 
> >
> >> OTOH .. at least a few people built full mesh IGPs on ATM overlays so
> >> assumptions of ISP sanity don't hold up universally.  :-(
> >
> >if the requirement for a different exp -> phb mapping for 
> >each of a medium to large number of lsps is considered
> >unreasonable then that should be taken into consideration
> >in the diff-ext protocol design.
> >
> >i thought about a separation of ds semantics from mpls
> >signalling using an "exp -> phb mapping index" which would
> >be signalled in the new tlv instead of the mapping itself.
> >a set of mappings would be configured and referred to in 
> >the by the index in the signalling messages.
> >
> >the technical benefits i see are reduced signalling 
> >bandwidth and processing and a reduced per lsp memory
> >budget.
> 
> Signaling will be reduced a bit (but signaling BW is not an issue in
> MPLS),
> but it creates another problem, which is that you need to configure your
> EXP->PHB mappings (which are now more than 8) in each router. Remember,
> the
> purpose of signaling was to eliminate the EXP->PHB configuration.
> 
> Regarding the reduction of per-LSP memory; well it all depends on what you
> are comparing it to. One solution which will reduce the per-LSP memory and
> still uses the signaled EXP->PHB mapping is to build a few general purpose
> EXP->PHB mapping tables (in each LSR), from the first few LSP setup
> messages, and use them as an index in per-LSP ILM/NHLFE tables.  Using
> this
> method, the amount of per-LSP memory is less than  or equal to your
> proposal.
> 
> 
> >
> >but there are other advantages. the diff-ext draft could
> >be radically simplified since the distinction of e-lsp
> >and l-lsp disappears -- they are just different classes
> >of mappings. conceivable, the mappings could go into
> >experimental rfcs and a range of indexes could be reserved
> >for standardisation. such a separation of mpls signalling
> >and (perhaps more controversial) ds-related semantics could 
> >be expeditious.
> >
> 
> Diff-ext-04 has been in circulation for quite a while. And we are
> releasing
> diff-ext-05 by Thursday. Therefore I not only I don't think such a
> seperation could be expeditious, but also that would delay the whole
> process
> by months if not a year.
> 
> 
> Regards,
> Shahram
> 
> 
> >c u
> >tom
> >

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: MPLS Diffserv Extensions related questions/comments </TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;but there are other =
advantages. the diff-ext draft could</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;be radically simplified =
since the distinction of e-lsp</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;and l-lsp disappears -- =
they are just different classes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;of mappings. =
conceivable, the mappings could go into</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;experimental rfcs and a =
range of indexes could be reserved</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;for standardisation. =
such a separation of mpls signalling</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;and (perhaps more =
controversial) ds-related semantics could </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt;be expeditious.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Diff-ext-04 has been in =
circulation for quite a while. And we are releasing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;diff-ext-05 by Thursday. =
Therefore I not only I don't think such a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;seperation could be =
expeditious, but also that would delay the whole process</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;by months if not a =
year.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Yes, I do not think that E-LSP and =
L-LSP distinction is an issue of data structures representation, but it =
is an enabler of diff serv configuration flexibility power per LSP that =
looks valuable to me. So, I ignore the strong reason why we should =
eliminate it.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sergio</FONT>
<UL>
<P><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sergio =
Catanzariti</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Senior Project =
Manager, Technology Integration</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">France Telecom =
R&amp;D </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">1000 Marina =
Boulevard Suite 300 </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brisbane CA =
94005</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tel. =
650-875-1526</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Fax. =
650-875-1505</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">email:sergio.catanzariti@rd.francetelecom.com =
</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
</P>
<BR>

<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Shahram Davari =
[SMTP:Shahram_Davari@pmc-sierra.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, June 06, 2000 8:54 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'tom worster'; curtis@avici.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'CATANZARITI Sergio FTR&amp;D/TI'; mpls@UU.NET</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: MPLS Diffserv Extensions related =
questions/comments </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;-----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;From: tom worster =
[<U></U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New"><A =
HREF=3D"mailto:tom@ennovatenetworks.com">mailto:tom@ennovatenetworks.com=
</A></FONT></U><FONT SIZE=3D2 FACE=3D"Courier New">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Sent: Tuesday, June 06, =
2000 11:05 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;To: curtis@avici.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Cc: 'CATANZARITI Sergio =
FTR&amp;D/TI'; mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Subject: RE: MPLS Diffserv =
Extensions related questions/comments </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;From: Curtis Villamizar =
[</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:curtis@avici.com">mailto:curtis@avici.com</A></FONT></U><=
FONT SIZE=3D2 FACE=3D"Courier New">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; In message </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; =
&lt;000801bfcfb5$fd44adb0$6640a8c0@tst.ennovatenetworks.com&gt;, =
&quot;tom wors</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; ter&quot; =
writes:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; &gt; I do not =
understand the &quot;hardware cost friendly&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; &gt; =
problem.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; the cost i'm =
referring to is that a system needs to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; provide memory to =
store an exp -&gt; phb mapping for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; every lsp. in a =
fast implementation that may come</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; &gt; at a noticeable =
marginal hw memory cost.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; If the network =
provider is reasonably sane, then you will probalby</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; need to map a medium =
to large number of LSPs into a small number of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; EXP to PHB =
mappings.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;that's what i imagined too. =
which is why i question the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;design of a protocol that =
provides unnecessary resolution</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;with a non-trivial cost =
attached to that resolution.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">In the diff-ext draft, the =
EXP-&gt;PHB signaling is optional. If an operator</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">does not want to use more than =
8 PHBs in his network, and wants to use</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">E-LSP, then the pre-configured =
EXP-&gt;PHB mapping can be used.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; OTOH .. at least a few =
people built full mesh IGPs on ATM overlays so</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&gt; assumptions of ISP =
sanity don't hold up universally.&nbsp; :-(</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;if the requirement for a =
different exp -&gt; phb mapping for </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;each of a medium to large =
number of lsps is considered</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;unreasonable then that =
should be taken into consideration</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;in the diff-ext protocol =
design.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;i thought about a =
separation of ds semantics from mpls</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;signalling using an =
&quot;exp -&gt; phb mapping index&quot; which would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;be signalled in the new tlv =
instead of the mapping itself.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;a set of mappings would be =
configured and referred to in </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;the by the index in the =
signalling messages.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;the technical benefits i =
see are reduced signalling </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;bandwidth and processing =
and a reduced per lsp memory</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;budget.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Signaling will be reduced a bit =
(but signaling BW is not an issue in MPLS),</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">but it creates another problem, =
which is that you need to configure your</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">EXP-&gt;PHB mappings (which are =
now more than 8) in each router. Remember, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">purpose of signaling was to =
eliminate the EXP-&gt;PHB configuration.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regarding the reduction of =
per-LSP memory; well it all depends on what you</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">are comparing it to. One =
solution which will reduce the per-LSP memory and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">still uses the signaled =
EXP-&gt;PHB mapping is to build a few general purpose</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">EXP-&gt;PHB mapping tables (in =
each LSR), from the first few LSP setup</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">messages, and use them as an =
index in per-LSP ILM/NHLFE tables.&nbsp; Using this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">method, the amount of per-LSP =
memory is less than&nbsp; or equal to your</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">proposal.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;but there are other =
advantages. the diff-ext draft could</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;be radically simplified =
since the distinction of e-lsp</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;and l-lsp disappears -- =
they are just different classes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;of mappings. conceivable, =
the mappings could go into</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;experimental rfcs and a =
range of indexes could be reserved</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;for standardisation. such a =
separation of mpls signalling</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;and (perhaps more =
controversial) ds-related semantics could </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;be expeditious.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Diff-ext-04 has been in =
circulation for quite a while. And we are releasing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">diff-ext-05 by Thursday. =
Therefore I not only I don't think such a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">seperation could be =
expeditious, but also that would delay the whole process</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">by months if not a year.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Shahram</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt;c u</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;tom</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFD006.7426691E--


From owner-mpls@UU.NET  Tue Jun  6 20:10:16 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20990
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 20:10:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisma22368;
	Wed, 7 Jun 2000 00:09:27 GMT
Received: by mail-control.mail.uu.net 
	id QQisma11702
	for mpls-outgoing; Wed, 7 Jun 2000 00:08:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisma11697
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 00:08:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisma23090
	for <mpls@UU.NET>; Tue, 6 Jun 2000 20:07:39 -0400 (EDT)
Received: from mail.krioukov.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cj114416-a.reston1.va.home.com [24.15.191.36])
	id QQisma25694
	for <mpls@UU.NET>; Wed, 7 Jun 2000 00:07:38 GMT
Received: from VA1ENG128 (dhcp-host-017.cj114416-a.reston1.va.home.com [192.168.1.17])
	by mail.krioukov.net (8.9.3/8.9.3) with SMTP id TAA03506;
	Tue, 6 Jun 2000 19:49:47 -0400
From: "Dmitri Krioukov" <dima@krioukov.net>
To: <curtis@avici.com>
Cc: "Juha Heinanen" <jh@lohi.eng.telia.fi>,
        "Loa Andersson" <loa.andersson@nortelnetworks.com>,
        "Grenville Armitage" <gja@dnrc.bell-labs.com>, <mpls@UU.NET>,
        <smd@ebone.net>, <akyol@pluris.com>, <bkumar@ennovatenetworks.com>
Subject: RE: MPLS Performance analysis..... 
Date: Tue, 6 Jun 2000 20:21:46 -0400
Message-ID: <NCBBIKACLKNMKDHKKKNFEECAELAA.dima@krioukov.net>
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)
Importance: Normal
In-Reply-To: <200006060223.WAA13395@curtis-lt.avici.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

thanks for the review. it does make sense.

in fact, you've noticed the same problem
brijesh mentioned a little bit later -- the
absence of the time parameter (a link failure
is partial case of the demand matrix evolution
in time). (another issue is if you really have
or can have even a static demand matrix for your
network.)

obviously, the fundamental cause of not having
time dependency is that the graph theory doesn't
have it either, and as soon as you have a link
cost change, you essentially have another graph
that you have to recalculate. unfortunately, this
starting point could never sound right to me...

has any dynamic routing protocol research been
done outside of the distance vector and link
state approaches?

thanks,
--
dima.

PS the reference under discussion was mentioned 
   by bora akyol

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Curtis
> Villamizar
> Sent: Monday, June 05, 2000 10:24 PM
> To: Dmitri Krioukov
> Cc: Juha Heinanen; Loa Andersson; Grenville Armitage; mpls@UU.NET;
> smd@ebone.net; akyol@pluris.com
> Subject: Re: MPLS Performance analysis..... 
> 
> 
> 
> In message <NCBBIKACLKNMKDHKKKNFKEBAELAA.dima@krioukov.net>, 
> "Dmitri Krioukov" 
> writes:
> > i'd like to hear any points of view of the members
> > of this list on motivation #1 (te) accompanied
> > with some far going criticism to this reference:
> > http://smg.ulb.ac.be/Preprints/Fortz99_29.html
> > (it was brought up to discussion on nanog
> > mailing list recently).
> > 
> > i understand that the major assumption in this paper
> > (about the demand matrix availability) is too
> > brave, but this paper is a major indication
> > that the te-related research beyond the ever
> > lasting vc reinvention approach has not been
> > exhausted yet. clearly, you wouldn't need any
> > external signaling mechanism if all benefits
> > te brings you (congestion avoidance, qos, etc)
> > may be achieved by means of some (rather
> > futuristic at this point) routing protocol.
> > 
> > at the very general level, the packet switched
> > networks proved to provide much higher level of
> > adaptation to the new requirements. since the
> > packet switched networks are theoretically
> > more complex than circuit switched ones, the way
> > to adapt to a new requirement (te) may not be obvious
> > until some significant research effort is done. this
> > does not mean that we have to avoid this effort since
> > the easy way may not lead anywhere...
> > 
> > the interesting point would be that ip was created
> > as a result of significant, well-funded academic
> > research effort. i'm not sure if the same was true
> > with respect to the osi stack.
> > --
> > dima.
> 
> 
> Dima,
> 
> Since you've asked for a quick review ...
> 
> I've seen a paper related to this work by other AT&T authors
> (unpublished) that produced a formal proof that for topologies with
> given constraints OSPF costs could be set sufficiently well that there
> was no benefit to MPLS-TE.  Unfortunately the constraints are violated
> by too many topologies and building to them is impractical so that
> other paper may remain unpublished.
> 
> Even where OSPF and MPLS perform nearly as well when everything is up,
> when a link fails and the OSPF costs can be very suboptimal.  The
> MPLS-TE might converge to a near optimal solution faster than the OSPF
> weights could all be changed by an external system.  There was also
> the very real possibility of multiple link failures which is always
> troublesome for techniques which rely on precomputed costs for any
> given single failure.
> 
> The AT&T approach outlined here may be very well suited for AT&T's
> immediate needs.  OSPF is a very stable protocol whose behaviour is
> well understood and implementations tend to be very reliable.  MPLS
> may gain an efficiency advantage as a network topology become a more
> of a dense mesh and this advantage becomes more important as a network
> becomes very heavily utilized.  OTOH, a TE implementation may converge
> to a result which is also quite poor and may be fairly unpredictable
> (ie: layout efficiency depending on order in which LSPs are restored).
> 
> Given a relatively simple and well provisioned network topology and a
> desire to stick with conservative design to acheive high reliability
> this approach is a good choice.  As MPLS implementations mature, the
> risk of deploying MPLS is lowered.  As risk lowers and if topology
> becomes more complex and high utilizations raise efficiency concerns,
> it may become advantageous to use MPLS TE.
> 
> There are some very smart people at AT&T.  This is both a good
> acedemic paper and the practicality of the approach for many
> circumstances makes it also a practical and relevant paper.
> 
> btw- Thanks for the pointer.  I wasn't aware that this was submitted
> for publication.
> 
> Curtis
> 
> > the interesting point would be that ip was created
> > as a result of significant, well-funded academic
> > research effort. i'm not sure if the same was true
> > with respect to the osi stack.
> 
> ps- Quite a bit of money was poured into OSI, much of it by commercial
> interests including the US telcos and European PTTs.  IP and the
> NSFNET was not all that well funded if you consider that most of the
> funding went into operating a network.  NSF put $15M/year into the
> T3NSFNET backbone at peak if my memory serves well.  I think that
> exceeded even the IETF chocolate chip cookie expenses by a significant
> margin.  It wasn't until a few years into commercialization that IP
> networks began playing with real money by government standards.  Its
> interesting to note that the whole NSFNET program was more than paid
> for in taxes resulting from the commercialization of the Internet.  :-)


From owner-mpls@UU.NET  Tue Jun  6 21:31:11 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21547
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 21:31:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQismf10456;
	Wed, 7 Jun 2000 01:28:49 GMT
Received: by mail-control.mail.uu.net 
	id QQismf25114
	for mpls-outgoing; Wed, 7 Jun 2000 01:28:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQismf25109
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 01:28:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQismf02620
	for <mpls@UU.NET>; Tue, 6 Jun 2000 21:28:11 -0400 (EDT)
Received: from ginger.lcs.mit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82])
	id QQismf09883
	for <mpls@UU.NET>; Wed, 7 Jun 2000 01:28:10 GMT
Received: (from jnc@localhost)
	by ginger.lcs.mit.edu (8.9.1/8.9.1) id VAA16250;
	Tue, 6 Jun 2000 21:28:08 -0400
Date: Tue, 6 Jun 2000 21:28:08 -0400
From: "J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>
Message-Id: <200006070128.VAA16250@ginger.lcs.mit.edu>
To: dima@krioukov.net, mpls@UU.NET
Subject: RE: MPLS Performance analysis.....
Cc: jnc@ginger.lcs.mit.edu
Sender: owner-mpls@UU.NET
Precedence: bulk

    > From: "Dmitri Krioukov" <dima@krioukov.net>

    > has any dynamic routing protocol research been done outside of the
    > distance vector and link state approaches?

That depends on what you mean by "distance vector" and "link state".

I suspect by the former you really meant "destination vector" (i.e. you get a
basically complete routing table [i.e. vector] from your neighbours), not
"distance vector" (which should properly be applied only to destination
vector routing protocols which provide only a metric, e.g. RIP). I know, the
terminology is confusing.... Note that BGP is a "destination vector" routing
protocol, but not a "distance vector" routing protocol; it's classified as a
"path vector" protocol since it provides a complete path for each listed
destination.

Same thing for "link state". That term should properly only be applied to
protocols which distribute a map to all players, then all the entities
participating, in parallel, compute complete routing tables from the map.
The path selection is hop-by-hop (i.e. each entity independently picks the
next hop for each given destination). (Note that everyone has to have
basically the same map [moulo area issues], and use the same path selection
algorithm, or the packets go in little circles.... :-) The "new" ARPANet
routing algorithm was the first LS routing algorithm; IS-IS and OSPF are both
LS algorithms.

There are also a whole class of routing architectures which distribute maps
(like LS), but which *don't* have the hop-by-hop path selection. (I've used
the term "map distribution" to cover both LS and these other architectures,
but there's no general term that I know of to over just this latter group.)
IDPR was the first one of these I know of in the Internet community, and
there are more (e.g. PNNI).


In general, I think you can slice routing protocols two ways:

i) what the data being passed around looks like; either maps (MD) or
routing tables (DV)

ii) how the path is selected; in basically one place (called "explicit"),
or in a peer distributed fashion ("hop-by-hop").

You can mix these two orthagonal axes and produce a four-way division. If
anyone knows of any good design that *doesn't* fall into one of these
categories, I'd be very interested to hear of it.

Then there are a few other wierd odds and ends; the "hot potato" algorithm
proposed (IIRC) in Baran's original paper, so-called "flooding" algorithms
(send a copy to everyone - not much of a routing algorithm, I know :-), etc,
etc.


	Noel


From owner-mpls@UU.NET  Tue Jun  6 23:20:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23981
	for <mpls-archive@lists.ietf.org>; Tue, 6 Jun 2000 23:20:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQismn11329;
	Wed, 7 Jun 2000 03:19:26 GMT
Received: by mail-control.mail.uu.net 
	id QQismn19095
	for mpls-outgoing; Wed, 7 Jun 2000 03:19:07 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQismn19086
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 03:19:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQismn15146
	for <mpls@UU.NET>; Tue, 6 Jun 2000 23:18:53 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQismn11927
	for <mpls@UU.NET>; Wed, 7 Jun 2000 03:18:51 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id XAA17145; Tue, 6 Jun 2000 23:16:52 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id XAA15797;
	Tue, 6 Jun 2000 23:16:12 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006070316.XAA15797@curtis-lt.avici.com>
To: "Dmitri Krioukov" <dima@krioukov.net>
cc: curtis@avici.com, "Juha Heinanen" <jh@lohi.eng.telia.fi>,
        "Loa Andersson" <loa.andersson@nortelnetworks.com>,
        "Grenville Armitage" <gja@dnrc.bell-labs.com>, mpls@UU.NET,
        smd@ebone.net, akyol@pluris.com, bkumar@ennovatenetworks.com
Reply-To: curtis@avici.com
Subject: Re: MPLS Performance analysis..... 
In-reply-to: Your message of "Tue, 06 Jun 2000 20:21:46 EDT."
             <NCBBIKACLKNMKDHKKKNFEECAELAA.dima@krioukov.net> 
Date: Tue, 06 Jun 2000 23:16:12 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <NCBBIKACLKNMKDHKKKNFEECAELAA.dima@krioukov.net>, "Dmitri Krioukov" 
writes:
> 
> has any dynamic routing protocol research been
> done outside of the distance vector and link
> state approaches?
> 
> thanks,
> --
> dima.


Yes, but we are straying outside the charter of the WG mailing list.

Curtis


From owner-mpls@UU.NET  Wed Jun  7 00:16:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24757
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 00:16:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQismr15926;
	Wed, 7 Jun 2000 04:15:50 GMT
Received: by mail-control.mail.uu.net 
	id QQismr01228
	for mpls-outgoing; Wed, 7 Jun 2000 04:15:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQismr01164
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 04:15:02 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQismq29260
	for <mpls@UU.NET>; Wed, 7 Jun 2000 00:14:47 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQismq15047
	for <mpls@UU.NET>; Wed, 7 Jun 2000 04:14:35 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id JAA04009;
	Wed, 7 Jun 2000 09:37:01 -0600 (GMT)
Message-ID: <006201bfd036$9663d680$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: "Eric Gray" <EGray@zaffire.com>, "'Bob Thomas'" <rhthomas@cisco.com>
Cc: <mpls@UU.NET>
References: <9A564CC874B5D3118FB9009027B0A6622D7D7B@ICARIAN>
Subject: Re: Address Message in LDP 
Date: Wed, 7 Jun 2000 09:42:24 +0530
Organization: Daewoo Telecom
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 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Eric
    Sorry for the goofup in name. It's actually Santosh. :)
Please c comments inline.

santosh
>
> To add to what Bob has said, one of your base
> assumptions is not necessarily correct.  Two LSR peers
> may be connected by more than one link.  Additional

fine

> interface addresses may be assigned to any interface
> of a router.  Also, an LSR that shares more than one
> link with a peer LSR will most likely use its router
> ID as its LDP ID (address portion) in order to avoid

I cant make out what do you mean by router ID. If a router has "n" cards
then it will have "n" IP Addresses corresponding to each card. Where is this
concept of router ID? Or is it the Internal representation (some no.
assigned ) at an LSR for the peer that you are refering to ?

> losing its LDP session as a result of removing the
> interface (from which it got the IP address) from
> service (i.e. - pulling out the interface card, or
> executing a "shut" command).  In any of these cases,
> it is some advantage to know additional addresses
> that apply to peer LSRs.
>
> --
> Eric Gray
>
> >
> >
> > Santosh,
> >
> > > Hello Bob
> > >     I have gone thru the section but still have a doubt.
> > Even in DownStream
> > > unsolicited Mode of label distribution, according to the
> > draft each LSR
> > > keeps a list of address prefix and their associated  (LDP
> > Identifier, label)
> > >
> > > LDP Identifier = Interface IP Address : Label Space.
> >
> > There is no guarantee/requirement that the first 4 octects of the
> > LDP Id is the IP address of the "Interface".
> >
> >
> > > Actually the Next hop address in the routing table will
> > exactly match the
> > > "Interface IP Address" specified in the LDP Identifier.
> > This "Interface IP
> >
> > I think you cannot guarantee that this is always true.
> >
> >
> > > Address" is the one directly connected to the peer.
> > > This is depicted below.
> > >
> > >                                             C
> > >                                       /
> > >                                 A   -----  | B |
> > >                                       \
> > >                                             D
> > >
> > > If B,C,D are directly connected to A then the "Interface IP
> > Address" that
> > > will be specified in the Address Message will be the same
> > as the Interface
> > > which A concludes from the HELLO message exchange. So what
> > is the need for a
> > > seperate "Address Message" altogether ?
> >
> > Please see comments above.
> >
> >
> > Bob
> >
> >
> > > One more thing, what is the use of specifying some other
> > "Interace IP
> > > Address" to A by B (say the interface of B with C ) if that
> > is not the
> > > directly connected interface to A?
> > >
> > >
> > > > Santosh,
> > > >
> > > > >     In draft-ietf-mpls-ldp-06.txt, there is an Address
> > Message and =
> > > > > Address Withdraw Message. I am not able to figure out
> > what purpose does
> > > =
> > > > > it serve. In the Hello packet that an LSR sends, it can
> > send the =
> > > > > Interface IP Address optionally. If it doesnt send then
> > the receiving =
> > > > > LSR can make out when it receives from the particular
> > socket. And what =
> > > > > do we gain if an LSR advertizes IP Addresses of other
> > interfaces also ?
> > > =
> > > > > The connection between 2 LSRs is anyway thru some
> > particular interface =
> > > > > and knowing the IP Address of other interfaces will be
> > of no use.
> > > >
> > > > See Section "LDP Identifiers and Next Hop Addresses".
> > > >
> > > > Bob
> > > >
> > >
> > >
> >
> >
>



From owner-mpls@UU.NET  Wed Jun  7 00:32:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24927
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 00:32:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisms02805;
	Wed, 7 Jun 2000 04:31:21 GMT
Received: by mail-control.mail.uu.net 
	id QQisms02055
	for mpls-outgoing; Wed, 7 Jun 2000 04:30:59 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisms02050
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 04:30:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisms26076
	for <mpls@UU.NET>; Wed, 7 Jun 2000 00:30:31 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQisms24806
	for <mpls@UU.NET>; Wed, 7 Jun 2000 04:30:22 GMT
Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id JAA04378
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:55:18 -0600 (GMT)
Message-ID: <393DD007.D312C99D@daewoo.dti.daewoo.co.kr>
Date: Wed, 07 Jun 2000 10:01:03 +0530
From: Neetu Gupta <neetug@daewoo.dti.daewoo.co.kr>
Reply-To: neetug@daewoo.dti.daewoo.co.kr
Organization: Daewoo Telecom
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: mpls <mpls@UU.NET>
Subject: Re: Applications running on RSVP Aware Host End
References: <393C9E75.856D8FB6@daewoo.dti.daewoo.co.kr> <393D17CB.FA27CB1B@fnc.fujitsu.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Snigdho,
    What do you mean by Diff Serv Compliant Application?
Does that mean that when the application runs on the host end, DSCP will be
set in the IP Header?

So we cannot run general applications on the host that cannot set DSCP value
in the IP Header?
-neetu

Snigdho Bardalai wrote:

> If you expect to have a DiffServ compliant application the IP header TOS
> bits should contain the DiffServ DSCP values like expedited, assured
> services etc.
>
> But if you expect to support Integrated Services the TOS bits in the IP
> header may not have any significance.
>
> Snigdho
>





From owner-mpls@UU.NET  Wed Jun  7 00:52:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25013
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 00:52:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQismt17602;
	Wed, 7 Jun 2000 04:51:09 GMT
Received: by mail-control.mail.uu.net 
	id QQismt02954
	for mpls-outgoing; Wed, 7 Jun 2000 04:50:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQismt02947
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 04:50:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQismt29640
	for <mpls@UU.NET>; Wed, 7 Jun 2000 00:50:26 -0400 (EDT)
Received: from cosmos.lgic.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [210.112.199.115])
	id QQismt16934
	for <mpls@UU.NET>; Wed, 7 Jun 2000 04:50:20 GMT
Received: from AEC010W ([150.150.56.10]) by cosmos.lgic.co.kr (8.8.8/8.8.8) with SMTP id NAA10470; Wed, 7 Jun 2000 13:39:02 +0900 (KST)
Message-ID: <011c01bfd03a$a3041ea0$0a389696@rex.lgic.co.kr>
Reply-To: "Yongjun Im" <yjim@lgic.co.kr>
From: "Yongjun Im" <yjim@lgic.co.kr>
To: "James R. Leu" <jleu@mindspring.com>,
        "David Wang" <david.wang@metro-optix.com>
Cc: <mpls@UU.NET>
References: <1000603034311A18874@cosmos.lgic.co.kr>
Subject: Re: Ingress LER in LDP
Date: Wed, 7 Jun 2000 13:41:16 +0900
Organization: LG Information & Communications
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4029.2901
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id AAA25013

According to "draft-ietf-label-encaps-07.txt", 

When transporting labeled packets over PPP,
PPP protocol fields are as follows:
   Unicast : 0x0281
   Multicast : 0x0283

When transporting labeled packets over LAN media,
ethertype fields are as follows:
   Unicast : 0x8847
   Mulicast : 0x8848

Do you mean that POS uses Ethernet or 802.3 LLC/SNAP encapsulation?

Yongjun Im

----- Original Message ----- 
From: "James R. Leu" <jleu@mindspring.com>
To: "David Wang" <david.wang@metro-optix.com>
Cc: <mpls@UU.NET>
Sent: Saturday, June 03, 2000 3:43 AM
Subject: Re: Ingress LER in LDP



On Fri, Jun 02, 2000 at 01:20:33PM -0500, David Wang wrote:
> One related question: How a LSR distinguishes a labeled packet from an
> unlabeled packet? 

Depends on the medium:
-ATM the VCC will contain a protcol type (AAL5Null requires this)
-POS the ether type will be 0x8847 or 0x8848 (as oppsed to 0x0800 for IP)
-PPP has some PIDs assigned for MPLS as well (as does IP)

Hope this helps.

Jim

> 
> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Thursday, June 01, 2000 9:28 AM
> To: Santosh Gupta
> Cc: mpls@UU.NET
> Subject: Re: Ingress LER in LDP 
> 
> 
> Santosh> Can someone tell me how to decide if a router is supposed to act as
> Santosh> an Ingress LER for some particular FEC in MPLS domain ?
> 
> People keep asking  this question, and I'm never quite sure  just what it is
> they are asking, because there isn't much of a mystery here.
> 
> If a router received an unlabeled  packet which belongs to a particular FEC,
> and the next hop for that packet supports MPLS, and the router is configured
> such that it is allowed to do allow label imposition for packets in that FEC
> with that next hop, then the router should impose the label assigned to that
> FEC by that next hop.
> 
> Does that answer your question? 

-- 
James R. Leu



From owner-mpls@UU.NET  Wed Jun  7 04:53:17 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07949
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 04:53:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnj00325;
	Wed, 7 Jun 2000 08:51:51 GMT
Received: by mail-control.mail.uu.net 
	id QQisnj21446
	for mpls-outgoing; Wed, 7 Jun 2000 08:51:31 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisnj21441
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 08:51:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisnj07607
	for <mpls@UU.NET>; Wed, 7 Jun 2000 04:51:05 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQisnj05512
	for <mpls@UU.NET>; Wed, 7 Jun 2000 08:51:00 GMT
Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id OAA09180
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:15:58 -0600 (GMT)
Message-ID: <393E0D28.CC9DF0A4@daewoo.dti.daewoo.co.kr>
Date: Wed, 07 Jun 2000 14:21:52 +0530
From: Neetu Gupta <neetug@daewoo.dti.daewoo.co.kr>
Reply-To: neetug@daewoo.dti.daewoo.co.kr
Organization: Daewoo Telecom
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: mpls <mpls@UU.NET>
Subject: Re: Applications running on RSVP Aware Host End
References: <9A564CC874B5D3118FB9009027B0A6622D7D79@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric,
    Does that mean the Customer will not set TOS byte in the data packet?

Then when the data packets are coming at the ingress point of the MPLS
Domain, how will it be known, to which Diff Serv LSP, the packet has to be
sent, since DSCP value is not set in the header.

Then, who will set the DSCP value?


Eric Gray wrote:

> Neetu,
>
>         Considering the primary application du jour
> for MPLS is traffic engineering, only network
> elements would determine the treatment of host
> packets in the network.  This could - for example
> - be the result of a service level agreement or
> a network domain local decision.
>
>         In general, it would be nice if the network
> operators could rely on hosts to properly set bits
> in the IP header according to how the packets will
> be treated in competition with other packets in a
> network.  But this is unlikely since "cheaters"
> prosper only too well.
>
> --
> Eric Gray





From owner-mpls@UU.NET  Wed Jun  7 05:09:54 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08078
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 05:09:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnk17227;
	Wed, 7 Jun 2000 09:08:59 GMT
Received: by mail-control.mail.uu.net 
	id QQisnk01140
	for mpls-outgoing; Wed, 7 Jun 2000 09:08:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisnk01135
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 09:08:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisnk15546
	for <mpls@uu.net>; Wed, 7 Jun 2000 05:08:15 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisnk12444
	for <mpls@uu.net>; Wed, 7 Jun 2000 09:08:14 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA19020
	for mpls@uu.net; Wed, 7 Jun 2000 05:08:13 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisnk01122
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 09:07:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisnk10095
	for <mpls@UU.NET>; Wed, 7 Jun 2000 05:07:39 -0400 (EDT)
Received: from gorilla.mchh.siemens.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18])
	id QQisnk16363
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:07:39 GMT
Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged))
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA13094;
	Wed, 7 Jun 2000 11:06:56 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA03388;
	Wed, 7 Jun 2000 11:04:34 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2448.0)
	id <MM4ZAHPC>; Wed, 7 Jun 2000 11:09:53 +0200
Message-ID: <3B59676F9ADBD211B5360060086E64EECC0124@MCHH237E>
From: Theimer Thomas <Thomas.Theimer@icn.siemens.de>
To: "'Ross Callon'" <rcallon@juniper.net>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 11:09:48 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

> -----Original Message-----
> From:	Ross Callon [SMTP:rcallon@juniper.net]
> To:	Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
> 
> If the outer label identifies the LSP, and the inner label is a
> special OAM value, then I think that there is a problem with
> penultimate hop label popping.
	[Theimer Thomas]  Good point. We missed that. However, if the
penultimate hop removes the top label, the egress node will receive the
packet with an OAM label on top. That would still trigger OAM processing in
the egress node, so I don't necessarily see a problem here, except that
perhaps the egress node needs to be an LSR. If not, then in my view the
penultimate hop is really the logical endpoint of the LSP, and should
process the OAM label if present. However, I must admit I don't clearly
understand how penultimate hop popping is really applied in a network. I
also could not find any explicit support in LDP, CR-LDP and TE-RSVP. Without
such support, is anyone actually using that mechanism in practice ?

	Thomas




From owner-mpls@UU.NET  Wed Jun  7 05:21:08 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08116
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 05:21:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnl24376;
	Wed, 7 Jun 2000 09:19:46 GMT
Received: by mail-control.mail.uu.net 
	id QQisnl02003
	for mpls-outgoing; Wed, 7 Jun 2000 09:19:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisnl01995
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 09:19:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisnl11996
	for <mpls@UU.NET>; Wed, 7 Jun 2000 05:19:05 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQisnl23578
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:18:40 GMT
Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id OAA09776;
	Wed, 7 Jun 2000 14:41:37 -0600 (GMT)
Message-ID: <393E132C.B957B94E@daewoo.dti.daewoo.co.kr>
Date: Wed, 07 Jun 2000 14:47:32 +0530
From: Neetu Gupta <neetug@daewoo.dti.daewoo.co.kr>
Reply-To: neetug@daewoo.dti.daewoo.co.kr
Organization: Daewoo Telecom
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: Snigdho Bardalai <snigdho.bardalai@fnc.fujitsu.com>
CC: mpls@UU.NET
Subject: Re: Applications running on RSVP Aware Host End
References: <393C9E75.856D8FB6@daewoo.dti.daewoo.co.kr> <393D17CB.FA27CB1B@fnc.fujitsu.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Snigdho,
    When the LSPs are created using Integrated Signalling protocol, the entry
is made in the Forwarding Engine, that contains a label for the information:
Source Address, Source Port, Destination Address, DestPort, Protocol, Class of
Service. This Class of Service can be the value specified for the Class of
Service in the Service Level Agreement with the Customer.
So, when the data packet comes, all these above mentioned fields are matched
with the fields in the IP Header of the Packet including  Class of Service
that is matched to TOS byte.
So, can't we map Class of Service to any of the DSCP values, and specify the
corresponding DSCP value for COS in the agreement with the Customer?

Snigdho Bardalai wrote:

> If you expect to have a DiffServ compliant application the IP header TOS
> bits should contain the DiffServ DSCP values like expedited, assured
> services etc.
>
> But if you expect to support Integrated Services the TOS bits in the IP
> header may not have any significance.
>
> Snigdho
>





From owner-mpls@UU.NET  Wed Jun  7 05:25:25 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08143
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 05:25:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnl27528;
	Wed, 7 Jun 2000 09:24:44 GMT
Received: by mail-control.mail.uu.net 
	id QQisnl02283
	for mpls-outgoing; Wed, 7 Jun 2000 09:24:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisnl02274
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 09:24:12 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisnl12673
	for <mpls@UU.NET>; Wed, 7 Jun 2000 05:24:01 -0400 (EDT)
From: PaulYungShain.Wu@swisscom.com
Received: from sbe3778.swissptt.ch by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: outmail6.swisscom.com [138.190.3.49])
	id QQisnl26933
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:23:59 GMT
Received: from sbe2173.swissptt.ch (138.190.70.55) by sbe3778.swissptt.ch (MX
          V5.1-A AnHp) with SMTP; Wed, 7 Jun 2000 11:23:07 +0200
Received: from 138.190.70.105 by sbe2173.swissptt.ch (InterScan E-Mail
          VirusWall NT);
          Wed, 07 Jun 2000 11:23:04 +0200 (W. Europe Daylight Time)
Received: by gd2zdk.swissptt.ch with Internet Mail Service (5.5.2448.0) id
          <L9WZ59G1>; Wed, 7 Jun 2000 11:22:51 +0200
Message-ID: <75ABF2D52A36D41196F20000F807EB767413A4@gd3ie0.swissptt.ch>
To: neetug@daewoo.dti.daewoo.co.kr, mpls@UU.NET
Subject: AW: Applications running on RSVP Aware Host End
Date: Wed, 7 Jun 2000 11:22:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA08143

Dear Gupta:

A scenario:
The customer get a subscrition for a service, say Olympic Gold data service,
with a SP.
At the time of authentication via the AAA-Server. The SP might be in the
position to assign the DSCP according to the subscrition contract to the
user. The DSCP of the IP header of the customer's data will be set
accordingly.

At the point of interconnection (PoI) - where the PE will translate the
DDSCP into CoS - the corresponding VPN, say VPN-Gold of this SP, will be
used for forwarding the user data according to the SLS (Service Level Spec)
and TCS (Traffic Conditioning Spec) contracted with the NP.

Is this feasible?

Regards,
Paul

-----Ursprüngliche Nachricht-----
Von: Neetu Gupta [mailto:neetug@daewoo.dti.daewoo.co.kr]
Gesendet am: Mittwoch, 7. Juni 2000 10:52
An: mpls
Betreff: Re: Applications running on RSVP Aware Host End

Eric,
    Does that mean the Customer will not set TOS byte in the data packet?

Then when the data packets are coming at the ingress point of the MPLS
Domain, how will it be known, to which Diff Serv LSP, the packet has to be
sent, since DSCP value is not set in the header.

Then, who will set the DSCP value?


Eric Gray wrote:

> Neetu,
>
>         Considering the primary application du jour
> for MPLS is traffic engineering, only network
> elements would determine the treatment of host
> packets in the network.  This could - for example
> - be the result of a service level agreement or
> a network domain local decision.
>
>         In general, it would be nice if the network
> operators could rely on hosts to properly set bits
> in the IP header according to how the packets will
> be treated in competition with other packets in a
> network.  But this is unlikely since "cheaters"
> prosper only too well.
>
> --
> Eric Gray




From owner-mpls@UU.NET  Wed Jun  7 05:50:18 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08321
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 05:50:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnn12279;
	Wed, 7 Jun 2000 09:49:14 GMT
Received: by mail-control.mail.uu.net 
	id QQisnn03699
	for mpls-outgoing; Wed, 7 Jun 2000 09:48:45 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisnn03694
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 09:48:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisnn16027
	for <mpls@UU.NET>; Wed, 7 Jun 2000 05:48:30 -0400 (EDT)
Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: solen.ce.chalmers.se [129.16.20.244])
	id QQisnn13137
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:48:30 GMT
Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199])
	by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id LAA10466;
	Wed, 7 Jun 2000 11:44:26 +0200 (MET DST)
From: Florian-Daniel Otel <otel@ce.chalmers.se>
Received: (from otel@localhost)
	by rasputin.ce.chalmers.se (8.8.8/8.8.8) id LAA03122;
	Wed, 7 Jun 2000 11:44:26 +0200 (MEST)
MIME-Version: 1.0
Date: Wed,  7 Jun 2000 11:44:26 +0200 (MEST)
To: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
Cc: Indra.Widjaja@tddny.fujitsu.com, Thomas.Theimer@icn.siemens.de,
        Shahram_Davari@pmc-sierra.com, pjw@ip-engineering.bt.com,
        neil.2.harrison@bt.com, mpls@UU.NET
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14654.6466.219988.844006@rasputin.ce.chalmers.se>
Reply-To: otel@ce.chalmers.se
Content-Type: text/plain; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Ben, Neil, Peter,

To me it seems that there are two sides of the story:

1) Signaling OAM packets. As Kireeti pointed out, seems that people
are unwilling to change the label semantics as they are now. So we are 
left to play around  Thomas proposal of using an additional OAM 
label, on top of or beanth the 'user-data' labels (is there a better term
for it?). 

2) Set of OAM operations. Neil and Peter already made some points
about it and there are prior discussions around the issues but i
haven't seen nothing concrete yet.


IMHO the first point should come _after_ the second i.e. defining the
OAM operation modes depend on what you're trying to do with it. So,
while Ben proposals sound about right, shouldn't they wait until 
after there is an consensus about the second point ?  In other words
trying to figure out how to signal OAM packets should come _after_ we
decide what we want the OAM functionality be ?


With kind regards,

Florian.


From owner-mpls@UU.NET  Wed Jun  7 07:07:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08915
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 07:07:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisns04828;
	Wed, 7 Jun 2000 11:06:00 GMT
Received: by mail-control.mail.uu.net 
	id QQisns21543
	for mpls-outgoing; Wed, 7 Jun 2000 11:05:28 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisns21393
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 11:05:13 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisns27022
	for <mpls@UU.NET>; Wed, 7 Jun 2000 07:04:57 -0400 (EDT)
Received: from janus.cypress.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: janus.cypress.com [157.95.1.1])
	id QQisns02421
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:04:57 GMT
Received: from cobweb.mis.cypress.com (cobweb.mis.cypress.com [172.16.2.5])
	by janus.cypress.com (8.9.1a/8.9.1) with ESMTP id EAA01754;
	Wed, 7 Jun 2000 04:04:51 -0700 (PDT)
Received: from cypress.com (max-ip114.mis.cypress.com [157.95.237.114])
	by cobweb.mis.cypress.com (8.8.8/8.8.8) with ESMTP id EAA23210;
	Wed, 7 Jun 2000 04:04:53 -0700 (PDT)
Message-ID: <393E2BEB.1AF847E9@cypress.com>
Date: Wed, 07 Jun 2000 04:03:07 -0700
From: Pankaj K Jha <pkj@cypress.com>
Organization: Cypress  Semiconductor Corp.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <EGray@zaffire.com>
CC: "'Chris LaVallee'" <clavallee@zumanetworks.com>, mpls@UU.NET,
        jleu@mindspring.com, David Wang <david.wang@metro-optix.com>
Subject: Re: Ingress LER in LDP
References: <9A564CC874B5D3118FB9009027B0A6622D7D7F@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

- In POS, the protocol used is PPP indeed, and entire provisioned (a VT,
STS-1, etc.) bandwidth of a SONET frame is terminated at a node. This means
that all packets containing PPP (POS) packets within the provisioned area of
SONET SPE are terminated at the node. This is similar to standard PPP where
all packets are point-to-point and the receiver receives all packets that
come on the point-to-point WAN link. Using MPLS on POS has same meaning and
usefulness as that on PPP.

- One of the uses of MPLS in POS is to enable mesh networking easily without
having to use LAN-like protocol for SONET (in LAN-like protocol, each SONET
node must be assigned a MAC address and an entire suite of Ethernet and
higher layer protocols must be used).

A note on LAN-like protocols:
So far, all LAN-like protocols for SONET/SDH are proprietary; some are at
standards committees for further discussions. At higher speeds, some do not
use HDLC since byte-stuffing and de-stuffing at OC-192-type speeds for each
byte is very difficult and because long packets are susceptible to malicious
scrambling. Those that do not use HDLC use a length/length-CRC construct for
packet framing (SDL protocol framing is an example). Almost all of these
LAN-like protocols contain extra bytes in the header to do a TTL discard on
the packet. Recall that in Ethernet packets do not 'come back' to sender. In
SONET, to ensure that a packet does not go around the ring ad nauseum each
node decrements TTL count as a packet passes by it, and discards a packet
(takes it off the ring) when TTL expires.

If MPLS is used with POS, nodes can use MPLS to interconnect and make mesh
network of nodes rather than use a LAN-like addressing for every packet. In
case of optical networks since packets/frames must pass through every node
(packets enter Rx port, and are analyzed after de-scrambling, etc. and then
sent out on Tx port)  there is no need for an Ethernet-like addressing.
Nodes can negotiate and establish MPLS labels and then use that to send
packets to different nodes. Advantage of using MPLS for POS will be that the
host system does not have to look at all of its received POS packets, look
at the layer3 info in payload and do full route lookup work for each packet
to determine where the packet should go. An MPLS lookup logic at line cards
will be able to do packet forwarding and re-routing.

-Pankaj

Eric Gray wrote:

> Chris,
>
>         The "standard" approach - as far as I know -
> is to use PPP for POS.  The ethertypes defined in
> [ENCAPS] are for transmission of MPLS labeled data
> over "LAN media".  It is arguable that some type of
> HDLC framing of IP packets makes SONET a "LAN media"
> but that may be a stretch - particularly if a pro-
> prietary approach is used.  PPP protocol numbers
> 0x0281 (unicast) and 0x0283 (multicast) are defined
> for PPP encapsulation of MPLS labeled packets.
>
>         I am not familiar with whether or not the
> Cisco proprietary approach you describe (I will
> take your word for it that it exists) is available
> without licensing fees.  If it exists, is deployed
> as the only Cisco supported POS approach and is not
> available for licensing, then I think we can look
> forward to government regulation of the new Internet
> monopoly in the very near future. :-)
>
> --
> Eric Gray
>
> > -----Original Message-----
> > From: Chris LaVallee [mailto:clavallee@zumanetworks.com]
> > Sent: Tuesday, June 06, 2000 9:35 AM
> > To: Eric Gray; jleu@mindspring.com; David Wang
> > Cc: mpls@UU.NET
> > Subject: RE: Ingress LER in LDP
> >
> >
> > I was already aware of the MPLSCP in the draft, so what I
> > really meant to
> > ask was this:
> >
> > 1) Cisco-HDLC uses ethertypes, right ? Therefore MPLS will treat
> > POS/Cisco-HDLC as Ethernet.
> >
> > 2) Is there really a benefit to PPP-MPLSCP ?
> > Meaning, you could just use Cisco-HDLC or PPP-BCP. MPLSCP
> > doesn't negotiate
> > anything.
> >
> > I guess you do save a few bytes with PPP-MPLS data and if
> > you're only MPLS
> > switching PPP to PPP, nothing has to be add/deleted or modified in the
> > packet.
> >
> >
> > Chris
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Eric Gray [mailto:EGray@zaffire.com]
> > > Sent: Tuesday, June 06, 2000 8:44 AM
> > > To: 'Chris LaVallee'; jleu@mindspring.com; David Wang
> > > Cc: mpls@UU.NET
> > > Subject: RE: Ingress LER in LDP
> > >
> > >
> > > Chris,
> > >
> > >     Please read the draft:
> > >
> > >
> > >
> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-enca
> > ps-07.txt
> > >
> > > I'm not sure where you got the quote below (I seem to
> > > be getting mail messages from the MPLS mailing list
> > > in some sort of random ordering), but it is incorrect
> > > - the numbers given are not ether types...
> > >
> > > --
> > > Eric Gray
> > >
> > > > -----Original Message-----
> > > > From: Chris LaVallee [mailto:clavallee@zumanetworks.com]
> > > > Sent: Friday, June 02, 2000 4:29 PM
> > > > To: jleu@mindspring.com; David Wang
> > > > Cc: mpls@UU.NET
> > > > Subject: RE: Ingress LER in LDP
> > > >
> > > >
> > > > > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to
> > > > 0x0800 for IP)
> > > >
> > > > This might be off topic, but...
> > > >
> > > > How do you get an ethertype over POS ?
> > > > I'm guessing it's Cisco-HDLC (which I know nothing about)
> > > >
> > > > PPP over POS has 2 other possibilities to carry MPLS
> > > > - Add a new CP (control proto) for MPLS
> > > > - Have BCP (PPP Bridging) carry MPLS
> > > >
> > > > Anyone have a preference / opinion on what people should use ?
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf
> > > > Of James R.
> > > > > Leu
> > > > > Sent: Friday, June 02, 2000 11:43 AM
> > > > > To: David Wang
> > > > > Cc: mpls@UU.NET
> > > > > Subject: Re: Ingress LER in LDP
> > > > >
> > > > >
> > > > > On Fri, Jun 02, 2000 at 01:20:33PM -0500, David Wang wrote:
> > > > > > One related question: How a LSR distinguishes a labeled
> > > > packet from an
> > > > > > unlabeled packet?
> > > > >
> > > > > Depends on the medium:
> > > > > -ATM the VCC will contain a protcol type (AAL5Null
> > requires this)
> > > > > -POS the ether type will be 0x8847 or 0x8848 (as oppsed to
> > > > 0x0800 for IP)
> > > > > -PPP has some PIDs assigned for MPLS as well (as does IP)
> > > > >
> > > > > Hope this helps.
> > > > >
> > > > > Jim
> > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric Rosen [mailto:erosen@cisco.com]
> > > > > > Sent: Thursday, June 01, 2000 9:28 AM
> > > > > > To: Santosh Gupta
> > > > > > Cc: mpls@UU.NET
> > > > > > Subject: Re: Ingress LER in LDP
> > > > > >
> > > > > >
> > > > > > Santosh> Can someone tell me how to decide if a router is
> > > > > supposed to act as
> > > > > > Santosh> an Ingress LER for some particular FEC in
> > MPLS domain ?
> > > > > >
> > > > > > People keep asking  this question, and I'm never quite sure
> > > > > just what it is
> > > > > > they are asking, because there isn't much of a mystery here.
> > > > > >
> > > > > > If a router received an unlabeled  packet which belongs to a
> > > > > particular FEC,
> > > > > > and the next hop for that packet supports MPLS, and the router
> > > > > is configured
> > > > > > such that it is allowed to do allow label imposition for
> > > > > packets in that FEC
> > > > > > with that next hop, then the router should impose the label
> > > > > assigned to that
> > > > > > FEC by that next hop.
> > > > > >
> > > > > > Does that answer your question?
> > > > >
> > > > > --
> > > > > James R. Leu
> > > > >
> > > >
> > >
> >



From owner-mpls@UU.NET  Wed Jun  7 08:01:11 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09395
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 08:01:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnv12071;
	Wed, 7 Jun 2000 11:59:30 GMT
Received: by mail-control.mail.uu.net 
	id QQisnv29569
	for mpls-outgoing; Wed, 7 Jun 2000 11:59:12 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisnv29564
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 11:59:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisnv10532
	for <mpls@UU.NET>; Wed, 7 Jun 2000 07:58:58 -0400 (EDT)
Received: from malmo.trab.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: malmo.trab.se [131.115.48.10])
	id QQisnv11394
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:58:56 GMT
Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id e57Bq8n00905; Wed, 7 Jun 2000 13:52:08 +0200 (MET DST)
Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0)
	id <KZXWD2CY>; Wed, 7 Jun 2000 13:52:07 +0200
Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D022541CB@trab-hermes.haninge.trab.se>
From: Nhat Thanh Hoang <Nhat.T.Hoang@telia.se>
To: "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        "'Ross Callon'"
	 <rcallon@juniper.net>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 13:52:00 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Penultimate hop does use in MPLS VPN context according to Cisco's
implementation, but they use TDP instead of LDP.  (Correct me if I'm wrong.)

/Nhat Thanh

Telia Research



-----Original Message-----
From: Theimer Thomas [mailto:Thomas.Theimer@icn.siemens.de]
Sent: den 7 juni 2000 11:10
To: 'Ross Callon'
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)


> -----Original Message-----
> From:	Ross Callon [SMTP:rcallon@juniper.net]
> To:	Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
> 
> If the outer label identifies the LSP, and the inner label is a
> special OAM value, then I think that there is a problem with
> penultimate hop label popping.
	[Theimer Thomas]  Good point. We missed that. However, if the
penultimate hop removes the top label, the egress node will receive the
packet with an OAM label on top. That would still trigger OAM processing in
the egress node, so I don't necessarily see a problem here, except that
perhaps the egress node needs to be an LSR. If not, then in my view the
penultimate hop is really the logical endpoint of the LSP, and should
process the OAM label if present. However, I must admit I don't clearly
understand how penultimate hop popping is really applied in a network. I
also could not find any explicit support in LDP, CR-LDP and TE-RSVP. Without
such support, is anyone actually using that mechanism in practice ?

	Thomas



From owner-mpls@UU.NET  Wed Jun  7 08:07:07 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09453
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 08:07:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnw14327;
	Wed, 7 Jun 2000 12:02:00 GMT
Received: by mail-control.mail.uu.net 
	id QQisnw00974
	for mpls-outgoing; Wed, 7 Jun 2000 12:01:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisnw00890
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 12:01:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisnw11037
	for <mpls@UU.NET>; Wed, 7 Jun 2000 08:00:56 -0400 (EDT)
Received: from tomts2-srv.bellnexxia.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tomts2.bellnexxia.net [209.226.175.140])
	id QQisnw09563
	for <mpls@UU.NET>; Wed, 7 Jun 2000 12:00:56 GMT
Received: from MartinPicard ([216.209.193.212])
          by tomts2-srv.bellnexxia.net
          (InterMail vM.4.01.02.17 201-229-119) with SMTP
          id <20000607120055.PFGZ18673.tomts2-srv.bellnexxia.net@MartinPicard>
          for <mpls@UU.NET>; Wed, 7 Jun 2000 08:00:55 -0400
Message-ID: <007901bfd077$5b005fa0$3279a98e@MartinPicard>
From: "Martin Picard" <mpicard@sinc.ca>
To: <mpls@UU.NET>
Subject: MPLS Traffic prioritization 
Date: Wed, 7 Jun 2000 07:56:03 -0400
Organization: SINC
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 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

   I am currently pulling together an inventory of the different
   technologies, techniques, methods and protocols to accomplish
   prioritization for traffic going through an MPLS network. This
   inventory is a starting point, since the ultimate goal is to review
   these elements and then establish a migration path to introduce
   traffic prioritization for an MPLS network.

   Any input would be appreciated.

   tx

Martin Picard
SINC




From owner-mpls@UU.NET  Wed Jun  7 08:11:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09497
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 08:11:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnw20708;
	Wed, 7 Jun 2000 12:09:43 GMT
Received: by mail-control.mail.uu.net 
	id QQisnw05487
	for mpls-outgoing; Wed, 7 Jun 2000 12:09:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisnw05460
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 12:09:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisnw12293
	for <mpls@UU.NET>; Wed, 7 Jun 2000 08:09:03 -0400 (EDT)
Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: solen.ce.chalmers.se [129.16.20.244])
	id QQisnw15198
	for <mpls@UU.NET>; Wed, 7 Jun 2000 12:09:02 GMT
Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199])
	by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id OAA19440;
	Wed, 7 Jun 2000 14:09:01 +0200 (MET DST)
From: Florian-Daniel Otel <otel@ce.chalmers.se>
Received: (from otel@localhost)
	by rasputin.ce.chalmers.se (8.8.8/8.8.8) id OAA03270;
	Wed, 7 Jun 2000 14:09:01 +0200 (MEST)
MIME-Version: 1.0
Date: Wed,  7 Jun 2000 14:09:01 +0200 (MEST)
To: "Martin Picard" <mpicard@sinc.ca>
Cc: <mpls@UU.NET>
Subject: Re: MPLS Traffic prioritization 
In-Reply-To: <007901bfd077$5b005fa0$3279a98e@MartinPicard>
References: <007901bfd077$5b005fa0$3279a98e@MartinPicard>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14654.14973.814553.75012@rasputin.ce.chalmers.se>
Reply-To: otel@ce.chalmers.se
Content-Type: text/plain; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


> Hi,
>    I am currently pulling together an inventory of the different
>    technologies, techniques, methods and protocols to accomplish
>    prioritization for traffic going through an MPLS network. This
>    inventory is a starting point, since the ultimate goal is to review
>    these elements and then establish a migration path to introduce
>    traffic prioritization for an MPLS network.

>    Any input would be appreciated.

draft-vaananen-mpls-svc-diff-framework-00.txt and references therein
might be a good prior reading before starting that work.


And welcome to the club ;)

>    tx

> Martin Picard
> SINC




Florian.


From owner-mpls@UU.NET  Wed Jun  7 09:21:38 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10141
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 09:21:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisob20835;
	Wed, 7 Jun 2000 13:20:32 GMT
Received: by mail-control.mail.uu.net 
	id QQisob23245
	for mpls-outgoing; Wed, 7 Jun 2000 13:20:00 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisob23128
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 13:19:46 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisob21235
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:19:24 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQisob04841
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:19:23 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 JAA23080
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:19:21 -0400 (EDT)
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 JAA04196
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:19:18 -0400 (EDT)
Message-ID: <393E4BEA.83077EC5@marconi.com>
Date: Wed, 07 Jun 2000 09:19:38 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Address Message in LDP
References: <9A564CC874B5D3118FB9009027B0A6622D7D7B@ICARIAN> <006201bfd036$9663d680$100d85a5@dti.daewoo.co.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Santosh Gupta wrote:
>> 
>> interface addresses may be assigned to any interface of a router.
>> Also, an LSR that shares more than one link with a peer LSR will most
>> likely use its router ID as its LDP ID (address portion) in order to
>> avoid
> 
> I cant make out what do you mean by router ID. If a router has "n"
> cards then it will have "n" IP Addresses corresponding to each card.
> Where is this concept of router ID? Or is it the Internal
> representation (some no. assigned ) at an LSR for the peer that you
> are refering to ?

Not necessarily.  There is a concept of an "unnumbered link", where a
port does not have its own address.

With many routing protocols, unnumbered links may be used for routing,
as long as there's a way to uniquely identify each router.  this is the
"router ID".  The router ID may be administratively assigned or it may
be dynamically assigned (eg. by choosing one address from those in use
by local ports that have IP addresses).

From the standpoint of a routing/forwarding table, a next-hop address of
a router ID address means "any port on that switch, I don't care
which.".

-- David


From owner-mpls@UU.NET  Wed Jun  7 09:37:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10364
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 09:37:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoc18346;
	Wed, 7 Jun 2000 13:36:15 GMT
Received: by mail-control.mail.uu.net 
	id QQisoc24175
	for mpls-outgoing; Wed, 7 Jun 2000 13:35:52 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisoc24170
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 13:35:43 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisoc24695
	for <mpls@uu.net>; Wed, 7 Jun 2000 09:35:15 -0400 (EDT)
Received: from mailhost.iitb.ac.in by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQisoc16976
	for <mpls@uu.net>; Wed, 7 Jun 2000 13:35:06 GMT
Received: (qmail 21656 invoked from network); 7 Jun 2000 13:45:44 -0000
Received: from bhairav.ee.iitb.ernet.in (144.16.100.100)
  by mailhost.iitb.ac.in with SMTP; 7 Jun 2000 13:45:44 -0000
Received: from localhost (gabhijit@localhost)
	by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id TAA11390
	for <mpls@uu.net>; Wed, 7 Jun 2000 19:05:09 +0530 (IST)
Date: Wed, 7 Jun 2000 19:05:09 +0530 (IST)
From: Abhijit <gabhijit@ee.iitb.ernet.in>
Reply-To: Abhijit <gabhijit@ee.iitb.ernet.in>
To: mpls@UU.NET
Subject: doubts in ENCAPS draft. 
Message-ID: <Pine.GSO.3.96.1000607185844.10848A-100000@bhairav.ee.iitb.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi all

I have a doubt abt the implicit NULL label. 

The draft says 

========================================================================
 value of 3 represents the "Implicit NULL Label".
                 This is a label that an LSR may assign and distribute,
                 but which never actually appears in the encapsulation.
                 When an LSR would otherwise replace the label at the
                 top of the stack with a new label, but the new label is
                 "Implicit NULL", the LSR will pop the stack instead of
                 doing the replacement.  Although this value may never
                 appear in the encapsulation, it needs to be specified          
		 in the Label Distribution Protocol, so a value is
                 reserved.                          

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

I didn't get the exact use of the Implicit Null Label. 

1. What I can infer is that this binding could be given by Egress LSR to
its Upstream so that when the outgoing label value is 3 as specified here,
the Penultimate LSR will Pop the Label entry. 

Is this correct? 

Thanks and Regards 

-abhijit



From owner-mpls@UU.NET  Wed Jun  7 09:57:20 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10618
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 09:57:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisod18494;
	Wed, 7 Jun 2000 13:55:34 GMT
Received: by mail-control.mail.uu.net 
	id QQisod25524
	for mpls-outgoing; Wed, 7 Jun 2000 13:54:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisod25517
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 13:54:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisod04876
	for <mpls@uu.net>; Wed, 7 Jun 2000 09:54:25 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisod17257
	for <mpls@uu.net>; Wed, 7 Jun 2000 13:54:24 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA12353
	for mpls@uu.net; Wed, 7 Jun 2000 09:54:24 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisod25459
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 13:53:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisod28888
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:53:40 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisod16683
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:53:40 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id GAA05899;
	Wed, 7 Jun 2000 06:50:31 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MCL80>; Wed, 7 Jun 2000 06:50:31 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405DC@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        "'Ross Callon'"
	 <rcallon@juniper.net>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 06:47:36 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Theimer,

I think what Ross meant was that using PHP, when OAM label is below the
forwarding label, the egress node can't determine the LSP that the OAM
packet belongs to.

Regards,
-Shahram

>-----Original Message-----
>From: Theimer Thomas [mailto:Thomas.Theimer@icn.siemens.de]
>Sent: Wednesday, June 07, 2000 5:10 AM
>To: 'Ross Callon'
>Cc: mpls@UU.NET
>Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
>
>
>> -----Original Message-----
>> From:	Ross Callon [SMTP:rcallon@juniper.net]
>> To:	Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
>> 
>> If the outer label identifies the LSP, and the inner label is a
>> special OAM value, then I think that there is a problem with
>> penultimate hop label popping.
>	[Theimer Thomas]  Good point. We missed that. However, if the
>penultimate hop removes the top label, the egress node will receive the
>packet with an OAM label on top. That would still trigger OAM 
>processing in
>the egress node, so I don't necessarily see a problem here, except that
>perhaps the egress node needs to be an LSR. If not, then in my view the
>penultimate hop is really the logical endpoint of the LSP, and should
>process the OAM label if present. However, I must admit I don't clearly
>understand how penultimate hop popping is really applied in a 
>network. I
>also could not find any explicit support in LDP, CR-LDP and 
>TE-RSVP. Without
>such support, is anyone actually using that mechanism in practice ?
>
>	Thomas
>
>



From owner-mpls@UU.NET  Wed Jun  7 09:57:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10629
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 09:57:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisod19771;
	Wed, 7 Jun 2000 13:56:40 GMT
Received: by mail-control.mail.uu.net 
	id QQisod25674
	for mpls-outgoing; Wed, 7 Jun 2000 13:55:56 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisod25640
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 13:55:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisod05344
	for <mpls@uu.net>; Wed, 7 Jun 2000 09:55:22 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisod04831
	for <mpls@uu.net>; Wed, 7 Jun 2000 13:55:21 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA12459
	for mpls@uu.net; Wed, 7 Jun 2000 09:55:20 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisod25538
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 13:55:02 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisod29238
	for <mpls@UU.NET>; Wed, 7 Jun 2000 09:54:51 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisod04051
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:54:51 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id GAA05994;
	Wed, 7 Jun 2000 06:54:11 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MCL9X>; Wed, 7 Jun 2000 06:54:11 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405DD@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Abhijit'" <gabhijit@ee.iitb.ernet.in>, mpls@UU.NET
Subject: RE: doubts in ENCAPS draft. 
Date: Wed, 7 Jun 2000 06:51:16 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Correct. This label is used to enable PHP.

-Shahram

>-----Original Message-----
>From: Abhijit [mailto:gabhijit@ee.iitb.ernet.in]
>Sent: Wednesday, June 07, 2000 9:35 AM
>To: mpls@UU.NET
>Subject: doubts in ENCAPS draft. 
>
>
>
>Hi all
>
>I have a doubt abt the implicit NULL label. 
>
>The draft says 
>
>===============================================================
>=========
> value of 3 represents the "Implicit NULL Label".
>                 This is a label that an LSR may assign and distribute,
>                 but which never actually appears in the encapsulation.
>                 When an LSR would otherwise replace the label at the
>                 top of the stack with a new label, but the 
>new label is
>                 "Implicit NULL", the LSR will pop the stack instead of
>                 doing the replacement.  Although this value may never
>                 appear in the encapsulation, it needs to be 
>specified          
>		 in the Label Distribution Protocol, so a value is
>                 reserved.                          
>
>=======================================================================
>
>I didn't get the exact use of the Implicit Null Label. 
>
>1. What I can infer is that this binding could be given by 
>Egress LSR to
>its Upstream so that when the outgoing label value is 3 as 
>specified here,
>the Penultimate LSR will Pop the Label entry. 
>
>Is this correct? 
>
>Thanks and Regards 
>
>-abhijit
>



From owner-mpls@UU.NET  Wed Jun  7 10:09:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10802
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 10:09:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoe15707;
	Wed, 7 Jun 2000 14:07:00 GMT
Received: by mail-control.mail.uu.net 
	id QQisoe03972
	for mpls-outgoing; Wed, 7 Jun 2000 14:06:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisoe03944
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:06:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisoe02337
	for <mpls@UU.NET>; Wed, 7 Jun 2000 10:05:55 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQisoe14688
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:05:54 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id JAA16214;
	Wed, 7 Jun 2000 09:05:46 -0500 (CDT)
Received: from tellabs.com (dhcp-90-119.lisle.tellabs.com [138.111.90.119])
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA21492;
	Wed, 7 Jun 2000 09:05:48 -0500 (CDT)
Message-ID: <393E546B.FF0400D5@tellabs.com>
Date: Wed, 07 Jun 2000 08:55:55 -0500
From: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: curtis@avici.com
CC: neil.2.harrison@bt.com, otel@ce.chalmers.se, Shahram_Davari@pmc-sierra.com,
        EGray@zaffire.com, swtan@mmu.edu.my, kireeti@juniper.net,
        dwilder@baynetworks.com, mpls@UU.NET
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?)
References: <200006061512.LAA13982@curtis-lt.avici.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Curtis,

Perhaps I'm sporting more ignorance in this matter.  I had not
considered ping as a path continuity test.  The idea is to have
a test at the MPLS layer (OK ping is a bit above that...maybe 
not a problem) that would follow the data path (even through
LSRs) so it can detect disconnected and misconnected LSPs.

If the LSP egress expected ping's regularly from the ingress,
lack of pings would detect a broken connection.  If the ping 
contains data that identifies the ingress and path (path trace 
info), some (all?) misconnections can be detected.  (Is adding
specific data to a ping OK, or is this frowned upon?)

The remaining question is how to detect the location of the
dis-or-misconnection.  If intermediate LSRs can monitor this path
trace ping, that would help.  So here we're back to the question
of how to identify OAM packets in transit...  I don't know of
an existing mechanism for this.  (Router alert doesn't seem to 
fit the bill since, I assume, router alert packets follow
a different data path through an LSR from user packets and thus 
will not reflect all possible connection faults.)

In any case, I agree ping is worth considering.

I'm not trying to reinvent the wheel -- just trying to figure
out how to make the cart roll straight with all the varied wheels
we have to work with...

Regards,
Ben

curtis@avici.com wrote:
> 
> In message <393CF7D3.9338D95C@tellabs.com>, Ben Mack-Crane writes:
> >
> > I have been thinking about this from the viewpoint of the recovery
> > framework and protection switching drafts to which I have contributed.
> > In looking at MPLS based recovery, it becomes clear that a simple
> > and reliable path continuity test would be very useful.  Also a fast
> > communication path to convey a fault indication is useful if rapid
> > protection switching is required.
> 
> Pardon my ignorance but to what extent does ping and traceroute
> implemented by the LSR meet these particular OAM needs?
> 
> It might help to start by identifying which features the OAM needs to
> accomoddate that are currently missing (timestamp, record route,
> other?).
> 
> For example, ping with record route doesn't work unless the MPLS
> router alert and an ability to modify the underlying IP packet is
> implemented (which hasn't even been suggested, and I am not implying
> that it is a good idea).  Then we can consider whether a MPLS specific
> ping with record route (or OAM packet) is needed to prevent DOS
> attack, or whether one ping for all underlying layers is still OK (and
> if one ping is better, then whether LSRs should provide configurable
> ability to either rate limit or block setting of MPLS router alert
> based on presence of RR IP options).
> 
> We might want to ask ISPs how valuable RR IP option on ping has been
> and how valuable the equivalent ATM OAM cells have been.  We may find
> that the former is used occasionally at most and the latter even less
> or not at all for IP over ATM networks.
> 
> > A simple way to identify OAM packets, while allowing them to
> > follow the same data path as user packets (when required), is
> > essential to these functions.  If this can be done without disruption
> > to the embedded MPLS base, as Kireeti has indicated, this would be
> > ideal.  I think there are some promising possibliities being discussed
> > in the related thread on "OAM labels".
> 
> draft-ietf-mpls-icmp-01.txt ?
> 
> Lets not reinvent the wheel if we don't have to.
> 
> Curtis


From owner-mpls@UU.NET  Wed Jun  7 10:15:59 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11086
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 10:15:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoe02998;
	Wed, 7 Jun 2000 14:13:54 GMT
Received: by mail-control.mail.uu.net 
	id QQisoe05777
	for mpls-outgoing; Wed, 7 Jun 2000 14:13:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisoe05772
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:13:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisoe09451
	for <mpls@UU.NET>; Wed, 7 Jun 2000 10:12:11 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQisoe20625
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:12:11 GMT
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprch1.nortel.com; Wed, 7 Jun 2000 09:09:36 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id M34FLBSX; Wed, 7 Jun 2000 10:09:38 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id LQHBLWZG; Wed, 7 Jun 2000 10:09:38 -0400
Message-ID: <393E57A1.897F0619@americasm01.nt.com>
Date: Wed, 07 Jun 2000 10:09:37 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: TE extensions and QoS/CoS
References: <336ECDAFDF7DD311B9E30090277AEE4101B405DC@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I was wondering if there ever was a proposal/discussion related to  carring
unreserved bandwidth per QoS/CoS in addition to priority (setup/holding).
It seems the current TE extensions to OSPF and ISIS for MPLS only allow
unreserved bandwidth to be specified for each of 8 priority levels. In
order to carry services like PNNI over MPLS it would be necesary to
advertise to PNNI bandwidth availability per QoS/CoS.

Thanks in advance,

Darek



From owner-mpls@UU.NET  Wed Jun  7 10:27:17 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11462
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 10:27:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisof00080;
	Wed, 7 Jun 2000 14:24:40 GMT
Received: by mail-control.mail.uu.net 
	id QQisof06783
	for mpls-outgoing; Wed, 7 Jun 2000 14:24:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisof06776
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:24:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisof11603
	for <mpls@uu.net>; Wed, 7 Jun 2000 10:23:22 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisof28885
	for <mpls@uu.net>; Wed, 7 Jun 2000 14:23:21 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA18375
	for mpls@uu.net; Wed, 7 Jun 2000 10:23:20 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisof06739
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:22:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisof11275
	for <mpls@UU.NET>; Wed, 7 Jun 2000 10:21:28 -0400 (EDT)
Received: from miranda.tx.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: miranda.tx.fnc.fujitsu.com [167.254.254.199])
	id QQisof08459
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:21:27 GMT
Received: from tdd1028.tx.fnc.fujitsu.com (tdd1028.tddeng00.fnts.com [167.254.144.174])
	by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20143;
	Wed, 7 Jun 2000 09:21:21 -0500 (CDT)
Received: from fnc.fujitsu.com (localhost [127.0.0.1])
	by tdd1028.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id JAA12923;
	Wed, 7 Jun 2000 09:21:20 -0500 (CDT)
Message-ID: <393E5A5E.ACC6BC77@fnc.fujitsu.com>
Date: Wed, 07 Jun 2000 09:21:19 -0500
From: Snigdho Bardalai <snigdho.bardalai@fnc.fujitsu.com>
Organization: Fujitsu Network Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: neetug@daewoo.dti.daewoo.co.kr
CC: mpls@UU.NET
Subject: Re: Applications running on RSVP Aware Host End
References: <393C9E75.856D8FB6@daewoo.dti.daewoo.co.kr> <393D17CB.FA27CB1B@fnc.fujitsu.com> <393E132C.B957B94E@daewoo.dti.daewoo.co.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Neetu Gupta wrote:

> Snigdho,
>     When the LSPs are created using Integrated Signalling protocol, the entry
> is made in the Forwarding Engine, that contains a label for the information:
> Source Address, Source Port, Destination Address, DestPort, Protocol, Class of
> Service. This Class of Service can be the value specified for the Class of
> Service in the Service Level Agreement with the Customer.
> So, when the data packet comes, all these above mentioned fields are matched
> with the fields in the IP Header of the Packet including  Class of Service
> that is matched to TOS byte.
> So, can't we map Class of Service to any of the DSCP values, and specify the
> corresponding DSCP value for COS in the agreement with the Customer?

Sure you can - technically !!! It may not always be acceptable, but instead of
your customer being aware of such mappings you could perform the mapping
at an ingress LER. You must keep in mind that IntServ and DiffServ services
do not match in terms of service characteristics, so mapping services
could be tricky.

>
> Snigdho Bardalai wrote:
>
> > If you expect to have a DiffServ compliant application the IP header TOS
> > bits should contain the DiffServ DSCP values like expedited, assured
> > services etc.
> >
> > But if you expect to support Integrated Services the TOS bits in the IP
> > header may not have any significance.
> >
> > Snigdho
> >

Snigdho

--
Snigdho C. Bardalai
Phone - (972) 479-2951
Fax   - (972) 479-4724
Email - snigdho.bardalai@fnc.fujitsu.com






From owner-mpls@UU.NET  Wed Jun  7 10:28:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11488
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 10:28:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisof12690;
	Wed, 7 Jun 2000 14:26:37 GMT
Received: by mail-control.mail.uu.net 
	id QQisof06903
	for mpls-outgoing; Wed, 7 Jun 2000 14:26:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisof06874
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:26:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisof12187
	for <mpls@uu.net>; Wed, 7 Jun 2000 10:25:42 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisof11653
	for <mpls@uu.net>; Wed, 7 Jun 2000 14:25:41 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA18905
	for mpls@uu.net; Wed, 7 Jun 2000 10:25:41 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisof06821
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:25:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisof11839
	for <mpls@UU.NET>; Wed, 7 Jun 2000 10:24:33 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQisof10562
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:24:31 GMT
Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA03163;
	Wed, 7 Jun 2000 07:24:34 -0700 (PDT)
Received: from p7020-img-nt.cisco.com (sj-dial-1-129.cisco.com [171.68.179.130]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA13957; Wed, 7 Jun 2000 09:24:03 -0500 (CDT)
Message-Id: <4.3.2.7.2.20000607062100.03d07300@flipper.cisco.com>
X-Sender: fred@flipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 07 Jun 2000 06:21:48 +0800
To: Bora Akyol <akyol@pluris.com>
From: Fred Baker <fred@cisco.com>
Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv
  Extension s  related  questions/comments
Cc: "'Brian E Carpenter'" <brian@hursley.ibm.com>,
        Bora Akyol <akyol@pluris.com>, diffserv@ietf.org,
        "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <E097FDA4F2FED311994000104B31A86115E65B@MONTEREY>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 05:11 AM 6/2/00 -0700, Bora Akyol wrote:
>ISPs getting hooked at OC48 speeds to the larger ISPs, there is no longer a
>core box or an edge box.

that's why I keep correcting people, to say "core interface" and "edge 
interface". We seem to have trouble keeping track of the fact that every 
device potentially has both roles.




From owner-mpls@UU.NET  Wed Jun  7 10:37:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11648
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 10:37:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisog19408;
	Wed, 7 Jun 2000 14:35:16 GMT
Received: by mail-control.mail.uu.net 
	id QQisog07457
	for mpls-outgoing; Wed, 7 Jun 2000 14:34:55 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisog07449
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:34:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisog14175
	for <mpls@uu.net>; Wed, 7 Jun 2000 10:34:22 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisog08294
	for <mpls@uu.net>; Wed, 7 Jun 2000 14:34:21 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA20964
	for mpls@uu.net; Wed, 7 Jun 2000 10:34:20 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisog07431
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:33:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisog14024
	for <mpls@UU.NET>; Wed, 7 Jun 2000 10:33:30 -0400 (EDT)
Received: from beamer.mchh.siemens.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163])
	id QQisog17935
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:33:30 GMT
Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged))
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA20456;
	Wed, 7 Jun 2000 16:32:57 +0200 (MET DST)
Received: from mchh201e.demchh201e.icn.siemens.de ([218.1.68.104])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA19647;
	Wed, 7 Jun 2000 16:30:30 +0200 (MET DST)
Received: by MCHH201E with Internet Mail Service (5.5.2448.0)
	id <MM447DVP>; Wed, 7 Jun 2000 16:35:49 +0200
Message-ID: <3B59676F9ADBD211B5360060086E64EECC0129@MCHH237E>
From: Theimer Thomas <Thomas.Theimer@icn.siemens.de>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Ross Callon'"
	 <rcallon@juniper.net>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 16:35:18 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

> From:	Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> To:	'Theimer Thomas'; 'Ross Callon'
> Theimer,
> 
> I think what Ross meant was that using PHP, when OAM label is below the
> forwarding label, the egress node can't determine the LSP that the OAM
> packet belongs to.
	[Theimer Thomas]  OK, thanks for the clarification.
	In this case the label stack at the egress does not identify the LSP
anymore.
	That means, one would have to insert something like an LSPID into
the
	the OAM packet payload to allow for such identification. That may be
	useful anyway to detect misinserted packets.
	The basic purpose of an OAM label - to get the packet directed to an
OAM
	process at a certain LSR - should not be defeated by PHP.

	Regards,

	Thomas



From owner-mpls@UU.NET  Wed Jun  7 10:41:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11794
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 10:41:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisog13256;
	Wed, 7 Jun 2000 14:39:30 GMT
Received: by mail-control.mail.uu.net 
	id QQisog07688
	for mpls-outgoing; Wed, 7 Jun 2000 14:38:59 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisog07683
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:38:57 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisog09341
	for <mpls@UU.NET>; Wed, 7 Jun 2000 10:38:24 -0400 (EDT)
Received: from tenornetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQisog22172
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:38:22 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id KAA29237;
	Wed, 7 Jun 2000 10:38:21 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          WED, 7 Jun 2000 10:35:04 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <LS6K6MX7>; Wed, 7 Jun 2000 10:35:04 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E5609EC45@newman.tenornet.com>
From: "Mancour, Tim" <timm@tenornetworks.com>
To: "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        "'Ross Callon'"
	 <rcallon@juniper.net>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 10:35:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom,

I understand the intent, but the idea of processing a label which is under
the top label seems to be in violation to the section 3.9 of the MPLS
architecture draft which states:

	Although, as we shall see, MPLS supports a hierarchy, the processing
      of a labeled packet is completely independent of the level of
      hierarchy.  The processing is always based on the top label, without
      regard for the possibility that some number of other labels may have
      been "above it" in the past, or that some number of other labels may
      be below it at present.

If we proceed down this path then this type of label processing behavior
should be clearly reflected in the MPLS architecture.

TimM

-----Original Message-----
From: Theimer Thomas [mailto:Thomas.Theimer@icn.siemens.de]
Sent: Wednesday, June 07, 2000 5:10 AM
To: 'Ross Callon'
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)


> -----Original Message-----
> From:	Ross Callon [SMTP:rcallon@juniper.net]
> To:	Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
> 
> If the outer label identifies the LSP, and the inner label is a
> special OAM value, then I think that there is a problem with
> penultimate hop label popping.
	[Theimer Thomas]  Good point. We missed that. However, if the
penultimate hop removes the top label, the egress node will receive the
packet with an OAM label on top. That would still trigger OAM processing in
the egress node, so I don't necessarily see a problem here, except that
perhaps the egress node needs to be an LSR. If not, then in my view the
penultimate hop is really the logical endpoint of the LSP, and should
process the OAM label if present. However, I must admit I don't clearly
understand how penultimate hop popping is really applied in a network. I
also could not find any explicit support in LDP, CR-LDP and TE-RSVP. Without
such support, is anyone actually using that mechanism in practice ?

	Thomas




From owner-mpls@UU.NET  Wed Jun  7 11:00:10 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12207
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 11:00:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoh27220;
	Wed, 7 Jun 2000 14:56:34 GMT
Received: by mail-control.mail.uu.net 
	id QQisoh08882
	for mpls-outgoing; Wed, 7 Jun 2000 14:56:11 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisoh08874
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 14:56:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisoh19048
	for <mpls@UU.NET>; Wed, 7 Jun 2000 10:53:14 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQisoh04636
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:53:13 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id JAA09426;
	Wed, 7 Jun 2000 09:51:51 -0500
Message-ID: <20000607095151.A9353@doit.wisc.edu>
Date: Wed, 7 Jun 2000 09:51:51 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: Bob Thomas <rhthomas@cisco.com>,
        Surekha Gupta <santoshg@daewoo.dti.daewoo.co.kr>
Cc: mpls@UU.NET
Subject: Re: Address Message in LDP
Reply-To: jleu@mindspring.com
References: <015401bfcfbf$90dd7940$100d85a5@dti.daewoo.co.kr> <200006061407.KAA28712@focal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <200006061407.KAA28712@focal.cisco.com>; from Bob Thomas on Tue, Jun 06, 2000 at 10:07:54AM -0400
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

My understanding is that the list of addresses messages given to me by a
peer will allow me to answer the question if this peer "is the nexthop" for
a particular route.  This allow me to know whether or not I should install
a mapping the peer has given me.  What if ... the address that I match
(which was given to me by the peer) is from a differnt labelspace then the
label he has allocated to me?  Maybe a picture will help.


   ---------                 ---------
  |         |A11---------A21|         |
  |   R1    |               |    R2   |------ FEC
  |         |A12---------A22|         |
   ---------                 ---------

-A21 means R2's 1st address.
-each interface has a labelspace that matches the address number
 (thus R2 has 2 labelspaces it allocates from 21,22)
-R1 and R2 have two LDP sessions
-R1 session with R2:21 has A22,A21 for an address list
-R1 session with R2:22 has A21,A22 for an address list

-R1 has a routing table of:
 Prefix     outif      nexthop
 FEC        A11        A21

R2:22 allocates a label(L1) in labelspace 22 and send the mapping to R1.
R1 gets the mapping and searches the address list for R2:22 and finds that
the next hop of A21 is in R2:22 address list, so it installs the label out
A12 for FEC.

-R1 now has a FTN that looks like:
 Prefix     outif      nexthop   label
 FEC        A12        A22       L1

I can see avoiding this problem if the check for "is the nexthop" also takes
into consideration the outgoing if.  How would that work in targeted mode?

I think this can be solved for both modes by limiting the address messages 
R2:22 gave to R1. Why not only give out the addresses of the interfaces that
match the labelspace you are advertising?

Jim
-- 
James R. Leu


From owner-mpls@UU.NET  Wed Jun  7 11:07:14 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12422
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 11:07:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoi14622;
	Wed, 7 Jun 2000 15:03:25 GMT
Received: by mail-control.mail.uu.net 
	id QQisoi12895
	for mpls-outgoing; Wed, 7 Jun 2000 15:02:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisoi12860
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:02:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisoi15698
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:01:59 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQisoi02712
	for <mpls@UU.NET>; Wed, 7 Jun 2000 15:01:59 GMT
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Wed, 7 Jun 2000 09:57:43 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <L3HQ1GK2>; Wed, 7 Jun 2000 09:57:33 -0400
Message-ID: <6DDA62170439D31185750000F80826AC02BFD4DC@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>,
        Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
Cc: Thomas.Theimer@icn.siemens.de, Shahram_Davari@pmc-sierra.com,
        pjw@ip-engineering.bt.com, mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 09:57:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD088.529C8AC6"
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_01BFD088.529C8AC6
Content-Type: text/plain;
	charset="iso-8859-1"

Can we bring a bit of discipline to this discussion.

- what problems are we trying to diagnose?
- what functionality do we require to take corrective action (protection
switching, fault sectionalization etc.)
- what mechanisms are required to diagnose the problems?
- what flows are required to propagate knowledge of the problems?
- how can we specify encoding those flows?

We know the last item in the list is a problem, but lets not solve it first.
We seem to agree it needs solving, I see lots of suggestions to populate the
toolbox.

Neil has mentioned a number of interesting issues as far as defects are
concerned (a combined list would include):
- segment or span failure,
- segment or span degredation,
- nodal failure,
- topology failure (misdirected end point or routing loop),
each of which may require a specific tool to diagnose.

There's at least two aspects to the functionality:
- fault detection and sectionalization
- propagation of knowledge of a defect to the nodes which require knowledge
of the defect

And some interesting twists to consider such as:
- assymetrical defects (one direction of a link fails)
- partial tree failure
- timliness of defect detection

Feel free to add or subtract from this list, maybe we can get a useful
concensus view. There's really nothing new here, the sandbox is different.

cheers
Dave





> -----Original Message-----
> From:	Indra.Widjaja [SMTP:Indra.Widjaja@tddny.fujitsu.com]
> Sent:	Tuesday, June 06, 2000 2:32 PM
> To:	Ben Mack-Crane
> Cc:	Thomas.Theimer@icn.siemens.de; Shahram_Davari@pmc-sierra.com;
> pjw@ip-engineering.bt.com; mpls@UU.NET
> Subject:	Re: OAM labels (was: can egress know the ingress of a
> packet?)
> 
> Ben:
> Please see my comments below.
> indra
> 
> 
> Ben Mack-Crane wrote:
> 
> > Hello,
> >
> > I have been thinking about OAM packet identification and I
> > think this evolving proposal looks promising.
> >
> > There are several possible processing modes for OAM packets,
> > and I am interested in your thoughts on (a) which are needed,
> > and (b) which can be supported by the current proposal.
> >
> > For the sake of discussion I have given them numbers (with no
> > particular significance) and included my initial thoughts.
> >
> > Mode 1:
> > Packet transparently forwarded along user packet data path
> >
> > This mode is needed for end-to-end OAM funcitons that depend
> > on following the user packet data path exactly (e.g., delay
> > measurement, as Indra mentioned, and path continuity tests).
> 
> OAM packet is inserted at an ingress LSR and is identified by an
> OAM label located at the bottom of the stack. When all user labels
> have been popped at an egress LSR, the OAM label directs the
> packet to an OAM engine for processing.
> 
> >
> >
> > Mode 2:
> > Packet transparently forwarded along user data path and also
> > passed to OAM processing (monitoring)
> >
> > This mode can be easily combined with Mode 1, and is useful
> > for isolating faults and monitoring subnetwork connections.
> 
> Do you assume that monitoring can be done at any intermediate LSR?
> If the answer is yes, then since only OAM packets (and not user packets)
> are to be selectively monitored, there is a need to identify an OAM packet
> based on user label at the top. Therefore there is a need for another
> OAM bit in the label stack entry.
> 
> >
> >
> > Mode 3:
> > Packet forwarded to OAM processing, then forwarded along next
> > hop of user packet data path (possibly not following user packet
> > data path at all points within the LSR)
> >
> > This mode may be useful for OAM packets that do not need to
> > follow the user data path exactly within the LSR, need more
> > flexible processing (i.e. are more suited to SW than HW
> > processing), and are not too frequent.
> >
> > Mode 4:
> > Packet forwarded to OAM processing and terminated
> >
> > This is the common mode for termination points (LSP endpoints)
> > and segment endpoints (if segment OAM is supported).  The
> > difficulty in the segment case is distinguishing which OAM
> > packets to terminate and which to pass if Mode 1 or 2 OAM packets
> > are also in use.  (Obviously Modes 3 and 4 can easily be combined.)
> 
> Are OAM packets forwarded hop-by-hop or transparently along the data path?
> If forwarding is hop-by-hop, then Mode 3 already takes care of this.
> If forwarded along the user data path, then Mode 2 may be able
> to take of this case.
> 
> >
> >
> > Mode 5:
> > Packet forwarded to previous hop on user packet data path
> > (forwarding OAM packets following LSP upstream)
> >
> > Same as Mode 1, but upstream so there is no "user packet data path"
> > per se.  This might be useful for end-to-end OAM funcitons that
> > require two way communication (are there any?) or funcitons
> > that require rapid communicaiton upstream (e.g., fault indication for
> > rapid protection switching).
> 
> Do you mean: packet forwarded to *the ingress* on user
> packet data path rather than to previous hop?
> One end-to-end application is for Mode 1 to do forward performance
> monitoring, and this mode to do backward performance reporting.
> However, I think we can use the same Mode 1 (or Mode 3) in the
> backward direction in terms of forwarding OAM packets
> (after processing at the egress).
> 
> >
> >
> > Mode 6:
> > Packet forwarded to previous hop on user packet data path and also
> > passed to OAM processing (monitoring upstream OAM)
> >
> > Same as mode 2, but upstream (do we detect a pattern here?).
> > As before, easily combined with Mode 5.  Might be good for subnetwork
> > connection protection switching, as long as the fault indication
> > does not cause any trouble passing further upstream.
> >
> > Mode 7:
> > Packet forwarded to OAM processing, then forwarded to previous hop
> > on user packet data path
> >
> > Same as Mode 3, but upstream.  Another option for upstream OAM
> > communication, possibly slower than Mode 5 or 6.
> >
> > Mode 8:
> > Packet forwarded to AOM processing and terminated (upstream direction)
> >
> > Same as Mode 4, but upstream.
> >
> > Regarding OAM packet identification, it seems reasonable to use the
> > user packet label on top for Modes 1 and 2 so the packet will follow
> > the user data path downstream.  Mode 2 could rely on looking for a
> > reserved OAM label next on the stack.  Modes 3 and 4 are easily
> > supported with a reserved OAM label on top, or at the LSP endpoint
> > where the user packet label is popped anyway (though it might need
> > to be preserved as Peter mentioned).  However, supporting Modes 3
> > or 4 at points within the path when the user label is on top is a
> > problem (how to decide to forward only to OAM processing and not along
> > user packet path -- Indra: Is this the point you were making?)
> 
> I was more thinking that in Mode 4, you want to forward OAM packets
> along the user data path (if forwarding is hop-by-hop, then Mode 3
> already takes care of this case). So the OAM label cannot be on top.
> However, Mode 4 is different from Mode 1 in that OAM termination
> at any node (including intermediate nodes) is allowed.
> It seems that the OAM label can be located at any level between the
> bottom (inclusieve) and top (exclusive) of the stack as long as the
> OAM path is restricted within the same level of hierarchy.
> 
> >
> >
> > In the upstream modes, the user label is not defined for forwarding
> > so perhaps this can always be done with an OAM reserved label on top.
> >
> > So...  What do you think about this?  Can we identify a subset of
> > modes that are necessary and sufficient, or is it simpler to define
> > an OAM packet identification scheme that supports all of them and
> > let folks decide later which mode to use in a particular OAM
> > application?
> 
> Sounds right.
> 
> >
> >
> > Regards,
> > Ben Mack-Crane
> >
> > Indra.Widjaja@tddny.fujitsu.com wrote:
> > >
> > > Thomas:
> > > I think both end-to-end and hop-by-hop OAM packets as you mentioned
> > > below should be supported.
> > > A third possible way is segment OAM packets where you still want the
> > > OAM packets to be treated the same way as data packets in the
> > > segment connection. I believe this can be realized by using the first
> > > approach plus a dedicated OAM bit. Is there a requirement for this?
> > > indra
> > >
> > > Theimer Thomas wrote:
> > >
> > > > Actually, there are at least two ways to use such a reserved OAM
> label:
> > > >
> > > > - end-end OAM packets would have a label stack where the reserved
> > > >   label is inserted below the original top label. After the top
> label is
> > > >   popped at the egress node, the reserved label is processed by
> > > >   forwarding the packet to OAM handling. Thus, all packets are
> > > >   forwarded using the original top label. OAM packets are visible
> > > >   only to ingress and egress nodes, and use exactly the same
> > > >   path as user packets.
> > > >
> > > > - hop-by-hop OAM packets would have the reserved label pushed
> > > >   on top of the original top label. Each LSR along the LSP would
> > > >   then recognise the reserved top label, forward the packet to
> > > >   OAM handling, and then forward the packet using the label
> > > >   second on the label stack (the original top label).
> > > >
> > > > It may simplify things if two different reserved labels are defined
> > > > for end-end and hop-by-hop OAM packets, if people feel that
> > > > both are needed. The hop-hop case is really very similar to
> > > > the router alert label.
> > > >
> > > > A dedicated OAM header bit would serve a similar purpose, but is
> > > > not strictly required.
> > > >
> > > > Regards,
> > > >
> > > > Thomas Theimer
> > > > > -----Original Message-----
> > > > > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> > > > > Sent: Monday, June 05, 2000 5:50 PM
> > > > > To:   'Peter Willis'; mpls@UU.NET
> > > > > Subject:      RE: OAM labels (was: can egress know the ingress of
> a
> > > > > packet?)
> > > > >
> > > > > Peter,
> > > > >
> > > > > But we can use two labels. The top label can be the reserved one,
> and the
> > > > > second label can be the actual label, which is used for forwarding
> the OAM
> > > > > packet. This is basically similar to the Router Alert Label = 1.
> > > > >
> > > > > Regards,
> > > > > -Shahram
> > > > >
> > > > > >-----Original Message-----
> > > > > >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> > > > > >Sent: Monday, June 05, 2000 11:37 AM
> > > > > >To: mpls@UU.NET
> > > > > >Subject: RE: OAM labels (was: can egress know the ingress of a
> packet?)
> > > > > >
> > > > > >
> > > > > >
> > > > > >An LSR will be terminating many LSPs so will be terminating
> > > > > >many OAM flows.
> > > > > >How do you correctly diagnose LSPs with merged or corrupted
> > > > > >labels if they all
> > > > > >arrive on the same reserved label? The label the OAM flow
> > > > > >arrives on has to
> > > > > >match exactly the label used for the data (user plane) flow in
> > > > > >order to be able
> > > > > >to detect faults caused by LSRs using broken label swapping
> tables.
> > > > > >
> > > > > >So we need a bit somewhere in the MPLS header to identify an
> > > > > >OAM payload but
> > > > > >we need to keep the same label as used for the user plane data.
> > > > > >
> > > > > >Peter.
> > > > > >
> > > > > >
> 
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: OAM labels (was: can egress know the ingress of a =
packet?)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Can we bring a bit =
of discipline to this discussion.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- what problems are =
we trying to diagnose?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- what =
functionality do we require to take corrective action (protection =
switching, fault sectionalization etc.)</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- what mechanisms =
are required to diagnose the problems?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- what flows are =
required to propagate knowledge of the problems?</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- how can we =
specify encoding those flows?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">We know the last =
item in the list is a problem, but lets not solve it first. We seem to =
agree it needs solving, I see lots of suggestions to populate the =
toolbox.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Neil has mentioned a =
number of interesting issues as far as defects are concerned (a =
combined list would include):</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- segment or span =
failure,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- segment or span =
degredation,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- nodal =
failure,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- topology failure =
(misdirected end point or routing loop),</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">each of which may =
require a specific tool to diagnose.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">There's at least two =
aspects to the functionality:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- fault detection =
and sectionalization</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- propagation of =
knowledge of a defect to the nodes which require knowledge of the =
defect</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">And some interesting =
twists to consider such as:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- assymetrical =
defects (one direction of a link fails)</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- partial tree =
failure</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">- timliness of =
defect detection</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Feel free to add or =
subtract from this list, maybe we can get a useful concensus view. =
There's really nothing new here, the sandbox is different.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">cheers</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Indra.Widjaja =
[SMTP:Indra.Widjaja@tddny.fujitsu.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, June 06, 2000 2:32 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Ben Mack-Crane</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Thomas.Theimer@icn.siemens.de; =
Shahram_Davari@pmc-sierra.com; pjw@ip-engineering.bt.com; =
mpls@UU.NET</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: OAM labels (was: can egress know =
the ingress of a packet?)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ben:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Please see my comments below.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">indra</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ben Mack-Crane wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Hello,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I have been thinking about OAM =
packet identification and I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; think this evolving proposal =
looks promising.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; There are several possible =
processing modes for OAM packets,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and I am interested in your =
thoughts on (a) which are needed,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and (b) which can be supported =
by the current proposal.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; For the sake of discussion I =
have given them numbers (with no</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; particular significance) and =
included my initial thoughts.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Mode 1:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Packet transparently forwarded =
along user packet data path</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This mode is needed for =
end-to-end OAM funcitons that depend</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; on following the user packet =
data path exactly (e.g., delay</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; measurement, as Indra mentioned, =
and path continuity tests).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">OAM packet is inserted at an ingress =
LSR and is identified by an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OAM label located at the bottom of =
the stack. When all user labels</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">have been popped at an egress LSR, =
the OAM label directs the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">packet to an OAM engine for =
processing.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Mode 2:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Packet transparently forwarded =
along user data path and also</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; passed to OAM processing =
(monitoring)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This mode can be easily combined =
with Mode 1, and is useful</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; for isolating faults and =
monitoring subnetwork connections.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Do you assume that monitoring can be =
done at any intermediate LSR?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">If the answer is yes, then since only =
OAM packets (and not user packets)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">are to be selectively monitored, =
there is a need to identify an OAM packet</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">based on user label at the top. =
Therefore there is a need for another</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OAM bit in the label stack =
entry.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Mode 3:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Packet forwarded to OAM =
processing, then forwarded along next</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; hop of user packet data path =
(possibly not following user packet</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; data path at all points within =
the LSR)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This mode may be useful for OAM =
packets that do not need to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; follow the user data path =
exactly within the LSR, need more</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; flexible processing (i.e. are =
more suited to SW than HW</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; processing), and are not too =
frequent.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Mode 4:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Packet forwarded to OAM =
processing and terminated</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; This is the common mode for =
termination points (LSP endpoints)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and segment endpoints (if =
segment OAM is supported).&nbsp; The</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; difficulty in the segment case =
is distinguishing which OAM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; packets to terminate and which =
to pass if Mode 1 or 2 OAM packets</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; are also in use.&nbsp; =
(Obviously Modes 3 and 4 can easily be combined.)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Are OAM packets forwarded hop-by-hop =
or transparently along the data path?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">If forwarding is hop-by-hop, then =
Mode 3 already takes care of this.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">If forwarded along the user data =
path, then Mode 2 may be able</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to take of this case.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Mode 5:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Packet forwarded to previous hop =
on user packet data path</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; (forwarding OAM packets =
following LSP upstream)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Same as Mode 1, but upstream so =
there is no &quot;user packet data path&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; per se.&nbsp; This might be =
useful for end-to-end OAM funcitons that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; require two way communication =
(are there any?) or funcitons</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; that require rapid communicaiton =
upstream (e.g., fault indication for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; rapid protection =
switching).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Do you mean: packet forwarded to *the =
ingress* on user</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">packet data path rather than to =
previous hop?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">One end-to-end application is for =
Mode 1 to do forward performance</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">monitoring, and this mode to do =
backward performance reporting.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">However, I think we can use the same =
Mode 1 (or Mode 3) in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">backward direction in terms of =
forwarding OAM packets</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(after processing at the =
egress).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Mode 6:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Packet forwarded to previous hop =
on user packet data path and also</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; passed to OAM processing =
(monitoring upstream OAM)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Same as mode 2, but upstream (do =
we detect a pattern here?).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; As before, easily combined with =
Mode 5.&nbsp; Might be good for subnetwork</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; connection protection switching, =
as long as the fault indication</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; does not cause any trouble =
passing further upstream.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Mode 7:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Packet forwarded to OAM =
processing, then forwarded to previous hop</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; on user packet data path</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Same as Mode 3, but =
upstream.&nbsp; Another option for upstream OAM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; communication, possibly slower =
than Mode 5 or 6.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Mode 8:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Packet forwarded to AOM =
processing and terminated (upstream direction)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Same as Mode 4, but =
upstream.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Regarding OAM packet =
identification, it seems reasonable to use the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; user packet label on top for =
Modes 1 and 2 so the packet will follow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the user data path =
downstream.&nbsp; Mode 2 could rely on looking for a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; reserved OAM label next on the =
stack.&nbsp; Modes 3 and 4 are easily</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; supported with a reserved OAM =
label on top, or at the LSP endpoint</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; where the user packet label is =
popped anyway (though it might need</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to be preserved as Peter =
mentioned).&nbsp; However, supporting Modes 3</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; or 4 at points within the path =
when the user label is on top is a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; problem (how to decide to =
forward only to OAM processing and not along</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; user packet path -- Indra: Is =
this the point you were making?)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I was more thinking that in Mode 4, =
you want to forward OAM packets</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">along the user data path (if =
forwarding is hop-by-hop, then Mode 3</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">already takes care of this case). So =
the OAM label cannot be on top.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">However, Mode 4 is different from =
Mode 1 in that OAM termination</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">at any node (including intermediate =
nodes) is allowed.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">It seems that the OAM label can be =
located at any level between the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">bottom (inclusieve) and top =
(exclusive) of the stack as long as the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OAM path is restricted within the =
same level of hierarchy.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; In the upstream modes, the user =
label is not defined for forwarding</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; so perhaps this can always be =
done with an OAM reserved label on top.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; So...&nbsp; What do you think =
about this?&nbsp; Can we identify a subset of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; modes that are necessary and =
sufficient, or is it simpler to define</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; an OAM packet identification =
scheme that supports all of them and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; let folks decide later which =
mode to use in a particular OAM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; application?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sounds right.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Ben Mack-Crane</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Indra.Widjaja@tddny.fujitsu.com =
wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Thomas:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I think both end-to-end and =
hop-by-hop OAM packets as you mentioned</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; below should be =
supported.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; A third possible way is =
segment OAM packets where you still want the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; OAM packets to be treated =
the same way as data packets in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; segment connection. I =
believe this can be realized by using the first</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; approach plus a dedicated =
OAM bit. Is there a requirement for this?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; indra</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Theimer Thomas =
wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Actually, there are at =
least two ways to use such a reserved OAM label:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; - end-end OAM packets =
would have a label stack where the reserved</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; label is =
inserted below the original top label. After the top label is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; popped at =
the egress node, the reserved label is processed by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; forwarding =
the packet to OAM handling. Thus, all packets are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; forwarded =
using the original top label. OAM packets are visible</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; only to =
ingress and egress nodes, and use exactly the same</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; path as =
user packets.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; - hop-by-hop OAM =
packets would have the reserved label pushed</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; on top of =
the original top label. Each LSR along the LSP would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; then =
recognise the reserved top label, forward the packet to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; OAM =
handling, and then forward the packet using the label</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp;&nbsp; second on =
the label stack (the original top label).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; It may simplify things =
if two different reserved labels are defined</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; for end-end and =
hop-by-hop OAM packets, if people feel that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; both are needed. The =
hop-hop case is really very similar to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; the router alert =
label.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; A dedicated OAM header =
bit would serve a similar purpose, but is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; not strictly =
required.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Thomas Theimer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; From: Shahram =
Davari [SMTP:Shahram_Davari@pmc-sierra.com]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; Sent: Monday, =
June 05, 2000 5:50 PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; To:&nbsp;&nbsp; =
'Peter Willis'; mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: OAM labels (was: can egress =
know the ingress of a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; packet?)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; Peter,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; But we can use =
two labels. The top label can be the reserved one, and the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; second label can =
be the actual label, which is used for forwarding the OAM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; packet. This is =
basically similar to the Router Alert Label =3D 1.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; -Shahram</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;-----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;From: Peter =
Willis [<U></U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"mailto:pjw@ip-engineering.bt.com">mailto:pjw@ip-engineering.bt.c=
om</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;Sent: Monday, =
June 05, 2000 11:37 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;To: =
mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;Subject: RE: =
OAM labels (was: can egress know the ingress of a packet?)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;An LSR will =
be terminating many LSPs so will be terminating</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;many OAM =
flows.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;How do you =
correctly diagnose LSPs with merged or corrupted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;labels if =
they all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;arrive on the =
same reserved label? The label the OAM flow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;arrives on =
has to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;match exactly =
the label used for the data (user plane) flow in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;order to be =
able</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;to detect =
faults caused by LSRs using broken label swapping tables.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;So we need a =
bit somewhere in the MPLS header to identify an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;OAM payload =
but</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;we need to =
keep the same label as used for the user plane data.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;Peter.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFD088.529C8AC6--


From owner-mpls@UU.NET  Wed Jun  7 11:24:56 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12915
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 11:24:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoj21536;
	Wed, 7 Jun 2000 15:23:13 GMT
Received: by mail-control.mail.uu.net 
	id QQisoj20222
	for mpls-outgoing; Wed, 7 Jun 2000 15:22:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisoj20200
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:22:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisoj26890
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:21:07 -0400 (EDT)
Received: from mailcarrier.snv1.gctr.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailcarrier.snv1.gctr.net [206.251.8.19])
	id QQisoj00875
	for <mpls@UU.NET>; Wed, 7 Jun 2000 15:21:07 GMT
Received: from pobox.snv1.gctr.net (pobox.snv1.gctr.net [204.71.194.242])
	by mailcarrier.snv1.gctr.net (8.9.3/8.9.0) with ESMTP id PAA07034
	for <mpls@UU.NET>; Wed, 7 Jun 2000 15:21:06 GMT
Received: (from dcooper@localhost)
	by pobox.snv1.gctr.net (8.9.3/8.9.3) id PAA02738
	for mpls@UU.NET; Wed, 7 Jun 2000 15:19:09 GMT
Date: Wed, 7 Jun 2000 15:19:09 +0000
From: Dave Cooper <dcooper@globalcenter.net>
To: mpls@UU.NET
Subject: TTL decrementing/propagation
Message-ID: <20000607151909.C1810@globalcenter.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
Sender: owner-mpls@UU.NET
Precedence: bulk


Are there plans or some drafts i have not seen that 
propose a specification/mechanism for dealing with 
TTL decrementing/propagation. I am seeing multiple 
vendor implementations of this functionality with 
interoperability issues and i am sure other 
vendors are in the same boat.

While this is somewhat cosmetic, it does lend to the 
ability of the provider to troubleshoot their network.

-dave


From owner-mpls@UU.NET  Wed Jun  7 11:25:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13022
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 11:25:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoj03691;
	Wed, 7 Jun 2000 15:24:10 GMT
Received: by mail-control.mail.uu.net 
	id QQisoj20282
	for mpls-outgoing; Wed, 7 Jun 2000 15:23:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisoj20263
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:23:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisoj27232
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:22:22 -0400 (EDT)
Received: from corecom.it by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.corecom.it [131.175.40.11])
	id QQisoj01613
	for <mpls@UU.NET>; Wed, 7 Jun 2000 15:21:48 GMT
Received: from [131.175.40.56] by corecom.it with
 ESMTP (Eudora Internet Mail Server 1.1.2); Wed, 7 Jun 2000 17:22:23 +0200
X-Sender: t00trini@mail.corecom.it
Message-Id: <l03130300b5641729b70d@[131.175.40.56]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 7 Jun 2000 17:20:27 +0200
To: mpls@UU.NET
From: Trini Jurado <t00trini@corecom.it>
Subject: LDPs establishments
Sender: owner-mpls@UU.NET
Precedence: bulk

Which is the most common implementation of MPLS from the point of view of
the way in which LDPs are established?

In the case of establishing an LDP every time a new RSVP session is opened,
is it possible to do LDP nesting?

Thank you for your replies.






From owner-mpls@UU.NET  Wed Jun  7 11:30:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13185
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 11:30:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoj27504;
	Wed, 7 Jun 2000 15:29:40 GMT
Received: by mail-control.mail.uu.net 
	id QQisoj20668
	for mpls-outgoing; Wed, 7 Jun 2000 15:29:15 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisoj20663
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:29:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisoj23064
	for <mpls@uu.net>; Wed, 7 Jun 2000 11:28:58 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisoj07773
	for <mpls@uu.net>; Wed, 7 Jun 2000 15:28:57 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA01703
	for mpls@uu.net; Wed, 7 Jun 2000 11:28:56 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisoj20630
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:28:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisoj28697
	for <mpls@uu.net>; Wed, 7 Jun 2000 11:28:15 -0400 (EDT)
Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQisoj26177
	for <mpls@uu.net>; Wed, 7 Jun 2000 15:28:14 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id SAA25593;
	Wed, 7 Jun 2000 18:28:11 +0300
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14654.27147.109792.728461@lohi.eng.telia.fi>
Date: Wed, 7 Jun 2000 18:28:11 +0300 (EEST)
To: Thomas Eklund <thomas.eklund@switchcore.com>
Cc: "'Brian E Carpenter'" <brian@hursley.ibm.com>, Kimmo.Raatikainen@nokia.com,
        akyol@pluris.com, diffserv@ietf.org, mpls@UU.NET
Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension
	s    related  questions/comments
In-Reply-To: <45AFD48D077ED211BB4700A0C9DCE8FD28A586@monza.broadswitch.com>
References: <45AFD48D077ED211BB4700A0C9DCE8FD28A586@monza.broadswitch.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thomas Eklund writes:

 > If you look at our product which is a switch/router-on-a-chip in ASIC it
 > runs a full MF classifier and have full diffserv (queeing, scheduling etc.)
 > support for 16 GigabitEthernet full duplex ports wirespeed!!

i didn't find in the documents any support for metering and policing.

-- juha



From owner-mpls@UU.NET  Wed Jun  7 11:37:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13430
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 11:37:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisok02361;
	Wed, 7 Jun 2000 15:34:57 GMT
Received: by mail-control.mail.uu.net 
	id QQisok21055
	for mpls-outgoing; Wed, 7 Jun 2000 15:34:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisok21050
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:34:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisok00145
	for <mpls@uu.net>; Wed, 7 Jun 2000 11:34:11 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisok01614
	for <mpls@uu.net>; Wed, 7 Jun 2000 15:34:11 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA03007
	for mpls@uu.net; Wed, 7 Jun 2000 11:34:10 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisok21037
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:33:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisok24205
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:33:31 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQisok11218
	for <mpls@UU.NET>; Wed, 7 Jun 2000 15:33:30 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA01102;
	Wed, 7 Jun 2000 08:33:36 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA16375; Wed, 7 Jun 2000 11:33:26 -0400 (EDT)
Message-Id: <200006071533.LAA16375@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: jleu@mindspring.com
cc: Surekha Gupta <santoshg@daewoo.dti.daewoo.co.kr>, mpls@UU.NET
Subject: Re: Address Message in LDP 
In-reply-to: Your message of "Wed, 07 Jun 2000 09:51:51 CDT."
             <20000607095151.A9353@doit.wisc.edu> 
Date: Wed, 07 Jun 2000 11:33:26 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Jim,

> My understanding is that the list of addresses messages given to me by a
> peer will allow me to answer the question if this peer "is the nexthop" for
> a particular route.  This allow me to know whether or not I should install
> a mapping the peer has given me.  What if ... the address that I match
> (which was given to me by the peer) is from a differnt labelspace then the
> label he has allocated to me?  Maybe a picture will help.
> 
> 
>    ---------                 ---------
>   |         |A11---------A21|         |
>   |   R1    |               |    R2   |------ FEC
>   |         |A12---------A22|         |
>    ---------                 ---------
> 
> -A21 means R2's 1st address.
> -each interface has a labelspace that matches the address number
>  (thus R2 has 2 labelspaces it allocates from 21,22)
> -R1 and R2 have two LDP sessions
> -R1 session with R2:21 has A22,A21 for an address list
> -R1 session with R2:22 has A21,A22 for an address list
> 
> -R1 has a routing table of:
>  Prefix     outif      nexthop
>  FEC        A11        A21
> 
> R2:22 allocates a label(L1) in labelspace 22 and send the mapping to R1.
> R1 gets the mapping and searches the address list for R2:22 and finds that
> the next hop of A21 is in R2:22 address list, so it installs the label out
> A12 for FEC.
> 
> -R1 now has a FTN that looks like:
>  Prefix     outif      nexthop   label
>  FEC        A12        A22       L1
> 
> I can see avoiding this problem if the check for "is the nexthop" also takes
> into consideration the outgoing if.  How would that work in targeted mode?
> 
> I think this can be solved for both modes by limiting the address messages 
> R2:22 gave to R1. Why not only give out the addresses of the interfaces that
> match the labelspace you are advertising?

I think you are making this more complicated that it need be.

The purpose of the Address Message is to make it possible for an LSR
to establish a mapping between the first 4 octets of a peer's LDP Id
and addresses bound to the peer.

This mapping is useful in determining whether the peer is the next
hop for a particular prefix.

Bob



From owner-mpls@UU.NET  Wed Jun  7 11:37:42 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13447
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 11:37:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisok14044;
	Wed, 7 Jun 2000 15:36:13 GMT
Received: by mail-control.mail.uu.net 
	id QQisok21095
	for mpls-outgoing; Wed, 7 Jun 2000 15:35:36 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisok21084
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:35:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisok24543
	for <mpls@uu.net>; Wed, 7 Jun 2000 11:35:16 -0400 (EDT)
Received: from sepahan.iut.ac.ir by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sepahan.iut.ac.ir [194.165.10.30])
	id QQisok12545
	for <mpls@uu.net>; Wed, 7 Jun 2000 15:35:12 GMT
Received: from localhost (s7627237@localhost)
	by sepahan.iut.ac.ir (8.9.3/8.9.3) with ESMTP id UAA02704
	for <mpls@uu.net>; Wed, 7 Jun 2000 20:06:15 +0430
Date: Wed, 7 Jun 2000 20:06:15 +0430 (IRST)
From: Manshaee Mohammad-Hossein <s7627237@sepahan.iut.ac.ir>
To: mpls@UU.NET
Subject: question about MPLS
In-Reply-To: <6DDA62170439D31185750000F80826AC02BFD4DC@zmerd004.ca.nortel.com>
Message-ID: <Pine.LNX.4.10.10006071945590.2441-100000@sepahan.iut.ac.ir>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

First I must say that I start studying MPLS and If you see that my
questions are cheap! pardon!

but my question:

about ATM and MPLS: I want to know that where is the place of Label
in ATM cells.

If we put them on VPI/VCI the length of Labels and VPI/VCI aren't same!

and if you put labels like IP packets we have problem in ATM switch.
I mean page 28 in "Multiprotocol Label Switching Architecture"

yours,

MH Manshaei





From owner-mpls@UU.NET  Wed Jun  7 11:51:54 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13886
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 11:51:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisol24852;
	Wed, 7 Jun 2000 15:50:05 GMT
Received: by mail-control.mail.uu.net 
	id QQisol22100
	for mpls-outgoing; Wed, 7 Jun 2000 15:49:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisol22093
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:49:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisol27951
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:49:22 -0400 (EDT)
Received: from solen.ce.chalmers.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: solen.ce.chalmers.se [129.16.20.244])
	id QQisol24079
	for <mpls@UU.NET>; Wed, 7 Jun 2000 15:49:21 GMT
Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199])
	by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id RAA01550;
	Wed, 7 Jun 2000 17:45:17 +0200 (MET DST)
From: Florian-Daniel Otel <otel@ce.chalmers.se>
Received: (from otel@localhost)
	by rasputin.ce.chalmers.se (8.8.8/8.8.8) id RAA03497;
	Wed, 7 Jun 2000 17:45:16 +0200 (MEST)
MIME-Version: 1.0
Date: Wed,  7 Jun 2000 17:45:16 +0200 (MEST)
To: "David Allan" <dallan@nortelnetworks.com>
Cc: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>,
        Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>,
        Thomas.Theimer@icn.siemens.de, Shahram_Davari@pmc-sierra.com,
        pjw@ip-engineering.bt.com, mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
In-Reply-To: <6DDA62170439D31185750000F80826AC02BFD4DC@zmerd004.ca.nortel.com>
References: <6DDA62170439D31185750000F80826AC02BFD4DC@zmerd004.ca.nortel.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14654.27394.250448.471063@rasputin.ce.chalmers.se>
Reply-To: otel@ce.chalmers.se
Content-Type: text/plain; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


> [1  <text/plain; iso-8859-1 (7bit)>]
> Can we bring a bit of discipline to this discussion.

> - what problems are we trying to diagnose?
> - what functionality do we require to take corrective action (protection
> switching, fault sectionalization etc.)
> - what mechanisms are required to diagnose the problems?
> - what flows are required to propagate knowledge of the problems?
> - how can we specify encoding those flows?


Well, I'll add only one more mail to these threads re-iterating what me
Thomas, Neil and others already said:

Is it possible that we consider this (i.e. OAM functionality) in
the light of:
	-Existing drafts for protection/restoration/loop prevention
	-ping/traceroute for MPLS
	-ICMP  and MPLS-ICMP
	-other expressed OAM needs


While i see quite a bit of overlapping IMHO I think we can tie
everything up and address all these issues in  a consistent manner. It 
would be a really nice way to clean this OAM slate and have everything
addressed in a consistent manner. The only thing that needs to be done
is to gather all the ideas under one frame. AFAICT there are enough
ideas already expressed to be a critical mass...


Just my $0.02 worth.

Regards,

Florian.






From owner-mpls@UU.NET  Wed Jun  7 12:01:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14317
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 12:01:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisom24596;
	Wed, 7 Jun 2000 16:00:03 GMT
Received: by mail-control.mail.uu.net 
	id QQisol22778
	for mpls-outgoing; Wed, 7 Jun 2000 15:59:37 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisol22771
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 15:59:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisol05748
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:58:15 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQisol00914
	for <mpls@UU.NET>; Wed, 7 Jun 2000 15:58:15 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id KAA25389;
	Wed, 7 Jun 2000 10:58:12 -0500 (CDT)
Received: from tellabs.com (tlab-138-111-90-119.tellabs.com [138.111.90.119] (may be forged))
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA11885;
	Wed, 7 Jun 2000 10:56:09 -0500 (CDT)
Message-ID: <393E6E2B.EB5CD416@tellabs.com>
Date: Wed, 07 Jun 2000 10:45:47 -0500
From: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Indra.Widjaja@tddny.fujitsu.com
CC: Thomas.Theimer@icn.siemens.de, Shahram_Davari@pmc-sierra.com,
        pjw@ip-engineering.bt.com, mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <3B59676F9ADBD211B5360060086E64EECC011A@MCHH237E> <393BEE17.7EE547D9@tddny.fujitsu.com> <393D0E6F.4F91E367@tellabs.com> <393D439B.4E9876C0@tddny.fujitsu.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Indra,

See responses below.  I've tried to clarify some things, but,
as others have pointed out, continuing this discussion might 
wait until we have some agreement on the problems that need 
to be solved.

Regards,
Ben

Indra.Widjaja@tddny.fujitsu.com wrote:
> 
> Ben:
> Please see my comments below.
> indra
> 
> Ben Mack-Crane wrote:
> 
> > Hello,
> >
> > I have been thinking about OAM packet identification and I
> > think this evolving proposal looks promising.
> >
> > There are several possible processing modes for OAM packets,
> > and I am interested in your thoughts on (a) which are needed,
> > and (b) which can be supported by the current proposal.
> >
> > For the sake of discussion I have given them numbers (with no
> > particular significance) and included my initial thoughts.
> >
> > Mode 1:
> > Packet transparently forwarded along user packet data path
> >
> > This mode is needed for end-to-end OAM funcitons that depend
> > on following the user packet data path exactly (e.g., delay
> > measurement, as Indra mentioned, and path continuity tests).
> 
> OAM packet is inserted at an ingress LSR and is identified by an
> OAM label located at the bottom of the stack. When all user labels
> have been popped at an egress LSR, the OAM label directs the
> packet to an OAM engine for processing.
> 
My description of these Modes may have been unclear -- they are 
essentially defining possible per hop behaviors for OAM packet
handling.  For example, the ingress LSR uses Mode 4 (termination --
actually origination or "termination source"), intervening LSRs
use Mode 1 (transparent) and the egress uses Mode 4 ("termination 
sink").  How these particular modes are tied together along a path
to accomplish some OAM function, and how to determine which mode
to apply to a given OAM packet, is the interesting part.

> >
> >
> > Mode 2:
> > Packet transparently forwarded along user data path and also
> > passed to OAM processing (monitoring)
> >
> > This mode can be easily combined with Mode 1, and is useful
> > for isolating faults and monitoring subnetwork connections.
> 
> Do you assume that monitoring can be done at any intermediate LSR?
> If the answer is yes, then since only OAM packets (and not user packets)
> are to be selectively monitored, there is a need to identify an OAM packet
> based on user label at the top. Therefore there is a need for another
> OAM bit in the label stack entry.
> 
Right.  This is an example of the problem of identifying how to handle
OAM packets (how to identify, from the packet, whether the packet is OAM and
which OAM processing mode to use).

> >
> >
> > Mode 3:
> > Packet forwarded to OAM processing, then forwarded along next
> > hop of user packet data path (possibly not following user packet
> > data path at all points within the LSR)
> >
> > This mode may be useful for OAM packets that do not need to
> > follow the user data path exactly within the LSR, need more
> > flexible processing (i.e. are more suited to SW than HW
> > processing), and are not too frequent.
> >
> > Mode 4:
> > Packet forwarded to OAM processing and terminated
> >
> > This is the common mode for termination points (LSP endpoints)
> > and segment endpoints (if segment OAM is supported).  The
> > difficulty in the segment case is distinguishing which OAM
> > packets to terminate and which to pass if Mode 1 or 2 OAM packets
> > are also in use.  (Obviously Modes 3 and 4 can easily be combined.)
> 
> Are OAM packets forwarded hop-by-hop or transparently along the data path?
> If forwarding is hop-by-hop, then Mode 3 already takes care of this.
> If forwarded along the user data path, then Mode 2 may be able
> to take of this case.
> 
Yes.  As before, these are per hop Modes, so Modes 2 and 3 support looking
at AND forwarding the OAM packet.  Mode 4 removes the OAM packet from the 
network (it does not go beyond this LSR).

> >
> >
> > Mode 5:
> > Packet forwarded to previous hop on user packet data path
> > (forwarding OAM packets following LSP upstream)
> >
> > Same as Mode 1, but upstream so there is no "user packet data path"
> > per se.  This might be useful for end-to-end OAM funcitons that
> > require two way communication (are there any?) or funcitons
> > that require rapid communicaiton upstream (e.g., fault indication for
> > rapid protection switching).
> 
> Do you mean: packet forwarded to *the ingress* on user
> packet data path rather than to previous hop?
> One end-to-end application is for Mode 1 to do forward performance
> monitoring, and this mode to do backward performance reporting.
> However, I think we can use the same Mode 1 (or Mode 3) in the
> backward direction in terms of forwarding OAM packets
> (after processing at the egress).
> 
My intent here was that there be a backward OAM path that follows
the same hops as the LSP, but since LSPs are unidirectional there
is no backward user data path.  Maybe it is better to say "Packet
forwarded to LSP previous hop LSR" so the idea of following the user 
packet data path doesn't confuse things.

> >
> >
> > Mode 6:
> > Packet forwarded to previous hop on user packet data path and also
> > passed to OAM processing (monitoring upstream OAM)
> >
> > Same as mode 2, but upstream (do we detect a pattern here?).
> > As before, easily combined with Mode 5.  Might be good for subnetwork
> > connection protection switching, as long as the fault indication
> > does not cause any trouble passing further upstream.
> >
> > Mode 7:
> > Packet forwarded to OAM processing, then forwarded to previous hop
> > on user packet data path
> >
> > Same as Mode 3, but upstream.  Another option for upstream OAM
> > communication, possibly slower than Mode 5 or 6.
> >
> > Mode 8:
> > Packet forwarded to AOM processing and terminated (upstream direction)
> >
> > Same as Mode 4, but upstream.
> >
> > Regarding OAM packet identification, it seems reasonable to use the
> > user packet label on top for Modes 1 and 2 so the packet will follow
> > the user data path downstream.  Mode 2 could rely on looking for a
> > reserved OAM label next on the stack.  Modes 3 and 4 are easily
> > supported with a reserved OAM label on top, or at the LSP endpoint
> > where the user packet label is popped anyway (though it might need
> > to be preserved as Peter mentioned).  However, supporting Modes 3
> > or 4 at points within the path when the user label is on top is a
> > problem (how to decide to forward only to OAM processing and not along
> > user packet path -- Indra: Is this the point you were making?)
> 
> I was more thinking that in Mode 4, you want to forward OAM packets
> along the user data path (if forwarding is hop-by-hop, then Mode 3
> already takes care of this case). So the OAM label cannot be on top.
> However, Mode 4 is different from Mode 1 in that OAM termination
> at any node (including intermediate nodes) is allowed.
> It seems that the OAM label can be located at any level between the
> bottom (inclusieve) and top (exclusive) of the stack as long as the
> OAM path is restricted within the same level of hierarchy.
> 
For cases where the packet must go to OAM processing regardless, the
OAM label can be on top, but as you point out this is a problem if
we are talking about the entire path of an OAM packet and it must be
passed transparently over some hops (in this case the user data label
must be on top, and some other means of identifying the packet as OAM
must be used when it is to be passed to OAM processing).
> >
> >
> > In the upstream modes, the user label is not defined for forwarding
> > so perhaps this can always be done with an OAM reserved label on top.
> >
> > So...  What do you think about this?  Can we identify a subset of
> > modes that are necessary and sufficient, or is it simpler to define
> > an OAM packet identification scheme that supports all of them and
> > let folks decide later which mode to use in a particular OAM
> > application?
> 
> Sounds right.
> 
> >
> >
> > Regards,
> > Ben Mack-Crane
> >
> > Indra.Widjaja@tddny.fujitsu.com wrote:
> > >
> > > Thomas:
> > > I think both end-to-end and hop-by-hop OAM packets as you mentioned
> > > below should be supported.
> > > A third possible way is segment OAM packets where you still want the
> > > OAM packets to be treated the same way as data packets in the
> > > segment connection. I believe this can be realized by using the first
> > > approach plus a dedicated OAM bit. Is there a requirement for this?
> > > indra
> > >
> > > Theimer Thomas wrote:
> > >
> > > > Actually, there are at least two ways to use such a reserved OAM label:
> > > >
> > > > - end-end OAM packets would have a label stack where the reserved
> > > >   label is inserted below the original top label. After the top label is
> > > >   popped at the egress node, the reserved label is processed by
> > > >   forwarding the packet to OAM handling. Thus, all packets are
> > > >   forwarded using the original top label. OAM packets are visible
> > > >   only to ingress and egress nodes, and use exactly the same
> > > >   path as user packets.
> > > >
> > > > - hop-by-hop OAM packets would have the reserved label pushed
> > > >   on top of the original top label. Each LSR along the LSP would
> > > >   then recognise the reserved top label, forward the packet to
> > > >   OAM handling, and then forward the packet using the label
> > > >   second on the label stack (the original top label).
> > > >
> > > > It may simplify things if two different reserved labels are defined
> > > > for end-end and hop-by-hop OAM packets, if people feel that
> > > > both are needed. The hop-hop case is really very similar to
> > > > the router alert label.
> > > >
> > > > A dedicated OAM header bit would serve a similar purpose, but is
> > > > not strictly required.
> > > >
> > > > Regards,
> > > >
> > > > Thomas Theimer
> > > > > -----Original Message-----
> > > > > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> > > > > Sent: Monday, June 05, 2000 5:50 PM
> > > > > To:   'Peter Willis'; mpls@UU.NET
> > > > > Subject:      RE: OAM labels (was: can egress know the ingress of a
> > > > > packet?)
> > > > >
> > > > > Peter,
> > > > >
> > > > > But we can use two labels. The top label can be the reserved one, and the
> > > > > second label can be the actual label, which is used for forwarding the OAM
> > > > > packet. This is basically similar to the Router Alert Label = 1.
> > > > >
> > > > > Regards,
> > > > > -Shahram
> > > > >
> > > > > >-----Original Message-----
> > > > > >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> > > > > >Sent: Monday, June 05, 2000 11:37 AM
> > > > > >To: mpls@UU.NET
> > > > > >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> > > > > >
> > > > > >
> > > > > >
> > > > > >An LSR will be terminating many LSPs so will be terminating
> > > > > >many OAM flows.
> > > > > >How do you correctly diagnose LSPs with merged or corrupted
> > > > > >labels if they all
> > > > > >arrive on the same reserved label? The label the OAM flow
> > > > > >arrives on has to
> > > > > >match exactly the label used for the data (user plane) flow in
> > > > > >order to be able
> > > > > >to detect faults caused by LSRs using broken label swapping tables.
> > > > > >
> > > > > >So we need a bit somewhere in the MPLS header to identify an
> > > > > >OAM payload but
> > > > > >we need to keep the same label as used for the user plane data.
> > > > > >
> > > > > >Peter.
> > > > > >
> > > > > >


From owner-mpls@UU.NET  Wed Jun  7 12:15:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14732
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 12:15:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisom07277;
	Wed, 7 Jun 2000 16:13:56 GMT
Received: by mail-control.mail.uu.net 
	id QQisom02912
	for mpls-outgoing; Wed, 7 Jun 2000 16:13:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisom02895
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 16:13:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisom09052
	for <mpls@UU.NET>; Wed, 7 Jun 2000 12:13:00 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQisom12233
	for <mpls@UU.NET>; Wed, 7 Jun 2000 16:13:00 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69LFP>; Wed, 7 Jun 2000 09:18:52 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690747@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Manshaee Mohammad-Hossein'" <s7627237@sepahan.iut.ac.ir>, mpls@UU.NET
Subject: RE: question about MPLS
Date: Wed, 7 Jun 2000 09:18:48 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

MH Manshaei,

	Read "MPLS using LDP and ATM VC Switching" by
Davie, et al.  It may be found at:

   http://www.ietf.org/internet-drafts/draft-ietf-mpls-atm-03.txt

This should address your question(s).


> -----Original Message-----
> From: Manshaee Mohammad-Hossein [mailto:s7627237@sepahan.iut.ac.ir]
> Sent: Wednesday, June 07, 2000 8:36 AM
> To: mpls@UU.NET
> Subject: question about MPLS
> 
> 
> Hi,
> 
> First I must say that I start studying MPLS and If you see that my
> questions are cheap! pardon!
> 
> but my question:
> 
> about ATM and MPLS: I want to know that where is the place of Label
> in ATM cells.
> 
> If we put them on VPI/VCI the length of Labels and VPI/VCI 
> aren't same!
> 
> and if you put labels like IP packets we have problem in ATM switch.
> I mean page 28 in "Multiprotocol Label Switching Architecture"
> 
> yours,
> 
> MH Manshaei
> 
> 
> 


From owner-mpls@UU.NET  Wed Jun  7 12:19:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14838
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 12:19:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQison09460;
	Wed, 7 Jun 2000 16:16:51 GMT
Received: by mail-control.mail.uu.net 
	id QQison03753
	for mpls-outgoing; Wed, 7 Jun 2000 16:16:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQison03735
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 16:16:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQison03981
	for <mpls@UU.NET>; Wed, 7 Jun 2000 12:15:41 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQison14122
	for <mpls@UU.NET>; Wed, 7 Jun 2000 16:15:40 GMT
Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP;
          Wed, 7 Jun 2000 16:48:54 +0100
Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWBG30F>; Wed, 7 Jun 2000 16:49:05 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16030@mbddmknt01.hc.bt.com>
To: Ben.Mack-Crane@tellabs.com, Indra.Widjaja@tddny.fujitsu.com,
        Thomas.Theimer@icn.siemens.de, Shahram_Davari@pmc-sierra.com,
        pjw@ip-engineering.bt.com
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 16:47:58 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Ben,

Before we define the 'modes' (as you refer to them Ben), I think it
important first to define why we want these modes.  I largely see the key
needs of OAM as:
-	making sure all  potential defect conditions can be detected and the
appropriate consequent actions taken
-	making sure customer traffic is not sent to the wrong place, ie 1st
level of security
-	making sure alarms are only raised in the appropriate place and that
operational staff get simple but adequate diagnostic tools
-	making sure protection-sw occurs in the appropriate place
-	making sure that if there are availability SLAs and QoS SLAs in
place we can measure them......noting that QoS metrics are really only valid
if the entity being considered is in the 'up-state' (which we need to define
1st)

Beyond this we have 'nice to have but not essential' functions.  In
particular, this is where I would place doing things like sampling the
network with 'probes' to give some network-wide statistical characterisation
of specific QoS parameters, eg errors pkts, abs/var on delay, etc.  One can
incur large processing costs if you aim to to detailed QoS metric collection
on a continuous basis network-wide, cf the PM cell in ATM.  A route trace
OAM function would also fall into the nice to have category.

I penned the following 'OAM principles' some time ago and then aimed to
define a min set of OAM functions that I thought we might need from MPLS to
satisfy them:

Layer independence:	Each layer network must have its own OAM
functionality to detect failures and abnormal performance that is not
dependent on a specific server or client layer technology.  This is critical
to ensure that layer networks can evolve (or be removed) without impacting
other layer networks.

End-to-end (E2E) and per domain monitoring capability:	It should be
possible to simultaneously measure the E2E and per domain (a specific case
of subnetwork partitioning) performance of trails.
Note - A key point about performance metrics (such as errored-PDUs,
lost-PDUs, PDU temporal arrival variance, etc) is that they are only
relevant when the connection is in the Available State.  Therefore,
connectivity status is the primary in-service metric that must be identified
at all times.

Defects:	All the major defect conditions that can affect trails must
be identified with in-service measurable entry and exit criteria, and all
consequent actions specified.  If possible, the entry and exit criteria
should be temporally harmonised as far as possible to simplify state
processing at trail termination points.  Attention should be paid to
relating the defect entry/exit criteria to 'short-breaks', which are
generally accepted as 3-9s periods of gross signal disturbance from which
the network may self-recover.  If the event lasts for >=10s this is the
normally accepted threshold for entering the Unavailable State - see next
item.

Availability:	The most important performance metric of a trail (or a
subnetwork partition thereof) is availability.  It is therefore critical to
define the entry and exit criteria for the Unavailable/Available State and
understand how these relate to the stopping/starting of the aggregation of
available state performance metrics such as PDU loss (noting that this may
be effectively applied at an earlier point to preserve the integrity of the
available state metrics, eg after 3s say, which marks the onset of (at
least) a short-break).

Decoupling of user behaviour from connectivity assessment:	It is
critical to remove user traffic behaviour from trail connectivity
assessment.  In practical terms, this means decoupling user behaviour from
all defect and (the dependent) available state entry/exit criteria.

Forward and Backward Defect Indicators:	The node in the layer network which
detects a defect (sourced from within that layer) must apply a well-known
Forward Defect Indication (FDI).  In the majority of current WAN
technologies such a signal has been termed AIS (Alarm Indication Signal).
At the trail termination point (or, if applicable, any subnetwork
termination point) the FDI signal must (i) create a complimentary Backward
Defect Indication (BDI) (which is removed at the upstream trail (or
subnetwork) termination point) and (ii) map the FDI signal from the server
layer to the FDI signal of the client layer(s) as part of the adaptation
process.

The primary purpose of the FDI is to suppress downstream and client layer
alarms (so that there is not an 'alarm explosion' and so Operations
Personnel can correctly target the real defect location source).  Three
secondary purposes of FDI (and indeed BDI) are:
(i) to allow correct processing of available state performance metrics;
(ii) to inform the ultimate end-system/customer applications that the
connection is no longer functioning correctly and to take appropriate
action, eg in the case of voice perhaps mute the speech path;
(iii) provide a user-plane originated trigger mechanism for
protection-switching purposes (maybe via control-plane functionality).  Note
that correctly targeted protection-switching in the context of nested MPLS
LSPs requires special attention.

From the preceding we should note that, if possible, the FDI/BDI signals
should provide information on the defect location and type (such information
is very useful to the lead operator for many reasons).

Connectivity verification:	A key characteristic of layer networks is
that they must have their own (within layer) globally unique addressing
structure that defines the layer network access points.  However, within the
layer network relative addressing may be used (which only has to be unique
per interface) as a mechanism to provide fast route forwarding of PDUs, eg
VPI/VCI of ATM, DLCI of FR, the 'label' of MPLS.

When relative addressing is used there is danger of misbranching defects.
These cover a variety of connectivity failures, including simple loss of
connectivity, swapped connections, unintended mismerging, self-mismerging
(ie routing loops), etc.  Unless detected and corrected, the consequence of
such defects can be very severe for an operator, ranging from simple SLA
availability violation through to more serious security, censorship and
misbilling implications.  The diagnosis (eg detection and location) of such
failures is difficult unless a globally unique trail source address is
periodically transmitted to detect these failures.

Customers should not be used as defect detectors:		Wherever
possible, the OAM tools should not require that customers have to act as
failure detectors.

OAM functionality under fault conditions:	Under fault conditions a
layer network cannot be expected to behave in a predictable manner.
Therefore care should be exercised when specifying and using OAM tools that
require a reliable layer network to function in a predicable manner for
fault diagnosis.

Against these principles I identified these minimal set of OAM
pkt/functions:

1	A Connectivity Verification (CV) pkt.  This would contain the
absolute source address of the LSP and be sent periodically from LSP
source->sink.  This will detect all the various connectivity failures that
could exist.  This would be the workhorse OAM tool, and used for assessing
up/down-states.  It would be used in conjunction with the FDI/BDI described
below.

2	A  CV+P (P=performance) pkt.  This is the same as the above, but
also contains a count of the payload pkts/octets sent from the LSP
source->sink between consecutive CV+P pkts....to simply allow a 1st level
assessment of lost traffic.  I would *not* suggest this be used in a
continuous mode (processing cost issue) but in an ad hoc mode for
trouble-shooting.  Note that at mid-LSP points one could passively tap-off
such a CV+P flow for subnetwork partition measurements......and the absolute
LSP source address should make this easier than chasing through the varying
relative label assignments (think of doing this in large and possibly
international networks, say at some NNIs).

3	Forward and Backward Defect Indicators (FDI/BDI).  These essentially
'come on' when the CV flow 'goes off'.  CV + FDI can be used together to
diagnose whether a fault lies within an LSP span or not.......useful for
prot-sw and alarm suppression.  They can also contain details of the type of
defect and its location......so that this can aid downstream operational
people in co-operation during fault diagnosis (again very useful in
large/international environments).  FDI goes downstream and the BDI goes
upstream (to tell the source end of downstream faults).

Earlier today I sent those on the list who have expressed an interest in
drafting an OAM ID some further thoughts/analysis of how the above would
work in a nested LSP environment, based on the use of special OAM labels in
a dual-stacked manner.......since I know there is great reluctance to change
any of the current MPLS header structure to provide a specific 'OAM payload
idetifier' field.  I think maybe that the group of people who have expressed
an interest in this work should perhaps take this subject off-line now until
we have better agreements and more mature proposals to put before the rest.

Regards, Neil
 

> -----Original Message-----
> From:	Ben Mack-Crane [SMTP:Ben.Mack-Crane@tellabs.com]
> Sent:	Tuesday, June 06, 2000 3:45 PM
> To:	Indra.Widjaja@tddny.fujitsu.com; Thomas.Theimer@icn.siemens.de;
> Shahram_Davari@pmc-sierra.com; pjw@ip-engineering.bt.com
> Cc:	mpls@UU.NET
> Subject:	Re: OAM labels (was: can egress know the ingress of a
> packet?)
> 
> Hello,
> 
> I have been thinking about OAM packet identification and I
> think this evolving proposal looks promising.
> 
> There are several possible processing modes for OAM packets,
> and I am interested in your thoughts on (a) which are needed, 
> and (b) which can be supported by the current proposal.
> 
> For the sake of discussion I have given them numbers (with no
> particular significance) and included my initial thoughts.
> 
> Mode 1: 
> Packet transparently forwarded along user packet data path
> 
> This mode is needed for end-to-end OAM funcitons that depend
> on following the user packet data path exactly (e.g., delay
> measurement, as Indra mentioned, and path continuity tests).
> 
> Mode 2:
> Packet transparently forwarded along user data path and also
> passed to OAM processing (monitoring)
> 
> This mode can be easily combined with Mode 1, and is useful
> for isolating faults and monitoring subnetwork connections.
> 
> Mode 3:
> Packet forwarded to OAM processing, then forwarded along next
> hop of user packet data path (possibly not following user packet
> data path at all points within the LSR)
> 
> This mode may be useful for OAM packets that do not need to 
> follow the user data path exactly within the LSR, need more 
> flexible processing (i.e. are more suited to SW than HW 
> processing), and are not too frequent.
> 
> Mode 4:
> Packet forwarded to OAM processing and terminated
> 
> This is the common mode for termination points (LSP endpoints)
> and segment endpoints (if segment OAM is supported).  The 
> difficulty in the segment case is distinguishing which OAM
> packets to terminate and which to pass if Mode 1 or 2 OAM packets
> are also in use.  (Obviously Modes 3 and 4 can easily be combined.)
> 
> Mode 5:
> Packet forwarded to previous hop on user packet data path 
> (forwarding OAM packets following LSP upstream)
> 
> Same as Mode 1, but upstream so there is no "user packet data path"
> per se.  This might be useful for end-to-end OAM funcitons that
> require two way communication (are there any?) or funcitons
> that require rapid communicaiton upstream (e.g., fault indication for
> rapid protection switching).
> 
> Mode 6:
> Packet forwarded to previous hop on user packet data path and also
> passed to OAM processing (monitoring upstream OAM)
> 
> Same as mode 2, but upstream (do we detect a pattern here?).
> As before, easily combined with Mode 5.  Might be good for subnetwork
> connection protection switching, as long as the fault indication
> does not cause any trouble passing further upstream.
> 
> Mode 7:
> Packet forwarded to OAM processing, then forwarded to previous hop
> on user packet data path
> 
> Same as Mode 3, but upstream.  Another option for upstream OAM
> communication, possibly slower than Mode 5 or 6.
> 
> Mode 8:
> Packet forwarded to AOM processing and terminated (upstream direction)
> 
> Same as Mode 4, but upstream.
> 
> 
> Regarding OAM packet identification, it seems reasonable to use the
> user packet label on top for Modes 1 and 2 so the packet will follow
> the user data path downstream.  Mode 2 could rely on looking for a
> reserved OAM label next on the stack.  Modes 3 and 4 are easily
> supported with a reserved OAM label on top, or at the LSP endpoint
> where the user packet label is popped anyway (though it might need
> to be preserved as Peter mentioned).  However, supporting Modes 3 
> or 4 at points within the path when the user label is on top is a 
> problem (how to decide to forward only to OAM processing and not along
> user packet path -- Indra: Is this the point you were making?)
> 
> In the upstream modes, the user label is not defined for forwarding
> so perhaps this can always be done with an OAM reserved label on top.
> 
> So...  What do you think about this?  Can we identify a subset of
> modes that are necessary and sufficient, or is it simpler to define
> an OAM packet identification scheme that supports all of them and 
> let folks decide later which mode to use in a particular OAM 
> application?
> 
> Regards,
> Ben Mack-Crane
> 
> Indra.Widjaja@tddny.fujitsu.com wrote:
> > 
> > Thomas:
> > I think both end-to-end and hop-by-hop OAM packets as you mentioned
> > below should be supported.
> > A third possible way is segment OAM packets where you still want the
> > OAM packets to be treated the same way as data packets in the
> > segment connection. I believe this can be realized by using the first
> > approach plus a dedicated OAM bit. Is there a requirement for this?
> > indra
> > 
> > Theimer Thomas wrote:
> > 
> > > Actually, there are at least two ways to use such a reserved OAM
> label:
> > >
> > > - end-end OAM packets would have a label stack where the reserved
> > >   label is inserted below the original top label. After the top label
> is
> > >   popped at the egress node, the reserved label is processed by
> > >   forwarding the packet to OAM handling. Thus, all packets are
> > >   forwarded using the original top label. OAM packets are visible
> > >   only to ingress and egress nodes, and use exactly the same
> > >   path as user packets.
> > >
> > > - hop-by-hop OAM packets would have the reserved label pushed
> > >   on top of the original top label. Each LSR along the LSP would
> > >   then recognise the reserved top label, forward the packet to
> > >   OAM handling, and then forward the packet using the label
> > >   second on the label stack (the original top label).
> > >
> > > It may simplify things if two different reserved labels are defined
> > > for end-end and hop-by-hop OAM packets, if people feel that
> > > both are needed. The hop-hop case is really very similar to
> > > the router alert label.
> > >
> > > A dedicated OAM header bit would serve a similar purpose, but is
> > > not strictly required.
> > >
> > > Regards,
> > >
> > > Thomas Theimer
> > > > -----Original Message-----
> > > > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com]
> > > > Sent: Monday, June 05, 2000 5:50 PM
> > > > To:   'Peter Willis'; mpls@UU.NET
> > > > Subject:      RE: OAM labels (was: can egress know the ingress of a
> > > > packet?)
> > > >
> > > > Peter,
> > > >
> > > > But we can use two labels. The top label can be the reserved one,
> and the
> > > > second label can be the actual label, which is used for forwarding
> the OAM
> > > > packet. This is basically similar to the Router Alert Label = 1.
> > > >
> > > > Regards,
> > > > -Shahram
> > > >
> > > > >-----Original Message-----
> > > > >From: Peter Willis [mailto:pjw@ip-engineering.bt.com]
> > > > >Sent: Monday, June 05, 2000 11:37 AM
> > > > >To: mpls@UU.NET
> > > > >Subject: RE: OAM labels (was: can egress know the ingress of a
> packet?)
> > > > >
> > > > >
> > > > >
> > > > >An LSR will be terminating many LSPs so will be terminating
> > > > >many OAM flows.
> > > > >How do you correctly diagnose LSPs with merged or corrupted
> > > > >labels if they all
> > > > >arrive on the same reserved label? The label the OAM flow
> > > > >arrives on has to
> > > > >match exactly the label used for the data (user plane) flow in
> > > > >order to be able
> > > > >to detect faults caused by LSRs using broken label swapping tables.
> > > > >
> > > > >So we need a bit somewhere in the MPLS header to identify an
> > > > >OAM payload but
> > > > >we need to keep the same label as used for the user plane data.
> > > > >
> > > > >Peter.
> > > > >
> > > > >


From owner-mpls@UU.NET  Wed Jun  7 12:27:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15129
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 12:27:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQison21099;
	Wed, 7 Jun 2000 16:25:59 GMT
Received: by mail-control.mail.uu.net 
	id QQison04665
	for mpls-outgoing; Wed, 7 Jun 2000 16:25:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQison04655
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 16:25:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQison05345
	for <mpls@UU.NET>; Wed, 7 Jun 2000 12:21:55 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQison13685
	for <mpls@UU.NET>; Wed, 7 Jun 2000 16:21:55 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69LG6>; Wed, 7 Jun 2000 09:27:42 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690748@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Trini Jurado'" <t00trini@corecom.it>
Cc: mpls@UU.NET
Subject: RE: LDPs establishments
Date: Wed, 7 Jun 2000 09:27:41 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Trini,

	I assume that everywhere you say "LDP", you
mean "LSP" (Label Switched Path).

	It is generally accepted at this point that
the most common deployed MPLS implementations use
RSVP-TE signaling to support Traffic Engineering
tunnels.  Other signaling may be used for other
purposes.  For example, TDP has been used by some
network operators for quite a while.

	It is still fairly early in the deployment
of MPLS as a technology to spend too much time in
analyzing current deployment data and forming any
concrete conclusions.  You might try asking this
question of service providers - off-line - if you
are still interested in gathering more details.

--
Eric Gray

> -----Original Message-----
> From: Trini Jurado [mailto:t00trini@corecom.it]
> Sent: Wednesday, June 07, 2000 8:20 AM
> To: mpls@UU.NET
> Subject: LDPs establishments
> 
> 
> Which is the most common implementation of MPLS from the 
> point of view of
> the way in which LDPs are established?
> 
> In the case of establishing an LDP every time a new RSVP 
> session is opened,
> is it possible to do LDP nesting?
> 
> Thank you for your replies.
> 
> 
> 
> 


From owner-mpls@UU.NET  Wed Jun  7 12:33:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15376
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 12:33:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQison19578;
	Wed, 7 Jun 2000 16:29:29 GMT
Received: by mail-control.mail.uu.net 
	id QQison04917
	for mpls-outgoing; Wed, 7 Jun 2000 16:29:09 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQison04908
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 16:29:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQison06518
	for <mpls@UU.NET>; Wed, 7 Jun 2000 12:27:59 -0400 (EDT)
Received: from ucayali.unired.net.pe by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ucayali.unired.net.pe [206.138.105.38])
	id QQison22839
	for <mpls@UU.NET>; Wed, 7 Jun 2000 16:27:56 GMT
Received: from telefonica.com.pe ([200.37.84.140])
	by ucayali.unired.net.pe (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id e576SC406185
	for <mpls@UU.NET>; Wed, 7 Jun 2000 11:28:12 +0500 (GMT)
Message-ID: <393E7832.3C813C17@telefonica.com.pe>
Date: Wed, 07 Jun 2000 11:28:34 -0500
From: Jesus Rodriguez Stuart <jrstuart@telefonica.com.pe>
Reply-To: jrstuart@telefonica.com.pe
Organization: Telefonica del Peru
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: LSP TUNNELS for IP-VPN
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sirs

Let me ask you:

In BGP/MPLS VPN context, If we want to define exclusive LSPs for 1 VPN ,
(Best effort, premium, gold LSPs).... how can I do?

Thanks in advance

JRSTUART

--
Jesus Rodriguez Stuart

Jefe Desarrollo de Soluciones
Telefonica del Peru
Comunicaciones de Empresa
jrstuart@telefonica.com.pe

Tfno: 210-4835
Fax : 422-0591




From owner-mpls@UU.NET  Wed Jun  7 13:27:09 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16586
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 13:27:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisor07759;
	Wed, 7 Jun 2000 17:25:43 GMT
Received: by mail-control.mail.uu.net 
	id QQisor18891
	for mpls-outgoing; Wed, 7 Jun 2000 17:25:09 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisor18869
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:24:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisor17654
	for <mpls@uu.net>; Wed, 7 Jun 2000 13:24:26 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisor28307
	for <mpls@uu.net>; Wed, 7 Jun 2000 17:24:25 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA23777
	for mpls@uu.net; Wed, 7 Jun 2000 13:24:24 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisor18791
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:24:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisor17509
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:23:40 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisor06321
	for <mpls@UU.NET>; Wed, 7 Jun 2000 17:23:39 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA17574;
	Wed, 7 Jun 2000 10:22:26 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MC3W2>; Wed, 7 Jun 2000 10:22:27 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405E0@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'jrstuart@telefonica.com.pe'" <jrstuart@telefonica.com.pe>, mpls@UU.NET
Subject: RE: LSP TUNNELS for IP-VPN
Date: Wed, 7 Jun 2000 10:19:32 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

You may use Diffserv and encode your PHBs in the EXP field of the top label
entry, or you may signal your required PHB. We will be releasing the
draft-ietf-mpls-diff-ext-05.txt tomorrow which has the BGP/MPLS VPN as an
example in MPLS support of diffserv.

Regards,
-Shahram 

>-----Original Message-----
>From: Jesus Rodriguez Stuart [mailto:jrstuart@telefonica.com.pe]
>Sent: Wednesday, June 07, 2000 12:29 PM
>To: mpls@UU.NET
>Subject: LSP TUNNELS for IP-VPN
>
>
>Sirs
>
>Let me ask you:
>
>In BGP/MPLS VPN context, If we want to define exclusive LSPs 
>for 1 VPN ,
>(Best effort, premium, gold LSPs).... how can I do?
>
>Thanks in advance
>
>JRSTUART
>
>--
>Jesus Rodriguez Stuart
>
>Jefe Desarrollo de Soluciones
>Telefonica del Peru
>Comunicaciones de Empresa
>jrstuart@telefonica.com.pe
>
>Tfno: 210-4835
>Fax : 422-0591
>
>



From owner-mpls@UU.NET  Wed Jun  7 13:37:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16836
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 13:37:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisos16422;
	Wed, 7 Jun 2000 17:36:02 GMT
Received: by mail-control.mail.uu.net 
	id QQisos19891
	for mpls-outgoing; Wed, 7 Jun 2000 17:35:31 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisos19885
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:35:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisos19650
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:35:06 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQisos14957
	for <mpls@UU.NET>; Wed, 7 Jun 2000 17:35:06 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69LNF>; Wed, 7 Jun 2000 10:40:55 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269074B@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'neetug@daewoo.dti.daewoo.co.kr'" <neetug@daewoo.dti.daewoo.co.kr>,
        "'MPLS mailing list'" <mpls@UU.NET>
Subject: RE: Applications running on RSVP Aware Host End
Date: Wed, 7 Jun 2000 10:40:45 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Neetu,

	The mapping from DS byte to PHB is domain
specific.  A service provider may work out an SLA
with a specific customer to map DS byte values in
packets received from that customer to a service
level to be provided for those packets.  Service
providers may - in turn - use DS byte values to
support those services, which means that the SP
will define a mapping from DS byte value received
to DS byte value used within the SP domain.  If
the SP does not tunnel the IP packets in providing
a service using this approach, the SP will likely
need to perform a reverse mapping for packets as
they leave the SP domain.

	Note that SP customers frequently include 
at least one other SP.  Therefore, this sort of
mapping is very likely to be needed.  But even if 
this sort of SLA is worked out with an enterprise
customer, the chances are very good that the value
that is plugged into the DS byte for packets that
are sent to the SP will be assigned under direct
control of the network services provider within 
the enterprise.  It is possible that a specific
enterprise may do this by allowing end stations
to pick their own DS byte values, depending on
how important each individual thinks their own
work is.  But then again, maybe not. :-)

--
Eric Gray

> -----Original Message-----
> From: Neetu Gupta [mailto:neetug@daewoo.dti.daewoo.co.kr]
> Sent: Wednesday, June 07, 2000 1:52 AM
> To: mpls
> Subject: Re: Applications running on RSVP Aware Host End
> 
> 
> Eric,
>     Does that mean the Customer will not set TOS byte in the 
> data packet?
> 
> Then when the data packets are coming at the ingress point of the MPLS
> Domain, how will it be known, to which Diff Serv LSP, the 
> packet has to be
> sent, since DSCP value is not set in the header.
> 
> Then, who will set the DSCP value?
> 
> 
> Eric Gray wrote:
> 
> > Neetu,
> >
> >         Considering the primary application du jour
> > for MPLS is traffic engineering, only network
> > elements would determine the treatment of host
> > packets in the network.  This could - for example
> > - be the result of a service level agreement or
> > a network domain local decision.
> >
> >         In general, it would be nice if the network
> > operators could rely on hosts to properly set bits
> > in the IP header according to how the packets will
> > be treated in competition with other packets in a
> > network.  But this is unlikely since "cheaters"
> > prosper only too well.
> >
> > --
> > Eric Gray
> 
> 
> 


From owner-mpls@UU.NET  Wed Jun  7 13:41:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16920
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 13:41:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisos09278;
	Wed, 7 Jun 2000 17:40:25 GMT
Received: by mail-control.mail.uu.net 
	id QQisos20207
	for mpls-outgoing; Wed, 7 Jun 2000 17:40:07 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisos20192
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:39:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisos20415
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:39:31 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQisos08474
	for <mpls@UU.NET>; Wed, 7 Jun 2000 17:39:31 GMT
Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP;
          Wed, 7 Jun 2000 18:39:26 +0100
Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2651.88) 
          id <MCGW02SP>; Wed, 7 Jun 2000 18:39:18 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16043@mbddmknt01.hc.bt.com>
To: mpls@UU.NET
Subject: FW:
         [Fwd: OAM functionality (Was: RE: can egress know the ingress of a  packet?)]
Date: Wed, 7 Jun 2000 18:39:15 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Major apologies to sending this to list......but I got this mail from
someone called 'Calin' but no return mail address.  So can that person who
sent me this please contact me directly (neil.2.harrison@bt.com) and I'll
try and answer your question.

Regards and apologies to all again, Neil

> -----Original Message-----
> From:	 
> Sent:	Tuesday, June 06, 2000 1:43 PM
> To:	neil.2.harrison@bt.com
> Subject:	[Fwd: OAM functionality (Was: RE: can egress know the
> ingress of a  packet?)]
> 
> 
> 
> Hello Neil!
> 
> > Its a very complex story and I don't want to
> > waste people's time by going through its history here (speak to me
> privately
> > if you want the details).....
> SNIPPED
> 
> And again: could you put me in Cc:?
> 
> 
> Thank you very much!
> 
> Best regards!
> 
> Calin
> 


From owner-mpls@UU.NET  Wed Jun  7 13:52:46 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17126
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 13:52:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisot17231;
	Wed, 7 Jun 2000 17:51:23 GMT
Received: by mail-control.mail.uu.net 
	id QQisot21034
	for mpls-outgoing; Wed, 7 Jun 2000 17:51:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisot21000
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:50:50 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisot22643
	for <mpls@uu.net>; Wed, 7 Jun 2000 13:50:34 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisot16366
	for <mpls@uu.net>; Wed, 7 Jun 2000 17:50:33 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA29688
	for mpls@uu.net; Wed, 7 Jun 2000 13:50:32 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisot20966
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:50:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisot22382
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:49:26 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisot15397
	for <mpls@UU.NET>; Wed, 7 Jun 2000 17:49:24 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA19299;
	Wed, 7 Jun 2000 10:46:08 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MCPCS>; Wed, 7 Jun 2000 10:46:08 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405E1@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Indra.Widjaja'" <Indra.Widjaja@tddny.fujitsu.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        "'Ross Callon'"
	 <rcallon@juniper.net>, mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 10:43:14 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Indra,

There is no problem in sending the packet to OAM processor. The problem is
when the packet is received by OAM processor, because the forwarding label
is not present any more, how can the OAM processor determine which LSP this
OAM packet belonged to. Because the processing of the OAM packet will depend
on identifying the LSP. 

-Shahram 

>-----Original Message-----
>From: Indra.Widjaja [mailto:Indra.Widjaja@tddny.fujitsu.com]
>Sent: Wednesday, June 07, 2000 1:41 PM
>To: Shahram Davari
>Cc: 'Theimer Thomas'; 'Ross Callon'; mpls@UU.NET
>Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
>
>
>Shahram:
>I still don't understand what the problem really is.
>The penultimate LSR forwards the packet to the egress LSR
>based on the user data label that was just popped out.
>When the packet with the OAM label arrives at the egress
>LSR, the egress LSR should be able to direct the OAM
>packet to the proper OAM handler.
>Does this work?
>indra
>
>
>Shahram Davari wrote:
>
>> Theimer,
>>
>> I think what Ross meant was that using PHP, when OAM label 
>is below the
>> forwarding label, the egress node can't determine the LSP 
>that the OAM
>> packet belongs to.
>>
>> Regards,
>> -Shahram
>>
>> >-----Original Message-----
>> >From: Theimer Thomas [mailto:Thomas.Theimer@icn.siemens.de]
>> >Sent: Wednesday, June 07, 2000 5:10 AM
>> >To: 'Ross Callon'
>> >Cc: mpls@UU.NET
>> >Subject: RE: OAM labels (was: can egress know the ingress 
>of a packet?)
>> >
>> >
>> >> -----Original Message-----
>> >> From:        Ross Callon [SMTP:rcallon@juniper.net]
>> >> To:  Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
>> >>
>> >> If the outer label identifies the LSP, and the inner label is a
>> >> special OAM value, then I think that there is a problem with
>> >> penultimate hop label popping.
>> >       [Theimer Thomas]  Good point. We missed that. However, if the
>> >penultimate hop removes the top label, the egress node will 
>receive the
>> >packet with an OAM label on top. That would still trigger OAM
>> >processing in
>> >the egress node, so I don't necessarily see a problem here, 
>except that
>> >perhaps the egress node needs to be an LSR. If not, then in 
>my view the
>> >penultimate hop is really the logical endpoint of the LSP, 
>and should
>> >process the OAM label if present. However, I must admit I 
>don't clearly
>> >understand how penultimate hop popping is really applied in a
>> >network. I
>> >also could not find any explicit support in LDP, CR-LDP and
>> >TE-RSVP. Without
>> >such support, is anyone actually using that mechanism in practice ?
>> >
>> >       Thomas
>> >
>> >
>



From owner-mpls@UU.NET  Wed Jun  7 13:53:05 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17151
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 13:53:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisot16512;
	Wed, 7 Jun 2000 17:50:41 GMT
Received: by mail-control.mail.uu.net 
	id QQisot20967
	for mpls-outgoing; Wed, 7 Jun 2000 17:50:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisot20949
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:49:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisot28014
	for <mpls@uu.net>; Wed, 7 Jun 2000 13:49:38 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisot26522
	for <mpls@uu.net>; Wed, 7 Jun 2000 17:49:37 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA29504
	for mpls@uu.net; Wed, 7 Jun 2000 13:49:36 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisot20915
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:48:53 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisot27864
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:48:41 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQisot14875
	for <mpls@UU.NET>; Wed, 7 Jun 2000 17:48:40 GMT
Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id MAA11079; Wed, 7 Jun 2000 12:40:54 -0500 (CDT)
Received: from tddny.fujitsu.com (pc185.tddny.fujitsu.com [167.254.242.185]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id M1SH4YFT; Wed, 7 Jun 2000 12:40:56 -0500
Message-ID: <393E891E.512022E6@tddny.fujitsu.com>
Date: Wed, 07 Jun 2000 13:40:46 -0400
From: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        "'Ross Callon'" <rcallon@juniper.net>, mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <336ECDAFDF7DD311B9E30090277AEE4101B405DC@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shahram:
I still don't understand what the problem really is.
The penultimate LSR forwards the packet to the egress LSR
based on the user data label that was just popped out.
When the packet with the OAM label arrives at the egress
LSR, the egress LSR should be able to direct the OAM
packet to the proper OAM handler.
Does this work?
indra


Shahram Davari wrote:

> Theimer,
>
> I think what Ross meant was that using PHP, when OAM label is below the
> forwarding label, the egress node can't determine the LSP that the OAM
> packet belongs to.
>
> Regards,
> -Shahram
>
> >-----Original Message-----
> >From: Theimer Thomas [mailto:Thomas.Theimer@icn.siemens.de]
> >Sent: Wednesday, June 07, 2000 5:10 AM
> >To: 'Ross Callon'
> >Cc: mpls@UU.NET
> >Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
> >
> >
> >> -----Original Message-----
> >> From:        Ross Callon [SMTP:rcallon@juniper.net]
> >> To:  Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
> >>
> >> If the outer label identifies the LSP, and the inner label is a
> >> special OAM value, then I think that there is a problem with
> >> penultimate hop label popping.
> >       [Theimer Thomas]  Good point. We missed that. However, if the
> >penultimate hop removes the top label, the egress node will receive the
> >packet with an OAM label on top. That would still trigger OAM
> >processing in
> >the egress node, so I don't necessarily see a problem here, except that
> >perhaps the egress node needs to be an LSR. If not, then in my view the
> >penultimate hop is really the logical endpoint of the LSP, and should
> >process the OAM label if present. However, I must admit I don't clearly
> >understand how penultimate hop popping is really applied in a
> >network. I
> >also could not find any explicit support in LDP, CR-LDP and
> >TE-RSVP. Without
> >such support, is anyone actually using that mechanism in practice ?
> >
> >       Thomas
> >
> >




From owner-mpls@UU.NET  Wed Jun  7 14:16:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17539
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 14:16:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisov16311;
	Wed, 7 Jun 2000 18:15:29 GMT
Received: by mail-control.mail.uu.net 
	id QQisov01945
	for mpls-outgoing; Wed, 7 Jun 2000 18:15:03 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisov01833
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 18:15:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisou03344
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:14:37 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQisou15582
	for <mpls@UU.NET>; Wed, 7 Jun 2000 18:14:37 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id NAA09642;
	Wed, 7 Jun 2000 13:14:30 -0500
Message-ID: <20000607131429.C9353@doit.wisc.edu>
Date: Wed, 7 Jun 2000 13:14:29 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: Bob Thomas <rhthomas@cisco.com>
Cc: mpls@UU.NET
Subject: Re: Address Message in LDP
Reply-To: jleu@mindspring.com
References: <20000607095151.A9353@doit.wisc.edu> <200006071533.LAA16375@rhthomas-sun2.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <200006071533.LAA16375@rhthomas-sun2.cisco.com>; from Bob Thomas on Wed, Jun 07, 2000 at 11:33:26AM -0400
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Jun 07, 2000 at 11:33:26AM -0400, Bob Thomas wrote:

<snip>

> I think you are making this more complicated that it need be.
>
> The purpose of the Address Message is to make it possible for an LSR
> to establish a mapping between the first 4 octets of a peer's LDP Id
> and addresses bound to the peer.
> 
> This mapping is useful in determining whether the peer is the next
> hop for a particular prefix.

I understand your second statement (the first about me making it more
complicated then it need be is always true :-).  With respect to the third
statement, are you saying that this mapping is or is not the ONLY way to
figure out if a peer is the next hop for a particular prefix?

My goal is to get an answer about "non-Directly Connected LSRs" and
how they guarantee that they are distributing labels and installing them
on the correct interfaces.

The way to get the above answer may involve or mimic the way we deal with
mappings over parallel links between two directly connected LDP peers.

If I have LDP sessions over parallel links and a particular prefix is
preferred over only one link, the peer closer to egress may provide mappings for
this prefix via both sessions.  If I use the address list as my definitive
source for which session is the next hop, both sessions will match.

What other information do we use in this case to decide whether or not
a particular session is ACTUALLY the next hop for a particular prefix?

Jim
-- 
James R. Leu


From owner-mpls@UU.NET  Wed Jun  7 14:21:07 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17609
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 14:21:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisov07954;
	Wed, 7 Jun 2000 18:19:56 GMT
Received: by mail-control.mail.uu.net 
	id QQisov02323
	for mpls-outgoing; Wed, 7 Jun 2000 18:19:33 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisov02318
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 18:19:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisov28505
	for <mpls@uu.net>; Wed, 7 Jun 2000 14:19:09 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisov19162
	for <mpls@uu.net>; Wed, 7 Jun 2000 18:19:08 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA06100
	for mpls@uu.net; Wed, 7 Jun 2000 14:19:08 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisov02290
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 18:18:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisov28395
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:18:38 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQisov18804
	for <mpls@UU.NET>; Wed, 7 Jun 2000 18:18:36 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA21357;
	Wed, 7 Jun 2000 11:18:23 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MCPS8>; Wed, 7 Jun 2000 11:18:23 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405E3@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'jleu@mindspring.com'" <jleu@mindspring.com>,
        Bob Thomas
	 <rhthomas@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Address Message in LDP
Date: Wed, 7 Jun 2000 11:15:28 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

James,

For non-directly connected LSRs, per-platform label space should be used.

-Shahram

>-----Original Message-----
>From: James R. Leu [mailto:jleu@mindspring.com]
>Sent: Wednesday, June 07, 2000 2:14 PM
>To: Bob Thomas
>Cc: mpls@UU.NET
>Subject: Re: Address Message in LDP
>
>
>On Wed, Jun 07, 2000 at 11:33:26AM -0400, Bob Thomas wrote:
>
><snip>
>
>> I think you are making this more complicated that it need be.
>>
>> The purpose of the Address Message is to make it possible for an LSR
>> to establish a mapping between the first 4 octets of a peer's LDP Id
>> and addresses bound to the peer.
>> 
>> This mapping is useful in determining whether the peer is the next
>> hop for a particular prefix.
>
>I understand your second statement (the first about me making it more
>complicated then it need be is always true :-).  With respect 
>to the third
>statement, are you saying that this mapping is or is not the 
>ONLY way to
>figure out if a peer is the next hop for a particular prefix?
>
>My goal is to get an answer about "non-Directly Connected LSRs" and
>how they guarantee that they are distributing labels and 
>installing them
>on the correct interfaces.
>
>The way to get the above answer may involve or mimic the way 
>we deal with
>mappings over parallel links between two directly connected LDP peers.
>
>If I have LDP sessions over parallel links and a particular prefix is
>preferred over only one link, the peer closer to egress may 
>provide mappings for
>this prefix via both sessions.  If I use the address list as 
>my definitive
>source for which session is the next hop, both sessions will match.
>
>What other information do we use in this case to decide whether or not
>a particular session is ACTUALLY the next hop for a particular prefix?
>
>Jim
>-- 
>James R. Leu
>



From owner-mpls@UU.NET  Wed Jun  7 14:27:32 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17693
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 14:27:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisov24252;
	Wed, 7 Jun 2000 18:26:16 GMT
Received: by mail-control.mail.uu.net 
	id QQisov02707
	for mpls-outgoing; Wed, 7 Jun 2000 18:25:53 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisov02702
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 18:25:46 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisov05605
	for <mpls@uu.net>; Wed, 7 Jun 2000 14:25:33 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisov12139
	for <mpls@uu.net>; Wed, 7 Jun 2000 18:25:32 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA07620
	for mpls@uu.net; Wed, 7 Jun 2000 14:25:31 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisov02673
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 18:25:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisov05456
	for <mpls@uu.net>; Wed, 7 Jun 2000 14:24:50 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQisov23154
	for <mpls@uu.net>; Wed, 7 Jun 2000 18:24:49 GMT
Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA04489 for <mpls@uu.net>; Wed, 7 Jun 2000 14:24:48 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA21104 for <mpls@uu.net>; Wed, 7 Jun 2000 14:24:48 -0400 (EDT)
Message-Id: <200006071824.OAA21104@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Last Call for LDP
Date: Wed, 07 Jun 2000 14:24:48 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message signals the begining of a last call on LDP.  This last
call is limited to the changes made in draft -07 to address the issues
raised in the previous last call.

The last call ends at 12 pm GMT Wednesday 6/14.

...George

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






From owner-mpls@UU.NET  Wed Jun  7 15:00:02 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18295
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 15:00:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisox16461;
	Wed, 7 Jun 2000 18:58:14 GMT
Received: by mail-control.mail.uu.net 
	id QQisox04772
	for mpls-outgoing; Wed, 7 Jun 2000 18:57:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisox04741
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 18:57:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisox11442
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:56:59 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQisox03856
	for <mpls@UU.NET>; Wed, 7 Jun 2000 18:56:58 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id OAA14217; Wed, 7 Jun 2000 14:56:55 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id OAA16572;
	Wed, 7 Jun 2000 14:57:16 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006071857.OAA16572@curtis-lt.avici.com>
To: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
cc: curtis@avici.com, neil.2.harrison@bt.com, otel@ce.chalmers.se,
        Shahram_Davari@pmc-sierra.com, EGray@zaffire.com, swtan@mmu.edu.my,
        kireeti@juniper.net, dwilder@baynetworks.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-reply-to: Your message of "Wed, 07 Jun 2000 08:55:55 CDT."
             <393E546B.FF0400D5@tellabs.com> 
Date: Wed, 07 Jun 2000 14:57:16 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <393E546B.FF0400D5@tellabs.com>, Ben Mack-Crane writes:
> Hello Curtis,
> 
> Perhaps I'm sporting more ignorance in this matter.  I had not
> considered ping as a path continuity test.  The idea is to have
> a test at the MPLS layer (OK ping is a bit above that...maybe 
> not a problem) that would follow the data path (even through
> LSRs) so it can detect disconnected and misconnected LSPs.
> 
> If the LSP egress expected ping's regularly from the ingress,
> lack of pings would detect a broken connection.  If the ping 
> contains data that identifies the ingress and path (path trace 
> info), some (all?) misconnections can be detected.  (Is adding
> specific data to a ping OK, or is this frowned upon?)

IP ping can use the IP record route IP option.  On a BSD system this
is done using "ping -R".  There is no corresponding MPLS RR option.

Without -R, ping is a continuity test only, though it does rely on
having a return path so it tests 2 way continuity.

traceroute uses a limited TTL and detects the TTL expired ICMP
response.  traceroute also requires a return path.

draft-ietf-mpls-icmp-01.txt extends the ICMP processing to allow
traceroute to list LSRs.  I thought I remembered a recommendation to
send the ICMP packet through the tunnel for an unreachable destination
in order to support VPNs, but I didn't see that in the draft.  In a
broken VPN LSP, the packets will never be able to complete the round
trip.  If a VPN LSP must travel inside an upper VPN, then the upper
LSP can be tested to find a fault (since a return address exists for
the ingress) but the lower VPN LSP cannot if the IP source address is
not reachable in the global routing table.  The lower LSP only has one
LSR looking at the label (the egress looks at the lower label after
the top label is popped, no other LSR looks at it) so this is not a
serious limitation.

> The remaining question is how to detect the location of the
> dis-or-misconnection.  If intermediate LSRs can monitor this path
> trace ping, that would help.  So here we're back to the question
> of how to identify OAM packets in transit...  I don't know of
> an existing mechanism for this.  (Router alert doesn't seem to 
> fit the bill since, I assume, router alert packets follow
> a different data path through an LSR from user packets and thus 
> will not reflect all possible connection faults.)
> 
> In any case, I agree ping is worth considering.

There is no real need for the intermediate to monitor.  What is needed
is a means to test connectivity and a means to determine the location
of a fault.  Ping and traceroute offer this.

> I'm not trying to reinvent the wheel -- just trying to figure
> out how to make the cart roll straight with all the varied wheels
> we have to work with...
> 
> Regards,
> Ben

A strength and down side of ping and traceroute have always been their
bidirectional nature.  It is a strength in that any host can run ping
and traceroute and minimal coordination is required (IP routers or LSR
need only correctly generate ICMP).  Some of the downsides are:

  1.  Round trip times are reported rather than one way delay.
  2.  There is no way to record route for MPLS on ping (but traceroute
      still works).
  3.  It is not always obvious whether a problem resides in the
      forward or the reverse path when a ping or traceroute fails.

The approach of sending MPLS OAM packets also has its down sides.  For
example, one potential LSP failure is in the mapping of an FEC to the
first LSP insegment at the ingress.  If this fails and the OAM packets
are injected into the LSP through some other means, this failure will
not be detected.  Passing an IP packet (ping echo request or
traceroute udp packet) from an external interface with exercise this
and detect the failure.  The same applies to failures involving the
outsegment at the egress.  To make matters worse, failures can occur
that involve only one particular ingress interface.

Curtis



From owner-mpls@UU.NET  Wed Jun  7 15:01:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18380
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 15:01:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisox05799;
	Wed, 7 Jun 2000 18:59:46 GMT
Received: by mail-control.mail.uu.net 
	id QQisox04839
	for mpls-outgoing; Wed, 7 Jun 2000 18:59:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisox04830
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 18:59:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisox11781
	for <mpls@uu.net>; Wed, 7 Jun 2000 14:58:46 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisox16955
	for <mpls@uu.net>; Wed, 7 Jun 2000 18:58:46 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA14026
	for mpls@uu.net; Wed, 7 Jun 2000 14:58:45 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisox04792
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 18:58:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisox05312
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:56:55 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQisox15397
	for <mpls@UU.NET>; Wed, 7 Jun 2000 18:56:54 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA21788;
	Wed, 7 Jun 2000 11:56:46 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <MLZ2G5JX>; Wed, 7 Jun 2000 11:56:47 -0700
Message-ID: <E097FDA4F2FED311994000104B31A86115E694@MONTEREY>
From: Bora Akyol <akyol@pluris.com>
To: "'Yakov Rekhter'" <yakov@cisco.com>
Cc: mpls@UU.NET
Subject: RE: MPLS Performance analysis..... 
Date: Wed, 7 Jun 2000 11:56:46 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,

It is a well known fact at this point we can make IP lookups as fast we can
do MPLS lookups.

So the lookup speed advantage of MPLS does not exist anymore which I believe
was the point that was being raised.

Bora (just catching up with my old mail)


> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@cisco.com]
> Sent: Monday, May 29, 2000 4:14 AM
> To: smd@ebone.net
> Cc: mpls@UU.NET
> Subject: Re: MPLS Performance analysis..... 
> 
> 
> Sean,
>  
> > Several people write:
> > 
> > > [lots of commentary about how wonderful MPLS is at making 
> forwarding fast]
> > 
> > You are analysing the performance of MPLS using the wrong metric.
> > I think MPLS performs exactly as intended.
> > Ipsilon basically died, and not even Nokia could revive it.
> > UUNET found a new layer-2 religion, essentially killing 
> backbone ATM.
> > Many companies are distracted from actually learning how to 
> do IP routing.
> 
> Of course, for some folks the *one and only* way to move data is by
> looking at the IP header, and executing the longest match algorithm on
> the destination address in that header (aka "destination based
> routing"). Anything else (e.g., MPLS), *regardless* of its pragmatic
> value, is viewed as "religion", "distraction", etc... 
> 
> Yakov.
> 



From owner-mpls@UU.NET  Wed Jun  7 15:15:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18616
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 15:15:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoq21257;
	Wed, 7 Jun 2000 17:04:25 GMT
Received: by mail-control.mail.uu.net 
	id QQisoq16257
	for mpls-outgoing; Wed, 7 Jun 2000 17:04:09 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisoq16219
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 17:03:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisoq19161
	for <mpls@UU.NET>; Wed, 7 Jun 2000 13:03:32 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQisoq13942
	for <mpls@UU.NET>; Wed, 7 Jun 2000 17:03:31 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69LKS>; Wed, 7 Jun 2000 10:09:24 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269074A@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'jrstuart@telefonica.com.pe'" <jrstuart@telefonica.com.pe>
Cc: mpls@UU.NET
Subject: RE: LSP TUNNELS for IP-VPN
Date: Wed, 7 Jun 2000 10:09:18 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Jesus,

	First of all, if you are not using some
extensions to BGP beyond those currently being
defined, you would use any other LSP signaling 
protocol able to signal the treatment you want 
to establish the LSP between BGP peers.  If 
you have the treatment you want across the 
logical link between BGP peers, it is a local
implementation matter as to how each BGP peer
provides corresponding queuing behavior.  It
is very likely that the BGP peers will be the
configuration points for your VPN SLA in any
case.

--
Eric Gray

> -----Original Message-----
> From: Jesus Rodriguez Stuart [mailto:jrstuart@telefonica.com.pe]
> Sent: Wednesday, June 07, 2000 9:29 AM
> To: mpls@UU.NET
> Subject: LSP TUNNELS for IP-VPN
> 
> 
> Sirs
> 
> Let me ask you:
> 
> In BGP/MPLS VPN context, If we want to define exclusive LSPs 
> for 1 VPN ,
> (Best effort, premium, gold LSPs).... how can I do?
> 
> Thanks in advance
> 
> JRSTUART
> 
> --
> Jesus Rodriguez Stuart
> 
> Jefe Desarrollo de Soluciones
> Telefonica del Peru
> Comunicaciones de Empresa
> jrstuart@telefonica.com.pe
> 
> Tfno: 210-4835
> Fax : 422-0591
> 
> 


From owner-mpls@UU.NET  Wed Jun  7 15:33:47 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18962
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 15:33:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisoz24479;
	Wed, 7 Jun 2000 19:26:20 GMT
Received: by mail-control.mail.uu.net 
	id QQisoz16990
	for mpls-outgoing; Wed, 7 Jun 2000 19:25:56 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisoz16968
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 19:25:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisoz16926
	for <mpls@UU.NET>; Wed, 7 Jun 2000 15:25:05 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQisoz05469
	for <mpls@UU.NET>; Wed, 7 Jun 2000 19:25:05 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69LW8>; Wed, 7 Jun 2000 12:30:57 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690753@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'jleu@mindspring.com'" <jleu@mindspring.com>,
        Bob Thomas
	 <rhthomas@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Address Message in LDP
Date: Wed, 7 Jun 2000 12:30:54 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Jim,

> -----Original Message-----
> From: James R. Leu [mailto:jleu@mindspring.com]
> Sent: Wednesday, June 07, 2000 11:14 AM
> To: Bob Thomas
> Cc: mpls@UU.NET
> Subject: Re: Address Message in LDP
> 
> 
> On Wed, Jun 07, 2000 at 11:33:26AM -0400, Bob Thomas wrote:
> 
> <snip>
> 

... <more snip> ...

> > 
> > This mapping is useful in determining whether the peer is the next
> > hop for a particular prefix.
> 

... <and more snip> ...

> With respect to the third statement, are you saying 
> that this mapping is or is not the ONLY way to figure 
> out if a peer is the next hop for a particular prefix?

Of course it is not the only way.  For one thing,
it is possible to configure this information.

(Bob does not have my warped sense of humor - if 
he meant "required" he would not have said "useful")

> 
> My goal is to get an answer about "non-Directly Connected 
> LSRs" and how they guarantee that they are distributing 
> labels and installing them on the correct interfaces.
> 
> The way to get the above answer may involve or mimic the way 
> we deal with mappings over parallel links between two 
> directly connected LDP peers.

There are numerous issues with this.  One of them is
the assumption of multiple parallel links between two
LDP peers - which necessarily implies the use of the
platform wide label space (as Shahram points out).

A second issue is that there is an element of risk if 
you stack a label provided by an indirectly connected 
LSR peer and you are not able to detect when the LSP 
over which you will forward the label-stacked packets 
is not a continuous LSP.  This implies that you should
signal the LSP between the two indirectly connected 
LSR peers using some approach that will A) not allow
the LSP to be established except as a continuous LSP
and B) indicate to the LSR establishing the LSP when
the LSP is broken.

A third issue is - if the label is platform wide - 
how do you prevent this label from being misused?

I'm sure there are other issues as well.

> 
> ...
>
> What other information do we use in this case to decide 
> whether or not a particular session is ACTUALLY the next 
> hop for a particular prefix?

I sense that this is an area in which many people
are still confused.

I think it will clear things up a little if it is
understood that the Address and Address Withdraw
messages would not be as useful if it were possible
to use the IGP to piggy-back labels.  But, then, we
would not be defining LDP as stand-alone signaling
protocol (or at least not for the same reasons).

Because LDP label distributions are not carried in
the routing advertisements to which they might be
said to apply, we need some way to associate labels
and route advertisements.  Since a next hop address
given in a route advertisement may not be the same
as the address that we know the associated LDP peer
by, we can benefit from use of Address and Address
Withdraw messages.  These messages allow us to know
what next hop address(es) might appear in route
advertisements that apply to an LSR peer and the
labels it distributes.

Does this help?

> 
> Jim
> -- 
> James R. Leu
> 


From owner-mpls@UU.NET  Wed Jun  7 15:45:36 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19192
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 15:45:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispa17617;
	Wed, 7 Jun 2000 19:42:07 GMT
Received: by mail-control.mail.uu.net 
	id QQispa18072
	for mpls-outgoing; Wed, 7 Jun 2000 19:41:46 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispa18067
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 19:41:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispa19859
	for <mpls@uu.net>; Wed, 7 Jun 2000 15:41:11 -0400 (EDT)
Received: from fcs-nt1.futsoft.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fcs-nt1.futsoft.com [38.242.189.2])
	id QQispa16775
	for <mpls@uu.net>; Wed, 7 Jun 2000 19:41:10 GMT
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000058999@fcs-nt1.futsoft.com>;
 Wed, 07 Jun 2000 12:28:18 -0700
Received: from rajeshs ([38.242.189.59])
	by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id LAA19089;
	Wed, 7 Jun 2000 11:36:10 -0700
Received: by localhost with Microsoft MAPI; Wed, 7 Jun 2000 12:54:50 -0700
Message-Id: <01BFD07F.916FA3E0.rajeshs@futsoft.com>
From: Rajesh Kumar <rajeshs@futsoft.com>
Reply-To: "rajeshs@futsoft.com" <rajeshs@futsoft.com>
To: "'Bora Akyol'" <akyol@pluris.com>
Cc: "mpls@uu.net" <mpls@UU.NET>, "'Yakov Rekhter'" <yakov@cisco.com>
Subject: RE: MPLS Performance analysis..... 
Date: Wed, 7 Jun 2000 12:54:49 -0700
Organization: Future Communications Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

"It is a well known fact at this point we can make IP lookups as fast we 
can do MPLS lookups"

"can" is right. But the complexity of implementing a longest-prefix-match 
in hardware (or using a cam) is definitely more than a table index lookup 
(like mpls allows). And more expensive too.

If your car could get you there as quickly, do you need to build a 
spaceship!!!!

-----Original Message-----
From:	Bora Akyol [SMTP:akyol@pluris.com]
Sent:	Wednesday, June 07, 2000 11:57 AM
To:	'Yakov Rekhter'
Cc:	mpls@uu.net
Subject:	RE: MPLS Performance analysis.....

Yakov,

It is a well known fact at this point we can make IP lookups as fast we can
do MPLS lookups.

So the lookup speed advantage of MPLS does not exist anymore which I 
believe
was the point that was being raised.

Bora (just catching up with my old mail)


> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@cisco.com]
> Sent: Monday, May 29, 2000 4:14 AM
> To: smd@ebone.net
> Cc: mpls@UU.NET
> Subject: Re: MPLS Performance analysis.....
>
>
> Sean,
>
> > Several people write:
> >
> > > [lots of commentary about how wonderful MPLS is at making
> forwarding fast]
> >
> > You are analysing the performance of MPLS using the wrong metric.
> > I think MPLS performs exactly as intended.
> > Ipsilon basically died, and not even Nokia could revive it.
> > UUNET found a new layer-2 religion, essentially killing
> backbone ATM.
> > Many companies are distracted from actually learning how to
> do IP routing.
>
> Of course, for some folks the *one and only* way to move data is by
> looking at the IP header, and executing the longest match algorithm on
> the destination address in that header (aka "destination based
> routing"). Anything else (e.g., MPLS), *regardless* of its pragmatic
> value, is viewed as "religion", "distraction", etc...
>
> Yakov.
> 


From owner-mpls@UU.NET  Wed Jun  7 16:11:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19706
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 16:11:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispc07099;
	Wed, 7 Jun 2000 20:10:02 GMT
Received: by mail-control.mail.uu.net 
	id QQispc28714
	for mpls-outgoing; Wed, 7 Jun 2000 20:09:26 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispc28707
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 20:09:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispc24151
	for <mpls@UU.NET>; Wed, 7 Jun 2000 16:04:19 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQispc02723
	for <mpls@UU.NET>; Wed, 7 Jun 2000 20:04:19 GMT
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Wed, 7 Jun 2000 15:55:53 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <L3HQ1VNJ>; Wed, 7 Jun 2000 15:55:32 -0400
Message-ID: <6DDA62170439D31185750000F80826AC02C3692F@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "Fiffi Hellstrand" <fiffi@nortelnetworks.com>,
        Vishal Sharma <Vishal.Sharma@tellabs.com>,
        "Chiu, Angela L, ALSVC" <alchiu@att.com>
Cc: mpls@UU.NET
Subject: LSTs, LSPs and the recovery framework draft.
Date: Wed, 7 Jun 2000 15:55:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD0BA.5616F3E4"
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_01BFD0BA.5616F3E4
Content-Type: text/plain

Fiffi, Vishal:

Given the discussion I've had on this on the list, and a desire to bring
this distinction to the framework draft, I find a read of the framework
draft neatly skirts the issue of distinguishing mp2p tributaries from the
whole tree by almost universally referring to "paths" instead of LSPs. 

This would suggest that only a few tweaks to the document would make me very
happy:

1) An explicit definition of "path" (sect 2.2.1) in the context of the
document as existing between a PSL and a PML and possibly being overlaid on
a mp2p LSP.

2) In 2.2 replace LSP with traffic:
   In protection switching, revertive mode requires the LSP/traffic to be
   switched back to a preferred path when the fault on that path is
   cleared.

3) In 3.5 replace LSP with path
   Path Degraded (PD) is a fault that indicates to MPLS-based recovery
   schemes/mechanisms that the LSP/path has connectivity, but that the
   quality of the connection is unacceptable. 


   Link Failure (LF) is an indication from a lower layer that the link
   over which the LSP/path is carried has failed. 

   Link Degraded (LD) is an indication from a lower layer that the
   link over which the LSP/path is carried is performing below an
   acceptable level. 

4) In 3.8.3  replace LSP with path.

    3.8.3 Reverting to Preferred LSP/path
    ....The controlled rearrangement of LSP/paths can also be used to
satisfy traffic
    engineering requirements for load balancing across an MPLS domain.

And we're done. ;-)

Dave


---------------------------------
Sr. Advisor Access Evolution
dallan@nortelnetworks.com



------_=_NextPart_001_01BFD0BA.5616F3E4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>LSTs, LSPs and the recovery framework draft.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Fiffi, Vishal:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Given the discussion I've had on this =
on the list, and a desire to bring this distinction to the framework =
draft, I find a read of the framework draft neatly skirts the issue of =
distinguishing mp2p tributaries from the whole tree by almost =
universally referring to &quot;paths&quot; instead of LSPs. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This would suggest that only a few =
tweaks to the document would make me very happy:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1) An explicit definition of =
&quot;path&quot; (sect 2.2.1) in the context of the document as =
existing between a PSL and a PML and possibly being overlaid on a mp2p =
LSP.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2) In 2.2 replace LSP with =
traffic:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; In protection switching, =
revertive mode requires the </FONT><FONT COLOR=3D"#FF0000" SIZE=3D2 =
FACE=3D"Arial">LSP/</FONT><FONT SIZE=3D2 FACE=3D"Arial">traffic to =
be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; switched back to a =
preferred path when the fault on that path is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; cleared.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3) In 3.5 replace LSP with path</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Path Degraded (PD) is a =
fault that indicates to MPLS-based recovery</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; schemes/mechanisms that =
the </FONT><FONT COLOR=3D"#FF0000" SIZE=3D2 =
FACE=3D"Arial">LSP/</FONT><FONT SIZE=3D2 FACE=3D"Arial">path has =
connectivity, but that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; quality of the =
connection is unacceptable. </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Link Failure (LF) is an =
indication from a lower layer that the link</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; over which the =
</FONT><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">LSP/</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">path is carried has failed. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Link Degraded (LD) is an =
indication from a lower layer that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; link over which the =
</FONT><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">LSP/</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">path is carried is performing below an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; acceptable level. =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">4) In 3.8.3&nbsp; replace LSP with =
path.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; 3.8.3 Reverting to =
Preferred </FONT><FONT COLOR=3D"#FF0000" SIZE=3D2 =
FACE=3D"Arial">LSP/</FONT><FONT SIZE=3D2 FACE=3D"Arial">path</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; ....The controlled =
rearrangement of </FONT><FONT COLOR=3D"#FF0000" SIZE=3D2 =
FACE=3D"Arial">LSP/</FONT><FONT SIZE=3D2 FACE=3D"Arial">paths can also =
be used to satisfy traffic</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; engineering =
requirements for load balancing across an MPLS domain.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">And we're done. ;-)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Tahoma">---------------------------------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">Sr. Advisor Access Evolution</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Tahoma">dallan@nortelnetworks.com</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFD0BA.5616F3E4--


From owner-mpls@UU.NET  Wed Jun  7 16:22:02 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20000
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 16:22:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispd04050;
	Wed, 7 Jun 2000 20:20:19 GMT
Received: by mail-control.mail.uu.net 
	id QQispd29577
	for mpls-outgoing; Wed, 7 Jun 2000 20:20:01 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispd29566
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 20:19:58 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQispd27119
	for <mpls@UU.NET>; Wed, 7 Jun 2000 16:19:40 -0400 (EDT)
Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQispd03375
	for <mpls@UU.NET>; Wed, 7 Jun 2000 20:19:40 GMT
Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4)
	id QAA10280; Wed, 7 Jun 2000 16:13:27 -0400
Message-ID: <393EBCBE.5359E16B@tellium.com>
Date: Wed, 07 Jun 2000 16:21:02 -0500
From: Debanjan Saha <dsaha@tellium.com>
Organization: Tellium Optical Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "rajeshs@futsoft.com" <rajeshs@futsoft.com>
CC: "'Bora Akyol'" <akyol@pluris.com>, "mpls@uu.net" <mpls@UU.NET>,
        "'Yakov Rekhter'" <yakov@cisco.com>
Subject: Re: MPLS Performance analysis.....
References: <01BFD07F.916FA3E0.rajeshs@futsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Rajesh Kumar wrote:
> 
> "It is a well known fact at this point we can make IP lookups as fast we
> can do MPLS lookups"
> 
> "can" is right. But the complexity of implementing a longest-prefix-match
> in hardware (or using a cam) is definitely more than a table index lookup
> (like mpls allows). And more expensive too.


Can you quantify it -- both the cost and the complexity when you
use ternary CAMs for LPM?


-- 
Debanjan Saha                         Phone: 732-923-4264
Senior Network Architect              Fax:   732-923-9804
Tellium Optical Systems               http://www.tellium.com


From owner-mpls@UU.NET  Wed Jun  7 16:46:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20405
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 16:46:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispf02028;
	Wed, 7 Jun 2000 20:45:07 GMT
Received: by mail-control.mail.uu.net 
	id QQispe00860
	for mpls-outgoing; Wed, 7 Jun 2000 20:44:41 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQispe00853
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 20:44:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispe01784
	for <mpls@UU.NET>; Wed, 7 Jun 2000 16:44:20 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQispe01402
	for <mpls@UU.NET>; Wed, 7 Jun 2000 20:44:20 GMT
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Wed, 7 Jun 2000 16:42:39 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <L3HQ1XJB>; Wed, 7 Jun 2000 16:42:38 -0400
Message-ID: <6DDA62170439D31185750000F80826AC02C36A21@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        "'Ross Callon'" <rcallon@juniper.net>, mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Wed, 7 Jun 2000 16:42:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD0C0.EAB1A192"
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_01BFD0C0.EAB1A192
Content-Type: text/plain

Indra:

How did the source of the OAM packet know the label used on the penultimate
hop. Or are we discussing some other means of identification.

Dave

> -----Original Message-----
> From:	Indra.Widjaja [SMTP:Indra.Widjaja@tddny.fujitsu.com]
> Sent:	Wednesday, June 07, 2000 4:28 PM
> To:	Shahram Davari
> Cc:	'Theimer Thomas'; 'Ross Callon'; mpls@UU.NET
> Subject:	Re: OAM labels (was: can egress know the ingress of a
> packet?)
> 
> Shahram:
> Thanks for your clarification.
> I was slow and didn't read the message from Thomas.
> As he said in his later message, the LSP can be identified in the
> body of the OAM packet if needed (which is still to be defined),
> so the problem can be solved, right?
> indra
> 

------_=_NextPart_001_01BFD0C0.EAB1A192
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: OAM labels (was: can egress know the ingress of a =
packet?)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Indra:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">How did the source =
of the OAM packet know the label used on the penultimate hop. Or are we =
discussing some other means of identification.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Indra.Widjaja =
[SMTP:Indra.Widjaja@tddny.fujitsu.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, June 07, 2000 4:28 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Shahram Davari</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'Theimer Thomas'; 'Ross Callon'; mpls@UU.NET</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: OAM labels (was: can egress know =
the ingress of a packet?)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Shahram:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks for your clarification.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I was slow and didn't read the =
message from Thomas.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As he said in his later message, the =
LSP can be identified in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">body of the OAM packet if needed =
(which is still to be defined),</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">so the problem can be solved, =
right?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">indra</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFD0C0.EAB1A192--


From owner-mpls@UU.NET  Wed Jun  7 16:49:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20468
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 16:49:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispe16220;
	Wed, 7 Jun 2000 20:37:46 GMT
Received: by mail-control.mail.uu.net 
	id QQispe00531
	for mpls-outgoing; Wed, 7 Jun 2000 20:37:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQispe00526
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 20:37:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQispe00552
	for <mpls@uu.net>; Wed, 7 Jun 2000 16:37:01 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQispe15598
	for <mpls@uu.net>; Wed, 7 Jun 2000 20:37:01 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA02255
	for mpls@uu.net; Wed, 7 Jun 2000 16:37:00 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQispe00488
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 20:36:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispe24973
	for <mpls@UU.NET>; Wed, 7 Jun 2000 16:36:17 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQispe25961
	for <mpls@UU.NET>; Wed, 7 Jun 2000 20:36:16 GMT
Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id PAA22608; Wed, 7 Jun 2000 15:28:37 -0500 (CDT)
Received: from tddny.fujitsu.com (pc185.tddny.fujitsu.com [167.254.242.185]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id M1SH46CY; Wed, 7 Jun 2000 15:28:37 -0500
Message-ID: <393EB06B.DDE25DD2@tddny.fujitsu.com>
Date: Wed, 07 Jun 2000 16:28:27 -0400
From: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        "'Ross Callon'" <rcallon@juniper.net>, mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <336ECDAFDF7DD311B9E30090277AEE4101B405E1@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shahram:
Thanks for your clarification.
I was slow and didn't read the message from Thomas.
As he said in his later message, the LSP can be identified in the
body of the OAM packet if needed (which is still to be defined),
so the problem can be solved, right?
indra


Shahram Davari wrote:

> Indra,
>
> There is no problem in sending the packet to OAM processor. The problem is
> when the packet is received by OAM processor, because the forwarding label
> is not present any more, how can the OAM processor determine which LSP this
> OAM packet belonged to. Because the processing of the OAM packet will depend
> on identifying the LSP.
>
> -Shahram
>
> >-----Original Message-----
> >From: Indra.Widjaja [mailto:Indra.Widjaja@tddny.fujitsu.com]
> >Sent: Wednesday, June 07, 2000 1:41 PM
> >To: Shahram Davari
> >Cc: 'Theimer Thomas'; 'Ross Callon'; mpls@UU.NET
> >Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
> >
> >
> >Shahram:
> >I still don't understand what the problem really is.
> >The penultimate LSR forwards the packet to the egress LSR
> >based on the user data label that was just popped out.
> >When the packet with the OAM label arrives at the egress
> >LSR, the egress LSR should be able to direct the OAM
> >packet to the proper OAM handler.
> >Does this work?
> >indra
> >
> >
> >Shahram Davari wrote:
> >
> >> Theimer,
> >>
> >> I think what Ross meant was that using PHP, when OAM label
> >is below the
> >> forwarding label, the egress node can't determine the LSP
> >that the OAM
> >> packet belongs to.
> >>
> >> Regards,
> >> -Shahram
> >>
> >> >-----Original Message-----
> >> >From: Theimer Thomas [mailto:Thomas.Theimer@icn.siemens.de]
> >> >Sent: Wednesday, June 07, 2000 5:10 AM
> >> >To: 'Ross Callon'
> >> >Cc: mpls@UU.NET
> >> >Subject: RE: OAM labels (was: can egress know the ingress
> >of a packet?)
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From:        Ross Callon [SMTP:rcallon@juniper.net]
> >> >> To:  Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
> >> >>
> >> >> If the outer label identifies the LSP, and the inner label is a
> >> >> special OAM value, then I think that there is a problem with
> >> >> penultimate hop label popping.
> >> >       [Theimer Thomas]  Good point. We missed that. However, if the
> >> >penultimate hop removes the top label, the egress node will
> >receive the
> >> >packet with an OAM label on top. That would still trigger OAM
> >> >processing in
> >> >the egress node, so I don't necessarily see a problem here,
> >except that
> >> >perhaps the egress node needs to be an LSR. If not, then in
> >my view the
> >> >penultimate hop is really the logical endpoint of the LSP,
> >and should
> >> >process the OAM label if present. However, I must admit I
> >don't clearly
> >> >understand how penultimate hop popping is really applied in a
> >> >network. I
> >> >also could not find any explicit support in LDP, CR-LDP and
> >> >TE-RSVP. Without
> >> >such support, is anyone actually using that mechanism in practice ?
> >> >
> >> >       Thomas
> >> >
> >> >
> >




From owner-mpls@UU.NET  Wed Jun  7 17:08:50 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20794
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 17:08:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispg07276;
	Wed, 7 Jun 2000 21:07:16 GMT
Received: by mail-control.mail.uu.net 
	id QQispg11663
	for mpls-outgoing; Wed, 7 Jun 2000 21:06:41 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQispg11647
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 21:06:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispg00687
	for <mpls@uu.net>; Wed, 7 Jun 2000 17:06:03 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQispg16607
	for <mpls@uu.net>; Wed, 7 Jun 2000 21:06:01 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA07697
	for mpls@uu.net; Wed, 7 Jun 2000 17:06:01 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQispg11410
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 21:05:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispg05931
	for <mpls@UU.NET>; Wed, 7 Jun 2000 17:05:07 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQispg15814
	for <mpls@UU.NET>; Wed, 7 Jun 2000 21:05:06 GMT
Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id PAA24034; Wed, 7 Jun 2000 15:50:40 -0500 (CDT)
Received: from tddny.fujitsu.com (pc185.tddny.fujitsu.com [167.254.242.185]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id M1SH46PS; Wed, 7 Jun 2000 15:50:41 -0500
Message-ID: <393EB596.A3FA03E1@tddny.fujitsu.com>
Date: Wed, 07 Jun 2000 16:50:31 -0400
From: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: otel@ce.chalmers.se
CC: David Allan <dallan@nortelnetworks.com>,
        Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>,
        Thomas.Theimer@icn.siemens.de, Shahram_Davari@pmc-sierra.com,
        pjw@ip-engineering.bt.com, mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <6DDA62170439D31185750000F80826AC02BFD4DC@zmerd004.ca.nortel.com> <14654.27394.250448.471063@rasputin.ce.chalmers.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree with Dave that the problem can be approached more
systematically by identifying the requirements/issues first.
I don't think the encoding thread was started intentionally, but
more because it just popped up and led to interesting discusssions.
Maybe we can get back to the general issues now.
indra


Florian-Daniel Otel wrote:

> > [1  <text/plain; iso-8859-1 (7bit)>]
> > Can we bring a bit of discipline to this discussion.
>
> > - what problems are we trying to diagnose?
> > - what functionality do we require to take corrective action (protection
> > switching, fault sectionalization etc.)
> > - what mechanisms are required to diagnose the problems?
> > - what flows are required to propagate knowledge of the problems?
> > - how can we specify encoding those flows?
>
> Well, I'll add only one more mail to these threads re-iterating what me
> Thomas, Neil and others already said:
>
> Is it possible that we consider this (i.e. OAM functionality) in
> the light of:
>         -Existing drafts for protection/restoration/loop prevention
>         -ping/traceroute for MPLS
>         -ICMP  and MPLS-ICMP
>         -other expressed OAM needs
>
> While i see quite a bit of overlapping IMHO I think we can tie
> everything up and address all these issues in  a consistent manner. It
> would be a really nice way to clean this OAM slate and have everything
> addressed in a consistent manner. The only thing that needs to be done
> is to gather all the ideas under one frame. AFAICT there are enough
> ideas already expressed to be a critical mass...
>
> Just my $0.02 worth.
>
> Regards,
>
> Florian.




From owner-mpls@UU.NET  Wed Jun  7 17:13:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20836
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 17:13:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispg11047;
	Wed, 7 Jun 2000 21:12:07 GMT
Received: by mail-control.mail.uu.net 
	id QQispg12141
	for mpls-outgoing; Wed, 7 Jun 2000 21:11:47 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQispg12125
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 21:11:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispg01554
	for <mpls@UU.NET>; Wed, 7 Jun 2000 17:10:24 -0400 (EDT)
Received: from ns1.cirilium.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns1.cirilium.com [207.13.202.251])
	id QQispg19597
	for <mpls@UU.NET>; Wed, 7 Jun 2000 21:10:24 GMT
Received: from cirilium1.cirilium.com (mailserver.cirilium.com [10.40.3.4])
	by ns1.cirilium.com (8.9.3/8.8.7) with ESMTP id OAA18775
	for <mpls@UU.NET>; Wed, 7 Jun 2000 14:09:52 -0700
Received: from lcoxnt1 ([10.40.3.241])
          by cirilium1.cirilium.com (Lotus Domino Release 5.0.3)
          with SMTP id 2000060714095353:11601 ;
          Wed, 7 Jun 2000 14:09:53 -0700 
Message-Id: <4.1.20000607140754.00a9b640@mail.neta.com>
X-Sender: lcox@mail.neta.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 07 Jun 2000 14:12:05 -0700
To: mpls@UU.NET
From: Larry Cox <lcox@neta.com>
Subject: RE: MPLS Performance analysis..... 
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at
 06/07/2000 02:09:53 PM,
	Serialize by Router on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at
 06/07/2000 02:10:23 PM,
	Serialize complete at 06/07/2000 02:10:23 PM
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 11:56 AM 6/7/00 -0700, Bora wrote:
>Yakov,
>
>It is a well known fact at this point we can make IP lookups as fast we can
>do MPLS lookups.
>
>So the lookup speed advantage of MPLS does not exist anymore which I believe
>was the point that was being raised.
>
>Bora (just catching up with my old mail)

(Initially I sent this off list but I think it may be applicable to a list
topic)

When one has 120K+ VoIP calls active on one OC192 fiber link and it becomes
necessary to move these calls enmass from route a to route b, moving a
labled path is much easier than handling all of the IP routing. It is
rather important to not have major underruns or overruns in the audio path
at the receiving end. Ideally, 200MSec or less to re-route all 120K+ voice
streams is prefered (30 MSec to avoid underruns).

Larry 



From owner-mpls@UU.NET  Wed Jun  7 18:15:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21565
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 18:15:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispk21811;
	Wed, 7 Jun 2000 22:14:17 GMT
Received: by mail-control.mail.uu.net 
	id QQispk25250
	for mpls-outgoing; Wed, 7 Jun 2000 22:13:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispk25243
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 22:13:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQispk17184
	for <mpls@UU.NET>; Wed, 7 Jun 2000 18:13:18 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQispk21126
	for <mpls@UU.NET>; Wed, 7 Jun 2000 22:13:17 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id RAA09794;
	Wed, 7 Jun 2000 17:13:11 -0500
Message-ID: <20000607171311.E9353@doit.wisc.edu>
Date: Wed, 7 Jun 2000 17:13:11 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: Eric Gray <EGray@zaffire.com>,
        "'jleu@mindspring.com'" <jleu@mindspring.com>,
        Bob Thomas <rhthomas@cisco.com>
Cc: mpls@UU.NET
Subject: Re: Address Message in LDP
Reply-To: jleu@mindspring.com
References: <9A564CC874B5D3118FB9009027B0A662690753@ICARIAN>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <9A564CC874B5D3118FB9009027B0A662690753@ICARIAN>; from Eric Gray on Wed, Jun 07, 2000 at 12:30:54PM -0700
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Jun 07, 2000 at 12:30:54PM -0700, Eric Gray wrote:

<snip>

> Of course it is not the only way.  For one thing,
> it is possible to configure this information.
> 
> (Bob does not have my warped sense of humor - if 
> he meant "required" he would not have said "useful")
> 
> > My goal is to get an answer about "non-Directly Connected 
> > LSRs" and how they guarantee that they are distributing 
> > labels and installing them on the correct interfaces.
> > 
> > The way to get the above answer may involve or mimic the way 
> > we deal with mappings over parallel links between two 
> > directly connected LDP peers.
> 
> There are numerous issues with this.  One of them is
> the assumption of multiple parallel links between two
> LDP peers - which necessarily implies the use of the
> platform wide label space (as Shahram points out).

Even though the downstream sessions uses a plateform wide label space that
STILL doesn't solve the problem when one of the upstream session receives a
mapping.  The upstream needs to decide if the downstream session that it
received the label from is running over the link that corresponds to the TRUE
next hop.

Jim
-- 
James R. Leu


From owner-mpls@UU.NET  Wed Jun  7 18:23:10 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21686
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 18:23:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispl27402;
	Wed, 7 Jun 2000 22:22:18 GMT
Received: by mail-control.mail.uu.net 
	id QQispl25860
	for mpls-outgoing; Wed, 7 Jun 2000 22:21:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispl25851
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 22:21:49 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQispl18498
	for <mpls@uu.net>; Wed, 7 Jun 2000 18:21:35 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQispl26854
	for <mpls@uu.net>; Wed, 7 Jun 2000 22:21:35 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA17919
	for mpls@uu.net; Wed, 7 Jun 2000 18:21:34 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispl25790
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 22:21:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQispl18450
	for <mpls@uu.net>; Wed, 7 Jun 2000 18:20:57 -0400 (EDT)
Received: from stl-smtpout-01.boeing.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: stl-smtpout-01.boeing.com [12.13.247.21])
	id QQispl26446
	for <mpls@uu.net>; Wed, 7 Jun 2000 22:20:57 GMT
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA13693
	for <mpls@uu.net>; Wed, 7 Jun 2000 17:20:56 -0500 (CDT)
Received: from stl-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id RAA19699
	for <mpls@uu.net>; Wed, 7 Jun 2000 17:20:55 -0500 (CDT)
Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Wed, 7 Jun 2000 17:20:41 -0500
Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21)
	id <KWZRVM26>; Wed, 7 Jun 2000 18:20:40 -0400
Message-Id: <4102273CEB77D211869200805FE6F5939EBC10@xch-phl-01.he.boeing.com>
From: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
To: "'Kimmo.Raatikainen@nokia.com'" <Kimmo.Raatikainen@nokia.com>
Cc: diffserv@ietf.org, mpls@UU.NET
Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions   related  questions/comments
Date: Wed, 7 Jun 2000 18:20:31 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

> -----Original Message-----
> From: Kimmo.Raatikainen@nokia.com [mailto:Kimmo.Raatikainen@nokia.com]

[ ... ]

> Please keep in mind that gigabit cards are already available. In our
> experiments we have found out that a high-end PC running 
> Linux can send at a
> rate of 250-300 megabits per second using TCP/UDP.

Actually, too bad Bora's "gripe" wasn't fully discussed on here. I guess it
didn't fit in with the router model work being done at the moment.

I'd like to know how one can offer "service differentiation" over a
packet-switched internet (small i) if one doesn't allow for network nodes to
examine header fields, and then make queuing decisions based on some
undefined and growing list of criteria? And potentially different criteria
for different networks, as far as that goes? 

Maybe some sort of more hardware-friendly scheme, where queuing decisions
are based on a simple set if rules associated with the 64 code points?
Dunno. But it would definitely lead discussions down a different path, no?

Bert
albert.e.manfredi@boeing.com



From owner-mpls@UU.NET  Wed Jun  7 18:32:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21848
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 18:32:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispm11040;
	Wed, 7 Jun 2000 22:31:09 GMT
Received: by mail-control.mail.uu.net 
	id QQispm26510
	for mpls-outgoing; Wed, 7 Jun 2000 22:30:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispm26503
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 22:30:26 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispm19913
	for <mpls@UU.NET>; Wed, 7 Jun 2000 18:30:15 -0400 (EDT)
Received: from nexen.nexen.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nexen.nexen.com [204.249.96.18])
	id QQispm10314
	for <mpls@UU.NET>; Wed, 7 Jun 2000 22:30:15 GMT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5])
	by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id SAA15941
	for <mpls@UU.NET>; Wed, 7 Jun 2000 18:30:15 -0400 (EDT)
Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id SAA00341 for <mpls@UU.NET>; Wed, 7 Jun 2000 18:30:14 -0400 (EDT)
Received: from nexen.com (sales2.nexen.com [204.249.97.154])
	by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id SAA09702
	for <mpls@UU.NET>; Wed, 7 Jun 2000 18:30:13 -0400 (EDT)
Message-ID: <393ECCF4.63EA952A@nexen.com>
Date: Wed, 07 Jun 2000 18:30:12 -0400
From: Mark Stewart <Mstewart@nexen.com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: "mpls@uu.net" <mpls@UU.NET>
Subject: Re: MPLS Performance analysis.....
References: <01BFD07F.916FA3E0.rajeshs@futsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> "It is a well known fact at this point we can make IP lookups as fast we
> can do MPLS lookups"
>
> "can" is right. But the complexity of implementing a longest-prefix-match
> in hardware (or using a cam) is definitely more than a table index lookup
> (like mpls allows). And more expensive too.
>
> If your car could get you there as quickly, do you need to build a
> spaceship!!!!
>

I believe we are flogging a dead horse with this debate.

If you ask a spaceship manufacturer the answer is "of course you do",
and if you ask a car manufacturer the answer is "of course not".

c u

Mark Stewart





From owner-mpls@UU.NET  Wed Jun  7 19:33:14 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22612
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 19:33:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispq09549;
	Wed, 7 Jun 2000 23:32:11 GMT
Received: by mail-control.mail.uu.net 
	id QQispq08165
	for mpls-outgoing; Wed, 7 Jun 2000 23:31:51 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQispq08155
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 23:31:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispq23043
	for <mpls@uu.net>; Wed, 7 Jun 2000 19:31:27 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQispq18144
	for <mpls@uu.net>; Wed, 7 Jun 2000 23:31:26 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA24130
	for mpls@uu.net; Wed, 7 Jun 2000 19:31:25 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispq08137
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 23:31:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQispq28227
	for <mpls@UU.NET>; Wed, 7 Jun 2000 19:30:45 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQispq08481
	for <mpls@UU.NET>; Wed, 7 Jun 2000 23:30:44 GMT
Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id SAA00689; Wed, 7 Jun 2000 18:23:02 -0500 (CDT)
Received: from tddny.fujitsu.com (pc210.tddny.fujitsu.com [167.254.242.210]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id M1SH48MD; Wed, 7 Jun 2000 18:23:02 -0500
Message-ID: <393ED951.25875E6@tddny.fujitsu.com>
Date: Wed, 07 Jun 2000 19:22:57 -0400
From: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Allan <dallan@nortelnetworks.com>
CC: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Theimer Thomas'" <Thomas.Theimer@icn.siemens.de>,
        "'Ross Callon'" <rcallon@juniper.net>, mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <6DDA62170439D31185750000F80826AC02C36A21@zmerd004.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------DC243AEE0F4CD0E1E0A419B7"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------DC243AEE0F4CD0E1E0A419B7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David Allan wrote:

>
>
> Indra:
>
> How did the source of the OAM packet know the label used on the
> penultimate hop. Or are we discussing some other means of
> identification.

David:
I don't think you would want to record someone else's local label.
I'd like to see some other identification discussed and defined, and
this
seems to depend on the particular OAM operations.
indra


>
>
> Dave
>
>      -----Original Message-----
>      From:   Indra.Widjaja [SMTP:Indra.Widjaja@tddny.fujitsu.com]
>      Sent:   Wednesday, June 07, 2000 4:28 PM
>      To:     Shahram Davari
>      Cc:     'Theimer Thomas'; 'Ross Callon'; mpls@UU.NET
>      Subject:        Re: OAM labels (was: can egress know the ingress
>      of a packet?)
>
>      Shahram:
>      Thanks for your clarification.
>      I was slow and didn't read the message from Thomas.
>      As he said in his later message, the LSP can be identified in the
>
>      body of the OAM packet if needed (which is still to be defined),
>      so the problem can be solved, right?
>      indra
>

--------------DC243AEE0F4CD0E1E0A419B7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David Allan wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>Indra:</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>How did the source
of the OAM packet know the label used on the penultimate hop. Or are we
discussing some other means of identification.</font></font></font></blockquote>
David:
<br>I don't think you would want to record someone else's local label.
<br>I'd like to see some other identification discussed and defined, and
this
<br>seems to depend on the particular OAM operations.
<br>indra
<br>&nbsp;
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>Dave</font></font></font>
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><b><font face="Arial"><font size=-2>From:&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Indra.Widjaja [SMTP:Indra.Widjaja@tddny.fujitsu.com]</font></font>
<br><b><font face="Arial"><font size=-2>Sent:&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Wednesday, June 07, 2000 4:28 PM</font></font>
<br><b><font face="Arial"><font size=-2>To:&nbsp;&nbsp;&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Shahram Davari</font></font>
<br><b><font face="Arial"><font size=-2>Cc:&nbsp;&nbsp;&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>'Theimer Thomas'; 'Ross Callon'; mpls@UU.NET</font></font>
<br><b><font face="Arial"><font size=-2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Re: OAM labels (was: can egress know the
ingress of a packet?)</font></font>
<p><font face="Arial"><font size=-1>Shahram:</font></font>
<br><font face="Arial"><font size=-1>Thanks for your clarification.</font></font>
<br><font face="Arial"><font size=-1>I was slow and didn't read the message
from Thomas.</font></font>
<br><font face="Arial"><font size=-1>As he said in his later message, the
LSP can be identified in the</font></font>
<br><font face="Arial"><font size=-1>body of the OAM packet if needed (which
is still to be defined),</font></font>
<br><font face="Arial"><font size=-1>so the problem can be solved, right?</font></font>
<br><font face="Arial"><font size=-1>indra</font></font></ul>
</blockquote>
</html>

--------------DC243AEE0F4CD0E1E0A419B7--




From owner-mpls@UU.NET  Wed Jun  7 21:55:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24614
	for <mpls-archive@lists.ietf.org>; Wed, 7 Jun 2000 21:55:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQispz04819;
	Thu, 8 Jun 2000 01:54:22 GMT
Received: by mail-control.mail.uu.net 
	id QQispz02053
	for mpls-outgoing; Thu, 8 Jun 2000 01:54:01 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQispz02048
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 01:53:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQispz13483
	for <mpls@UU.NET>; Wed, 7 Jun 2000 21:53:35 -0400 (EDT)
Received: from NOD.RESTON.MCI.NET by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [166.60.6.38])
	id QQispz10541
	for <mpls@UU.NET>; Thu, 8 Jun 2000 01:53:35 GMT
Received: from BONI ([166.60.18.134])
 by shoe.reston.mci.net (PMDF V5.2-32 #40475)
 with SMTP id <01JQC4T755549AMGJR@shoe.reston.mci.net> for mpls@UU.NET; Wed,
 7 Jun 2000 21:53:34 EST
Date: Wed, 07 Jun 2000 21:52:52 -0500
From: Ron Bonica <rbonica@mci.net>
Subject: RE: OAM functionality (Was: RE: can egress know the ingressof apacket?)
In-reply-to: <200006071857.OAA16572@curtis-lt.avici.com>
To: curtis@avici.com, Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
Cc: neil.2.harrison@bt.com, otel@ce.chalmers.se, Shahram_Davari@pmc-sierra.com,
        EGray@zaffire.com, swtan@mmu.edu.my, kireeti@juniper.net,
        dwilder@baynetworks.com, mpls@UU.NET
Message-id: <NBBBJGONOLIJDDNHNNBEGEFMDOAA.rbonica@mci.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7BIT

> draft-ietf-mpls-icmp-01.txt extends the ICMP processing to allow
> traceroute to list LSRs.  I thought I remembered a recommendation to
> send the ICMP packet through the tunnel for an unreachable destination
> in order to support VPNs, but I didn't see that in the draft.

Hi Curtis,

You saw that recommendation in Section 2.3.2 of
draft-ietf-mpls-label-encaps-07. Section 5 of draft-ietf-mpls-icmp-01
explicitly defers to draft-ietf-mpls-label-encaps-07 in this matter.

                                   Ron



From owner-mpls@UU.NET  Thu Jun  8 01:01:28 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27254
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 01:01:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisql21269;
	Thu, 8 Jun 2000 04:59:54 GMT
Received: by mail-control.mail.uu.net 
	id QQisql08530
	for mpls-outgoing; Thu, 8 Jun 2000 04:59:33 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisql08525
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 04:59:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisql04502
	for <mpls@UU.NET>; Thu, 8 Jun 2000 00:59:09 -0400 (EDT)
Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8])
	id QQisql20669
	for <mpls@UU.NET>; Thu, 8 Jun 2000 04:59:08 GMT
Received: by MILES with Internet Mail Service (5.5.2650.21)
	id <LNVRSZ53>; Thu, 8 Jun 2000 05:59:05 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2A3198@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: Paul Langille <langille@crescentnets.com>,
        "Thomas D. Nadeau"
	 <tnadeau@cisco.com>
Cc: mpls@UU.NET, Cheenu Srinivasan <cheenu_s@yahoo.com>,
        arun Viswanathan
	 <arun@force10networks.com>
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable
Date: Thu, 8 Jun 2000 05:59:04 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi.  Sorry to be so slow jumping in.

<Paul>
>>>     So now I am wondering, do you need the tunnel cookie 
>>>    (since it is the source address and the tunnel index)?

<Tom>
>>      I believe that we are going to eliminate the cookies
>>      from the MIB. There was some discussion about this a
>>      while back.

I recall this discussion, and I think you are accurately 
representing the consensus.

What you are saying is that the cookie is replaced with a 
explicit fields.  This is good.

You're all right that about the information required to 
identify a tunnel anywhere apart from the source.

Now we come to the issue of signaling.

You have made the (reasonable) assumption that the Tunnel_ID
(Tunnel ID in the RSVP LSP_TUNNEL_IPvx Session Objects, or
Local CR-LSP ID in the CR-LDP LSPID TLV).  This is not,
however, a requirement yet.  I suggest we make it so by 
adding text to the Description for mplsTunnelIndex.

   "This value is exchanged in the signaling protocols
    to help to uniquely identify the tunnel at remote
    LSRs.  In RSVP this field is maps to the Tunnel ID
    field of the Session Object.  In CR-LDP it maps to
    the CR-LSP ID field in the LSPID TLV."

Although putting this wording in may seem restrictive (why
should an implementation not pick its LSP IDs in its own 
way?) I think it is compatible with your requirements that
we force MIB-configured LSPs to signal this information in
a consistent way.

How, then do you propose that the tunnel instance is signaled?
You could use the Extended Tunnel ID in RSVP but that conflicts
with where you need to signal the source address. Are you
proposing an extension to the protocols or are you happy that
tunnel instance is only visible at the source?  If this is the
case, I'd suggest reserving the value zero for use at all LSRs
apart from the ingress.  Suitable text for the Description
might be...

   "When this MIB row reflects a tunnel for which this LSR is
    not the ingress and when the signaling protocol is not
    capable of signaling the tunnel instance of a particular
    tunnel, the value of this field SHOULD be zero."



Lastly, I'd like to look at how this approach fits with merging
in RSVP.  I don't want to open up the whole subject but rather
to float a concern.

In RSVP (2205) you can merge flows if the Session IDs match (and
some other conditions).  For RSVP this amounts very much to 
ensuring that the destinations match.

In RSVP-TE it would make sense to allow merging of LSPs if many of
the same conditions hold.  The Session ID, is extended to include
the Tunnel ID and the extended Tunnel ID.

One interpretation is that you may merge LSPs if they are on the same
session, i.e. if the Session IDs are the same.  Thus, if you want to
prevent merge but allow make-before-break, you set merge_permitted,
but also fill in the Extended Tunnel ID to contain your source IP 
address.  If you want to allow merge, you set the extended Tunnel ID
to all zeros, and we can merge with any LSP that carries the same 
Tunnel ID.

It becomes a configuration issue at the ingresses to ensure that all 
Tunnels that we want to be merged use the same Tunnel ID (in your
scheme, by making sure they have the same mplsTunnelIndex on each
ingress).  

This, however, means we can't pass the source address (which doesn't
really have a meaning once we've merged).  Is this OK with your
planned use of the MIB?

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


From owner-mpls@UU.NET  Thu Jun  8 06:09:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10493
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 06:09:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrg18955;
	Thu, 8 Jun 2000 10:08:43 GMT
Received: by mail-control.mail.uu.net 
	id QQisrg18118
	for mpls-outgoing; Thu, 8 Jun 2000 10:08:14 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisrg18113
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 10:08:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisrg29353
	for <mpls@UU.NET>; Thu, 8 Jun 2000 06:07:45 -0400 (EDT)
Received: from corecom.it by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.corecom.it [131.175.40.11])
	id QQisrg18195
	for <mpls@UU.NET>; Thu, 8 Jun 2000 10:07:31 GMT
Received: from [131.175.40.56] by corecom.it with
 ESMTP (Eudora Internet Mail Server 1.1.2); Thu, 8 Jun 2000 12:08:12 +0200
X-Sender: t00trini@mail.corecom.it (Unverified)
Message-Id: <l03130300b5651eb703b7@[131.175.40.56]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 8 Jun 2000 12:06:14 +0200
To: mpls@UU.NET
From: Trini Jurado <t00trini@corecom.it>
Subject: LSP establishments
Sender: owner-mpls@UU.NET
Precedence: bulk

Assuming that RSVP is used to LSP's establishments,

In RSVP, data packets that are
addressed to a particular session but which do not match any of the filter
specs for that session are handled as best-effort traffic.

If we have an LSP for this session, does it mean that the packets will not
follow this LSP, and, even more, will not be assigned any label being
routed then as IP traditional routing?

Does it mean that it is necessary, at least, one wavelength in each link to
be reserved for these packets (all that do not match the specs of their
corresponding session)?

Thank you for your replies.

  Trinidad Jurado.




From owner-mpls@UU.NET  Thu Jun  8 06:23:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10557
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 06:23:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrh18061;
	Thu, 8 Jun 2000 10:21:27 GMT
Received: by mail-control.mail.uu.net 
	id QQisrh19225
	for mpls-outgoing; Thu, 8 Jun 2000 10:20:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisrh19216
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 10:20:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisrh04066
	for <mpls@uu.net>; Thu, 8 Jun 2000 06:20:42 -0400 (EDT)
Received: from alu-etsetb.upc.es by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alu-etsetb.upc.es [147.83.68.11])
	id QQisrh25609
	for <mpls@uu.net>; Thu, 8 Jun 2000 10:20:27 GMT
Received: from alu-etsetb.upc.es (a2s104a-6.upc.es [147.83.68.206])
	by alu-etsetb.upc.es (Postfix) with ESMTP id E3BF1CF946A
	for <mpls@uu.net>; Thu, 08 Jun 2000 12:20:14 +0200 (CEST)
Message-ID: <393F735D.6BCB395D@alu-etsetb.upc.es>
Date: Thu, 08 Jun 2000 12:20:14 +0200
From: Juan Diego Otero <jote4102@alu-etsetb.upc.es>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: MPLS and fast reroute.
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,

In IEEE Communications Magazine (December 1999), there is an article
written
by Tony Li called "MPLS and the Evolving Internet Architecture". In page
41,
talking about fast reroute, Tony says: "...MPLS can also be used in a
manner very similar to synchronous optical network (SONET), where no
signaling is necessary to perform the protection switching of the LSP.
This
results in restoration times competitive with SONET." My question is:

Can anybody explain me how MPLS can be used as SONET in
switching a LSP after a faliure, with no signaling?

Thanks a lot.

Diego Otero
UPC (Universitat Politècnica de Catalunya)



From owner-mpls@UU.NET  Thu Jun  8 06:25:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10568
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 06:25:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrh27565;
	Thu, 8 Jun 2000 10:23:36 GMT
Received: by mail-control.mail.uu.net 
	id QQisrh19421
	for mpls-outgoing; Thu, 8 Jun 2000 10:23:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisrh19405
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 10:22:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisrh00894
	for <mpls@UU.NET>; Thu, 8 Jun 2000 06:22:32 -0400 (EDT)
Received: from babelbrox.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: babelbrox.axion.bt.co.uk [132.146.16.6])
	id QQisrh18814
	for <mpls@UU.NET>; Thu, 8 Jun 2000 10:22:31 GMT
Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) 
          by babelbrox (local) with SMTP; Thu, 8 Jun 2000 11:22:09 +0100
Received: from ip-engineering.bt.com 
          by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id LAA07796;
          Thu, 8 Jun 2000 11:22:08 +0100 (BST)
Message-Id: <200006081022.LAA07796@celiborn.ip-engineering.bt.com>
X-Mailer: exmh version 2.0.3 9/28/98
To: mpls@UU.NET
Subject: Re: OAM functionality 
         (Was: RE: can egress know the ingressof a packet?)
In-reply-to: Your message of "Wed, 07 Jun 2000 14:57:16 EDT." <200006071857.OAA16572@curtis-lt.avici.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 Jun 2000 11:22:08 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Problems with Ping and Traceroute Alone as OAM Tools For MPLS
-------------------------------------------------------------

1 - Failure of LSP does not imply ping will fail.
	An LSP X is established between PE A and PE D. To test continuity
	a ping process runs on A pinging D. If LSP X fails the ping may
	still be successful because D may still be reachable via per-hop
	routing. Example fault is that the LSR process on LSR C fails but its
	destination based per-hop routing process continues.

2 - Complexity of using ping as a proactive continuity check.
	It is essential to a network operator that failures in any LSP are
	raised as alarms to its NMS ASAP. To this end we have alarms from
	SDH, ATM, FR, PPP, HDLC and L2TP that causes routers to send traps 
	to NMS.  We need a similar function from MPLS. Even if pings fail
	when LSPs fail the complexity of running ping processes on all routers
	to test all LSPs is not acceptable and not current practice for other
	network technologies.
	Ping is ideally suited as a fault finding tool but lacks the 
	integration with the network protocols to be an effective pro-active
	monitoring tool within a complex network.

	- Especially in an IP VPN Environment.
	In an IP VPN environment only CEs within a VPN can ping other CEs
	within the same VPN. That is a ping can not run from the PE routers
	to test LSP connectivity between CEs. It is possible to run pings
	from the CEs and by making every CE also a member of the NMS VPN we
	can get the CEs to send network performance information back to the
	NMS. However how many CEs does 1 CE have to ping to measure LSP
	connectivity? The CEs have to be owned by the network operator in
	order for the network operator to provider this service. It is not
	acceptable to network operators to force customers to monitor their
	VPN service in order to raise alarms of LSP failures where customers
	own their own CPE.

3 - Non-uniqueness of IP Addresses in an IP VPN Service.
	In an IP VPN service different customers will be reusing the same
	address space. This leads to the possibility that if a LSP is
	misdirected that a ping test would still suceed. Usually this
	will require 2 faults, that is the outgoing and return LSPs to
	be misdirected however this is feasible as a single bug on a single
	LSR could lead to this. There is also the possibility that if
	CE a is using registered addresses to source the ping and pinging
	a private address, in the event of a misdirection of an LSP, the
	wrong device would respond and send the response back to the
	registered address via the Internet (I've actually seen this happen!).

4 - Failure of Traceroute where customers have their own MPLS network in an
	IP VPN environment.
	In the simple IP VPN service where we only offer standard IP 
	connectivity to customers traceroute may suffice (Although tracerouting
	to a customer's private address from within the provider core is
	not possible!) However if in the future there is a market for selling
	MPLS connectivity to customers in an IP VPN service traceroute
	will have many shortcommings. (I can imagine large corporate customers
	running their own MPLS networks and wanting to buy some service from
	network operators to connect their large MPLS networks together).
	In this situation traceroute is an insufficient tool for the
	customer to use and for the network operator to use. (I don't ever
	see how the network operator could traceroute into the customer's
	network but if the customer has tools to traceroute across their
	nets and the providers nets in an end-to-end manner it would be useful.)

5 - Seperation of IP-FEC failures from MPLS LSR label switching failures 
	requires seperate tools.
	It is true that MPLS OAM would not detect failures in with IP FEC and
	other possible IP routing failures. However this is reasonable,
	similarly ATM OAM does not spot IP failures. The question is can
	we depend on IP customers doing their own continuity tests and
	reporting failures to the network operators? If MPLS has OAM then
	at least the network operator can detect a significant number of
	failures in their customers' service. 
	In the event of failures in the IP FEC would it be helpful to have
	information that rules out failures in the LSRs label switching?
	I've run an ISP with a FR backbone and it was always useful to be
	able to tell if the fault was in the IP routing or the FR switches.
	MPLS OAM would give us the same ability to tell the difference
	between "simple" LSR label switching failure and more "complex" IP
	routing failures.

Peter.




From owner-mpls@UU.NET  Thu Jun  8 07:56:39 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11874
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 07:56:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrn18489;
	Thu, 8 Jun 2000 11:54:03 GMT
Received: by mail-control.mail.uu.net 
	id QQisrn03283
	for mpls-outgoing; Thu, 8 Jun 2000 11:53:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisrn03278
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 11:53:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisrn10456
	for <mpls@UU.NET>; Thu, 8 Jun 2000 07:53:29 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQisrn18060
	for <mpls@UU.NET>; Thu, 8 Jun 2000 11:53:28 GMT
Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP;
          Thu, 8 Jun 2000 12:52:30 +0100
Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWBHRCL>; Thu, 8 Jun 2000 12:52:42 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16051@mbddmknt01.hc.bt.com>
To: pjw@ip-engineering.bt.com, mpls@UU.NET
Subject: RE: OAM functionality  
         (Was: RE: can egress know the ingressof a packet?)
Date: Thu, 8 Jun 2000 12:52:35 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Peter, good observations from someone who designs/runs IP networks and hence
has operational experience of these matters.....few additional remarks
below:

Regards, Neil

> Problems with Ping and Traceroute Alone as OAM Tools For MPLS
> -------------------------------------------------------------
> 
> 1 - Failure of LSP does not imply ping will fail.
> 	An LSP X is established between PE A and PE D. To test continuity
> 	a ping process runs on A pinging D. If LSP X fails the ping may
> 	still be successful because D may still be reachable via per-hop
> 	routing. Example fault is that the LSR process on LSR C fails but
> its
> 	destination based per-hop routing process continues.
	[Harrison,N,Neil,INC1 X]  One should not be using OAM tools in a
client layer to detect faults in a server layer....this is the wrong layer
and not good architectural practice.  It gets worse if one then tries to use
OAM mechanisms in one layer to effect actions in another layer (either
direction up/down stack).  Each layer needs its own OAM tools for the
specific defects that the layer could produce......and these also need
splitting between user-plane and control-plane since (i) one cannot always
assume these will be congruent, (ii) go through same functional processing
or (iii) have the same failure mechanisms or fault behaviour.

> 2 - Complexity of using ping as a proactive continuity check.
> 	It is essential to a network operator that failures in any LSP are
> 	raised as alarms to its NMS ASAP. To this end we have alarms from
> 	SDH, ATM, FR, PPP, HDLC and L2TP that causes routers to send traps 
> 	to NMS.  We need a similar function from MPLS. Even if pings fail
> 	when LSPs fail the complexity of running ping processes on all
> routers
> 	to test all LSPs is not acceptable and not current practice for
> other
> 	network technologies.
> 	Ping is ideally suited as a fault finding tool but lacks the 
> 	integration with the network protocols to be an effective pro-active
> 	monitoring tool within a complex network.
	[Harrison,N,Neil,INC1 X]  Ping will not detect/diagnose (at the MPLS
layer) where various forms of misbranching/mismerging defects are occurring.
Further, one should be very careful with OAM tools that assume some
reliability from the network for their sucessful operation......under fault
conditions the network is, by definition, not reliable, eg any trace-route
type of function requiring a loopback-like response must assume misbranching
failures are bi-directionally symmetric.  One cannot guarantee networks will
know they have to fail in such a well behaved manner.

	But Connectivity Verification and Route-Tracing are not the total
picture anyway.......we need distributed local consequent actions on
detection of failures.  For example, to make sure we don't get alarm storms
and that prot-sw is correctly targetted.  This is particularly important for
nested LSP scenarios.

> 	- Especially in an IP VPN Environment.
> 	In an IP VPN environment only CEs within a VPN can ping other CEs
> 	within the same VPN. That is a ping can not run from the PE routers
> 	to test LSP connectivity between CEs. It is possible to run pings
> 	from the CEs and by making every CE also a member of the NMS VPN we
> 	can get the CEs to send network performance information back to the
> 	NMS. However how many CEs does 1 CE have to ping to measure LSP
> 	connectivity? The CEs have to be owned by the network operator in
> 	order for the network operator to provider this service. It is not
> 	acceptable to network operators to force customers to monitor their
> 	VPN service in order to raise alarms of LSP failures where customers
> 	own their own CPE.
> 
> 3 - Non-uniqueness of IP Addresses in an IP VPN Service.
> 	In an IP VPN service different customers will be reusing the same
> 	address space. This leads to the possibility that if a LSP is
> 	misdirected that a ping test would still suceed. Usually this
> 	will require 2 faults, that is the outgoing and return LSPs to
> 	be misdirected however this is feasible as a single bug on a single
> 	LSR could lead to this. There is also the possibility that if
> 	CE a is using registered addresses to source the ping and pinging
> 	a private address, in the event of a misdirection of an LSP, the
> 	wrong device would respond and send the response back to the
> 	registered address via the Internet (I've actually seen this
> happen!).
	[Harrison,N,Neil,INC1 X]  This is 'the wrong layer' issue again.

> 4 - Failure of Traceroute where customers have their own MPLS network in
> an
> 	IP VPN environment.
> 	In the simple IP VPN service where we only offer standard IP 
> 	connectivity to customers traceroute may suffice (Although
> tracerouting
> 	to a customer's private address from within the provider core is
> 	not possible!) However if in the future there is a market for
> selling
> 	MPLS connectivity to customers in an IP VPN service traceroute
> 	will have many shortcommings. (I can imagine large corporate
> customers
> 	running their own MPLS networks and wanting to buy some service from
> 	network operators to connect their large MPLS networks together).
> 	In this situation traceroute is an insufficient tool for the
> 	customer to use and for the network operator to use. (I don't ever
> 	see how the network operator could traceroute into the customer's
> 	network but if the customer has tools to traceroute across their
> 	nets and the providers nets in an end-to-end manner it would be
> useful.)
	[Harrison,N,Neil,INC1 X]  Wrong layer issue again.

> 5 - Seperation of IP-FEC failures from MPLS LSR label switching failures 
> 	requires seperate tools.
> 	It is true that MPLS OAM would not detect failures in with IP FEC
> and
> 	other possible IP routing failures. However this is reasonable,
> 	similarly ATM OAM does not spot IP failures. The question is can
> 	we depend on IP customers doing their own continuity tests and
> 	reporting failures to the network operators? If MPLS has OAM then
> 	at least the network operator can detect a significant number of
> 	failures in their customers' service. 
> 	In the event of failures in the IP FEC would it be helpful to have
> 	information that rules out failures in the LSRs label switching?
> 	I've run an ISP with a FR backbone and it was always useful to be
> 	able to tell if the fault was in the IP routing or the FR switches.
> 	MPLS OAM would give us the same ability to tell the difference
> 	between "simple" LSR label switching failure and more "complex" IP
> 	routing failures.
	[Harrison,N,Neil,INC1 X]  Wrong layer issue again.

> Peter.
> 


From owner-mpls@UU.NET  Thu Jun  8 09:11:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03571
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 09:11:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrs27903;
	Thu, 8 Jun 2000 13:08:36 GMT
Received: by mail-control.mail.uu.net 
	id QQisrs25536
	for mpls-outgoing; Thu, 8 Jun 2000 13:07:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisrs25531
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 13:07:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisrs21475
	for <mpls@UU.NET>; Thu, 8 Jun 2000 09:07:36 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQisrs27117
	for <mpls@UU.NET>; Thu, 8 Jun 2000 13:07:36 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Thu, 8 Jun 2000 08:05:50 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <MPD1S1MS>; Thu, 8 Jun 2000 08:05:55 -0500
Message-ID: <6DDA62170439D31185750000F80826AC02C36DB7@zmerd004.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Juan Diego Otero <jote4102@alu-etsetb.upc.es>, mpls@UU.NET
Subject: RE: MPLS and fast reroute.
Date: Thu, 8 Jun 2000 08:05:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD14A.46B93070"
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_01BFD14A.46B93070
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

IMHO only in a simple case "look thog, fiber go dark", which can only =
deal
with gross physical defects, and I have predefined recovery strategies =
(such
as the virtual ring proposals the group has entertained).

Dave

> -----Original Message-----
> From:	Juan Diego Otero [SMTP:jote4102@alu-etsetb.upc.es]
> Sent:	Thursday, June 08, 2000 6:20 AM
> To:	mpls@UU.NET
> Subject:	MPLS and fast reroute.
>=20
> Hi,
>=20
> In IEEE Communications Magazine (December 1999), there is an article
> written
> by Tony Li called "MPLS and the Evolving Internet Architecture". In =
page
> 41,
> talking about fast reroute, Tony says: "...MPLS can also be used in a
> manner very similar to synchronous optical network (SONET), where no
> signaling is necessary to perform the protection switching of the =
LSP.
> This
> results in restoration times competitive with SONET." My question is:
>=20
> Can anybody explain me how MPLS can be used as SONET in
> switching a LSP after a faliure, with no signaling?
>=20
> Thanks a lot.
>=20
> Diego Otero
> UPC (Universitat Polit=E8cnica de Catalunya)
>=20

------_=_NextPart_001_01BFD14A.46B93070
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: MPLS and fast reroute.</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">IMHO only in a =
simple case &quot;look thog, fiber go dark&quot;, which can only deal =
with gross physical defects, and I have predefined recovery strategies =
(such as the virtual ring proposals the group has =
entertained).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Juan Diego Otero =
[SMTP:jote4102@alu-etsetb.upc.es]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, June 08, 2000 6:20 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">mpls@UU.NET</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">MPLS and fast reroute.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In IEEE Communications Magazine =
(December 1999), there is an article</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">written</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">by Tony Li called &quot;MPLS and the =
Evolving Internet Architecture&quot;. In page</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">41,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">talking about fast reroute, Tony =
says: &quot;...MPLS can also be used in a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">manner very similar to synchronous =
optical network (SONET), where no</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signaling is necessary to perform the =
protection switching of the LSP.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">results in restoration times =
competitive with SONET.&quot; My question is:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can anybody explain me how MPLS can be =
used as SONET in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">switching a LSP after a faliure, with =
no signaling?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks a lot.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Diego Otero</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">UPC (Universitat Polit=E8cnica de =
Catalunya)</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFD14A.46B93070--


From owner-mpls@UU.NET  Thu Jun  8 09:23:08 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05449
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 09:23:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrp00634;
	Thu, 8 Jun 2000 12:27:14 GMT
Received: by mail-control.mail.uu.net 
	id QQisrp14493
	for mpls-outgoing; Thu, 8 Jun 2000 12:26:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisrp14488
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 12:26:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisrp17808
	for <mpls@UU.NET>; Thu, 8 Jun 2000 08:26:34 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQisrp29968
	for <mpls@UU.NET>; Thu, 8 Jun 2000 12:26:26 GMT
Received: from daewoo (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id RAA26536;
	Thu, 8 Jun 2000 17:24:39 -0600 (GMT)
Message-ID: <016101bfd141$15bc3ac0$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <jleu@mindspring.com>, "Eric Gray" <EGray@zaffire.com>,
        "Bob Thomas" <rhthomas@cisco.com>
Cc: <mpls@UU.NET>
References: <9A564CC874B5D3118FB9009027B0A662690753@ICARIAN> <20000607171311.E9353@doit.wisc.edu>
Subject: Re: Address Message in LDP
Date: Thu, 8 Jun 2000 17:29:21 +0530
Organization: Daewoo Telecom
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 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

> On Wed, Jun 07, 2000 at 12:30:54PM -0700, Eric Gray wrote:
>
> <snip>
>
> > Of course it is not the only way.  For one thing,
> > it is possible to configure this information.
> >
> > (Bob does not have my warped sense of humor - if
> > he meant "required" he would not have said "useful")
> >
> > > My goal is to get an answer about "non-Directly Connected
> > > LSRs" and how they guarantee that they are distributing
> > > labels and installing them on the correct interfaces.
> > >
> > > The way to get the above answer may involve or mimic the way
> > > we deal with mappings over parallel links between two
> > > directly connected LDP peers.
> >
> > There are numerous issues with this.  One of them is
> > the assumption of multiple parallel links between two
> > LDP peers - which necessarily implies the use of the
> > platform wide label space (as Shahram points out).
>
> Even though the downstream sessions uses a plateform wide label space that
> STILL doesn't solve the problem when one of the upstream session receives
a
> mapping.  The upstream needs to decide if the downstream session that it
> received the label from is running over the link that corresponds to the
TRUE
> next hop.

If the TRUE next hop is one of the 2 interfaces, then it should be the TRUE
one. But in case if it is not one of the 2 interfaces which are not directly
connected then you can choose any one of the 2 and it will work. You install
the
Incoming interface/label ---------> Outgoing Interface/Label
into the switch. Once data starts coming, it doesnt matter if it goes to the
peer on link1 or link 2 if you have seperate LDP sessions on both, though
one of the paths might be less costly.

santosh
>
> Jim
> --
> James R. Leu
>



From owner-mpls@UU.NET  Thu Jun  8 09:25:28 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05821
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 09:25:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrt08859;
	Thu, 8 Jun 2000 13:24:32 GMT
Received: by mail-control.mail.uu.net 
	id QQisrt26842
	for mpls-outgoing; Thu, 8 Jun 2000 13:23:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisrt26831
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 13:23:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisrt24439
	for <mpls@UU.NET>; Thu, 8 Jun 2000 09:23:27 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQisrt16127
	for <mpls@UU.NET>; Thu, 8 Jun 2000 13:23:27 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id JAA13508; Thu, 8 Jun 2000 09:23:16 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id JAA17405;
	Thu, 8 Jun 2000 09:23:39 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006081323.JAA17405@curtis-lt.avici.com>
To: Peter Willis <pjw@ip-engineering.bt.com>
cc: curtis@avici.com, Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>,
        neil.2.harrison@bt.com, otel@ce.chalmers.se,
        Shahram_Davari@pmc-sierra.com, EGray@zaffire.com, swtan@mmu.edu.my,
        kireeti@juniper.net, dwilder@baynetworks.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-reply-to: Your message of "Tue, 06 Jun 2000 18:04:13 BST."
             <200006061704.SAA24312@celiborn.ip-engineering.bt.com> 
Date: Thu, 08 Jun 2000 09:23:38 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200006061704.SAA24312@celiborn.ip-engineering.bt.com>, Peter Willis
 writes:
> 
> 
> > We might want to ask ISPs how valuable RR IP option on ping has been
> > and how valuable the equivalent ATM OAM cells have been.  We may find
> > that the former is used occasionally at most and the latter even less
> > or not at all for IP over ATM networks.
> 
> I have been network manager of BT's Internet services for 4 years. The RR
> option on ping was used very rarely. ATM OAM is essential to the operation
> of the network (we have an extensive ATM network). The ATM OAM is used
> by the routers to detect failures in ATM VCs and raise SNMP traps. The
> up/down status of the router interface is also dependent on ATM OAM so
> we can run resilient ATM services to customers without running a routing
> protocol to the customers' CPE/NTE.
> 
> As a network operator I have the following requirements:
> - I need to detect failure of an LSP. (I don't want to wait for the
> 	customer to report a failure)

This is a good requirement statement.

> 	There are more failure states of LSPs than standard destination
> 	based routing because relative labels are used for switching. For
> 	example we can have LSP traffic delivered to the wrong destination
> 	by a simple bug on a single LSR (it is far less likely to happen
> 	on an IP network using per hop routing because if
> 	a router sends it the wrong way the next router will probably
> 	send it back (get a routing loop) or send it the right way). How
> 	do I (as an operator) detect this failure?

If it were a TE tunnel an IBGP adjacency going down be a real big
hint.  This isn't supposed to happen (the tunnel going down without
the control plane knowing about it).

> 	Sure I could use a remote ping function on the customer premises 
> 	equipment and when it fails raise an alarm. But I have to create
> 	a full mesh of addresses to ping to cover all the customers
> 	address space and sites (in the case of IP VPNs). This seems a bit
> 	clumsy to me. And for IP VPNs what happens if the customers are using
> 	the same 10.0.0.0 address space, chances are if my ping gets 
> 	misdelivered they'll still be a box in somebody else's network that
> 	will respond to the address I'm pinging (although we'll need 2 faults
> 	for that icmp echo-reply to get back).

OAM packets would not use the same hardware resources that the VPN
traffic would unless they travel transparently in which case they
would behave a lot like ping packets.

> 	When MPLS is used for TE what do I ping from where? If the TE trunk
> 	fails won't I still get a response from ping because normal per-hop
> 	based routing will take over? So we need a TE tunnel liveness
> 	indicator.

Apparently the type of failure you are looking for is a mismatch
between the control plane and the actual forwarding (an implementation
bug or fault).  If the control plane knows of a failure, your NMS
should know about it.

If the tunnel goes down and the control plane recovers by reverting to
per-hop forwarding, then it ought to tell the NMS that it has done so.

> - I need tools to isolate where the fault is. Which LSR is causing the problem?
> 	It would be useful if when I get a failure in the network the alarms
> 	raised are a useful indicator of where the fault is. Then I can
> 	start using tools like ping and traceroute to narrow down where
> 	the fault is.

The type of fault you seem to be describing is where a label
spontaneously evaporates or some similar occurance where the control
plane is not aware that forwarding isn't working.

In some subset of such cases, counters that should normally be zero
would be incremented.  For example, the fault may increment counters
of labels for which there was no valid table entry or for which some
internal table was invalid.  If no counters are incremented traffic
levels should either fall to zero or differ radically at ingress and
egress.

For TE tunnels, a zero or near zero traffic rate would give an
indication that such a fault had occurred, assuming that in an
Internet backbone zero traffic never happens.  This is not a safe
assumption for VPNs or enterprise since zero traffic can be possible.

For those cases were zero traffic is possible, add some traffic for
the purpose of measurement (run a ping) and since you are pinging, you
might as well verify that the pings go through.

If a hardware fault has caused a table entry to rot, then using an OAM
packet that takes a different path (handled via router alert label)
would not detect the fault.

A big help in preventing this inability to detect faults is to put
parity or ECC on internal data paths and where possible internal data
sets.  This exposes the most common cause of internal data rot
(unreliable internal data paths due to marginal or intermittent
components that could otherwise result in the wrong value being set).

> Peter.

I don't see the point to specifying OAM packets if they do exactly
what a ping would do and I don't yet see why the OAM packet would do
anything different from ordinary traffic (therefore making pings a
good candidate since they are ordinary traffic).  The issue then
becomes specifying how pings and counters on the LSRs should be
handled in order to notify the NMS.  Some might argue that this is out
of scope for the MPLS WG.

One of the big problems with PVCs configured from the NMS (in ATM) had
been the NMS missing one of the hops due to an undetected failure when
trying to configure the switches.  In the absense of a control plane
(use of PVCs) this can only be detected by some type of traffic not
going through.  The same would be true of MPLS if it were used in this
way.  Introducing OAM to MPLS in order to run without a control plane
(configuring LSPs from the NMS) may be misguided logic.

Thats all from me on this.  If you still see a need for OAM packets
then keep in mind that it is very late in the evolution of the MPLS
encapsulation and changing the encapsulation is not an option that you
will be able to propose without strong opposition.

Curtis


From owner-mpls@UU.NET  Thu Jun  8 09:28:56 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06389
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 09:28:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrt09940;
	Thu, 8 Jun 2000 13:25:49 GMT
Received: by mail-control.mail.uu.net 
	id QQisrt26924
	for mpls-outgoing; Thu, 8 Jun 2000 13:25:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisrt26918
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 13:25:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisrt24692
	for <mpls@UU.NET>; Thu, 8 Jun 2000 09:25:07 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQisrt17115
	for <mpls@UU.NET>; Thu, 8 Jun 2000 13:25:06 GMT
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA05920
	for <mpls@UU.NET>; Thu, 8 Jun 2000 09:25:06 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA05896;
	Thu, 8 Jun 2000 09:25:05 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id JAA04561; Thu, 8 Jun 2000 09:25:04 -0400 (EDT)
Message-ID: <393F9EB0.D17E15AA@lucent.com>
Date: Thu, 08 Jun 2000 09:25:04 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Juan Diego Otero <jote4102@alu-etsetb.upc.es>
CC: mpls@UU.NET
Subject: Re: MPLS and fast reroute.
References: <393F735D.6BCB395D@alu-etsetb.upc.es>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Diego Otero,

For the most simple protection, unidirectional 1+1, neither MPLS nor SONET
requires signaling. The trade of is that you may have to dedicate 100% network
resource for protection. The protection switching is sure very fast. 

For more complicated SONET protection switching mechanisms (BLSR for example),
they do have signaling, however not message-based signaling but within SONET
overhead bytes with hardware facilitation. So in order to have MPLS to achieve
SONET like performance, not only protocol but also the infrastructure has to be
there. For example, at least QoS has to be guaranteed to differentiate
protection switching messages from other traffic. 

MPLS rerouting has to be both fast and deterministic in order to be competitive
with SONET. Actually, they don't need to compete with each other. They can
absolutely work together well.

Yangguang


> talking about fast reroute, Tony says: "...MPLS can also be used in a
> manner very similar to synchronous optical network (SONET), where no
> signaling is necessary to perform the protection switching of the LSP.
> This
> results in restoration times competitive with SONET." My question is:
> 
> Can anybody explain me how MPLS can be used as SONET in
> switching a LSP after a faliure, with no signaling?
>


From owner-mpls@UU.NET  Thu Jun  8 09:59:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07861
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 09:59:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisro16344;
	Thu, 8 Jun 2000 12:04:33 GMT
Received: by mail-control.mail.uu.net 
	id QQisro12716
	for mpls-outgoing; Thu, 8 Jun 2000 12:04:00 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisro12703
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 12:03:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisro14627
	for <mpls@UU.NET>; Thu, 8 Jun 2000 08:03:31 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQisro15678
	for <mpls@UU.NET>; Thu, 8 Jun 2000 12:03:30 GMT
Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP;
          Thu, 8 Jun 2000 12:52:48 +0100
Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2651.88) 
          id <MCGXA17D>; Thu, 8 Jun 2000 12:52:34 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16050@mbddmknt01.hc.bt.com>
To: jote4102@alu-etsetb.upc.es, mpls@UU.NET
Subject: RE: MPLS and fast reroute.
Date: Thu, 8 Jun 2000 12:52:33 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA07861

This assumes one has already defined all failures and consequent actions.  I
see at least 4 possibilities, none of which are clearly defined anyway in
terms of entry/exit criteria and consequent actions (signalling for prot-sw
being but just 1 aspect):
-	simple LSP connectivity break......sourced from server layer or from
MPLS layer
-	swapped LSPs
-	mismerged (different) LSPs
-	self-mismerged LSPs (aka looping)

Warning - L1 networks can experience significant error events and then
recover.  So one can do more harm than good by prot-sw too soon.  If your
detection scheme and prot-sw are above L1 then anything much less than 2-3s
may not be very sensible.

neil 

> -----Original Message-----
> From:	Juan Diego Otero [SMTP:jote4102@alu-etsetb.upc.es]
> Sent:	Thursday, June 08, 2000 11:20 AM
> To:	mpls@UU.NET
> Subject:	MPLS and fast reroute.
> 
> Hi,
> 
> In IEEE Communications Magazine (December 1999), there is an article
> written
> by Tony Li called "MPLS and the Evolving Internet Architecture". In page
> 41,
> talking about fast reroute, Tony says: "...MPLS can also be used in a
> manner very similar to synchronous optical network (SONET), where no
> signaling is necessary to perform the protection switching of the LSP.
> This
> results in restoration times competitive with SONET." My question is:
> 
> Can anybody explain me how MPLS can be used as SONET in
> switching a LSP after a faliure, with no signaling?
> 
> Thanks a lot.
> 
> Diego Otero
> UPC (Universitat Politècnica de Catalunya)


From owner-mpls@UU.NET  Thu Jun  8 10:31:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08497
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 10:31:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrx29602;
	Thu, 8 Jun 2000 14:28:20 GMT
Received: by mail-control.mail.uu.net 
	id QQisrx09774
	for mpls-outgoing; Thu, 8 Jun 2000 14:27:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisrx09749
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 14:27:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisrx08431
	for <mpls@UU.NET>; Thu, 8 Jun 2000 10:27:15 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQisrx22254
	for <mpls@UU.NET>; Thu, 8 Jun 2000 14:27:15 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id KAA18670; Thu, 8 Jun 2000 10:27:05 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA17667;
	Thu, 8 Jun 2000 10:27:01 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006081427.KAA17667@curtis-lt.avici.com>
To: Larry Cox <lcox@neta.com>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS Performance analysis..... 
In-reply-to: Your message of "Wed, 07 Jun 2000 14:12:05 PDT."
             <4.1.20000607140754.00a9b640@mail.neta.com> 
Date: Thu, 08 Jun 2000 10:27:01 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4.1.20000607140754.00a9b640@mail.neta.com>, Larry Cox writes:
> At 11:56 AM 6/7/00 -0700, Bora wrote:
> >Yakov,
> >
> >It is a well known fact at this point we can make IP lookups as fast we can
> >do MPLS lookups.
> >
> >So the lookup speed advantage of MPLS does not exist anymore which I believe
> >was the point that was being raised.
> >
> >Bora (just catching up with my old mail)
> 
> (Initially I sent this off list but I think it may be applicable to a list
> topic)
> 
> When one has 120K+ VoIP calls active on one OC192 fiber link and it becomes
> necessary to move these calls enmass from route a to route b, moving a
> labled path is much easier than handling all of the IP routing. It is
> rather important to not have major underruns or overruns in the audio path
> at the receiving end. Ideally, 200MSec or less to re-route all 120K+ voice
> streams is prefered (30 MSec to avoid underruns).
> 
> Larry 


Larry,

One might consider using CIDR addressing so that only a few prefixes
were rerouted.  I seriously doubt anyone would advertise 120K /32 IP
prefixes to handle 120K voice streams.  In this respect, MPLS can be
considered to be another form of route (or more correctly control
information) aggregation.

The major benefit of MPLS in your example would come from MPLS
local-protect.  Note that without local-protect, the one way delay
back to the ingress could exceed the 30msec.  Quite obviously, no IGP
would converge in that time so IP routing wouldn't respond in that
kind of time, but neither would MPLS reroute initiated at the ingress.

Curtis



From owner-mpls@UU.NET  Thu Jun  8 10:38:29 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08611
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 10:38:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrp03812;
	Thu, 8 Jun 2000 12:17:45 GMT
Received: by mail-control.mail.uu.net 
	id QQisrp13834
	for mpls-outgoing; Thu, 8 Jun 2000 12:17:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisrp13825
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 12:17:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisrp16283
	for <mpls@uu.net>; Thu, 8 Jun 2000 08:17:00 -0400 (EDT)
Received: from relay1.alcatel.be by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc119.alcatel.be [195.207.101.119])
	id QQisrp24331
	for <mpls@uu.net>; Thu, 8 Jun 2000 12:16:59 GMT
Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e58CGwD00804
	for <mpls@uu.net>; Thu, 8 Jun 2000 14:16:59 +0200 (MET DST)
Received: from btmxbh.rc.bel.alcatel.be (btmxbh [138.203.64.184])
	by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id OAA26992
	for <mpls@uu.net>; Thu, 8 Jun 2000 14:16:59 +0200 (MET DST)
Received: (from schrijvp@localhost)
	by btmxbh.rc.bel.alcatel.be (8.9.3/8.9.3) id MAA06325
	for mpls@uu.net; Mon, 29 May 2000 12:46:28 +0200
Date: Mon, 29 May 2000 12:46:27 +0200
From: De Schrijver Peter <schrijvp@rc.bel.alcatel.be>
To: mpls@UU.NET
Subject: LDP notification
Message-ID: <20000529124627.D490@rc.bel.alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I have some questions about the interpretation of an LDP notification
message. 
What is an LSR supposed to do when it receives a notification
with an unknown status data field, the E-bit clear and the F-bit set ?
The message ID refers to a label request. Is the LSR supposed to
teardown the LSP or not ? Should the LSR forward the notification
message and also include TLV's unknown to the LSR but with both U and F bits 
set ?

Peter.


From owner-mpls@UU.NET  Thu Jun  8 10:48:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08830
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 10:48:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisrp08021;
	Thu, 8 Jun 2000 12:23:52 GMT
Received: by mail-control.mail.uu.net 
	id QQisrp14187
	for mpls-outgoing; Thu, 8 Jun 2000 12:23:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisrp14182
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 12:23:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisrp17458
	for <mpls@uu.net>; Thu, 8 Jun 2000 08:23:05 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQisrp28213
	for <mpls@uu.net>; Thu, 8 Jun 2000 12:23:03 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA05867
	for <mpls@uu.net>; Thu, 8 Jun 2000 05:23:11 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA00607 for mpls@uu.net; Thu, 8 Jun 2000 08:23:02 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisqw13477
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 07:35:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisqw17601
	for <mpls@uu.net>; Thu, 8 Jun 2000 03:34:59 -0400 (EDT)
Received: from monza.broadswitch.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: monzaext.broadswitch.com [195.178.164.73])
	id QQisqw15397
	for <mpls@uu.net>; Thu, 8 Jun 2000 07:34:58 GMT
Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A58A@monza.broadswitch.com>
From: Thomas Eklund <thomas.eklund@switchcore.com>
To: "'Juha Heinanen'" <jh@lohi.eng.telia.fi>
Cc: "'Brian E Carpenter'" <brian@hursley.ibm.com>, Kimmo.Raatikainen@nokia.com,
        akyol@pluris.com, diffserv@ietf.org, mpls@UU.NET
Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension
	 s    related  questions/comments
Date: Thu, 8 Jun 2000 09:34:51 +0200 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Juha,
Good question. But yes we have metering and policing.

It has in terms of QoS MF classifier, Marker, Meter, Queue Mgt, Scheduler,
Buffer Mgt, Dropper ...

The classifier can do packet filtering from layer 1-4 (statful inspection)
at the same time..

There is a lot of propriatery solutions in order to optimize the hardware
architechure to achieve full diffserv support , which I can tell about under
a NDA...

Best Regards 
 Thomas

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
> Sent: Wednesday, June 07, 2000 5:28 PM
> To: Thomas Eklund
> Cc: 'Brian E Carpenter'; Kimmo.Raatikainen@nokia.com; 
> akyol@pluris.com;
> diffserv@ietf.org; mpls@uu.net
> Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv
> Extension s related questions/comments
> 
> 
> Thomas Eklund writes:
> 
>  > If you look at our product which is a 
> switch/router-on-a-chip in ASIC it
>  > runs a full MF classifier and have full diffserv (queeing, 
> scheduling etc.)
>  > support for 16 GigabitEthernet full duplex ports wirespeed!!
> 
> i didn't find in the documents any support for metering and policing.
> 
> -- juha
> 



From owner-mpls@UU.NET  Thu Jun  8 11:11:30 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09361
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 11:11:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissa16908;
	Thu, 8 Jun 2000 15:01:57 GMT
Received: by mail-control.mail.uu.net 
	id QQissa16514
	for mpls-outgoing; Thu, 8 Jun 2000 15:01:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQissa16239
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 15:01:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissa14043
	for <mpls@UU.NET>; Thu, 8 Jun 2000 11:01:15 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQissa16210
	for <mpls@UU.NET>; Thu, 8 Jun 2000 15:01:14 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id LAA21603; Thu, 8 Jun 2000 11:01:05 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA17770;
	Thu, 8 Jun 2000 11:01:24 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006081501.LAA17770@curtis-lt.avici.com>
To: Juan Diego Otero <jote4102@alu-etsetb.upc.es>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS and fast reroute. 
In-reply-to: Your message of "Thu, 08 Jun 2000 12:20:14 +0200."
             <393F735D.6BCB395D@alu-etsetb.upc.es> 
Date: Thu, 08 Jun 2000 11:01:24 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <393F735D.6BCB395D@alu-etsetb.upc.es>, Juan Diego Otero writes:
> Hi,
> 
> In IEEE Communications Magazine (December 1999), there is an article
> written
> by Tony Li called "MPLS and the Evolving Internet Architecture". In page
> 41,
> talking about fast reroute, Tony says: "...MPLS can also be used in a
> manner very similar to synchronous optical network (SONET), where no
> signaling is necessary to perform the protection switching of the LSP.
> This
> results in restoration times competitive with SONET." My question is:
> Can anybody explain me how MPLS can be used as SONET in
> switching a LSP after a faliure, with no signaling?
> 
> Thanks a lot.
> 
> Diego Otero
> UPC (Universitat Politècnica de Catalunya)


See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.  The feature is known as
local-protect in MPLS.

At each potential point of failure a backup path is created ahead of
time.  On the LSR the spare outsegment is programmed (the hardware is
set up) but the insegment points to the primary outsegment.  When the
failure is detected by the interface egressing the LSR, a message is
sent to all other interfaces.  Each interface reprograms the insegment
(makes a table entry change) that points the insegment at the backup
path.  This can be accomplished in about the same time required to do
SONET restoration.

There is more information in draft-swallow-rsvp-bypass-label-00.txt,
though this provides a means of using one LSP to backup multiple LSP
that take the same recovery path.  It does provide additional insight
into how this works.  You can also check the mailing list archives for
discussion of "local protect" or "fast reroute".

Curtis



From owner-mpls@UU.NET  Thu Jun  8 11:15:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09475
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 11:15:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissa01108;
	Thu, 8 Jun 2000 15:12:06 GMT
Received: by mail-control.mail.uu.net 
	id QQissa21984
	for mpls-outgoing; Thu, 8 Jun 2000 15:11:37 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQissa21977
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 15:11:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissa17487
	for <mpls@UU.NET>; Thu, 8 Jun 2000 11:11:13 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQissa23796
	for <mpls@UU.NET>; Thu, 8 Jun 2000 15:11:12 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id LAA22510; Thu, 8 Jun 2000 11:11:11 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA17791;
	Thu, 8 Jun 2000 11:11:32 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006081511.LAA17791@curtis-lt.avici.com>
To: neil.2.harrison@bt.com
cc: jote4102@alu-etsetb.upc.es, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS and fast reroute. 
In-reply-to: Your message of "Thu, 08 Jun 2000 12:52:33 BST."
             <B9571FDEBD3DD21181E500606DD5EE0507B16050@mbddmknt01.hc.bt.com> 
Date: Thu, 08 Jun 2000 11:11:32 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B9571FDEBD3DD21181E500606DD5EE0507B16050@mbddmknt01.hc.bt.com>, nei
l.2.harrison@bt.com writes:
> This assumes one has already defined all failures and consequent actions.  I
> see at least 4 possibilities, none of which are clearly defined anyway in
> terms of entry/exit criteria and consequent actions (signalling for prot-sw
> being but just 1 aspect):
> -	simple LSP connectivity break......sourced from server layer or from
> MPLS layer
> -	swapped LSPs
> -	mismerged (different) LSPs
> -	self-mismerged LSPs (aka looping)
> 
> Warning - L1 networks can experience significant error events and then
> recover.  So one can do more harm than good by prot-sw too soon.  If your
> detection scheme and prot-sw are above L1 then anything much less than 2-3s
> may not be very sensible.
> 
> neil 


I think most people planning to use local protect plan to use either
MPLS local protect or SONET APS but not both.  The benefit of MPLS
local protect is that it doesn't require reserving 1/2 capacity for
protect circuits and can be applied to a subset of traffic (those
paying for better service).  Another means of protection is in the
OXC.  I don't think anyone plans to use more than one sub-100ms
protection scheme at the same time as they would interact.

People planning to use both at the same time can please correct me.

Curtis


From owner-mpls@UU.NET  Thu Jun  8 12:06:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10465
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 12:06:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisse01134;
	Thu, 8 Jun 2000 16:04:25 GMT
Received: by mail-control.mail.uu.net 
	id QQisse04456
	for mpls-outgoing; Thu, 8 Jun 2000 16:03:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisse04365
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 16:03:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissd26804
	for <mpls@uu.net>; Thu, 8 Jun 2000 11:59:42 -0400 (EDT)
Received: from arthur.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: arthur.axion.bt.co.uk [132.146.5.4])
	id QQissd27644
	for <mpls@uu.net>; Thu, 8 Jun 2000 15:59:41 GMT
Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) 
          by arthur (local) with SMTP; Thu, 8 Jun 2000 16:59:30 +0100
Received: from ip-engineering.bt.com 
          by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id QAA16021;
          Thu, 8 Jun 2000 16:59:24 +0100 (BST)
Message-Id: <200006081559.QAA16021@celiborn.ip-engineering.bt.com>
X-Mailer: exmh version 2.0.3 9/28/98
To: mpls@UU.NET
Subject: Re: OAM functionality 
         (Was: RE: can egress know the ingressof a packet?)
In-reply-to: Your message of "Thu, 08 Jun 2000 09:23:38 EDT." <200006081323.JAA17405@curtis-lt.avici.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 Jun 2000 16:59:23 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> The issue then
> becomes specifying how pings and counters on the LSRs should be
> handled in order to notify the NMS.  Some might argue that this is out
> of scope for the MPLS WG.
> Curtis

I can see that a system employing pingers on CPE, polling of counters, 
monitors of iBGP and other control plane aspects would deliver some of the OAM 
requirements. Such a system requires the deployment of proprietary components
to interface to the propreitary aspects of the LSRs. When I introduce
more than one vendor into the core network I have to rework these MPLS "OAM"
systems to interface to that new vendor.
On the other hand if MPLS OAM was incorporated as an optional standard then
I could deploy any vendors LSRs in my network that implemented the MPLS OAM
standard without having to rework my systems. Indeed if an MPLS OAM standard
was available how many network operators would not ask for conformance to it?
There will also be future issues when customers require MPLS services or 
customers
require IP VPNs implemented across more than one network operator. In such a
situation to get end-to-end MPLS OAM would require integration at the NMS 
level,
an MPLS OAM standard would be an easier way of facilitating this interworking.

By the way a common cause of internal "data rot" is software with bugs in it so
a system that can handle software and hardware failures is highly desirable.

Peter.



From owner-mpls@UU.NET  Thu Jun  8 12:11:57 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10527
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 12:11:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisse06436;
	Thu, 8 Jun 2000 16:11:01 GMT
Received: by mail-control.mail.uu.net 
	id QQisse05145
	for mpls-outgoing; Thu, 8 Jun 2000 16:10:15 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisse05133
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 16:10:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisse27749
	for <mpls@uu.net>; Thu, 8 Jun 2000 12:08:38 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQisse11998
	for <mpls@uu.net>; Thu, 8 Jun 2000 16:08:37 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10435
	for <mpls@uu.net>; Thu, 8 Jun 2000 09:08:47 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA01152 for mpls@uu.net; Thu, 8 Jun 2000 12:08:36 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisse04395
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 16:03:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisse27167
	for <mpls@uu.net>; Thu, 8 Jun 2000 12:00:52 -0400 (EDT)
Received: from web5101.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5101.mail.yahoo.com [216.115.106.71])
	id QQisse28561
	for <mpls@uu.net>; Thu, 8 Jun 2000 16:00:51 GMT
Message-ID: <20000608160050.6160.qmail@web5101.mail.yahoo.com>
Received: from [169.144.16.187] by web5101.mail.yahoo.com; Thu, 08 Jun 2000 09:00:50 PDT
Date: Thu, 8 Jun 2000 09:00:50 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk



larry,
I have a few doubts. Please pardon my ignorance.

In message
<4.1.20000607140754.00a9b640@mail.neta.com>, Larry Cox
writes:
> At 11:56 AM 6/7/00 -0700, Bora wrote:
> >Yakov,
> >
> >It is a well known fact at this point we can make
IP lookups as fast we can
> >do MPLS lookups.
Do you really think it is true ? I am not aware of any
10G LPM fabric. I am not sure that LPM is as fast as
a label lookup as yet. And I am not even talking about
the cost yet. 

In any case if it is true, should we not simply drop
point 3 of MPLS charter.

> >
> >So the lookup speed advantage of MPLS does not
exist anymore which I believe
> >was the point that was being raised.
> >
> >Bora (just catching up with my old mail)
> 
> (Initially I sent this off list but I think it may
be applicable to a list
> topic)
> 
> When one has 120K+ VoIP calls active on one OC192
fiber link and it becomes
> necessary to move these calls enmass from route a to
route b, moving a
> labled path is much easier than handling all of the
IP routing. It is
> rather important to not have major underruns or
overruns in the audio path
> at the receiving end. Ideally, 200MSec or less to
re-route all 120K+ voice
> streams is prefered (30 MSec to avoid underruns).
> 
> Larry 

Again I am not sure I understand. are u saying that
the
Router/switch at the ingress is aware of the VoIP
calls. Again, I am not sure. 

Could you please explain ?

C.





Larry,

One might consider using CIDR addressing so that only
a few prefixes
were rerouted.  I seriously doubt anyone would
advertise 120K /32 IP
prefixes to handle 120K voice streams.  In this
respect, MPLS can be
considered to be another form of route (or more
correctly control
information) aggregation.

The major benefit of MPLS in your example would come
from MPLS
local-protect.  Note that without local-protect, the
one way delay
back to the ingress could exceed the 30msec.  Quite
obviously, no IGP
would converge in that time so IP routing wouldn't
respond in that
kind of time, but neither would MPLS reroute initiated
at the ingress.

Curtis


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com



From owner-mpls@UU.NET  Thu Jun  8 12:12:02 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10542
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 12:12:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisse13854;
	Thu, 8 Jun 2000 16:11:02 GMT
Received: by mail-control.mail.uu.net 
	id QQisse05150
	for mpls-outgoing; Thu, 8 Jun 2000 16:10:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisse05136
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 16:10:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisse27767
	for <mpls@uu.net>; Thu, 8 Jun 2000 12:08:40 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQisse04412
	for <mpls@uu.net>; Thu, 8 Jun 2000 16:08:40 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA15104
	for <mpls@uu.net>; Thu, 8 Jun 2000 09:08:48 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA01156 for mpls@uu.net; Thu, 8 Jun 2000 12:08:38 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisse04403
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 16:03:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissd26820
	for <mpls@UU.NET>; Thu, 8 Jun 2000 11:59:47 -0400 (EDT)
Received: from thumper.research.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thumper.research.telcordia.com [128.96.41.1])
	id QQissd27698
	for <mpls@UU.NET>; Thu, 8 Jun 2000 15:59:46 GMT
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e58Fxgd10117;
	Thu, 8 Jun 2000 11:59:44 -0400 (EDT)
Received: from localhost (ohba@tari-dhcp4.research.telcordia.com [207.3.232.118])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA21188;
	Thu, 8 Jun 2000 11:59:38 -0400 (EDT)
To: jleu@mindspring.com
Cc: rhthomas@cisco.com, mpls@UU.NET
Subject: Re: Address Message in LDP
In-Reply-To: <20000607131429.C9353@doit.wisc.edu>
References: <20000607095151.A9353@doit.wisc.edu>
	<200006071533.LAA16375@rhthomas-sun2.cisco.com>
	<20000607131429.C9353@doit.wisc.edu>
X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Bryce Canyon)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000608073534X.yohba@tari.toshiba.com>
Date: Thu, 08 Jun 2000 07:35:34 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
X-Dispatcher: imput version 991025(IM133)
Lines: 64
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

From: "James R. Leu" <jleu@mindspring.com>
Subject: Re: Address Message in LDP
Date: Wed, 7 Jun 2000 13:14:29 -0500

> On Wed, Jun 07, 2000 at 11:33:26AM -0400, Bob Thomas wrote:
> 
> <snip>
> 
> > I think you are making this more complicated that it need be.
> >
> > The purpose of the Address Message is to make it possible for an LSR
> > to establish a mapping between the first 4 octets of a peer's LDP Id
> > and addresses bound to the peer.
> > 
> > This mapping is useful in determining whether the peer is the next
> > hop for a particular prefix.
> 
> I understand your second statement (the first about me making it more
> complicated then it need be is always true :-).  With respect to the third
> statement, are you saying that this mapping is or is not the ONLY way to
> figure out if a peer is the next hop for a particular prefix?
> 
> My goal is to get an answer about "non-Directly Connected LSRs" and
> how they guarantee that they are distributing labels and installing them
> on the correct interfaces.
> 
> The way to get the above answer may involve or mimic the way we deal with
> mappings over parallel links between two directly connected LDP peers.
> 
> If I have LDP sessions over parallel links and a particular prefix is
> preferred over only one link, the peer closer to egress may provide mappings for
> this prefix via both sessions.  If I use the address list as my definitive
> source for which session is the next hop, both sessions will match.
> 
> What other information do we use in this case to decide whether or not
> a particular session is ACTUALLY the next hop for a particular prefix?
> 

In the case of parallel links between directly connected LDP peers,
there is another method to obtain the correct mapping between the next
hop and a session:

1. Find an interface that matches the next hop.

2. Find an LDP peer that matches the interface found in step 1.
   Since the interface is on a point-to-point link, at most one LDP
   peer will match that interface.  Note that the mapping between
   an LDP peer and an interface is determined during LDP Link Hello
   message exchange.

I think this method is useful in the case where there is a possibility
that two or more LDP peers on the same neighboring LSR may advertise
overlapping address lists in their Address messages.  Of course, this
is not necessaly if the implementation is good (or complicated?) 
enough to advertise non-overlapping address lists.

Yoshihiro Ohba

> Jim
> -- 
> James R. Leu




From owner-mpls@UU.NET  Thu Jun  8 13:08:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12212
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 13:08:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissi22042;
	Thu, 8 Jun 2000 17:07:31 GMT
Received: by mail-control.mail.uu.net 
	id QQissi18864
	for mpls-outgoing; Thu, 8 Jun 2000 17:06:50 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQissi18843
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 17:06:35 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissi07752
	for <mpls@uu.net>; Thu, 8 Jun 2000 13:05:48 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQissi14297
	for <mpls@uu.net>; Thu, 8 Jun 2000 17:05:47 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA22959
	for mpls@uu.net; Thu, 8 Jun 2000 13:05:46 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQissi18660
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 17:05:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQissi08269
	for <mpls@UU.NET>; Thu, 8 Jun 2000 13:05:04 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQissi19598
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:05:03 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP id 01A11180
	for <mpls@UU.NET>; Thu,  8 Jun 2000 19:05:02 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp10.cisco.com [144.254.60.32])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id TAA21997
	for <mpls@UU.NET>; Thu, 8 Jun 2000 19:05:01 +0200 (MET DST)
Message-Id: <200006081705.TAA21997@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Thu, 08 Jun 2000 19:00:15 +0200
To: mpls@UU.NET
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Annoucing <draft-ietf-mpls-diff-ext-05.txt>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

We've just posted <draft-ietf-mpls-diff-ext-05.txt>. It should be available on the IETF server shortly.

This is an update on 04.txt. The main point is the resolution of the single issue left open by 04.txt (after the "informal last call) which is details ingress/egress Diff-Serv behavior when pushing and popping labels (including hierarchical operations). The principles of the resolution for this have already been described on the alias in March (see message below).

Other changes are relatively minor:
	- clean up of mappings in differnet cases involving ATM/FR (eg LC or non LC interfaces)
	- typos/clarifications

As indicated earlier, we will ask the WG chairs to issue an official WG Last Call.

Francois


>X-Sender: flefauch@europe.cisco.com
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
>Date: Thu, 23 Mar 2000 19:10:14 +0100
>To: mpls@UU.NET
>From: Francois Le Faucheur <flefauch@cisco.com>
>Subject: Proposal for last open issue re draft-ietf-mpls-diff-ext-04.txt
>Cc: flefauch@europe.cisco.com, bsd@cisco.com, flefauch@cisco.com,
>        liwwu@europe.cisco.com, pasi.vaananen@ntc.nokia.com,
>        ram@nexabit.com ('Ram Krishnan'),
>        Shahram_Davari@pmc-sierra.com (Shahram Davari),
>        Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi
>Sender: owner-mpls@UU.NET
>X-SMTP-HELO: wodc7-1.corprelay.mail.uu.net
>X-SMTP-MAIL-FROM: owner-mpls@UU.NET
>X-SMAP-Received-From: outside
>X-SMTP-PEER-INFO: wodc7-1.corprelay.mail.uu.net [192.48.96.68]
>
>Hello,
>
>A single issue from the Informal Last Call on
>draft-ietf-mpls-diff-ext-03.txt had not been closed as of
>draft-ietf-mpls-diff-ext-04.txt. This is the detailed ingress and egress
>Diff-Serv behavior when pushing and popping labels.
>
>Here is a high level proposal for resolution of this issue.
>
>The proposal borrows heavily from draft-ietf-diffserv-tunnels-00.txt,
>'Differentiated Services and Tunnels' from D Black.
>
>Most of the characteristics of the problem statement addressed by this
>draft are common with the issue we need to address in
>draft-ietf-mpls-diff-ext-04.txt:
>	- intermediate nodes only see and operate on the "outer" Diff-Serv
>information
>	- IP tunnels/LSPs Tunnels are unidirectionnal
>	- the outer Diff-SErv information may get modified somewhere on the span
>of the IP Tunnel/LSP Tunnel
>
>There is a few notable differences between an LSP Tunnel and an IP Tunnel
>though:
>	- Penultimate Hop Popping (PHP) results in the LSP Tunnel Diff-SErv
>information not being transmitted to the LSP Tunnel Egress.
>	- two level LSP Tunnels from same ingress to same egress are expected to
>be common occurence in MPLS-land for MPLS VPN so we need to address this
>case. I have only covered below the case of unlabelled packets going into a
>two level LSP tunnel because MPLS VPN is the only case I can think of for
>this two level LSP tunnels.
>
>Based on this, I would propose that:
>
>	- like with draft-ietf-mpls-diff-ext-04.txt, we recognise that there are
>two meaningful conceptual models which are "Uniform" model and "Tunnel" model.
>
>	- like with draft-ietf-mpls-diff-ext-04.txt, we recognise that they are
>both useful.
>
>	- unlike with draft-ietf-mpls-diff-ext-04.txt, we can play with PHP to
>simplify operations of the egress in case of single level LSP Tunnel
>
>	- for single level LSP Tunnel, to achieve "tunnel" mode:
>		* Ingress: Egress PHB is reflected in pushed label. Egress PHB is NOT
>reflected in swapped label or encapsulated IP DSCP.
>		* Egress: requests PHP and therefore use "outer" Diff-Serv info for
>incoming PHB determination (ie outer label for received labelled packet or
>DSCP for received unlabelled packet).
>
>	- for single level LSP Tunnel, to achieve "uniform" mode:
>		* Ingress: Egress PHB is reflected in pushed label. It does not matter if
>Egress PHB is also reflected in swapped label or encapsulated IP DSCP since
>this will be rewritten at egress ayway.
>		* Egress: requests No-PHP and use "outer" Diff-Serv info for incoming PHB
>determination (ie outer label before POP for received labelled packet, or
>DSCP for received unlabelled packet). 
>
>	- for two level LSP Tunnel (MPLS VPN), to achieve "tunnel" mode:
>		* Ingress: Egress PHB is reflected in both pushed labels. Egress PHB is
>NOT reflected in encapsulated IP DSCP.
>		* Egress: requests PHP but still can NOT use "outer" label for incoming
>PHB determination. Egress must be able to use the DSCP of the packet (as
>exposed after the POP) to do PHB determination. In other words, Egress must
>be able to (logically) do the PHB determination after the POP.
>
>	- for two level LSP Tunnel (MPLS VPN), to achieve "uniform" mode:
>		* Ingress: Egress PHB is reflected in both pushed labels. It does not
>matter if it is also reflected in encapsulated IP DSCP since this will be
>rewritten at egress ayway.
>		* Egress: requests PHP anyway (because with MPLS VPNs both labels are
>expected to reflect the same PHB) and use "outer" label/or DSCP for
>incoming PHB determination (before doing POP).In other words, Egress must
>be able to (logically) do the PHB determination before the POP.
>
>
>Thanks for comments. 
>As soon as we've reached agreement I will proposed detailed text for the
>next rev of the draft.
>
>Francois
>
>_________________________________________________________________
>Francois Le Faucheur   
>Development Engineer, IOS Layer 3 Services 
>Cisco Systems 
>Office Phone:   	+33 4 92 96 75 64
>Home Office Phone:     +33 4 92 94 00 78
>Mobile :               +33 6 89 108 159
>Vmail:                 +33 1 58 04 62 66
>Fax:                   +33 4 92 96 79 08
>Email:          	flefauch@cisco.com
>_________________________________________________________________
>Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
>_________________________________________________________________ 
> 





From owner-mpls@UU.NET  Thu Jun  8 13:24:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12537
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 13:24:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissj26536;
	Thu, 8 Jun 2000 17:23:46 GMT
Received: by mail-control.mail.uu.net 
	id QQissj20407
	for mpls-outgoing; Thu, 8 Jun 2000 17:23:16 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQissj20401
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 17:23:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQissj11341
	for <mpls@UU.NET>; Thu, 8 Jun 2000 13:22:37 -0400 (EDT)
Received: from osf1.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: osf1.gmu.edu [129.174.1.13])
	id QQissj03358
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:22:37 GMT
Received: from localhost (adasgupt@localhost)
	by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id NAA09452;
	Thu, 8 Jun 2000 13:22:14 -0400 (EDT)
Date: Thu, 8 Jun 2000 13:22:14 -0400 (EDT)
From: Arunima Dasgupta <adasgupt@osf1.gmu.edu>
To: schrijvp@rc.bel.alcatel.be
cc: mpls@UU.NET
Subject: Fw: LDP notification 
Message-ID: <Pine.OSF.4.21.0006081309120.3929-100000@osf1.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Peter,
   Please see my comments below....


----- Original Message -----
From: De Schrijver Peter <schrijvp@rc.bel.alcatel.be>
To: <mpls@UU.NET>
Sent: Monday, May 29, 2000 6:46 AM
Subject: LDP notification


> Hi,
>
> I have some questions about the interpretation of an LDP notification
> message.
> What is an LSR supposed to do when it receives a notification
> with an unknown status data field, the E-bit clear and the F-bit set ?

The unknown TLV is ignored and the rest of the message is processed as if
the unknown TLV did not exist.  Then the unknown TLV is forwarded with the
containing message.  Please see "3.3. Type-Length-Value Encoding" of
draft-ietf-mpls-ldp-07.txt.

> The message ID refers to a label request. Is the LSR supposed to
> teardown the LSP or not ?


If E-bit is set, the LSR closes the TCP connection and discards all label
mappings learned via the session.  If E-bit is clear, the processing of the
message will depend on U and F bits.  Please see "1.4. LDP Error Handling"
of draft-ietf-mpls-ldp-07.txt.

Should the LSR forward the notification
> message and also include TLV's unknown to the LSR but with both U and F
bits
> set ?    

   Yes.

> Peter.


regards
Arunima



From owner-mpls@UU.NET  Thu Jun  8 13:59:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13074
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 13:59:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissl28766;
	Thu, 8 Jun 2000 17:57:52 GMT
Received: by mail-control.mail.uu.net 
	id QQissl22885
	for mpls-outgoing; Thu, 8 Jun 2000 17:57:26 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQissl22851
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 17:57:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissl17247
	for <mpls@UU.NET>; Thu, 8 Jun 2000 13:56:40 -0400 (EDT)
Received: from osf1.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: osf1.gmu.edu [129.174.1.13])
	id QQissl18619
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:56:39 GMT
Received: from localhost (rpapneja@localhost)
	by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id NAA05560;
	Thu, 8 Jun 2000 13:56:34 -0400 (EDT)
Date: Thu, 8 Jun 2000 13:56:34 -0400 (EDT)
From: Rajiv Papneja <rpapneja@osf1.gmu.edu>
To: Larry Cox <lcox@neta.com>
cc: mpls@UU.NET
Subject: RE: MPLS Performance analysis..... 
In-Reply-To: <4.1.20000607140754.00a9b640@mail.neta.com>
Message-ID: <Pine.OSF.4.21.0006081354430.10629-100000@osf1.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, 7 Jun 2000, Larry Cox wrote:

> At 11:56 AM 6/7/00 -0700, Bora wrote:
> >Yakov,
> >
> >It is a well known fact at this point we can make IP lookups as fast we can
> >do MPLS lookups.
> >
> >So the lookup speed advantage of MPLS does not exist anymore which I believe
> >was the point that was being raised.
> >
> >Bora (just catching up with my old mail)
> 
> (Initially I sent this off list but I think it may be applicable to a list
> topic)
> 
> When one has 120K+ VoIP calls active on one OC192 fiber link and it becomes
> necessary to move these calls enmass from route a to route b, moving a
> labled path is much easier than handling all of the IP routing. It is
> rather important to not have major underruns or overruns in the audio path
> at the receiving end. Ideally, 200MSec or less to re-route all 120K+ voice
> streams is prefered (30 MSec to avoid underruns).
> 
> Larry 


  Hi Larry,

  I would support your point here, but this could only be possible with
use of local repairs as it is the key to maintaining voice calls and other
high priority sevices.

  In MPLS, there are couple of techniques available with which this could
be achieved. This could be either splicing or Label stacking. In the
former technique an alternate LSP is pre-established from the point of
protection to the destination through a path bypassing the downstream
elements that are being protected. Once the failure is detected, the
Forwarding entry for the protested LSP is updated to use the label of the
bypass tunnel. The latter method of local repair uses the advantages of
label stacking.

 Further, this could make the repairs happen in the same time frame as the
SONET restoration.     

 There are some drafts available at the ietf site which refer to
these, like  draft-swallow-rsvp-bypass-label-00.txt.

 Take care

 Rajiv
 


> 
> 

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4700
email: rpapneja@osf1.gmu.edu
********************************



From owner-mpls@UU.NET  Thu Jun  8 14:01:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13183
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 14:01:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissm21456;
	Thu, 8 Jun 2000 18:00:10 GMT
Received: by mail-control.mail.uu.net 
	id QQissl23134
	for mpls-outgoing; Thu, 8 Jun 2000 17:59:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQissl23116
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 17:59:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQissl17919
	for <mpls@uu.net>; Thu, 8 Jun 2000 13:59:17 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQissl29956
	for <mpls@uu.net>; Thu, 8 Jun 2000 17:59:16 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA02501
	for mpls@uu.net; Thu, 8 Jun 2000 13:59:15 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQissl23038
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 17:58:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQissl17707
	for <mpls@UU.NET>; Thu, 8 Jun 2000 13:58:24 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQissl29321
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:58:21 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA14111;
	Thu, 8 Jun 2000 10:58:08 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <LG4MC6LX>; Thu, 8 Jun 2000 10:58:08 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B405EE@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Indra.Widjaja'" <Indra.Widjaja@tddny.fujitsu.com>
Cc: mpls@UU.NET
Subject: RE: OAM labels (was: can egress know the ingress of a packet?)
Date: Thu, 8 Jun 2000 10:55:11 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Indra,

>-----Original Message-----
>From: Indra.Widjaja [mailto:Indra.Widjaja@tddny.fujitsu.com]
>Sent: Wednesday, June 07, 2000 4:28 PM
>To: Shahram Davari
>Cc: 'Theimer Thomas'; 'Ross Callon'; mpls@UU.NET
>Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
>
>
>Shahram:
>Thanks for your clarification.
>I was slow and didn't read the message from Thomas.
>As he said in his later message, the LSP can be identified in the
>body of the OAM packet if needed (which is still to be defined),
>so the problem can be solved, right?

Not exactly. What if there are hierarchical tunnels and the egress of one
tunnel is the intermediate node of another tunnel. Then you can't identify
the LSP by looking at the body of the OAM packet, because the OAM packet
belongs to many LSPs (i.e., hierarchical LSPs). Right?

-Shahram

>indra
>
>
>Shahram Davari wrote:
>
>> Indra,
>>
>> There is no problem in sending the packet to OAM processor. 
>The problem is
>> when the packet is received by OAM processor, because the 
>forwarding label
>> is not present any more, how can the OAM processor determine 
>which LSP this
>> OAM packet belonged to. Because the processing of the OAM 
>packet will depend
>> on identifying the LSP.
>>
>> -Shahram
>>
>> >-----Original Message-----
>> >From: Indra.Widjaja [mailto:Indra.Widjaja@tddny.fujitsu.com]
>> >Sent: Wednesday, June 07, 2000 1:41 PM
>> >To: Shahram Davari
>> >Cc: 'Theimer Thomas'; 'Ross Callon'; mpls@UU.NET
>> >Subject: Re: OAM labels (was: can egress know the ingress 
>of a packet?)
>> >
>> >
>> >Shahram:
>> >I still don't understand what the problem really is.
>> >The penultimate LSR forwards the packet to the egress LSR
>> >based on the user data label that was just popped out.
>> >When the packet with the OAM label arrives at the egress
>> >LSR, the egress LSR should be able to direct the OAM
>> >packet to the proper OAM handler.
>> >Does this work?
>> >indra
>> >
>> >
>> >Shahram Davari wrote:
>> >
>> >> Theimer,
>> >>
>> >> I think what Ross meant was that using PHP, when OAM label
>> >is below the
>> >> forwarding label, the egress node can't determine the LSP
>> >that the OAM
>> >> packet belongs to.
>> >>
>> >> Regards,
>> >> -Shahram
>> >>
>> >> >-----Original Message-----
>> >> >From: Theimer Thomas [mailto:Thomas.Theimer@icn.siemens.de]
>> >> >Sent: Wednesday, June 07, 2000 5:10 AM
>> >> >To: 'Ross Callon'
>> >> >Cc: mpls@UU.NET
>> >> >Subject: RE: OAM labels (was: can egress know the ingress
>> >of a packet?)
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From:        Ross Callon [SMTP:rcallon@juniper.net]
>> >> >> To:  Theimer Thomas; 'Shahram Davari'; 'Peter Willis'
>> >> >>
>> >> >> If the outer label identifies the LSP, and the inner label is a
>> >> >> special OAM value, then I think that there is a problem with
>> >> >> penultimate hop label popping.
>> >> >       [Theimer Thomas]  Good point. We missed that. 
>However, if the
>> >> >penultimate hop removes the top label, the egress node will
>> >receive the
>> >> >packet with an OAM label on top. That would still trigger OAM
>> >> >processing in
>> >> >the egress node, so I don't necessarily see a problem here,
>> >except that
>> >> >perhaps the egress node needs to be an LSR. If not, then in
>> >my view the
>> >> >penultimate hop is really the logical endpoint of the LSP,
>> >and should
>> >> >process the OAM label if present. However, I must admit I
>> >don't clearly
>> >> >understand how penultimate hop popping is really applied in a
>> >> >network. I
>> >> >also could not find any explicit support in LDP, CR-LDP and
>> >> >TE-RSVP. Without
>> >> >such support, is anyone actually using that mechanism in 
>practice ?
>> >> >
>> >> >       Thomas
>> >> >
>> >> >
>> >
>



From owner-mpls@UU.NET  Thu Jun  8 15:32:17 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15102
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 15:32:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisss27252;
	Thu, 8 Jun 2000 19:30:57 GMT
Received: by mail-control.mail.uu.net 
	id QQisss19755
	for mpls-outgoing; Thu, 8 Jun 2000 19:30:33 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisss19747
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 19:30:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisss05865
	for <mpls@uu.net>; Thu, 8 Jun 2000 15:30:22 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisss26591
	for <mpls@uu.net>; Thu, 8 Jun 2000 19:30:20 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA17899
	for mpls@uu.net; Thu, 8 Jun 2000 15:30:19 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQissr19687
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 19:29:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissr05562
	for <mpls@uu.net>; Thu, 8 Jun 2000 15:29:32 -0400 (EDT)
Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5])
	id QQissr25813
	for <mpls@uu.net>; Thu, 8 Jun 2000 19:29:31 GMT
Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21)
	id <MC1NZP3B>; Thu, 8 Jun 2000 15:29:31 -0400
Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEB82@brixcorp2.brixnet.com>
From: "Cucchiara, Joan" <JCucchiara@Brixnet.com>
To: "'rhthomas@cisco.com'" <rhthomas@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Last Call for LDP
Date: Thu, 8 Jun 2000 15:29:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


Bob,

My understanding is that the Frame Relay Forum has
dropped support for 17-bit DLCIs.  The LDP MIB and
LSR MIB (drafts) are not supporting 17-bit FrameRelay
labels.

I would like to request that references to 17-bit DLCI
Frame Relay labels be removed from the LDP Specification.
Admittedly, this was not an issue during the prior last
call because the 17-bit FR DLCIs were still being supported
by the FRF during that time.  

This change would more closely align the LDP spec with the 
LDP MIB and LSR MIB.

   Thank you, Joan

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Wednesday, June 07, 2000 2:25 PM
> To: mpls@UU.NET
> Subject: Last Call for LDP
> 
> 
> This message signals the begining of a last call on LDP.  This last
> call is limited to the changes made in draft -07 to address the issues
> raised in the previous last call.
> 
> The last call ends at 12 pm GMT Wednesday 6/14.
> 
> ...George
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 
> 
> 



From owner-mpls@UU.NET  Thu Jun  8 15:54:11 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15398
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 15:54:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisst20557;
	Thu, 8 Jun 2000 19:52:45 GMT
Received: by mail-control.mail.uu.net 
	id QQisst21518
	for mpls-outgoing; Thu, 8 Jun 2000 19:52:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisst21505
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 19:52:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisst09853
	for <mpls@uu.net>; Thu, 8 Jun 2000 15:51:49 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisst13289
	for <mpls@uu.net>; Thu, 8 Jun 2000 19:51:48 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA22058
	for mpls@uu.net; Thu, 8 Jun 2000 15:51:47 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisst21428
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 19:51:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisst09742
	for <mpls@UU.NET>; Thu, 8 Jun 2000 15:51:15 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisst19496
	for <mpls@UU.NET>; Thu, 8 Jun 2000 19:51:14 GMT
Received: from rschmitt-nt (ch2-dhcp134-243.cisco.com [161.44.134.243])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA21953;
	Thu, 8 Jun 2000 15:51:12 -0400 (EDT)
Message-Id: <4.2.0.58.20000608155349.00a6f100@pilgrim.cisco.com>
X-Sender: rschmitt@pilgrim.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 08 Jun 2000 15:55:47 -0700
To: "Cucchiara, Joan" <JCucchiara@Brixnet.com>
From: Rob Schmitt <rschmitt@cisco.com>
Subject: RE: Last Call for LDP
Cc: <mpls@UU.NET>
In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB2AEB82@brixcorp2.brixnet.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

LDP MIB authors:

Last time I saw a rev, it was '05' and the MODULE-ID
was set at 'experiment XXX'.  Is a valid experiment
number contemplated to be acquired from the
appropriate authority?
Thanks
/rs

At 03:29 PM 6/8/00 -0400, Cucchiara, Joan wrote:

>Bob,
>
>My understanding is that the Frame Relay Forum has
>dropped support for 17-bit DLCIs.  The LDP MIB and
>LSR MIB (drafts) are not supporting 17-bit FrameRelay
>labels.
>
>I would like to request that references to 17-bit DLCI
>Frame Relay labels be removed from the LDP Specification.
>Admittedly, this was not an issue during the prior last
>call because the 17-bit FR DLCIs were still being supported
>by the FRF during that time.
>
>This change would more closely align the LDP spec with the
>LDP MIB and LSR MIB.
>
>    Thank you, Joan
>
> > -----Original Message-----
> > From: George Swallow [mailto:swallow@cisco.com]
> > Sent: Wednesday, June 07, 2000 2:25 PM
> > To: mpls@UU.NET
> > Subject: Last Call for LDP
> >
> >
> > This message signals the begining of a last call on LDP.  This last
> > call is limited to the changes made in draft -07 to address the issues
> > raised in the previous last call.
> >
> > The last call ends at 12 pm GMT Wednesday 6/14.
> >
> > ...George
> >
> > ======================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
> >
> >
> >
> >
>

+-----------------------------------------------------------------+
       Robert Schmitt            CISCO SYSTEMS
       rschmitt@cisco.com
       Chelmsford, MA              978-244-3076
+----------------------------------------------------------------+





From owner-mpls@UU.NET  Thu Jun  8 16:19:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15841
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 16:19:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissv08919;
	Thu, 8 Jun 2000 20:18:50 GMT
Received: by mail-control.mail.uu.net 
	id QQissv03225
	for mpls-outgoing; Thu, 8 Jun 2000 20:18:33 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQissv03217
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 20:18:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissv14574
	for <mpls@UU.NET>; Thu, 8 Jun 2000 16:17:52 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQissv02131
	for <mpls@UU.NET>; Thu, 8 Jun 2000 20:17:51 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id QAA18209; Thu, 8 Jun 2000 16:17:45 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id QAA18383;
	Thu, 8 Jun 2000 16:18:04 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006082018.QAA18383@curtis-lt.avici.com>
To: Yangguang Xu <xuyg@lucent.com>
cc: Juan Diego Otero <jote4102@alu-etsetb.upc.es>, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS and fast reroute. 
In-reply-to: Your message of "Thu, 08 Jun 2000 09:25:04 EDT."
             <393F9EB0.D17E15AA@lucent.com> 
Date: Thu, 08 Jun 2000 16:18:04 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <393F9EB0.D17E15AA@lucent.com>, Yangguang Xu writes:
> 
> For example, at least QoS has to be guaranteed to differentiate
> protection switching messages from other traffic. 


The granularity for MPLS protection is the LSP while the granularity
for SONET is the link itself.  It is therefore much easier to put
higher priority trraffic on different LSPs from lower priority traffic
and provide local-protect for the former and require the latter to
reroute from the ingress.

Curtis



From owner-mpls@UU.NET  Thu Jun  8 16:47:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16468
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 16:47:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissx26591;
	Thu, 8 Jun 2000 20:47:04 GMT
Received: by mail-control.mail.uu.net 
	id QQissx05012
	for mpls-outgoing; Thu, 8 Jun 2000 20:46:35 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQissx04996
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 20:46:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissx22404
	for <mpls@UU.NET>; Thu, 8 Jun 2000 16:45:54 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQissx25573
	for <mpls@UU.NET>; Thu, 8 Jun 2000 20:45:53 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MRJ2MS7X>; Thu, 8 Jun 2000 13:51:48 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690762@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Joan Cucchiara'" <JCucchiara@Brixnet.com>
Cc: "'MPLS Mailing list'" <mpls@UU.NET>, "'Bob Thomas'" <rhthomas@cisco.com>
Subject: RE: Last Call for LDP
Date: Thu, 8 Jun 2000 13:51:47 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Joan,

	I had heard the same from Andy Malis.
That's why I was a little surprised to discover
that this same issue exists in the latest draft 
for MPLS over Frame Relay.  

	I think that LDP needs to be consistent
with the Frame Relay MPLS draft.  I'm not sure
which should be fixed...

--
Eric Gray

> -----Original Message-----
> From: Cucchiara, Joan [mailto:JCucchiara@Brixnet.com]
> Sent: Thursday, June 08, 2000 12:29 PM
> To: 'rhthomas@cisco.com'
> Cc: 'mpls@uu.net'
> Subject: RE: Last Call for LDP
> 
> 
> 
> Bob,
> 
> My understanding is that the Frame Relay Forum has
> dropped support for 17-bit DLCIs.  The LDP MIB and
> LSR MIB (drafts) are not supporting 17-bit FrameRelay
> labels.
> 
> I would like to request that references to 17-bit DLCI
> Frame Relay labels be removed from the LDP Specification.
> Admittedly, this was not an issue during the prior last
> call because the 17-bit FR DLCIs were still being supported
> by the FRF during that time.  
> 
> This change would more closely align the LDP spec with the 
> LDP MIB and LSR MIB.
> 
>    Thank you, Joan
> 
> > -----Original Message-----
> > From: George Swallow [mailto:swallow@cisco.com]
> > Sent: Wednesday, June 07, 2000 2:25 PM
> > To: mpls@UU.NET
> > Subject: Last Call for LDP
> > 
> > 
> > This message signals the begining of a last call on LDP.  This last
> > call is limited to the changes made in draft -07 to address 
> the issues
> > raised in the previous last call.
> > 
> > The last call ends at 12 pm GMT Wednesday 6/14.
> > 
> > ...George
> > 
> > 
> ======================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
> > 
> > 
> > 
> > 
> 


From owner-mpls@UU.NET  Thu Jun  8 17:15:48 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17030
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 17:15:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQissy26065;
	Thu, 8 Jun 2000 21:14:36 GMT
Received: by mail-control.mail.uu.net 
	id QQissy15883
	for mpls-outgoing; Thu, 8 Jun 2000 21:14:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQissy15874
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:13:58 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQissy26704
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:13:32 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQissy15315
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:13:26 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id RAA22823; Thu, 8 Jun 2000 17:13:02 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id RAA18449;
	Thu, 8 Jun 2000 17:13:13 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006082113.RAA18449@curtis-lt.avici.com>
To: Peter Willis <pjw@ip-engineering.bt.com>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-reply-to: Your message of "Thu, 08 Jun 2000 16:59:23 BST."
             <200006081559.QAA16021@celiborn.ip-engineering.bt.com> 
Date: Thu, 08 Jun 2000 17:13:13 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200006081559.QAA16021@celiborn.ip-engineering.bt.com>, Peter Willis
 writes:
> > The issue then
> > becomes specifying how pings and counters on the LSRs should be
> > handled in order to notify the NMS.  Some might argue that this is out
> > of scope for the MPLS WG.
> > Curtis
> 
> I can see that a system employing pingers on CPE, polling of counters, 
> monitors of iBGP and other control plane aspects would deliver some of the OA
> M 
> requirements.


Welcome to the world of Internet operations.  Simple things that work
is what got us this far.  I'm still a bit skeptical about the OAM
approach.


> By the way a common cause of internal "data rot" is software with bugs
> in it so a system that can handle software and hardware failures is highly
> desirable.
> 
> Peter.


This is true.  The point is that the control plane and the forwarding
hardware have different information.  This is supposed to be a very
rare exception and it is supposed to get fixed.  If the software
works, then microcode or hardware may fail.  This is supposed to be
even more rare.  However, unlike software, hardware doesn't last
forever and is expected to eventually fail.  It is better if it
doesn't fail in subtle ways, hence my comment on parity or ECC in
internal hardware data paths and even data registers where possible.


Back to the requirement.  We have, in order of expected frequency, the
following types of failures:

  1.  Failures that are detected by the control plane.  For example,
      link failures or complete hardware component failures.

  2.  Software failures that are not detectable at the control plane.
      These will exist iff there remain software bugs which allow
      inconsistencies between control plane software and low level
      software or hardware.

  3.  Hardware failures that are not detectable at the control plane.
      These will exist iff there remain data paths or highly
      persistent data storage (like forwarding tables) that is not
      protected by ECC or parity.

OAM is not needed for the first set because the control plane will
recover and/or report the fault.

The third case is better covered by making sure all registers can be
read back and periodically checking hardware registers to
make sure that they match the software copies.

The second and third cases can be detected by sending probe traffic
through the network (OAM) but 100% coverage cannot be assured.  

The problem may occur at:

  1.  ingress,
  2.  midpoint, or
  3.  egress.

For example, if the ingress node loses the hardware entry that is
supposed to map a given IP prefix into an LSP, the same ingress may
successfully inject OAM packets because those do not enter as IP with
that prefix.  This is probably by far the most common error and it is
not detectable by OAM packets.  This is also not detectable by ping
unless the ping uses an IP destination corresponding to the faulty
entry.  This is detectable by a traceroute, because traceroute is IP
and can have the identical destination (and source, but that gets a
bit more tricky) and can be given a limited TTL that just verifies the
tunnel.

Note that an RFC2547 style VPNs there are multiple forwarding tables
in the provider edge routers.  These forwarding tables can only be
verified by injecting traffic through the same interface that would
exercise the same table entries.  Sounds to me a lot like a ping would
do the job nicely while an OAM packet that already had an MPLS
encapsulation would not.

If a midpoint loses a hardware entry for a given label, and the OAM
packet has a special label that kicks the OAM packet to software to be
counted, checked, or manipulated in some way, it still hasn't caught
the problem where the hardware table for that label is wrong since it
consults software.

The OAM label is diverted at the egress before it hits the hardware
that does things like POP the label and adjust the packet length,
adjust the underlying TTL (if IP), ECN, etc.  So the OAM packet
doesn't detect this fault either.

One thing that might help, but is not ATM OAM like is some form of LQM
for MPLS.  For example, the ingress could place a packet into the
stream with the label stack it wants to measure and a special LQM
label (in the reserved range) below it and place LSP counters in the
underlying packet.  A special outsegment would be needed at the
ingress to put the label stack and current counters in place.  At the
egress, the last forwarding label would be POPed and the reserved
label would be revealed.  The hardware would have to place its LSP
counters in the packet and forward to software for exception
processing.  The software can then subtract the counters of two
successive MPLS LQM (as is done in RFC1989 PPP LQM) to determine the
traffic rate and loss along the LSP.  Only the ingress and egress
would need to do this.  If the egress didn't know how, it would count
and silently discard the packet and you'd be no worse off.

MPLS LQM would definitely require hardware change so expect to hear
some screams.  On the positive side, only the ingress and egress need
to do it and it can be deployed incrementally.

Curtis


From owner-mpls@UU.NET  Thu Jun  8 17:33:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17325
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 17:33:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQista29978;
	Thu, 8 Jun 2000 21:32:27 GMT
Received: by mail-control.mail.uu.net 
	id QQista17699
	for mpls-outgoing; Thu, 8 Jun 2000 21:32:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQista17694
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:32:02 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQista29673
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:31:54 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQista29391
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:31:54 GMT
Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id RAA07080;
	Thu, 8 Jun 2000 17:31:09 -0400 (EDT)
	(envelope-from bkumar@ennovatenetworks.com)
Reply-To: <bkumar@ennovatenetworks.com>
From: "Brijesh Kumar" <bkumar@ennovatenetworks.com>
To: <curtis@avici.com>, "'Yangguang Xu'" <xuyg@lucent.com>
Cc: "'Juan Diego Otero'" <jote4102@alu-etsetb.upc.es>, <mpls@UU.NET>
Subject: RE: MPLS and fast reroute. 
Date: Thu, 8 Jun 2000 17:34:59 -0400
Message-ID: <00aa01bfd191$66a7cf80$d001010a@tst.ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <200006082018.QAA18383@curtis-lt.avici.com>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> In message <393F9EB0.D17E15AA@lucent.com>, Yangguang Xu writes:
> >
> > For example, at least QoS has to be guaranteed to differentiate
> > protection switching messages from other traffic.
>
> The granularity for MPLS protection is the LSP while the granularity
> for SONET is the link itself.  It is therefore much easier to put
> higher priority trraffic on different LSPs from lower priority
traffic
> and provide local-protect for the former and require the latter to
> reroute from the ingress.

I would like to add a bit to Curtis's message.

I don't see a point in comparing essentially two altogether dis-joint
technologies. Moreover, it is meaningless to talk about QoS in the
context of APS in SONET as all services are being shifted on the
alternate path (including all MPLS LSPs). MPLS over SONET
automatically inherits all the virtues of SONET reliability.

MPLS local protection mechanisms (over non-SONET network) are purely
software "possibilities" at this point, but I hope some day techniques
imagined above will indeed be available. But we have to go from MPLS
(1) to MPLS with Diffserv (2) to MPLS with Diffserv with local-protect
(3). That sounds lot of coding work for lot of s/w persons;-).

SONET APS is available now, and there is more to SONET APS such as a
number of options can be considered in the deployment of SONET
architectures, including:

1) What is being protected: SONET has mechanisms to protect at either
the line or path level.

2) Which direction the signals flow in a ring: Signals can all route
in the same direction (unidirectional) or in opposite directions
(bidirectional).

3) How many fibers are being used in each link: Either one- or
two-pair (two- or four-fiber) configurations are selected.

The number of combinations in which these options can be employed
leads to a variety of SONET protection schemes. Some of the more
frequently used abbreviations of the SONET protection architectures
are Bidirectional line-switched ring (BLSR), Bidirectional
path-switched ring (BPSR), Unidirectional line-switched ring (ULSR),
Unidirectional path-switched ring (UPSR).

Whether MPLS can emulate such a wide variety of Protection options
over other networks can't be definitively answered yet. There is a
long way to go, before we reach there.

Cheers,

--brijesh
Ennovate Networks Inc.



From owner-mpls@UU.NET  Thu Jun  8 17:40:45 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17462
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 17:40:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQista06754;
	Thu, 8 Jun 2000 21:39:57 GMT
Received: by mail-control.mail.uu.net 
	id QQista18167
	for mpls-outgoing; Thu, 8 Jun 2000 21:39:25 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQista18162
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:39:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQista00619
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:39:02 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQista13775
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:39:02 GMT
Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP;
          Thu, 8 Jun 2000 22:38:00 +0100
Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVV0PWFS>; Thu, 8 Jun 2000 22:37:55 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B1605A@mbddmknt01.hc.bt.com>
To: pjw@ip-engineering.bt.com, mpls@UU.NET
Subject: RE: OAM functionality  
         (Was: RE: can egress know the ingressof a packet?)
Date: Thu, 8 Jun 2000 22:37:47 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

	Peter Willis observerd.......
	<SNIP>
	>In such a
	situation to get end-to-end MPLS OAM would require integration at
the NMS 
	level,
	an MPLS OAM standard would be an easier way of facilitating this
interworking

If you wait for this (ie TMN-like solutions) then you/I will have
retired....and probably our children too.  This has to be agreed at the
network user/control-plane level.

Neil


From owner-mpls@UU.NET  Thu Jun  8 17:40:54 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17473
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 17:40:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQista14770;
	Thu, 8 Jun 2000 21:40:14 GMT
Received: by mail-control.mail.uu.net 
	id QQista18174
	for mpls-outgoing; Thu, 8 Jun 2000 21:39:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQista18169
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:39:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQista00623
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:39:02 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQista13786
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:39:02 GMT
Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP;
          Thu, 8 Jun 2000 22:38:00 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWFYH01>; Thu, 8 Jun 2000 22:37:55 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16059@mbddmknt01.hc.bt.com>
To: curtis@avici.com, pjw@ip-engineering.bt.com
Cc: Ben.Mack-Crane@tellabs.com, otel@ce.chalmers.se,
        Shahram_Davari@pmc-sierra.com, EGray@zaffire.com, swtan@mmu.edu.my,
        kireeti@juniper.net, dwilder@baynetworks.com, mpls@UU.NET
Subject: RE: OAM functionality  
         (Was: RE: can egress know the ingressof a packet?)
Date: Thu, 8 Jun 2000 22:37:46 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

See comments below, Regards Neil

	[Harrison,N,Neil,INC1 X]  <Snip> 

> > As a network operator I have the following requirements:
> > - I need to detect failure of an LSP. (I don't want to wait for the
> > 	customer to report a failure)
> 
> This is a good requirement statement.
	[Harrison,N,Neil,INC1 X]  Good.  Then perhaps we can agree that all
defects need defining and tools providing to allow an operator to detect
them in advance of a customer reporting a fault.  So for LSPs there are at
least the following:
	-	simple connectivity failures (sourced from server or MPLS
layer......and we need to distinguish......note that ISP may not own
physical layer, cf earlier prot-sw issue on mail) 
	-	swapped LSPs
	-	mismerging of >=2 LSps
	-	self-mismerging
	As far as I can tell TTL is our only standardised OAM tool in the
MPLS layer.  This does not detect/diagnose any of above, but provides damage
limitation in case of self-mismerging.  A simple keepalive OAM pkt sent
periodically from the source of each LSP (and constaining the absolute LSP
source address) to its sink will however detect/diagnose all of these.
	I am open to better/other solutions.

> > 	There are more failure states of LSPs than standard destination
> > 	based routing because relative labels are used for switching. For
> > 	example we can have LSP traffic delivered to the wrong destination
> > 	by a simple bug on a single LSR (it is far less likely to happen
> > 	on an IP network using per hop routing because if
> > 	a router sends it the wrong way the next router will probably
> > 	send it back (get a routing loop) or send it the right way). How
> > 	do I (as an operator) detect this failure?
> 
> If it were a TE tunnel an IBGP adjacency going down be a real big
> hint.  This isn't supposed to happen (the tunnel going down without
> the control plane knowing about it).
	[Harrison,N,Neil,INC1 X]  If your customer's traffic was leaking
into another LSP how would this help detect and then diagnose it?  We are
considering more than simple breaks here.

> > 	Sure I could use a remote ping function on the customer premises 
> > 	equipment and when it fails raise an alarm. But I have to create
> > 	a full mesh of addresses to ping to cover all the customers
> > 	address space and sites (in the case of IP VPNs). This seems a bit
> > 	clumsy to me. And for IP VPNs what happens if the customers are
> using
> > 	the same 10.0.0.0 address space, chances are if my ping gets 
> > 	misdelivered they'll still be a box in somebody else's network that
> > 	will respond to the address I'm pinging (although we'll need 2
> faults
> > 	for that icmp echo-reply to get back).
> 
> OAM packets would not use the same hardware resources that the VPN
> traffic would unless they travel transparently in which case they
> would behave a lot like ping packets.
	[Harrison,N,Neil,INC1 X]  I thought Peter had already established
ping is not adequate.

> > 	When MPLS is used for TE what do I ping from where? If the TE trunk
> > 	fails won't I still get a response from ping because normal per-hop
> > 	based routing will take over? So we need a TE tunnel liveness
> > 	indicator.
> 
> Apparently the type of failure you are looking for is a mismatch
> between the control plane and the actual forwarding (an implementation
> bug or fault).
	[Harrison,N,Neil,INC1 X]  Not necessarily.  Why could there not be a
fault in the fowarding processing (in the user-plane) of which the
control-plane is in blissful ignorance? 
>   If the control plane knows of a failure, your NMS
> should know about it.
> 
> If the tunnel goes down and the control plane recovers by reverting to
> per-hop forwarding, then it ought to tell the NMS that it has done so.
	[Harrison,N,Neil,INC1 X]  If I had a pound (or even dollar) for each
time someone told me that the NMS should solve my problem I would a very
rich person.  I am not rich......and I am still waiting for the all-seeing
TMN solution 12 years after hearing it was 'coming soon'.  NMS solutions
should be a last resort IMHO.  Defects need to be handled in a distributed
manner at the network level......esp when one considers international
scenarios.

> > - I need tools to isolate where the fault is. Which LSR is causing the
> problem?
> > 	It would be useful if when I get a failure in the network the alarms
> > 	raised are a useful indicator of where the fault is. Then I can
> > 	start using tools like ping and traceroute to narrow down where
> > 	the fault is.
> 
> The type of fault you seem to be describing is where a label
> spontaneously evaporates or some similar occurance where the control
> plane is not aware that forwarding isn't working.
> 
> In some subset of such cases, counters that should normally be zero
> would be incremented.  For example, the fault may increment counters
> of labels for which there was no valid table entry or for which some
> internal table was invalid.  If no counters are incremented traffic
> levels should either fall to zero or differ radically at ingress and
> egress.
	[Harrison,N,Neil,INC1 X]  I would be grateful if you could please
explain how this works for all the misbranching cases I noted earlier.  If
all vendors can convince me they have identical solutions, and that my
operations people can diagnose the problem, and that customers will be
protected from leaking (out or in) traffic then OK.  Note - I really should
not rely on any customer generated traffic for diagnosis.....since this may
have large quiescent periods for one reason (and you did agree above that
customer's should not be used as the defect diagnosis tool). 

> For TE tunnels, a zero or near zero traffic rate would give an
> indication that such a fault had occurred,
	[Harrison,N,Neil,INC1 X]  This seems to indicate only a simple
connectivity break is being considered....it does not cater for the other
connectivity defects.
>  assuming that in an
> Internet backbone zero traffic never happens.  This is not a safe
> assumption for VPNs or enterprise since zero traffic can be possible.
	[Harrison,N,Neil,INC1 X]  Agreed...re above point that customers
traffic can be quiescent and the detection tool should not therefore rely on
customer traffic.

> For those cases were zero traffic is possible, add some traffic for
> the purpose of measurement (run a ping) and since you are pinging, you
> might as well verify that the pings go through.
	[Harrison,N,Neil,INC1 X]  Pings have problems as Peter pointed out
in prior mail.  Again this only considers simple breaks (though it might
detect some of the other misbranching cases....though at the wrong
point/layer).  Moreover, it does not address consequent actions.......which
are important, esp when LSPs are nested in a client/server layer
relationship.

> If a hardware fault has caused a table entry to rot, then using an OAM
> packet that takes a different path (handled via router alert label)
> would not detect the fault.
> 
> A big help in preventing this inability to detect faults is to put
> parity or ECC on internal data paths and where possible internal data
> sets.  This exposes the most common cause of internal data rot
> (unreliable internal data paths due to marginal or intermittent
> components that could otherwise result in the wrong value being set).
> 
> > Peter.
> 
> I don't see the point to specifying OAM packets if they do exactly
> what a ping would do and I don't yet see why the OAM packet would do
> anything different from ordinary traffic (therefore making pings a
> good candidate since they are ordinary traffic).
	[Harrison,N,Neil,INC1 X]  They don't.  We needs tools specific for
the MPLS layer itself.  And we need consequent actions defined, eg
forwarding of forward/backward defect indications to LSP trail terminations
points to take the appropriate consequent actions.
>   The issue then
> becomes specifying how pings and counters on the LSRs should be
> handled in order to notify the NMS.  Some might argue that this is out
> of scope for the MPLS WG.
	[Harrison,N,Neil,INC1 X]  I won't buy any OAM solutions that are
predicated on NMSs and their international co-operation.  Defects that
affect customer traffic have to be addressed/handled at the network level.

> One of the big problems with PVCs configured from the NMS (in ATM) had
> been the NMS missing one of the hops due to an undetected failure when
> trying to configure the switches.  In the absense of a control plane
> (use of PVCs) this can only be detected by some type of traffic not
> going through.  The same would be true of MPLS if it were used in this
> way.  Introducing OAM to MPLS in order to run without a control plane
> (configuring LSPs from the NMS) may be misguided logic.
	[Harrison,N,Neil,INC1 X]  Who is avocating this?

> Thats all from me on this.  If you still see a need for OAM packets
> then keep in mind that it is very late in the evolution of the MPLS
> encapsulation and changing the encapsulation is not an option that you
> will be able to propose without strong opposition.
	[Harrison,N,Neil,INC1 X]  Already noted.  And totally agree that
whatever is proposed should keep a close eye on backwards compatibilty.  One
final point on last sentence above.  It depends on who is doing the
'opposing'.  It really should be the operators call if they want certain OAM
functions to be addressed in a standardised and non-proprietary
manner....there is no point in asking operators for requirements and then
manufacturers ignoring/opposing them.  If a significant number of other
operators oppose such requirements though, then fair enough.

> Curtis


From owner-mpls@UU.NET  Thu Jun  8 17:46:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17504
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 17:46:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQistb12015;
	Thu, 8 Jun 2000 21:45:52 GMT
Received: by mail-control.mail.uu.net 
	id QQistb18905
	for mpls-outgoing; Thu, 8 Jun 2000 21:45:16 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQistb18886
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:45:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQista02778
	for <mpls@uu.net>; Thu, 8 Jun 2000 17:44:44 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQista10910
	for <mpls@uu.net>; Thu, 8 Jun 2000 21:44:43 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA10276
	for mpls@uu.net; Thu, 8 Jun 2000 17:44:43 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQista18662
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:44:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQista02663
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:44:02 -0400 (EDT)
Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5])
	id QQista17451
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:44:02 GMT
Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21)
	id <MC1NZPRT>; Thu, 8 Jun 2000 17:44:02 -0400
Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEB84@brixcorp2.brixnet.com>
From: "Cucchiara, Joan" <JCucchiara@Brixnet.com>
To: "'Rob Schmitt'" <rschmitt@cisco.com>,
        "Cucchiara, Joan"
	 <JCucchiara@Brixnet.com>
Cc: mpls@UU.NET,
        "'jluciani@tollbridgetech.com'"
	 <jluciani@tollbridgetech.com>,
        "'hans.sjostrand@etx.ericsson.se'"
	 <hans.sjostrand@etx.ericsson.se>
Subject: RE: Last Call for LDP
Date: Thu, 8 Jun 2000 17:43:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk



> -----Original Message-----
> From: Rob Schmitt [mailto:rschmitt@cisco.com]
> Sent: Thursday, June 08, 2000 6:56 PM
> To: Cucchiara, Joan
> Cc: mpls@UU.NET
> Subject: RE: Last Call for LDP
> 
> 
> LDP MIB authors:
> 
> Last time I saw a rev, it was '05' and the MODULE-ID
> was set at 'experiment XXX'.  Is a valid experiment
> number contemplated to be acquired from the
> appropriate authority?

Speaking for the LDP MIB co-authors, we have not 
requested any number under the experiemental branch.

   -Joan


> Thanks
> /rs
> 
> At 03:29 PM 6/8/00 -0400, Cucchiara, Joan wrote:
> 
> >Bob,
> >
> >My understanding is that the Frame Relay Forum has
> >dropped support for 17-bit DLCIs.  The LDP MIB and
> >LSR MIB (drafts) are not supporting 17-bit FrameRelay
> >labels.
> >
> >I would like to request that references to 17-bit DLCI
> >Frame Relay labels be removed from the LDP Specification.
> >Admittedly, this was not an issue during the prior last
> >call because the 17-bit FR DLCIs were still being supported
> >by the FRF during that time.
> >
> >This change would more closely align the LDP spec with the
> >LDP MIB and LSR MIB.
> >
> >    Thank you, Joan
> >
> > > -----Original Message-----
> > > From: George Swallow [mailto:swallow@cisco.com]
> > > Sent: Wednesday, June 07, 2000 2:25 PM
> > > To: mpls@UU.NET
> > > Subject: Last Call for LDP
> > >
> > >
> > > This message signals the begining of a last call on LDP.  
> This last
> > > call is limited to the changes made in draft -07 to 
> address the issues
> > > raised in the previous last call.
> > >
> > > The last call ends at 12 pm GMT Wednesday 6/14.
> > >
> > > ...George
> > >
> > > 
> ======================================================================
> > > George Swallow       Cisco Systems                   
> (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> > >
> > >
> > >
> > >
> >
> 
> +-----------------------------------------------------------------+
>        Robert Schmitt            CISCO SYSTEMS
>        rschmitt@cisco.com
>        Chelmsford, MA              978-244-3076
> +----------------------------------------------------------------+
> 
> 
> 



From owner-mpls@UU.NET  Thu Jun  8 17:47:14 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17515
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 17:47:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQistb12931;
	Thu, 8 Jun 2000 21:46:36 GMT
Received: by mail-control.mail.uu.net 
	id QQistb19039
	for mpls-outgoing; Thu, 8 Jun 2000 21:46:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQistb18970
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:46:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQistb01800
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:45:53 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQistb12011
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:45:52 GMT
Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP;
          Thu, 8 Jun 2000 22:37:41 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWFYH0D>; Thu, 8 Jun 2000 22:37:51 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16058@mbddmknt01.hc.bt.com>
To: curtis@avici.com
Cc: jote4102@alu-etsetb.upc.es, mpls@UU.NET
Subject: RE: MPLS and fast reroute. 
Date: Thu, 8 Jun 2000 22:37:43 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Curtis,

Agreed if one owns all network instrastructure 'to the duct' (and even then
one need very good records of the client/server trail
relationships).......but what if the L1 (ie Sonet) was a leased connection
for some other operator?  Now one does not know whether L1 protection exists
or not.  So what do you do now?

Neil

> -----Original Message-----
> From:	Curtis Villamizar [SMTP:curtis@avici.com]
> Sent:	Thursday, June 08, 2000 4:12 PM
> To:	neil.2.harrison@bt.com
> Cc:	jote4102@alu-etsetb.upc.es; mpls@UU.NET
> Subject:	Re: MPLS and fast reroute. 
> 
> 
> In message
> <B9571FDEBD3DD21181E500606DD5EE0507B16050@mbddmknt01.hc.bt.com>, nei
> l.2.harrison@bt.com writes:
> > This assumes one has already defined all failures and consequent
> actions.  I
> > see at least 4 possibilities, none of which are clearly defined anyway
> in
> > terms of entry/exit criteria and consequent actions (signalling for
> prot-sw
> > being but just 1 aspect):
> > -	simple LSP connectivity break......sourced from server layer or from
> > MPLS layer
> > -	swapped LSPs
> > -	mismerged (different) LSPs
> > -	self-mismerged LSPs (aka looping)
> > 
> > Warning - L1 networks can experience significant error events and then
> > recover.  So one can do more harm than good by prot-sw too soon.  If
> your
> > detection scheme and prot-sw are above L1 then anything much less than
> 2-3s
> > may not be very sensible.
> > 
> > neil 
> 
> 
> I think most people planning to use local protect plan to use either
> MPLS local protect or SONET APS but not both.  The benefit of MPLS
> local protect is that it doesn't require reserving 1/2 capacity for
> protect circuits and can be applied to a subset of traffic (those
> paying for better service).  Another means of protection is in the
> OXC.  I don't think anyone plans to use more than one sub-100ms
> protection scheme at the same time as they would interact.
> 
> People planning to use both at the same time can please correct me.
> 
> Curtis


From owner-mpls@UU.NET  Thu Jun  8 17:54:21 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17622
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 17:54:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQistb23663;
	Thu, 8 Jun 2000 21:53:26 GMT
Received: by mail-control.mail.uu.net 
	id QQistb19444
	for mpls-outgoing; Thu, 8 Jun 2000 21:53:12 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQistb19439
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:53:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQistb04314
	for <mpls@uu.net>; Thu, 8 Jun 2000 17:52:52 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQistb23248
	for <mpls@uu.net>; Thu, 8 Jun 2000 21:52:52 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA12178
	for mpls@uu.net; Thu, 8 Jun 2000 17:52:51 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQistb19421
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:52:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQistb04210
	for <mpls@UU.NET>; Thu, 8 Jun 2000 17:52:01 -0400 (EDT)
Received: from fortress.fnc.fujitsu.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fortress.fnc.fujitsu.com [204.253.82.1])
	id QQistb22740
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:52:01 GMT
Received: from fnc01.fnc.fujitsu.com (fnc01.fnc.fujitsu.com [167.254.100.17]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id QAA18529; Thu, 8 Jun 2000 16:51:31 -0500 (CDT)
Received: from tddny.fujitsu.com (pc185.tddny.fujitsu.com [167.254.242.185]) by fnc01.fnc.fujitsu.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id M1SHVQMR; Thu, 8 Jun 2000 16:51:34 -0500
Message-ID: <39401558.523671E1@tddny.fujitsu.com>
Date: Thu, 08 Jun 2000 17:51:20 -0400
From: "Indra.Widjaja" <Indra.Widjaja@tddny.fujitsu.com>
X-Mailer: Mozilla 4.61 [en]C-CCK-MCD fnc_08_99  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: mpls@UU.NET
Subject: Re: OAM labels (was: can egress know the ingress of a packet?)
References: <336ECDAFDF7DD311B9E30090277AEE4101B405EE@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Shahram:

>
> >Shahram:
> >Thanks for your clarification.
> >I was slow and didn't read the message from Thomas.
> >As he said in his later message, the LSP can be identified in the
> >body of the OAM packet if needed (which is still to be defined),
> >so the problem can be solved, right?
>
> Not exactly. What if there are hierarchical tunnels and the egress of one
> tunnel is the intermediate node of another tunnel. Then you can't identify
> the LSP by looking at the body of the OAM packet, because the OAM packet
> belongs to many LSPs (i.e., hierarchical LSPs). Right?
>

I'm not sure if I follow you completely; however, I see that there could
be a problem if the OAM sink has to know the LSP that the OAM packet
came from.
So the question is what type of identification that is sufficient for an OAM
sink
to know. Is it sufficient to provide the LSR ID of the OAM source,
probably plus another ID unique within that OAM source to take care
of possible multiple LSPs?
Do you know of an example of a particular OAM operation that requires the
OAM sink to know the LSP?
indra





From owner-mpls@UU.NET  Thu Jun  8 19:09:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18814
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 19:09:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQistg19511;
	Thu, 8 Jun 2000 23:08:25 GMT
Received: by mail-control.mail.uu.net 
	id QQistg26566
	for mpls-outgoing; Thu, 8 Jun 2000 23:07:53 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQistg26559
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 23:07:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQistg14256
	for <mpls@UU.NET>; Thu, 8 Jun 2000 19:07:29 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQistg18582
	for <mpls@UU.NET>; Thu, 8 Jun 2000 23:07:29 GMT
Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP;
          Fri, 9 Jun 2000 00:06:56 +0100
Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVV0PXF2>; Fri, 9 Jun 2000 00:07:07 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B1605E@mbddmknt01.hc.bt.com>
To: curtis@avici.com, pjw@ip-engineering.bt.com
Cc: mpls@UU.NET
Subject: RE: OAM functionality  
         (Was: RE: can egress know the ingressof a packet?)
Date: Fri, 9 Jun 2000 00:07:02 +0100 
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

See remarks below.  Regards, Neil

	[Harrison,N,Neil,INC1 X]  <Snip>
>  Back to the requirement.  We have, in order of expected frequency, the
> following types of failures:
> 
>   1.  Failures that are detected by the control plane.  For example,
>       link failures or complete hardware component failures.
> 
>   2.  Software failures that are not detectable at the control plane.
>       These will exist iff there remain software bugs which allow
>       inconsistencies between control plane software and low level
>       software or hardware.
> 
>   3.  Hardware failures that are not detectable at the control plane.
>       These will exist iff there remain data paths or highly
>       persistent data storage (like forwarding tables) that is not
>       protected by ECC or parity.
> 
> OAM is not needed for the first set because the control plane will
> recover and/or report the fault.
	[Harrison,N,Neil,INC1 X]  And why is this?  It's because the
control-plane had OAM functions designed into it at the outset.  But the
control-plane is not one single entity.....at its coarsest it comprises (i)
addressing (ii) a routing protocol (iii) a signalling protocol (at least for
CO-type routings).  What we really mean here is that the routing protocol
will (eventually) detect the failures........providing they are simple
breaks and not more complex misbranching cases.   We don't have to worry
about misbranching in IP........each pkt contains an absolute source (and
indeed sink) address....subject to global uniqueness issues.  This is not
true in MPLS.  Labels are ostensibly only unique per interface and are
therefore relative addresses.  BTW, to also rely on the 'control-plane'
requires it to have total congruence with the user plane.........can we
really be so prescriptive on this? 

	Last point on this paragraph wrt observation of this being highest
expected failure cause frequency.  I agree L1 server failures should be
expected to yield the highest frequency, and these will manifest themselves
as simple connectivity breaks in the server's client layers.  (This is also
a good reason not to react too quickly with prot-sw in clients....esp if one
does not own the L1).  But I suspect one will find that the L1 has OAM which
detects its own failures and reacts accordingly.....so our focus should not
be on detection/diagnosis of defects sourced in the L1, but those sourced in
MPLS.  

> The third case is better covered by making sure all registers can be
> read back and periodically checking hardware registers to
> make sure that they match the software copies.
	[Harrison,N,Neil,INC1 X]  Operators cannot be prescriptive about
manufacturer implementations .  We would hope they pay attention to internal
nodal defects as suggested.

> The second and third cases can be detected by sending probe traffic
> through the network (OAM) but 100% coverage cannot be assured.
	[Harrison,N,Neil,INC1 X]  Probes seem like a good way to get some
form of statistical sampling of one's network behaviour (at the IP layer),
but to scale to 100% to cover all cases is a non-starter.
Collection/processing costs alone would rule this out.  In any case it is
overkill.  CF The PM cell in ATM.  Probes are good for doing sampling in the
case of QoS metrics (eg errored pkts, abs/var on delay, etc) that one would
not normally be concerned about in a workhorse OAM sense.......here basic
connectivity assurances are the most important.  So whilst probes have their
use (sampling or ad hoc detailed trouble-shooting) this is not a scaleable
solution in my view.  

> The problem may occur at:
> 
>   1.  ingress,
>   2.  midpoint, or
>   3.  egress.
> 
> For example, if the ingress node loses the hardware entry that is
> supposed to map a given IP prefix into an LSP, the same ingress may
> successfully inject OAM packets because those do not enter as IP with
> that prefix.  This is probably by far the most common error and it is
> not detectable by OAM packets.
	[Harrison,N,Neil,INC1 X]  This is describing a defect which is in
the IP layer......or perhaps more accurately in the IP->MPLS layer
adaptation function.  So it is not valid to say MPLS OAM will not detect
this....it indeed should not.
>   This is also not detectable by ping
> unless the ping uses an IP destination corresponding to the faulty
> entry.  This is detectable by a traceroute, because traceroute is IP
> and can have the identical destination (and source, but that gets a
> bit more tricky) and can be given a limited TTL that just verifies the
> tunnel.
	[Harrison,N,Neil,INC1 X]  Then we have a tool at the right layer for
this particular defect.

> Note that an RFC2547 style VPNs there are multiple forwarding tables
> in the provider edge routers.  These forwarding tables can only be
> verified by injecting traffic through the same interface that would
> exercise the same table entries.  Sounds to me a lot like a ping would
> do the job nicely while an OAM packet that already had an MPLS
> encapsulation would not.
	[Harrison,N,Neil,INC1 X]  Agreed.  We are talking of IP->MPLS
adaptation again I think.  So the IP layer needs to detect this since it is
not a defect of the MPLS layer. [Note - If we had some decent functional
architecture diagrams I think this would help us a great deal......Andy Reid
and Mike Sexton, if you are out there reading this please come to our
rescue......I'll forward this mail to you anyway]
>  
> If a midpoint loses a hardware entry for a given label, and the OAM
> packet has a special label that kicks the OAM packet to software to be
> counted, checked, or manipulated in some way, it still hasn't caught
> the problem where the hardware table for that label is wrong since it
> consults software.
	[Harrison,N,Neil,INC1 X]  I would not expect mid points of an LSP to
alter a CV (Connectivity Verification) OAM pkt in any way.  They should be
treated as normal user-plane traffic.  CV pkts are generated at the LSP
source point and only examined again at the LSP sink point.  If there are
lower layer LSPs, then the higher layer LSP simply gets encapsulated and
passes transparently.  Or at the least that's the model I have in mind for
all this.

> The OAM label is diverted at the egress before it hits the hardware
> that does things like POP the label and adjust the packet length,
> adjust the underlying TTL (if IP), ECN, etc.  So the OAM packet
> doesn't detect this fault either.
	[Harrison,N,Neil,INC1 X]  Need proper functional architecture to
decide whether the issues being described are a function of the client layer
or the server layer, ie do they come after or before the LSP trail
termination point?  But they all sound client layer to me and so look like
they should be a function of the client layer to check 'correctness'.

> One thing that might help, but is not ATM OAM like is some form of LQM
> for MPLS.  For example, the ingress could place a packet into the
> stream with the label stack it wants to measure and a special LQM
> label (in the reserved range) below it and place LSP counters in the
> underlying packet.  A special outsegment would be needed at the
> ingress to put the label stack and current counters in place.  At the
> egress, the last forwarding label would be POPed and the reserved
> label would be revealed.  The hardware would have to place its LSP
> counters in the packet and forward to software for exception
> processing.  The software can then subtract the counters of two
> successive MPLS LQM (as is done in RFC1989 PPP LQM) to determine the
> traffic rate and loss along the LSP.  Only the ingress and egress
> would need to do this.  If the egress didn't know how, it would count
> and silently discard the packet and you'd be no worse off.
> 
> MPLS LQM would definitely require hardware change so expect to hear
> some screams.  On the positive side, only the ingress and egress need
> to do it and it can be deployed incrementally.
	[Harrison,N,Neil,INC1 X]  I'd like to know more about this.....I'll
check out the refs you gave (thanks).  In the stuff I have been looking at I
tried to keep the OAM as minimal and consistent as I could (having been
through the ATM 'experience').  My basic Connectvity Verification pkt is
nothing more that a sort of keepalive that is sent LSP_trail_source to
LSP_trail_sink on a periodic basis.  This detects all the connectivity
defects that might occur.  I also designed a variation on this which simply
counted the client layer pkts/octets sent between sucessive CV pkts....which
I called a CV+P pkt.  Its not something I would recommend for day-day use
(processing burden) but is simply there as a 1-step-up ad hoc diagnostic
tool for looking at pkt loss (and something that could be picked-off, by a
search for the absolute LSP source address, at intermediate points along an
LSP for subnetwork partition monitoring).  More than this (ie full QoS
metric suite) would require a sampling regime, like the probes discussed
earlier.

> Curtis


From owner-mpls@UU.NET  Thu Jun  8 21:50:03 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21363
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 21:50:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQistr14233;
	Fri, 9 Jun 2000 01:48:06 GMT
Received: by mail-control.mail.uu.net 
	id QQistr27233
	for mpls-outgoing; Fri, 9 Jun 2000 01:47:47 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQistr27225
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 01:47:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQistr04498
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:47:31 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQistr13631
	for <mpls@UU.NET>; Fri, 9 Jun 2000 01:47:31 GMT
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA26543
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:47:31 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA26500;
	Thu, 8 Jun 2000 21:47:22 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id VAA21576; Thu, 8 Jun 2000 21:47:17 -0400 (EDT)
Message-ID: <39404CA3.77E3805A@lucent.com>
Date: Thu, 08 Jun 2000 21:47:15 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: bkumar@ennovatenetworks.com
CC: curtis@avici.com, "'Juan Diego Otero'" <jote4102@alu-etsetb.upc.es>,
        mpls@UU.NET
Subject: Re: MPLS and fast reroute.
References: <00aa01bfd191$66a7cf80$d001010a@tst.ennovatenetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

See my comments below:

> I don't see a point in comparing essentially two altogether dis-joint
> technologies. Moreover, it is meaningless to talk about QoS in the
> context of APS in SONET as all services are being shifted on the
> alternate path (including all MPLS LSPs). MPLS over SONET
> automatically inherits all the virtues of SONET reliability.

I guess my point is misunderstood. SONET protection switching uses dedicated
overhead bytes for signaling and end-to-end coordination. This is why SONET
protection is fast and deterministic. MPLS uses message-based signaling to
coordinate protection switching. With only best effort IP, there is no way you
can guarantee to deliver these signaling messages on time. So there has to be
infrastructure to treat these signaling messages specially. This is why I
mentioned QoS.

> The number of combinations in which these options can be employed
> leads to a variety of SONET protection schemes. Some of the more
> frequently used abbreviations of the SONET protection architectures
> are Bidirectional line-switched ring (BLSR), Bidirectional
> path-switched ring (BPSR), Unidirectional line-switched ring (ULSR),
> Unidirectional path-switched ring (UPSR).
> 
> Whether MPLS can emulate such a wide variety of Protection options
> over other networks can't be definitively answered yet. There is a
> long way to go, before we reach there.

MPLS doesn't need to mimic SONET protection, which so far are almost ring-based.
MPLS can use these ring protection ideas, but it should focus on mesh-based.

Yangguang


From owner-mpls@UU.NET  Thu Jun  8 21:53:37 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21376
	for <mpls-archive@lists.ietf.org>; Thu, 8 Jun 2000 21:53:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQistr16783;
	Fri, 9 Jun 2000 01:50:37 GMT
Received: by mail-control.mail.uu.net 
	id QQistr27362
	for mpls-outgoing; Fri, 9 Jun 2000 01:50:05 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQistr27340
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 01:49:49 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQistr01553
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:49:41 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQistr15849
	for <mpls@UU.NET>; Fri, 9 Jun 2000 01:49:41 GMT
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA27027
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:49:40 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA27023;
	Thu, 8 Jun 2000 21:49:40 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id VAA21640; Thu, 8 Jun 2000 21:49:38 -0400 (EDT)
Message-ID: <39404D30.EB8BBBB0@lucent.com>
Date: Thu, 08 Jun 2000 21:49:36 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: curtis@avici.com, jote4102@alu-etsetb.upc.es, mpls@UU.NET
Subject: Re: MPLS and fast reroute.
References: <B9571FDEBD3DD21181E500606DD5EE0507B16058@mbddmknt01.hc.bt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


I think whether L1 protection exists or not should be know, because the price is
different.

Yangguang


neil.2.harrison@bt.com wrote:
> 
> Hi Curtis,
> 
> Agreed if one owns all network instrastructure 'to the duct' (and even then
> one need very good records of the client/server trail
> relationships).......but what if the L1 (ie Sonet) was a leased connection
> for some other operator?  Now one does not know whether L1 protection exists
> or not.  So what do you do now?
> 
> Neil


From owner-mpls@UU.NET  Fri Jun  9 01:48:40 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29431
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 01:48:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisuh18001;
	Fri, 9 Jun 2000 05:47:20 GMT
Received: by mail-control.mail.uu.net 
	id QQisuh21585
	for mpls-outgoing; Fri, 9 Jun 2000 05:46:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisuh21579
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 05:46:42 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisuh26529
	for <mpls@uu.net>; Fri, 9 Jun 2000 01:46:30 -0400 (EDT)
Received: from tcb.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tcb.net [205.168.100.1])
	id QQisuh15788
	for <mpls@uu.net>; Fri, 9 Jun 2000 05:46:30 GMT
Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1])
	by tcb.net (8.9.3/8.9.3) with ESMTP id XAA10965
	for <mpls@uu.net>; Thu, 8 Jun 2000 23:47:42 -0600
Message-Id: <200006090547.XAA10965@tcb.net>
X-Mailer: exmh version 2.0.3
To: mpls@UU.NET
From: Danny McPherson <danny@tcb.net>
Reply-To: danny@tcb.net
Subject: Re: MPLS and fast reroute. 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 08 Jun 2000 23:47:41 -0600
Sender: owner-mpls@UU.NET
Precedence: bulk


[snip]
From: Danny McPherson <danny@ambernetworks.com>
Reply-To: danny@ambernetworks.com
Subject: Re: MPLS and fast reroute. 
Date: Thu, 08 Jun 2000 21:57:37 -0600
Sender: danny@sofos.tcb.net


> I guess my point is misunderstood. SONET protection switching uses dedicated
> overhead bytes for signaling and end-to-end coordination. This is why SONET
> protection is fast and deterministic. MPLS uses message-based signaling to
> coordinate protection switching. With only best effort IP, there is no way you
> can guarantee to deliver these signaling messages on time. So there has to be
> infrastructure to treat these signaling messages specially. This is why I
> mentioned QoS.

Yangguang,
You're missing the point.  When using local protection the backup path is 
PRECALCULATED.  Therefore, a switch only requires failure propagation [and 
subsequent detection] of the failure by the egress interface associated with
the path in the local LSR.  There are no real-time signalling messages to 
be lost with local-protection, it occurs only within the local LSR.  Given, 
re-optimization may be desirable at the head-end, but not necessarily, and
certainly not within even IGP convergence timeframes.  

The benefit of an approach such as this in comparison to SONET APS is that 
with APS the protection infrastructure has traditionally been unusable, while 
MPLS-based restoration and TE provide a considerable amount of granularity for
other [preemptable] traffic to use the protect path under normal conditions,
as well as in additon to failure modes, if capacity is available.  If the
protection schema supports statistical multiplexing capabilities that aren't
available with SONET APS, it becomes that much more desirable to service 
providers.

IGPs also must converge when using SONET APS to protect against router 
failures
(i.e., routers connecting to ADM trib ports to provide local protection).  
This
often results in a considerable amount of non-forwarding time, with failure
detection alone introducing a significant delay, not to mention propagation 
delay
associated with routing protocol messages required for adjacency establishment 
between the new pair of interfaces/routers, and even delay introduced by path
calculation throttles over the networks as a result of near back-to-back link
state packets being flooded to report both initial failures and new links.

> MPLS doesn't need to mimic SONET protection, which so far are almost ring-based.

You're referring here only to the "network" application for APS.  It's commonly
used to protect against router failures as well.

> MPLS can use these ring protection ideas, but it should focus on mesh-based.

See above.

To reiterate Curtis's earlier comment, this has all been discussed here before.
A quick look over the mailing list archives, as well as the cited drafts, 
should
provide additional insight.

- -danny

------- End of Forwarded Message





From owner-mpls@UU.NET  Fri Jun  9 05:56:32 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08034
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 05:56:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisux10663;
	Fri, 9 Jun 2000 09:54:15 GMT
Received: by mail-control.mail.uu.net 
	id QQisux16167
	for mpls-outgoing; Fri, 9 Jun 2000 09:53:45 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisux16159
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 09:53:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisux27915
	for <mpls@UU.NET>; Fri, 9 Jun 2000 05:53:16 -0400 (EDT)
Received: from old-callisto.ftel.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: big-relay-1.ftel.co.uk [192.65.220.123])
	id QQisux10137
	for <mpls@UU.NET>; Fri, 9 Jun 2000 09:53:16 GMT
Received: (from root@localhost)
	by old-callisto.ftel.co.uk (8.10.1/8.10.1/Revision:1.53/cyrus/yp) id e599qsK17515;
	Fri, 9 Jun 2000 10:52:54 +0100 (BST)
Received: from ftel.co.uk (kiwi.ftel.co.uk [172.16.13.170])
	by old-callisto.ftel.co.uk (8.10.1/8.10.1/Revision:1.53/scanin/yp) with ESMTP id e599qm317492;
	Fri, 9 Jun 2000 10:52:49 +0100 (BST)
Message-ID: <3940BE7A.F3086E38@ftel.co.uk>
Date: Fri, 09 Jun 2000 10:52:58 +0100
From: Robert M Matheson <R.Matheson@ftel.co.uk>
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
CC: neil.2.harrison@bt.com, curtis@avici.com, jote4102@alu-etsetb.upc.es,
        mpls@UU.NET
Subject: Re: MPLS and fast reroute.
References: <B9571FDEBD3DD21181E500606DD5EE0507B16058@mbddmknt01.hc.bt.com> <39404D30.EB8BBBB0@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Surely when a connection is leased there will be an associated service level
agreement; it is then up to the provider of the connection to do whatever they deem
necessary to meet that agreement, which could include L1 protection. Decisions about
whether higher layer protection is required are then based on that service level
agreement, rather than on what is being used to achieve that level of service??

Robert

Yangguang Xu wrote:

> I think whether L1 protection exists or not should be know, because the price is
> different.
>
> Yangguang
>
> neil.2.harrison@bt.com wrote:
> >
> > Hi Curtis,
> >
> > Agreed if one owns all network instrastructure 'to the duct' (and even then
> > one need very good records of the client/server trail
> > relationships).......but what if the L1 (ie Sonet) was a leased connection
> > for some other operator?  Now one does not know whether L1 protection exists
> > or not.  So what do you do now?
> >
> > Neil



From owner-mpls@UU.NET  Fri Jun  9 08:23:32 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09903
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 08:23:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvh16299;
	Fri, 9 Jun 2000 12:22:23 GMT
Received: by mail-control.mail.uu.net 
	id QQisvh26755
	for mpls-outgoing; Fri, 9 Jun 2000 12:21:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisvh26732
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 12:21:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisvh08879
	for <mpls@uu.net>; Fri, 9 Jun 2000 08:21:15 -0400 (EDT)
Received: from 21cn.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.104.32.246])
	id QQisvh15234
	for <mpls@uu.net>; Fri, 9 Jun 2000 12:21:12 GMT
Received: from 21cn.com([10.1.0.101]) by 21cn.com(JetMail 2.5.3.0)
	with SMTP id jm173940f097; Fri,  9 Jun 2000 12:09:20 -0000
Received: from wodc7-1.corprelay.mail.uu.net([192.48.96.68]) by 21cn.com(JetMail 2.5.3.0)
	with SMTP id jm0393e6eb0; Wed,  7 Jun 2000 12:10:52 -0000
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisnw20846;
	Wed, 7 Jun 2000 12:09:47 GMT
Received: by mail-control.mail.uu.net 
	id QQisnw05487
	for mpls-outgoing; Wed, 7 Jun 2000 12:09:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisnw05460
	for <mpls@mail-control.mail.uu.net>; Wed, 7 Jun 2000 12:09:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisnw12293
	for <mpls@UU.NET>; Wed, 7 Jun 2000 08:09:03 -0400 (EDT)
Received: from solen.ce.chalmers.se by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: solen.ce.chalmers.se [129.16.20.244])
	id QQisnw15198
	for <mpls@UU.NET>; Wed, 7 Jun 2000 12:09:02 GMT
Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199])
	by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id OAA19440;
	Wed, 7 Jun 2000 14:09:01 +0200 (MET DST)
From: Florian-Daniel Otel <otel@ce.chalmers.se>
Received: (from otel@localhost)
	by rasputin.ce.chalmers.se (8.8.8/8.8.8) id OAA03270;
	Wed, 7 Jun 2000 14:09:01 +0200 (MEST)
MIME-Version: 1.0
Date: Wed,  7 Jun 2000 14:09:01 +0200 (MEST)
To: "Martin Picard" <mpicard@sinc.ca>
Cc: <mpls@UU.NET>
Subject: Re: MPLS Traffic prioritization 
In-Reply-To: <007901bfd077$5b005fa0$3279a98e@MartinPicard>
References: <007901bfd077$5b005fa0$3279a98e@MartinPicard>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14654.14973.814553.75012@rasputin.ce.chalmers.se>
Reply-To: otel@ce.chalmers.se
Content-Type: text/plain; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


> Hi,
>    I am currently pulling together an inventory of the different
>    technologies, techniques, methods and protocols to accomplish
>    prioritization for traffic going through an MPLS network. This
>    inventory is a starting point, since the ultimate goal is to review
>    these elements and then establish a migration path to introduce
>    traffic prioritization for an MPLS network.

>    Any input would be appreciated.

draft-vaananen-mpls-svc-diff-framework-00.txt and references therein
might be a good prior reading before starting that work.


And welcome to the club ;)

>    tx

> Martin Picard
> SINC




Florian.


From owner-mpls@UU.NET  Fri Jun  9 09:34:18 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11325
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 09:34:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvm25803;
	Fri, 9 Jun 2000 13:31:50 GMT
Received: by mail-control.mail.uu.net 
	id QQisvm11055
	for mpls-outgoing; Fri, 9 Jun 2000 13:31:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisvm11050
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 13:31:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisvm19169
	for <mpls@UU.NET>; Fri, 9 Jun 2000 09:31:01 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQisvm24928
	for <mpls@UU.NET>; Fri, 9 Jun 2000 13:31:01 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id JAA12980; Fri, 9 Jun 2000 09:30:53 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id JAA18939;
	Fri, 9 Jun 2000 09:31:10 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006091331.JAA18939@curtis-lt.avici.com>
To: neil.2.harrison@bt.com
cc: curtis@avici.com, jote4102@alu-etsetb.upc.es, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS and fast reroute. 
In-reply-to: Your message of "Thu, 08 Jun 2000 22:37:43 BST."
             <B9571FDEBD3DD21181E500606DD5EE0507B16058@mbddmknt01.hc.bt.com> 
Date: Fri, 09 Jun 2000 09:31:10 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B9571FDEBD3DD21181E500606DD5EE0507B16058@mbddmknt01.hc.bt.com>, nei
l.2.harrison@bt.com writes:
> Hi Curtis,
> 
> Agreed if one owns all network instrastructure 'to the duct' (and even then
> one need very good records of the client/server trail
> relationships).......but what if the L1 (ie Sonet) was a leased connection
> for some other operator?  Now one does not know whether L1 protection exists
> or not.  So what do you do now?
> 
> Neil


When you lease large amounts of bandwidth you get to ask questions
like whether it is dark or lit, one lambda or the whole spectrum.  At
lower speeds you get to ask if it is SONET APS or not.  For the kind
of money you're paying you have a right to ask.  At still lower speeds
maybe you don't know.

If you don't know whether you have L1 protect, you can keeep MPLS
protection time threshholds short and maybe avoid using a L1 protected
link that can back very quickly, or you can set MPLS protection time
threshholds longer assuming you might have L1 protection and risk
prolonging an outage.

Which decision you make in the face of uncertainty is a tough question
no matter what the context of the question and the answer depends on
probability of one or the other outcome and relative severity of
guessing wrong for a particular situation (service class in this case).

Curtis



From owner-mpls@UU.NET  Fri Jun  9 09:55:28 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11715
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 09:55:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvn16540;
	Fri, 9 Jun 2000 13:54:08 GMT
Received: by mail-control.mail.uu.net 
	id QQisvn12348
	for mpls-outgoing; Fri, 9 Jun 2000 13:53:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisvn12342
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 13:53:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisvn28268
	for <mpls@uu.net>; Fri, 9 Jun 2000 09:53:17 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQisvn15654
	for <mpls@uu.net>; Fri, 9 Jun 2000 13:53:17 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA02783
	for <mpls@uu.net>; Fri, 9 Jun 2000 06:53:26 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA01879 for mpls@uu.net; Fri, 9 Jun 2000 09:53:15 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisso05563
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 18:35:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisso25410
	for <mpls@UU.NET>; Thu, 8 Jun 2000 14:35:00 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQisso26650
	for <mpls@UU.NET>; Thu, 8 Jun 2000 18:34:59 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MHX69NMX>; Thu, 8 Jun 2000 11:40:53 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6625FEA77@ICARIAN>
From: George Frank <GFrank@zaffire.com>
To: "'curtis@avici.com'" <curtis@avici.com>,
        Juan Diego Otero
	 <jote4102@alu-etsetb.upc.es>
Cc: mpls@UU.NET
Subject: RE: MPLS and fast reroute. 
Date: Thu, 8 Jun 2000 11:40:53 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Also see draft-makam-mpls-recovery-frmwrk-00.txt,
among others. Searching for 'recovery' or something
similar on the I-D web site turns up several
drafts.

george


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@avici.com]
> Sent: Thursday, June 08, 2000 8:01 AM
> To: Juan Diego Otero
> Cc: mpls@UU.NET
> Subject: Re: MPLS and fast reroute. 
> 
> 
> 
> In message <393F735D.6BCB395D@alu-etsetb.upc.es>, Juan Diego 
> Otero writes:
> > Hi,
> > 
> > In IEEE Communications Magazine (December 1999), there is an article
> > written
> > by Tony Li called "MPLS and the Evolving Internet 
> Architecture". In page
> > 41,
> > talking about fast reroute, Tony says: "...MPLS can also be 
> used in a
> > manner very similar to synchronous optical network (SONET), where no
> > signaling is necessary to perform the protection switching 
> of the LSP.
> > This
> > results in restoration times competitive with SONET." My 
> question is:
> > Can anybody explain me how MPLS can be used as SONET in
> > switching a LSP after a faliure, with no signaling?
> > 
> > Thanks a lot.
> > 
> > Diego Otero
> > UPC (Universitat Politecnica de Catalunya)
> 
> 
> See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.  The feature is known as
> local-protect in MPLS.
> 
> At each potential point of failure a backup path is created ahead of
> time.  On the LSR the spare outsegment is programmed (the hardware is
> set up) but the insegment points to the primary outsegment.  When the
> failure is detected by the interface egressing the LSR, a message is
> sent to all other interfaces.  Each interface reprograms the insegment
> (makes a table entry change) that points the insegment at the backup
> path.  This can be accomplished in about the same time required to do
> SONET restoration.
> 
> There is more information in draft-swallow-rsvp-bypass-label-00.txt,
> though this provides a means of using one LSP to backup multiple LSP
> that take the same recovery path.  It does provide additional insight
> into how this works.  You can also check the mailing list archives for
> discussion of "local protect" or "fast reroute".
> 
> Curtis
> 



From owner-mpls@UU.NET  Fri Jun  9 09:57:01 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11763
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 09:57:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvn18216;
	Fri, 9 Jun 2000 13:55:43 GMT
Received: by mail-control.mail.uu.net 
	id QQisvn12419
	for mpls-outgoing; Fri, 9 Jun 2000 13:55:10 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisvn12409
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 13:55:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisvn23355
	for <mpls@uu.net>; Fri, 9 Jun 2000 09:54:06 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQisvn16487
	for <mpls@uu.net>; Fri, 9 Jun 2000 13:54:06 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA03334
	for <mpls@uu.net>; Fri, 9 Jun 2000 06:54:15 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA01889 for mpls@uu.net; Fri, 9 Jun 2000 09:54:04 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisss20667
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 19:38:56 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisss07306
	for <mpls@uu.net>; Thu, 8 Jun 2000 15:38:41 -0400 (EDT)
Received: from osf1.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: osf1.gmu.edu [129.174.1.13])
	id QQisss10421
	for <mpls@uu.net>; Thu, 8 Jun 2000 19:38:41 GMT
Received: from localhost (vjosyula@localhost)
	by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA31018;
	Thu, 8 Jun 2000 15:38:35 -0400 (EDT)
Date: Thu, 8 Jun 2000 15:38:35 -0400 (EDT)
From: Venumadhav Josyula <vjosyula@osf1.gmu.edu>
To: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>
cc: "'Kimmo.Raatikainen@nokia.com'" <Kimmo.Raatikainen@nokia.com>,
        diffserv@ietf.org, mpls@UU.NET
Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extensions
   related  questions/comments
In-Reply-To: <4102273CEB77D211869200805FE6F5939EBC10@xch-phl-01.he.boeing.com>
Message-ID: <Pine.OSF.4.21.0006081533040.14535-100000@osf1.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Forgive me if what is does not make sense , I am basically new to this and
I right now doing my part-time masters I work is netwroking company called
mantra communications

If you do somekind of labeling based on service do ustill need to look
at the headers because u would be using label to particular queuing
decison or Is it so that I am missing something


cheers
venu

On Wed, 7 Jun 2000,
Manfredi, Albert E wrote:

> > -----Original Message-----
> > From: Kimmo.Raatikainen@nokia.com [mailto:Kimmo.Raatikainen@nokia.com]
> 
> [ ... ]
> 
> > Please keep in mind that gigabit cards are already available. In our
> > experiments we have found out that a high-end PC running 
> > Linux can send at a
> > rate of 250-300 megabits per second using TCP/UDP.
> 
> Actually, too bad Bora's "gripe" wasn't fully discussed on here. I guess it
> didn't fit in with the router model work being done at the moment.
> 
> I'd like to know how one can offer "service differentiation" over a
> packet-switched internet (small i) if one doesn't allow for network nodes to
> examine header fields, and then make queuing decisions based on some
> undefined and growing list of criteria? And potentially different criteria
> for different networks, as far as that goes? 
> 
> Maybe some sort of more hardware-friendly scheme, where queuing decisions
> are based on a simple set if rules associated with the 64 code points?
> Dunno. But it would definitely lead discussions down a different path, no?
> 
> Bert
> albert.e.manfredi@boeing.com
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> 








!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Josyula Venumadhav

Residnce:
4303 Apt#L, Ramona Drive
Fairfax, Virginia-22030
						
Phone:
Residence: (703)-359-5419
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 




From owner-mpls@UU.NET  Fri Jun  9 09:57:17 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11778
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 09:57:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvn00823;
	Fri, 9 Jun 2000 13:55:44 GMT
Received: by mail-control.mail.uu.net 
	id QQisvn12428
	for mpls-outgoing; Fri, 9 Jun 2000 13:55:16 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisvn12414
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 13:55:05 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisvn23417
	for <mpls@uu.net>; Fri, 9 Jun 2000 09:54:32 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQisvn29924
	for <mpls@uu.net>; Fri, 9 Jun 2000 13:54:31 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA26577
	for <mpls@uu.net>; Fri, 9 Jun 2000 06:54:40 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA01895 for mpls@uu.net; Fri, 9 Jun 2000 09:54:30 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQistb19423
	for <mpls@mail-control.mail.uu.net>; Thu, 8 Jun 2000 21:52:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQistb04222
	for <mpls@uu.net>; Thu, 8 Jun 2000 17:52:05 -0400 (EDT)
Received: from mail-gw.hursley.ibm.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-gw.hursley.ibm.com [194.196.110.15])
	id QQistb22791
	for <mpls@uu.net>; Thu, 8 Jun 2000 21:52:04 GMT
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA44730; Thu, 8 Jun 2000 22:52:02 +0100
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA16360; Thu, 8 Jun 2000 22:52:00 +0100 (BST)
Message-ID: <3940154C.4C3924F4@hursley.ibm.com>
Date: Thu, 08 Jun 2000 16:51:08 -0500
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Venumadhav Josyula <vjosyula@osf1.gmu.edu>
CC: "Manfredi, Albert E" <Albert.Manfredi@PHL.Boeing.com>,
        "'Kimmo.Raatikainen@nokia.com'" <Kimmo.Raatikainen@nokia.com>,
        diffserv@ietf.org, mpls@UU.NET
Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv 
 Extensionsrelated  questions/comments
References: <Pine.OSF.4.21.0006081533040.14535-100000@osf1.gmu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Venu,

This is getting off track for a standards working group discussion.
I think you should take this question to the diffserv-interest list.

diffserv-interest@external.cisco.com is an unmoderated list 
for any other diffserv-related discussion. Send a message 
whose body is "subscribe diffserv-interest" to mailer@cisco.com

(Hint: do not send such a message to the list itself, as somebody
did a day or two ago.)

   Brian Carpenter
   diffserv co-chair

Venumadhav Josyula wrote:
> 
> Forgive me if what is does not make sense , I am basically new to this and
> I right now doing my part-time masters I work is netwroking company called
> mantra communications
> 
> If you do somekind of labeling based on service do ustill need to look
> at the headers because u would be using label to particular queuing
> decison or Is it so that I am missing something
> 
> cheers
> venu
> 
> On Wed, 7 Jun 2000,
> Manfredi, Albert E wrote:
> 
> > > -----Original Message-----
> > > From: Kimmo.Raatikainen@nokia.com [mailto:Kimmo.Raatikainen@nokia.com]
> >
> > [ ... ]
> >
> > > Please keep in mind that gigabit cards are already available. In our
> > > experiments we have found out that a high-end PC running
> > > Linux can send at a
> > > rate of 250-300 megabits per second using TCP/UDP.
> >
> > Actually, too bad Bora's "gripe" wasn't fully discussed on here. I guess it
> > didn't fit in with the router model work being done at the moment.
> >
> > I'd like to know how one can offer "service differentiation" over a
> > packet-switched internet (small i) if one doesn't allow for network nodes to
> > examine header fields, and then make queuing decisions based on some
> > undefined and growing list of criteria? And potentially different criteria
> > for different networks, as far as that goes?
> >
> > Maybe some sort of more hardware-friendly scheme, where queuing decisions
> > are based on a simple set if rules associated with the 64 code points?
> > Dunno. But it would definitely lead discussions down a different path, no?
> >
> > Bert
> > albert.e.manfredi@boeing.com
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> >
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Josyula Venumadhav
> 
> Residnce:
> 4303 Apt#L, Ramona Drive
> Fairfax, Virginia-22030
> 
> Phone:
> Residence: (703)-359-5419
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: brian@icair.org



From owner-mpls@UU.NET  Fri Jun  9 09:58:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11791
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 09:58:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvn01765;
	Fri, 9 Jun 2000 13:56:29 GMT
Received: by mail-control.mail.uu.net 
	id QQisvn12523
	for mpls-outgoing; Fri, 9 Jun 2000 13:56:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisvn12444
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 13:55:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisvn23472
	for <mpls@uu.net>; Fri, 9 Jun 2000 09:54:52 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQisvn17349
	for <mpls@uu.net>; Fri, 9 Jun 2000 13:54:51 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA03854
	for <mpls@uu.net>; Fri, 9 Jun 2000 06:55:01 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA01899 for mpls@uu.net; Fri, 9 Jun 2000 09:54:49 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQistz25156
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 03:56:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQistz18951
	for <mpls@UU.NET>; Thu, 8 Jun 2000 23:56:25 -0400 (EDT)
Received: from tcb.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tcb.net [205.168.100.1])
	id QQistz13116
	for <mpls@UU.NET>; Fri, 9 Jun 2000 03:56:25 GMT
Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1])
	by tcb.net (8.9.3/8.9.3) with ESMTP id VAA10436
	for <mpls@UU.NET>; Thu, 8 Jun 2000 21:57:37 -0600
Message-Id: <200006090357.VAA10436@tcb.net>
To: mpls@UU.NET
From: Danny McPherson <danny@ambernetworks.com>
Reply-To: danny@ambernetworks.com
Subject: Re: MPLS and fast reroute. 
Date: Thu, 08 Jun 2000 21:57:37 -0600
Sender: owner-mpls@UU.NET
Precedence: bulk


> I guess my point is misunderstood. SONET protection switching uses dedicated
> overhead bytes for signaling and end-to-end coordination. This is why SONET
> protection is fast and deterministic. MPLS uses message-based signaling to
> coordinate protection switching. With only best effort IP, there is no way you
> can guarantee to deliver these signaling messages on time. So there has to be
> infrastructure to treat these signaling messages specially. This is why I
> mentioned QoS.

Yangguang,
You're missing the point.  When using local protection the backup path is 
PRECALCULATED.  Therefore, a switch only requires failure propagation [and 
subsequent detection] of the failure by the egress interface associated with
the path in the local LSR.  There are no real-time signalling messages to 
be lost with local-protection, it occurs only within the local LSR.  Given, 
re-optimization may be desirable at the head-end, but not necessarily, and
certainly not within even IGP convergence timeframes.  

The benefit of an approach such as this in comparison to SONET APS is that 
with APS the protection infrastructure has traditionally been unusable, while 
MPLS-based restoration and TE provide a considerable amount of granularity for
other [preemptable] traffic to use the protect path under normal conditions,
as well as in additon to failure modes, if capacity is available.  If the
protection schema supports statistical multiplexing capabilities that aren't
available with SONET APS, it becomes that much more desirable to service 
providers.

IGPs also must converge when using SONET APS to protect against router failures 
(i.e., routers connecting to ADM trib ports to provide local protection).  This 
often results in a considerable amount of non-forwarding time, with failure
detection alone introducing a significant delay, not to mention propagation delay
associated with routing protocol messages required for adjacency establishment 
between the new pair of interfaces/routers, and even delay introduced by path
calculation throttles over the networks as a result of near back-to-back link
state packets being flooded to report both initial failures and new links.

> MPLS doesn't need to mimic SONET protection, which so far are almost ring-based.

You're referring here only to the "network" application for APS.  It's commonly
used to protect against router failures as well.

> MPLS can use these ring protection ideas, but it should focus on mesh-based.

See above.

To reiterate Curtis's earlier comment, this has all been discussed here before.
A quick look over the mailing list archives, as well as the cited drafts, should
provide additional insight.

-danny



From owner-mpls@UU.NET  Fri Jun  9 10:49:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12458
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 10:49:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvr07886;
	Fri, 9 Jun 2000 14:47:24 GMT
Received: by mail-control.mail.uu.net 
	id QQisvr24889
	for mpls-outgoing; Fri, 9 Jun 2000 14:47:04 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisvr24884
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 14:46:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisvr08236
	for <mpls@UU.NET>; Fri, 9 Jun 2000 10:46:17 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQisvr00297
	for <mpls@UU.NET>; Fri, 9 Jun 2000 14:46:17 GMT
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25449
	for <mpls@UU.NET>; Fri, 9 Jun 2000 10:46:17 -0400 (EDT)
Received: from pai820exch001h.wins.lucent.com (h135-14-3-59.lucent.com [135.14.3.59])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25445
	for <mpls@UU.NET>; Fri, 9 Jun 2000 10:46:16 -0400 (EDT)
Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2650.21)
	id <MKAWMV7K>; Fri, 9 Jun 2000 10:46:16 -0400
Message-ID: <B4270D38D7D2D311A7510008C7567EF5B3D20B@pai820exch001u.micro.lucent.com>
From: "Waldo, Michael (Michael)" <waldo@lucent.com>
To: mpls@UU.NET
Subject: RE: MPLS and fast reroute. 
Date: Fri, 9 Jun 2000 10:46:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk


	
>	The benefit of an approach such as this in comparison to SONET APS
is that 
>	with APS the protection infrastructure has traditionally been
unusable, while 
>	MPLS-based restoration and TE provide a considerable amount of
granularity for
>	other [preemptable] traffic to use the protect path under normal
conditions,
>	as well as in additon to failure modes, if capacity is available.
If the
>	protection schema supports statistical multiplexing capabilities
that aren't
>	available with SONET APS, it becomes that much more desirable to
service 
>	providers.


The protection infrastructure in SONET is usable (I'm not sure what was
meant by "traditionally") for some SONET protection schemes. BLSR and linear
1:1 SONET APS protection protocols/networks allow for preemptable traffic to
be carried over the protection channels. It's been defined in the SONET
standards, and the SONET products that I have worked on, supported this
capability.

-Waldo



From owner-mpls@UU.NET  Fri Jun  9 10:51:41 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12483
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 10:51:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvr02781;
	Fri, 9 Jun 2000 14:49:15 GMT
Received: by mail-control.mail.uu.net 
	id QQisvr24955
	for mpls-outgoing; Fri, 9 Jun 2000 14:48:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisvr24948
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 14:48:39 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisvr03071
	for <mpls@UU.NET>; Fri, 9 Jun 2000 10:47:23 -0400 (EDT)
Received: from nexen.nexen.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nexen.nexen.com [204.249.96.18])
	id QQisvr01142
	for <mpls@UU.NET>; Fri, 9 Jun 2000 14:47:23 GMT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5])
	by nexen.nexen.com (8.8.8/8.8.8) with ESMTP id KAA16676;
	Fri, 9 Jun 2000 10:46:05 -0400 (EDT)
Received: from zanuda.nexen.com (zanuda.nexen.com [204.249.98.150]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id KAA26827; Fri, 9 Jun 2000 10:46:04 -0400 (EDT)
Received: from nexen.com (sales2.nexen.com [204.249.97.154])
	by zanuda.nexen.com (8.8.5/8.8.5) with ESMTP id KAA12627;
	Fri, 9 Jun 2000 10:45:53 -0400 (EDT)
Message-ID: <39410320.1620469F@nexen.com>
Date: Fri, 09 Jun 2000 10:45:52 -0400
From: Mark Stewart <Mstewart@nexen.com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
CC: neil.2.harrison@bt.com, curtis@avici.com, jote4102@alu-etsetb.upc.es,
        mpls@UU.NET
Subject: Re: MPLS and fast reroute.
References: <B9571FDEBD3DD21181E500606DD5EE0507B16058@mbddmknt01.hc.bt.com> <39404D30.EB8BBBB0@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

There is no doubt that a carrier should make it clear what levels of APS apply,
unfortunately this information is not allways readily accesable to those with a
need or desire to know.

Ciao

Mark Stewart

Yangguang Xu wrote:

> I think whether L1 protection exists or not should be know, because the price is
> different.
>
> Yangguang
>
> neil.2.harrison@bt.com wrote:
> >
> > Hi Curtis,
> >
> > Agreed if one owns all network instrastructure 'to the duct' (and even then
> > one need very good records of the client/server trail
> > relationships).......but what if the L1 (ie Sonet) was a leased connection
> > for some other operator?  Now one does not know whether L1 protection exists
> > or not.  So what do you do now?
> >
> > Neil



From owner-mpls@UU.NET  Fri Jun  9 11:07:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12768
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 11:07:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvs16307;
	Fri, 9 Jun 2000 15:06:49 GMT
Received: by mail-control.mail.uu.net 
	id QQisvs04525
	for mpls-outgoing; Fri, 9 Jun 2000 15:06:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisvs04262
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 15:05:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisvs11997
	for <mpls@UU.NET>; Fri, 9 Jun 2000 11:05:11 -0400 (EDT)
Received: from tcb.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tcb.net [205.168.100.1])
	id QQisvs20998
	for <mpls@UU.NET>; Fri, 9 Jun 2000 15:05:11 GMT
Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1])
	by tcb.net (8.9.3/8.9.3) with ESMTP id JAA12914
	for <mpls@UU.NET>; Fri, 9 Jun 2000 09:06:23 -0600
Message-Id: <200006091506.JAA12914@tcb.net>
To: mpls@UU.NET
From: Danny McPherson <danny@tcb.net>
Reply-To: danny@tcb.net
Subject: Re: MPLS and fast reroute. 
Date: Fri, 09 Jun 2000 09:06:23 -0600
Sender: owner-mpls@UU.NET
Precedence: bulk


> The protection infrastructure in SONET is usable (I'm not sure what was
> meant by "traditionally") for some SONET protection schemes. BLSR and linear
> 1:1 SONET APS protection protocols/networks allow for preemptable traffic to
> be carried over the protection channels. It's been defined in the SONET
> standards, and the SONET products that I have worked on, supported this
> capability.

I was referring more to the router<->ADM section, I guess I should 
have been more clear in my message.  However, the granularity provided
by an MPLS protection scheme is clearly more flexible than that of SONET
APS, especially when designing networks expressly for packet switching 
services. 

-danny



From owner-mpls@UU.NET  Fri Jun  9 11:08:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12790
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 11:08:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvs19619;
	Fri, 9 Jun 2000 15:03:16 GMT
Received: by mail-control.mail.uu.net 
	id QQisvs29427
	for mpls-outgoing; Fri, 9 Jun 2000 15:02:56 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisvs29368
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 15:02:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisvs06057
	for <mpls@UU.NET>; Fri, 9 Jun 2000 11:02:18 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQisvs18909
	for <mpls@UU.NET>; Fri, 9 Jun 2000 15:02:18 GMT
Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA27620;
	Fri, 9 Jun 2000 11:01:23 -0400 (EDT)
	(envelope-from bkumar@ennovatenetworks.com)
Reply-To: <bkumar@ennovatenetworks.com>
From: "Brijesh Kumar" <bkumar@ennovatenetworks.com>
To: "'Yangguang Xu'" <xuyg@lucent.com>
Cc: <curtis@avici.com>, "'Juan Diego Otero'" <jote4102@alu-etsetb.upc.es>,
        <mpls@UU.NET>
Subject: RE: MPLS and fast reroute.
Date: Fri, 9 Jun 2000 11:05:15 -0400
Message-ID: <00df01bfd224$1ebcab80$d001010a@tst.ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <39404CA3.77E3805A@lucent.com>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


In his previous mail, Yanhguang writes,

> -----Original Message-----
>
> See my comments below:
> I guess my point is misunderstood. SONET protection switching
> uses dedicated
> overhead bytes for signaling and end-to-end coordination.
> This is why SONET
> protection is fast and deterministic. MPLS uses message-based
> signaling to
> coordinate protection switching. With only best effort IP,
> there is no way you
> can guarantee to deliver these signaling messages on time. So
> there has to be
> infrastructure to treat these signaling messages specially.
> This is why I
> mentioned QoS.

It appears that we are perfectly in sync. You raised a very valid
point regarding the need to accommodate QoS in MPLS protection
switching. The point I was trying make was that even without QoS, it
is very hard to obtain SONET like reliability in the system with the
mpls local protect mechanisms. There are many more issues such as
provisioning for fall back capacity, and ability to survive
multi-point failures.


Cheers,

--brijesh
Ennovate Networks Inc.



From owner-mpls@UU.NET  Fri Jun  9 11:48:28 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13531
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 11:48:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvv16053;
	Fri, 9 Jun 2000 15:47:01 GMT
Received: by mail-control.mail.uu.net 
	id QQisvv07749
	for mpls-outgoing; Fri, 9 Jun 2000 15:46:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisvv07744
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 15:46:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisvv13716
	for <mpls@UU.NET>; Fri, 9 Jun 2000 11:45:37 -0400 (EDT)
Received: from auemail2.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail2.lucent.com [192.11.223.163])
	id QQisvv18541
	for <mpls@UU.NET>; Fri, 9 Jun 2000 15:45:37 GMT
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA00372
	for <mpls@UU.NET>; Fri, 9 Jun 2000 11:45:37 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA00353;
	Fri, 9 Jun 2000 11:45:36 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA11745; Fri, 9 Jun 2000 11:45:34 -0400 (EDT)
Message-ID: <3941111E.871095DE@lucent.com>
Date: Fri, 09 Jun 2000 11:45:34 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: danny@tcb.net
CC: mpls@UU.NET
Subject: Re: MPLS and fast reroute.
References: <200006091506.JAA12914@tcb.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



> I was referring more to the router<->ADM section, I guess I should
> have been more clear in my message.  However, the granularity provided
> by an MPLS protection scheme is clearly more flexible than that of SONET
> APS, especially when designing networks expressly for packet switching
> services.
> 

One way to use take advantage of both SONET APS and MPLS flexibility is to have
LSR aggregate LSPs with similar requirements onto SONET tribs, which are
provisioned with certain protection scheme. 

Yangguang


From owner-mpls@UU.NET  Fri Jun  9 12:06:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14050
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 12:06:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvw02142;
	Fri, 9 Jun 2000 16:05:33 GMT
Received: by mail-control.mail.uu.net 
	id QQisvw14038
	for mpls-outgoing; Fri, 9 Jun 2000 16:04:57 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisvw13903
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 16:04:43 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisvw16542
	for <mpls@uu.net>; Fri, 9 Jun 2000 12:02:42 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQisvw27208
	for <mpls@uu.net>; Fri, 9 Jun 2000 16:02:42 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 MAA12535
	for <mpls@uu.net>; Fri, 9 Jun 2000 12:02:39 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25753
	for <mpls@uu.net>; Fri, 9 Jun 2000 12:02:41 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <MR1YPHQ0>; Fri, 9 Jun 2000 12:02:40 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CFE4941F@whq-msgusr-02.fore.com>
From: "Punj, Arun" <Arun.Punj@marconi.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Last Call for LDP
Date: Fri, 9 Jun 2000 12:02:36 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Any reason why LDP can't use SCTP ( sigtran ) instead of TCP ?
It doesnot seem to utilize byte stream feature of TCP anyway,
And would be far more light weight if it used SCTP.

-TL







From owner-mpls@UU.NET  Fri Jun  9 12:41:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14786
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 12:41:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvy22099;
	Fri, 9 Jun 2000 16:38:23 GMT
Received: by mail-control.mail.uu.net 
	id QQisvy20197
	for mpls-outgoing; Fri, 9 Jun 2000 16:37:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisvy20192
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 16:37:43 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisvy21827
	for <mpls@uu.net>; Fri, 9 Jun 2000 12:37:29 -0400 (EDT)
From: mankin@ISI.EDU
Received: from east.isi.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: east.isi.edu [38.245.76.2])
	id QQisvy23734
	for <mpls@uu.net>; Fri, 9 Jun 2000 16:37:29 GMT
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
	by east.isi.edu (8.9.2/8.9.2) with SMTP id MAA01373;
	Fri, 9 Jun 2000 12:37:57 -0400 (EDT)
Date: Fri, 9 Jun 00 12:40:07 EDT
Posted-Date: Fri, 9 Jun 00 12:40:07 EDT
Message-Id: <10006091640.AA03629@maia.east.isi.edu>
Received: by maia.east.isi.edu (4.1/4.0.3-6)
	id <AA03629>; Fri, 9 Jun 00 12:40:07 EDT
To: arun.punj@marconi.com
Subject: re: Last Call for LDP
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

> Any reason why LDP can't use SCTP ( sigtran ) instead of TCP ?

One reason is that the TCP MD-5 usage called for in LDP is a
well-established peer trust mechanism and there's not been any
deployment of SCTP security yet.

> And it would be far more light weight if it used SCTP.

SCTP isn't lighter weight than TCP, but has different services
to meet different requirements.

Allison (TSV Co-AD)


From owner-mpls@UU.NET  Fri Jun  9 12:48:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14926
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 12:48:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisvz28657;
	Fri, 9 Jun 2000 16:46:59 GMT
Received: by mail-control.mail.uu.net 
	id QQisvz20774
	for mpls-outgoing; Fri, 9 Jun 2000 16:46:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisvz20769
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 16:46:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisvz29270
	for <mpls@UU.NET>; Fri, 9 Jun 2000 12:45:56 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQisvz27739
	for <mpls@UU.NET>; Fri, 9 Jun 2000 16:45:55 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 MAA16986;
	Fri, 9 Jun 2000 12:45:52 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06648;
	Fri, 9 Jun 2000 12:45:55 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <MR1YP20R>; Fri, 9 Jun 2000 12:45:54 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CFE49420@whq-msgusr-02.fore.com>
From: "Punj, Arun" <Arun.Punj@marconi.com>
To: "'mankin@ISI.EDU'" <mankin@ISI.EDU>
Cc: mpls@UU.NET
Subject: RE: Last Call for LDP
Date: Fri, 9 Jun 2000 12:45:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Allison,

IPsec SA between peers should solve security requirement,
which is not mandatory in any case. 

As for "horses, for courses" requirements, it would seem 
to me that SCTP is meant for packet oriented signalling
protocols, which is what LDP is.

may be I am missing something.

Arun

-----Original Message-----
From: mankin@ISI.EDU [mailto:mankin@ISI.EDU]
Sent: Friday, June 09, 2000 12:40 PM
To: Punj, Arun
Cc: mpls@UU.NET
Subject: re: Last Call for LDP



Hi,

> Any reason why LDP can't use SCTP ( sigtran ) instead of TCP ?

One reason is that the TCP MD-5 usage called for in LDP is a
well-established peer trust mechanism and there's not been any
deployment of SCTP security yet.

> And it would be far more light weight if it used SCTP.

SCTP isn't lighter weight than TCP, but has different services
to meet different requirements.

Allison (TSV Co-AD)


From owner-mpls@UU.NET  Fri Jun  9 13:17:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15552
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 13:17:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswb19526;
	Fri, 9 Jun 2000 17:15:53 GMT
Received: by mail-control.mail.uu.net 
	id QQiswb01722
	for mpls-outgoing; Fri, 9 Jun 2000 17:15:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiswb01717
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 17:15:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiswa27671
	for <mpls@UU.NET>; Fri, 9 Jun 2000 13:12:56 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQiswa17751
	for <mpls@UU.NET>; Fri, 9 Jun 2000 17:12:55 GMT
Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA12509;
	Fri, 9 Jun 2000 10:12:23 -0700 (PDT)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id KAA12892; Fri, 9 Jun 2000 10:12:22 -0700 (PDT)
Date: Fri, 9 Jun 2000 10:12:22 -0700 (PDT)
Message-Id: <200006091712.KAA12892@cirrus.juniper.net>
From: Dave Katz <dkatz@juniper.net>
To: Arun.Punj@marconi.com
CC: mankin@ISI.EDU, mpls@UU.NET
In-reply-to: <4FBEA8857476D311A03300204840E1CFE49420@whq-msgusr-02.fore.com>
	(Arun.Punj@marconi.com)
Subject: Re: Last Call for LDP
Sender: owner-mpls@UU.NET
Precedence: bulk

It is less likely for a protocol to reach the "working code" half of
the IETF mantra if it also requires going off and implementing
(typically in the kernel environment) another transport protocol when
there is already one universally available that works just fine.
"Lighter weight," whether true or not, is an uninteresting
optimization unless TCP proves to be too "heavy."  (From an
implementation standpoint, STCP is decidedly not "lighter weight"
because it requires effort greater than zero.)

And transport protocols are notorious for being much harder to implement
well than they look at first glance.

--Dave


   Hi Allison,

   IPsec SA between peers should solve security requirement,
   which is not mandatory in any case. 

   As for "horses, for courses" requirements, it would seem 
   to me that SCTP is meant for packet oriented signalling
   protocols, which is what LDP is.

   may be I am missing something.

   Arun

   -----Original Message-----
   From: mankin@ISI.EDU [mailto:mankin@ISI.EDU]
   Sent: Friday, June 09, 2000 12:40 PM
   To: Punj, Arun
   Cc: mpls@UU.NET
   Subject: re: Last Call for LDP



   Hi,

   > Any reason why LDP can't use SCTP ( sigtran ) instead of TCP ?

   One reason is that the TCP MD-5 usage called for in LDP is a
   well-established peer trust mechanism and there's not been any
   deployment of SCTP security yet.

   > And it would be far more light weight if it used SCTP.

   SCTP isn't lighter weight than TCP, but has different services
   to meet different requirements.

   Allison (TSV Co-AD)



From owner-mpls@UU.NET  Fri Jun  9 13:36:24 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15928
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 13:36:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswc04151;
	Fri, 9 Jun 2000 17:35:34 GMT
Received: by mail-control.mail.uu.net 
	id QQiswc03287
	for mpls-outgoing; Fri, 9 Jun 2000 17:35:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiswc03273
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 17:35:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiswc00773
	for <mpls@UU.NET>; Fri, 9 Jun 2000 13:34:02 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49])
	id QQiswc01616
	for <mpls@UU.NET>; Fri, 9 Jun 2000 17:34:02 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Jun  9 13:33:50 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn65.pa.bell-labs.com [135.250.1.65])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA19210;
	Fri, 9 Jun 2000 13:34:09 -0400 (EDT)
Message-ID: <39412B67.2D5AA2E0@dnrc.bell-labs.com>
Date: Fri, 09 Jun 2000 10:37:43 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Punj, Arun" <Arun.Punj@marconi.com>
CC: mpls@UU.NET
Subject: Re: Last Call for LDP
References: <4FBEA8857476D311A03300204840E1CFE49420@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Punj, Arun" wrote:
	[..]
> may be I am missing something.

That TCP is already widely implemented?

cheers,
gja


From owner-mpls@UU.NET  Fri Jun  9 14:01:28 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16326
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 14:01:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswd20909;
	Fri, 9 Jun 2000 17:59:56 GMT
Received: by mail-control.mail.uu.net 
	id QQiswd04814
	for mpls-outgoing; Fri, 9 Jun 2000 17:59:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiswd04809
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 17:59:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiswd04467
	for <mpls@uu.net>; Fri, 9 Jun 2000 13:57:20 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiswd18992
	for <mpls@uu.net>; Fri, 9 Jun 2000 17:57:20 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA25460
	for mpls@uu.net; Fri, 9 Jun 2000 13:57:19 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiswd04707
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 17:56:39 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiswd04012
	for <mpls@UU.NET>; Fri, 9 Jun 2000 13:54:40 -0400 (EDT)
Received: from qhars002.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19])
	id QQiswd16622
	for <mpls@UU.NET>; Fri, 9 Jun 2000 17:54:24 GMT
Received: from zhard00d.europe.nortel.com (actually zhard00d) 
          by qhars002.nortel.com; Fri, 9 Jun 2000 18:46:21 +0100
Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) 
          by zhard00d.europe.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id MR4BP05Y; Fri, 9 Jun 2000 18:46:21 +0100
Received: from nortelnetworks.com (LANDERSS [141.251.192.190]) 
          by zvb1c002.corpemea.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id L4PJH4GY; Fri, 9 Jun 2000 19:46:18 +0200
Message-ID: <39412D84.46FDFA73@nortelnetworks.com>
Date: Fri, 09 Jun 2000 19:46:44 +0200
X-Sybari-Space: 00000000 00000000 00000000
From: "Loa Andersson" <loa.andersson@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Katz <dkatz@juniper.net>
CC: Arun.Punj@marconi.com, mankin@ISI.EDU, mpls@UU.NET
Subject: Re: Last Call for LDP
References: <200006091712.KAA12892@cirrus.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

this was something we discussed quite a bit in the LDP design team
the first and second meeting. The reason was that ARIS (the early
IBM implementation) run directly over IP and implemented a 
reliable transport of its own.

We decided to to use TCP because it was readily available and well
known.
It has been in the LDP spec since 97 and was slightly discussed at the 
Washington meeting that year. It has since then - through WG Last calls 
and IESG last call and been generally accepted.

IMHO there are to many divergencies in the Label distribution area, to 
make yet another one useful. 

I agree with what  Dave Katz wrote:
> 
> It is less likely for a protocol to reach the "working code" half of
> the IETF mantra if it also requires going off and implementing
> (typically in the kernel environment) another transport protocol when
> there is already one universally available that works just fine.
> "Lighter weight," whether true or not, is an uninteresting
> optimization unless TCP proves to be too "heavy."  (From an
> implementation standpoint, STCP is decidedly not "lighter weight"
> because it requires effort greater than zero.)
> 
> And transport protocols are notorious for being much harder to implement
> well than they look at first glance.
> 
> --Dave
> 

/Loa

>    Hi Allison,
> 
>    IPsec SA between peers should solve security requirement,
>    which is not mandatory in any case.
> 
>    As for "horses, for courses" requirements, it would seem
>    to me that SCTP is meant for packet oriented signalling
>    protocols, which is what LDP is.
> 
>    may be I am missing something.
> 
>    Arun
> 
>    -----Original Message-----
>    From: mankin@ISI.EDU [mailto:mankin@ISI.EDU]
>    Sent: Friday, June 09, 2000 12:40 PM
>    To: Punj, Arun
>    Cc: mpls@UU.NET
>    Subject: re: Last Call for LDP
> 
>    Hi,
> 
>    > Any reason why LDP can't use SCTP ( sigtran ) instead of TCP ?
> 
>    One reason is that the TCP MD-5 usage called for in LDP is a
>    well-established peer trust mechanism and there's not been any
>    deployment of SCTP security yet.
> 
>    > And it would be far more light weight if it used SCTP.
> 
>    SCTP isn't lighter weight than TCP, but has different services
>    to meet different requirements.
> 
>    Allison (TSV Co-AD)

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: loa.andersson@nortelnetworks.com



From owner-mpls@UU.NET  Fri Jun  9 14:02:03 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16387
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 14:02:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswe21701;
	Fri, 9 Jun 2000 18:00:32 GMT
Received: by mail-control.mail.uu.net 
	id QQiswd04824
	for mpls-outgoing; Fri, 9 Jun 2000 17:59:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiswd04819
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 17:59:41 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiswd11578
	for <mpls@uu.net>; Fri, 9 Jun 2000 13:59:16 -0400 (EDT)
From: mankin@ISI.EDU
Received: from east.isi.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: east.isi.edu [38.245.76.2])
	id QQiswd20261
	for <mpls@uu.net>; Fri, 9 Jun 2000 17:59:16 GMT
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
	by east.isi.edu (8.9.2/8.9.2) with SMTP id NAA02132;
	Fri, 9 Jun 2000 13:59:44 -0400 (EDT)
Date: Fri, 9 Jun 00 14:01:54 EDT
Posted-Date: Fri, 9 Jun 00 14:01:54 EDT
Message-Id: <10006091801.AA03664@maia.east.isi.edu>
Received: by maia.east.isi.edu (4.1/4.0.3-6)
	id <AA03664>; Fri, 9 Jun 00 14:01:54 EDT
To: arun.punj@marconi.com
Subject: re: Last Call for LDP
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk


Arun,

> IPsec SA between peers should solve security requirement,
> which is not mandatory in any case. 

I'm not up enough on the spec to comment on how to use IPsec
and not fully cognizant of the protocol status, but it seems
from the risk factors described in the LDP Security Considerations
that it would be important to require security.  My two cents...

> As for "horses, for courses" requirements, it would seem
> to me that SCTP is meant for packet oriented signalling
> protocols, which is what LDP is.

If a requirements analysis shows that SCTP matches LDP's needs
well, which it might, that's very valid.  I was pushing back
on your suggestion that SCTP would be a good choice because
it's "light weight".  

Allison


From owner-mpls@UU.NET  Fri Jun  9 14:12:07 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16574
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 14:12:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswe29442;
	Fri, 9 Jun 2000 18:10:54 GMT
Received: by mail-control.mail.uu.net 
	id QQiswe14684
	for mpls-outgoing; Fri, 9 Jun 2000 18:10:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiswe14664
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 18:10:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiswe13666
	for <mpls@uu.net>; Fri, 9 Jun 2000 14:09:51 -0400 (EDT)
From: mankin@ISI.EDU
Received: from east.isi.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: east.isi.edu [38.245.76.2])
	id QQiswe28564
	for <mpls@uu.net>; Fri, 9 Jun 2000 18:09:50 GMT
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
	by east.isi.edu (8.9.2/8.9.2) with SMTP id OAA02256;
	Fri, 9 Jun 2000 14:10:17 -0400 (EDT)
Date: Fri, 9 Jun 00 14:12:28 EDT
Posted-Date: Fri, 9 Jun 00 14:12:28 EDT
Message-Id: <10006091812.AA03686@maia.east.isi.edu>
Received: by maia.east.isi.edu (4.1/4.0.3-6)
	id <AA03686>; Fri, 9 Jun 00 14:12:28 EDT
To: mpls@UU.NET
Subject: re: Last Call for LDP
Cc: mankin@ISI.EDU
Sender: owner-mpls@UU.NET
Precedence: bulk


By the way, I agree too with Dave Katz's points.  

There were compelling requirements in SIGTRAN because of 
estabished telephony signalling parameters that TCP 
could not meet.

We're encouraging WGs to consider the use of SCTP 
especially when muxing or multiple hosting are important, but
with careful evaluation of the costs and benefits.

Allison


From owner-mpls@UU.NET  Fri Jun  9 14:52:07 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17214
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 14:52:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswh27052;
	Fri, 9 Jun 2000 18:50:52 GMT
Received: by mail-control.mail.uu.net 
	id QQiswh16873
	for mpls-outgoing; Fri, 9 Jun 2000 18:50:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiswh16867
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 18:50:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiswh20698
	for <mpls@uu.net>; Fri, 9 Jun 2000 14:49:43 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiswh26068
	for <mpls@uu.net>; Fri, 9 Jun 2000 18:49:42 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA04235
	for mpls@uu.net; Fri, 9 Jun 2000 14:49:41 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiswh16823
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 18:49:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiswh20471
	for <mpls@uu.net>; Fri, 9 Jun 2000 14:48:15 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQiswh24845
	for <mpls@uu.net>; Fri, 9 Jun 2000 18:48:15 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA14313
	for <mpls@uu.net>; Fri, 9 Jun 2000 11:48:14 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <MLZ2G85S>; Fri, 9 Jun 2000 11:48:14 -0700
Message-ID: <E097FDA4F2FED311994000104B31A86115E6C0@MONTEREY>
From: Bora Akyol <akyol@pluris.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Hierarchical Tunnel Establishment in RSVP-TE
Date: Fri, 9 Jun 2000 11:48:08 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD243.4474D554"
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_01BFD243.4474D554
Content-Type: text/plain;
	charset="iso-8859-1"

How does one establish hierarchical tunnels using RSVP-TE?
 
I know that the label object can be deeper than one label, but you need more
than this
to establish hierarchical tunnels.
 
Thanks
 
Bora
 

------_=_NextPart_001_01BFD243.4474D554
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.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=498514618-09062000>How does one 
establish hierarchical tunnels using RSVP-TE?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=498514618-09062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=498514618-09062000>I know that the 
label object can be deeper than one label, but you need more than 
this</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=498514618-09062000>to establish 
hierarchical tunnels.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=498514618-09062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=498514618-09062000>Thanks</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=498514618-09062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=498514618-09062000>Bora</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=498514618-09062000></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01BFD243.4474D554--



From owner-mpls@UU.NET  Fri Jun  9 15:43:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18050
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 15:43:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswk03292;
	Fri, 9 Jun 2000 19:42:23 GMT
Received: by mail-control.mail.uu.net 
	id QQiswk29600
	for mpls-outgoing; Fri, 9 Jun 2000 19:41:53 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiswk29587
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 19:41:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiswk00575
	for <mpls@uu.net>; Fri, 9 Jun 2000 15:41:15 -0400 (EDT)
Received: from web5102.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5102.mail.yahoo.com [216.115.106.72])
	id QQiswk03798
	for <mpls@uu.net>; Fri, 9 Jun 2000 19:41:14 GMT
Message-ID: <20000609194113.16297.qmail@web5102.mail.yahoo.com>
Received: from [169.144.16.187] by web5102.mail.yahoo.com; Fri, 09 Jun 2000 12:41:13 PDT
Date: Fri, 9 Jun 2000 12:41:13 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
To: Bora Akyol <akyol@pluris.com>, mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

I would also like to know why and if any body would
ever be interested in pushing more than one label 
at a ingress LSR.

C.

--- Bora Akyol <akyol@pluris.com> wrote:
> How does one establish hierarchical tunnels using
> RSVP-TE?
>  
> I know that the label object can be deeper than one
> label, but you need more
> than this
> to establish hierarchical tunnels.
>  
> Thanks
>  
> Bora
>  
> 


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Fri Jun  9 16:35:19 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18577
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 16:35:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswo09262;
	Fri, 9 Jun 2000 20:34:32 GMT
Received: by mail-control.mail.uu.net 
	id QQiswo12883
	for mpls-outgoing; Fri, 9 Jun 2000 20:34:14 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiswo12878
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 20:34:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiswo09532
	for <mpls@uu.net>; Fri, 9 Jun 2000 16:34:02 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiswo11582
	for <mpls@uu.net>; Fri, 9 Jun 2000 20:34:01 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA19882
	for mpls@uu.net; Fri, 9 Jun 2000 16:34:00 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiswo12867
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 20:33:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiswo00263
	for <mpls@UU.NET>; Fri, 9 Jun 2000 16:33:05 -0400 (EDT)
Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailman.cisco.com [171.68.225.9])
	id QQiswo08037
	for <mpls@UU.NET>; Fri, 9 Jun 2000 20:33:05 GMT
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29506;
	Fri, 9 Jun 2000 13:33:01 -0700 (PDT)
Message-Id: <4.3.1.2.20000609162314.00ae72a0@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 09 Jun 2000 16:32:25 -0400
To: "Punj, Arun" <Arun.Punj@marconi.com>, "'mpls@uu.net'" <mpls@UU.NET>
From: Chip Sharp <chsharp@cisco.com>
Subject: Re: Last Call for LDP
In-Reply-To: <4FBEA8857476D311A03300204840E1CFE4941F@whq-msgusr-02.fore.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

It might be interesting some time in the future to investigate it, but 
right now I don't know of a compelling reason to do it.

FWIW, SCTP (the spec) will support the same port numbers as TCP for 
LDP.  You can theoretically run SCTP over IPSEC for security although you'd 
have to think carefully about the multihoming issues and it hasn't been 
beaten on.  There is a reliable, unordered mode of operation and it does 
support multiple independent data streams in a single session.

SCTP is just now going through its first bakeoff.  Give it a year and see 
how it works out.  There is no need to rush it.

Of course, if you come up with a huge advantage for using SCTP let me know.
:-)

Chip
SCTP co-editor

At 12:02 PM 6/9/00 -0400, Punj, Arun wrote:
>Hi,
>
>Any reason why LDP can't use SCTP ( sigtran ) instead of TCP ?
>It doesnot seem to utilize byte stream feature of TCP anyway,
>And would be far more light weight if it used SCTP.
>
>-TL
>
>
>
>


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Change it.	
http://www.netaid.org		
-------------------------------------------------------------------




From owner-mpls@UU.NET  Fri Jun  9 16:41:20 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18635
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 16:41:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswo14134;
	Fri, 9 Jun 2000 20:40:26 GMT
Received: by mail-control.mail.uu.net 
	id QQiswo13297
	for mpls-outgoing; Fri, 9 Jun 2000 20:40:11 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiswo13276
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 20:39:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiswo01295
	for <mpls@uu.net>; Fri, 9 Jun 2000 16:39:22 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiswo15258
	for <mpls@uu.net>; Fri, 9 Jun 2000 20:39:20 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA20818
	for mpls@uu.net; Fri, 9 Jun 2000 16:39:19 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiswo13238
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 20:39:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiswo10354
	for <mpls@UU.NET>; Fri, 9 Jun 2000 16:38:50 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiswo12626
	for <mpls@UU.NET>; Fri, 9 Jun 2000 20:38:49 GMT
Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA20739;
	Fri, 9 Jun 2000 16:38:48 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA09408; Fri, 9 Jun 2000 16:38:48 -0400 (EDT)
Message-Id: <200006092038.QAA09408@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: "Punj, Arun" <Arun.Punj@marconi.com>
cc: "'mpls@uu.net'" <mpls@UU.NET>, swallow@cisco.com
Subject: Re: Last Call for LDP 
In-reply-to: Your message of "Fri, 09 Jun 2000 12:02:36 EDT."
             <4FBEA8857476D311A03300204840E1CFE4941F@whq-msgusr-02.fore.com> 
Date: Fri, 09 Jun 2000 16:38:48 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

All -

This is a reminder that this last call is limited to the issues raised
in the previous last call.

Arun -

> Any reason why LDP can't use SCTP ( sigtran ) instead of TCP ?
> It doesnot seem to utilize byte stream feature of TCP anyway,
> And would be far more light weight if it used SCTP.

Thanks for providing such a clear example of something that's out of
scope!

...George

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



From owner-mpls@UU.NET  Fri Jun  9 18:55:02 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19687
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 18:55:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiswx18373;
	Fri, 9 Jun 2000 22:55:02 GMT
Received: by mail-control.mail.uu.net 
	id QQiswx09064
	for mpls-outgoing; Fri, 9 Jun 2000 22:54:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiswx09059
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 22:54:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiswx28153
	for <mpls@UU.NET>; Fri, 9 Jun 2000 18:53:56 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQiswx25215
	for <mpls@UU.NET>; Fri, 9 Jun 2000 22:53:56 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id SAA27177; Fri, 9 Jun 2000 18:53:49 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id SAA19341;
	Fri, 9 Jun 2000 18:53:57 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006092253.SAA19341@curtis-lt.avici.com>
To: neil.2.harrison@bt.com
cc: curtis@avici.com, pjw@ip-engineering.bt.com, Ben.Mack-Crane@tellabs.com,
        otel@ce.chalmers.se, Shahram_Davari@pmc-sierra.com, EGray@zaffire.com,
        swtan@mmu.edu.my, kireeti@juniper.net, dwilder@baynetworks.com,
        mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-reply-to: Your message of "Thu, 08 Jun 2000 22:37:46 BST."
             <B9571FDEBD3DD21181E500606DD5EE0507B16059@mbddmknt01.hc.bt.com> 
Date: Fri, 09 Jun 2000 18:53:57 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B9571FDEBD3DD21181E500606DD5EE0507B16059@mbddmknt01.hc.bt.com>, nei
l.2.harrison@bt.com writes:
> See comments below, Regards Neil
> 
> 	[Harrison,N,Neil,INC1 X]  <Snip> 
> 
> > > As a network operator I have the following requirements:
> > > - I need to detect failure of an LSP. (I don't want to wait for the
> > > 	customer to report a failure)
> > 
> > This is a good requirement statement.
> 	[Harrison,N,Neil,INC1 X]  Good.  Then perhaps we can agree that all
> defects need defining and tools providing to allow an operator to detect
> them in advance of a customer reporting a fault.  So for LSPs there are at
> least the following:

OK.  We at least agree that we need to start with a statement of the
probelm we are trying to solve.

> 	-	simple connectivity failures (sourced from server or MPLS
> layer......and we need to distinguish......note that ISP may not own
> physical layer, cf earlier prot-sw issue on mail) 

Diagnosing physical layer problems would depend on each physical layer
unless we wanted simply to treat the physical layer as opaque and get
a measure of how well it is doing.  For that application something
alone the lines of LQM is well suited.  OAM is not since you can't put
enough probe packets into the network to start with.

> 	-	swapped LSPs
> 	-	mismerging of >=2 LSps
> 	-	self-mismerging

Problems of this type fall into two categories:

  1.  The control software has bugs and has either signaled wrong
      labels or assigned incorrect table entries.  SNMP query of an
      MPLS MIB which reveals ingress FEC mappings, the insegments, and
      outsegment would allow tunnels to be verified and allow this
      type of problem to be identified.  We already have such a thing.

  2.  The control software has it right, but the lower level software
      or hardware doesn't agree with the control software.  In this
      case the traffic verifying the packet flow must take a path
      throught the hardware that is as close to identical to the
      actual traffic as possible, or make a very accurate measurement
      of the actual traffic.

In the latter case, you can send probe packets thorugh the tunnel but
they really should have an identical top label (or label stack under
test).  LQM does somwhat better in that if there are a few million PPS
of traffic and only a small amount of LQM packets, there is a huge
sampling.

Even with OAM or a yet to be specified MPLS LQM there is still a
problem of verifying the mapping of FEC into LSPs at the ingress.  If
there are 70,000 IP routes at an ingress LSR and only 700 tunnels, OAM
or LQM only covers 1% of the entries needed to make traffic flow in
the right direction.  If anything is done in this area, I'd favor
specifying an LQM for MPLS as I suggested in a prior email.

The only way that the 70,000 other entries can be verified would be to
send probe packets (IP OAM, traceroute, whatever) to each destination.
If 100 PPS of probe traffic is injected, then each route is checked
only once every 10 minutes but this is better than with MPLS OAM where
it is never checked.

Curtis



From owner-mpls@UU.NET  Fri Jun  9 19:33:32 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20083
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 19:33:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisxa11526;
	Fri, 9 Jun 2000 23:33:31 GMT
Received: by mail-control.mail.uu.net 
	id QQisxa20624
	for mpls-outgoing; Fri, 9 Jun 2000 23:33:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisxa20619
	for <mpls@mail-control.mail.uu.net>; Fri, 9 Jun 2000 23:32:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisxa01870
	for <mpls@UU.NET>; Fri, 9 Jun 2000 19:30:51 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQisxa24383
	for <mpls@UU.NET>; Fri, 9 Jun 2000 23:30:46 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id TAA28957; Fri, 9 Jun 2000 19:30:45 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id TAA19384;
	Fri, 9 Jun 2000 19:31:05 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006092331.TAA19384@curtis-lt.avici.com>
To: neil.2.harrison@bt.com
cc: curtis@avici.com, pjw@ip-engineering.bt.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-reply-to: Your message of "Fri, 09 Jun 2000 00:07:02 BST."
             <B9571FDEBD3DD21181E500606DD5EE0507B1605E@mbddmknt01.hc.bt.com> 
Date: Fri, 09 Jun 2000 19:31:05 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B9571FDEBD3DD21181E500606DD5EE0507B1605E@mbddmknt01.hc.bt.com>, nei
l.2.harrison@bt.com writes:
> See remarks below.  Regards, Neil
> 
> 	[Harrison,N,Neil,INC1 X]  <Snip>
> >  Back to the requirement.  We have, in order of expected frequency, the
> > following types of failures:
> > 
> >   1.  Failures that are detected by the control plane.  For example,
> >       link failures or complete hardware component failures.
> > 
> >   2.  Software failures that are not detectable at the control plane.
> >       These will exist iff there remain software bugs which allow
> >       inconsistencies between control plane software and low level
> >       software or hardware.
> > 
> >   3.  Hardware failures that are not detectable at the control plane.
> >       These will exist iff there remain data paths or highly
> >       persistent data storage (like forwarding tables) that is not
> >       protected by ECC or parity.
> > 
> > OAM is not needed for the first set because the control plane will
> > recover and/or report the fault.
> 	[Harrison,N,Neil,INC1 X]  And why is this?  It's because the
> control-plane had OAM functions designed into it at the outset.  

No.  Because the control plane can be queried with SNMP and
periodically verfied.

> But the
> control-plane is not one single entity.....at its coarsest it comprises (i)
> addressing (ii) a routing protocol (iii) a signalling protocol (at least for
> CO-type routings).  What we really mean here is that the routing protocol
> will (eventually) detect the failures........providing they are simple
> breaks and not more complex misbranching cases.   We don't have to worry
> about misbranching in IP........each pkt contains an absolute source (and
> indeed sink) address....subject to global uniqueness issues.  This is not
> true in MPLS.  Labels are ostensibly only unique per interface and are
> therefore relative addresses.  BTW, to also rely on the 'control-plane'
> requires it to have total congruence with the user plane.........can we
> really be so prescriptive on this? 

All of which have (or should have) MIBs.

> > The third case is better covered by making sure all registers can be
> > read back and periodically checking hardware registers to
> > make sure that they match the software copies.
> 	[Harrison,N,Neil,INC1 X]  Operators cannot be prescriptive about
> manufacturer implementations .  We would hope they pay attention to internal
> nodal defects as suggested.

I doubt that you are suggesting that we ignore this type of problem.
If we did we could properly instrument the control plane (with MIBs)
and we're done.

> > The problem may occur at:
> > 
> >   1.  ingress,
> >   2.  midpoint, or
> >   3.  egress.
> > 
> > For example, if the ingress node loses the hardware entry that is
> > supposed to map a given IP prefix into an LSP, the same ingress may
> > successfully inject OAM packets because those do not enter as IP with
> > that prefix.  This is probably by far the most common error and it is
> > not detectable by OAM packets.
> 	[Harrison,N,Neil,INC1 X]  This is describing a defect which is in
> the IP layer......or perhaps more accurately in the IP->MPLS layer
> adaptation function.  So it is not valid to say MPLS OAM will not detect
> this....it indeed should not.
> >   This is also not detectable by ping
> > unless the ping uses an IP destination corresponding to the faulty
> > entry.  This is detectable by a traceroute, because traceroute is IP
> > and can have the identical destination (and source, but that gets a
> > bit more tricky) and can be given a limited TTL that just verifies the
> > tunnel.
> 	[Harrison,N,Neil,INC1 X]  Then we have a tool at the right layer for
> this particular defect.

So you agree that traceroute is the right tool for this.  OK we agree.

> > Note that an RFC2547 style VPNs there are multiple forwarding tables
> > in the provider edge routers.  These forwarding tables can only be
> > verified by injecting traffic through the same interface that would
> > exercise the same table entries.  Sounds to me a lot like a ping would
> > do the job nicely while an OAM packet that already had an MPLS
> > encapsulation would not.
> 	[Harrison,N,Neil,INC1 X]  Agreed.  We are talking of IP->MPLS
> adaptation again I think.  So the IP layer needs to detect this since it is
> not a defect of the MPLS layer. [Note - If we had some decent functional
> architecture diagrams I think this would help us a great deal......Andy Reid
> and Mike Sexton, if you are out there reading this please come to our
> rescue......I'll forward this mail to you anyway]

So OAM doesn't adress this either.  We agree here too.

> > If a midpoint loses a hardware entry for a given label, and the OAM
> > packet has a special label that kicks the OAM packet to software to be
> > counted, checked, or manipulated in some way, it still hasn't caught
> > the problem where the hardware table for that label is wrong since it
> > consults software.
> 	[Harrison,N,Neil,INC1 X]  I would not expect mid points of an LSP to
> alter a CV (Connectivity Verification) OAM pkt in any way.  They should be
> treated as normal user-plane traffic.  CV pkts are generated at the LSP
> source point and only examined again at the LSP sink point.  If there are
> lower layer LSPs, then the higher layer LSP simply gets encapsulated and
> passes transparently.  Or at the least that's the model I have in mind for
> all this.

That would mean that a special top label that flags a packet as OAM is
out of the question.  Good.  We agree again.

> > The OAM label is diverted at the egress before it hits the hardware
> > that does things like POP the label and adjust the packet length,
> > adjust the underlying TTL (if IP), ECN, etc.  So the OAM packet
> > doesn't detect this fault either.
> 	[Harrison,N,Neil,INC1 X]  Need proper functional architecture to
> decide whether the issues being described are a function of the client layer
> or the server layer, ie do they come after or before the LSP trail
> termination point?  But they all sound client layer to me and so look like
> they should be a function of the client layer to check 'correctness'.

So OAM does not address this either.  OK.  Further agreement.

> > One thing that might help, but is not ATM OAM like is some form of LQM
> > for MPLS.  For example, the ingress could place a packet into the
> > stream with the label stack it wants to measure and a special LQM
> > label (in the reserved range) below it and place LSP counters in the
> > underlying packet.  A special outsegment would be needed at the
> > ingress to put the label stack and current counters in place.  At the
> > egress, the last forwarding label would be POPed and the reserved
> > label would be revealed.  The hardware would have to place its LSP
> > counters in the packet and forward to software for exception
> > processing.  The software can then subtract the counters of two
> > successive MPLS LQM (as is done in RFC1989 PPP LQM) to determine the
> > traffic rate and loss along the LSP.  Only the ingress and egress
> > would need to do this.  If the egress didn't know how, it would count
> > and silently discard the packet and you'd be no worse off.
> > 
> > MPLS LQM would definitely require hardware change so expect to hear
> > some screams.  On the positive side, only the ingress and egress need
> > to do it and it can be deployed incrementally.
> 	[Harrison,N,Neil,INC1 X]  I'd like to know more about this.....I'll
> check out the refs you gave (thanks).  In the stuff I have been looking at I
> tried to keep the OAM as minimal and consistent as I could (having been
> through the ATM 'experience').  My basic Connectvity Verification pkt is
> nothing more that a sort of keepalive that is sent LSP_trail_source to
> LSP_trail_sink on a periodic basis.  This detects all the connectivity
> defects that might occur.  I also designed a variation on this which simply
> counted the client layer pkts/octets sent between sucessive CV pkts....which
> I called a CV+P pkt.  Its not something I would recommend for day-day use
> (processing burden) but is simply there as a 1-step-up ad hoc diagnostic
> tool for looking at pkt loss (and something that could be picked-off, by a
> search for the absolute LSP source address, at intermediate points along an
> LSP for subnetwork partition monitoring).  More than this (ie full QoS
> metric suite) would require a sampling regime, like the probes discussed
> earlier.

It might be possible to have two types of packets.  

One is an OAM connectivity verification that is injected at the
ingress and goes under the last label that you are testing
connectivity for.  When POP occurs, the OAM packet is simply counted
and possibly something in the packet is recorded (a sequence number
for example).  The ingress can inject these at some prescribed
(settable) rate.  SNMP can use two successive polls, subtract the
sequence numbers and subtract the counters and determine how many
probe packets (OAM packets) have been lost.  To have some chance at
detecting 0.1% loss you need to send at least 1,000 OAM packets.
This could be implemented entirely in software.

The other type would be LQM packets.  This would require hardware
assist to implement.  If there were 10^5 PPS on an LSP very small
levels of loss could be detected and extremely accurate loss
measurements could be made even if one LQM packet per second were
sent.

Of course both would be optional but there would be very little
incentive not to offer the first.

Curtis



From owner-mpls@UU.NET  Fri Jun  9 22:31:19 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22852
	for <mpls-archive@lists.ietf.org>; Fri, 9 Jun 2000 22:31:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisxm04198;
	Sat, 10 Jun 2000 02:31:20 GMT
Received: by mail-control.mail.uu.net 
	id QQisxm27794
	for mpls-outgoing; Sat, 10 Jun 2000 02:31:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisxm27753
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 02:30:55 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisxm19908
	for <mpls@UU.NET>; Fri, 9 Jun 2000 22:30:28 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQisxm01535
	for <mpls@UU.NET>; Sat, 10 Jun 2000 02:30:28 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id WAA06994; Fri, 9 Jun 2000 22:30:26 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id WAA19843;
	Fri, 9 Jun 2000 22:30:39 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006100230.WAA19843@curtis-lt.avici.com>
To: Yangguang Xu <xuyg@lucent.com>
cc: danny@tcb.net, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS and fast reroute. 
In-reply-to: Your message of "Fri, 09 Jun 2000 11:45:34 EDT."
             <3941111E.871095DE@lucent.com> 
Date: Fri, 09 Jun 2000 22:30:39 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3941111E.871095DE@lucent.com>, Yangguang Xu writes:
> 
> 
> > I was referring more to the router<->ADM section, I guess I should
> > have been more clear in my message.  However, the granularity provided
> > by an MPLS protection scheme is clearly more flexible than that of SONET
> > APS, especially when designing networks expressly for packet switching
> > services.
> > 
> 
> One way to use take advantage of both SONET APS and MPLS flexibility is to ha
> ve
> LSR aggregate LSPs with similar requirements onto SONET tribs, which are
> provisioned with certain protection scheme. 
> 
> Yangguang


Except for the fact that that would be grossly inefficient from a
traffic engineering standpoint, this is a fine idea.  

For example, if 10% of your traffic required the type of restoration
offerred by APS or MPLS local-protect, then you'd spend a lot less
accommodating your backup need with MPLS local-protect on the 10% of
the LSPs than carving out separate lambdas for those SONET paths that
were carrying traffic needing protection.

Curtis



From owner-mpls@UU.NET  Sat Jun 10 01:26:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27325
	for <mpls-archive@lists.ietf.org>; Sat, 10 Jun 2000 01:26:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisxx20329;
	Sat, 10 Jun 2000 05:26:30 GMT
Received: by mail-control.mail.uu.net 
	id QQisxx04340
	for mpls-outgoing; Sat, 10 Jun 2000 05:26:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQisxx04305
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 05:26:00 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisxx09725
	for <mpls@uu.net>; Sat, 10 Jun 2000 01:25:52 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisxx19706
	for <mpls@uu.net>; Sat, 10 Jun 2000 05:25:51 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA24263
	for mpls@uu.net; Sat, 10 Jun 2000 01:25:50 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQisxx04291
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 05:25:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisxx28562
	for <mpls@UU.NET>; Sat, 10 Jun 2000 01:25:21 -0400 (EDT)
Received: from redd235.procket.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: flowpoint.procket.com [205.253.146.41])
	id QQisxx16614
	for <mpls@UU.NET>; Sat, 10 Jun 2000 05:25:20 GMT
Received: (from tli@localhost)
	by redd235.procket.com (8.9.3/8.9.3) id WAA01869;
	Fri, 9 Jun 2000 22:24:48 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redd235.procket.com: tli set sender to tli@redd235.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14657.53536.422247.469955@redd235.procket.com>
Date: Fri, 9 Jun 2000 22:24:48 -0700 (PDT)
To: Bora Akyol <akyol@pluris.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Hierarchical Tunnel Establishment in RSVP-TE
In-Reply-To: <55903347@toto.iv>
X-Mailer: VM 6.75 under Emacs 20.4.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



 | How does one establish hierarchical tunnels using RSVP-TE?
 |  
 | I know that the label object can be deeper than one label, but you need more
 | than this to establish hierarchical tunnels.


A hierarchical tunnel requires the participation of at least two LSRs.  The
operation of the LSR creating the innermost tunnel is straightforward and
is unchanged from what has been endlessly discussed here.

For an LSR to create an outer tunnel, it simply creates another tunnel and
specifies MPLS as the L3PID.  It then forwards packets received on the
inner tunnel by pushing a label for the outer tunnel.  The RSVP control
traffic for the inner tunnel is also forwarded through the outer tunnel
after first being encapsulated with a null IP label.

Recurse, ad nauseum.

Simple, really.  ;-)

Tony



From owner-mpls@UU.NET  Sat Jun 10 01:53:02 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29864
	for <mpls-archive@lists.ietf.org>; Sat, 10 Jun 2000 01:53:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisxz11110;
	Sat, 10 Jun 2000 05:53:02 GMT
Received: by mail-control.mail.uu.net 
	id QQisxz05751
	for mpls-outgoing; Sat, 10 Jun 2000 05:52:45 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisxz05746
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 05:52:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisxz12518
	for <mpls@uu.net>; Sat, 10 Jun 2000 01:52:33 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisxz02286
	for <mpls@uu.net>; Sat, 10 Jun 2000 05:52:32 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA25371
	for mpls@uu.net; Sat, 10 Jun 2000 01:52:32 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisxz05733
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 05:52:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQisxz12439
	for <mpls@UU.NET>; Sat, 10 Jun 2000 01:51:46 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQisxz01832
	for <mpls@UU.NET>; Sat, 10 Jun 2000 05:51:46 GMT
Received: from pluris.com (volsung.pluris.com [172.16.50.19])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id WAA22856;
	Fri, 9 Jun 2000 22:51:44 -0700 (PDT)
Message-ID: <3941D763.69C42D6A@pluris.com>
Date: Fri, 09 Jun 2000 22:51:31 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Li <tli@Procket.com>
CC: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <14657.53536.422247.469955@redd235.procket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tony

Thank you for the explanation. I have a few more questions.

1. Do the RSVP messages for the second (hierarchical) tunnel get forwarded via the
previously established LSP or go hop by hop?

2. What happens to the bandwidth reserved for the original tunnel when a
hierarchical tunnel rides over it?

3. In the following example:

A-->B               E-->F
          \              /
           C---->D

Let there be an initial tunnel established between B & E with the ILMs from B to E
as follows

B--C: 23
C--D: 34
D--E: 45

Let us also assume that we want to establish a second tunnel from A to F.

When a PATH message goes from A to F, how does B, C, D, E know that this is a
hierarchical tunnel vs a regular tunnel (related to question 1 above).

What exactly are the steps that are performed?

I am asking these questions to make sure that I have the right understanding of
this use of RSVP-TE, and I appreciate your answer.

Regards

Bora





Tony Li wrote:

>  | How does one establish hierarchical tunnels using RSVP-TE?
>  |
>  | I know that the label object can be deeper than one label, but you need more
>  | than this to establish hierarchical tunnels.
>
> A hierarchical tunnel requires the participation of at least two LSRs.  The
> operation of the LSR creating the innermost tunnel is straightforward and
> is unchanged from what has been endlessly discussed here.
>
> For an LSR to create an outer tunnel, it simply creates another tunnel and
> specifies MPLS as the L3PID.  It then forwards packets received on the
> inner tunnel by pushing a label for the outer tunnel.  The RSVP control
> traffic for the inner tunnel is also forwarded through the outer tunnel
> after first being encapsulated with a null IP label.
>
> Recurse, ad nauseum.
>
> Simple, really.  ;-)
>
> Tony




From owner-mpls@UU.NET  Sat Jun 10 02:40:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06706
	for <mpls-archive@lists.ietf.org>; Sat, 10 Jun 2000 02:40:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQisyc10892;
	Sat, 10 Jun 2000 06:40:35 GMT
Received: by mail-control.mail.uu.net 
	id QQisyc17244
	for mpls-outgoing; Sat, 10 Jun 2000 06:40:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQisyc17239
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 06:40:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisyc07231
	for <mpls@uu.net>; Sat, 10 Jun 2000 02:39:53 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQisyc09842
	for <mpls@uu.net>; Sat, 10 Jun 2000 06:39:51 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA27151
	for mpls@uu.net; Sat, 10 Jun 2000 02:39:51 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQisyc17222
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 06:39:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQisyc18309
	for <mpls@UU.NET>; Sat, 10 Jun 2000 02:39:00 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQisyc08555
	for <mpls@UU.NET>; Sat, 10 Jun 2000 06:38:58 GMT
Received: from cisco.com (rraszuk-dsl4.cisco.com [10.19.31.93])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA03197;
	Fri, 9 Jun 2000 23:37:56 -0700 (PDT)
Message-ID: <3941E00D.22820214@cisco.com>
Date: Fri, 09 Jun 2000 23:28:29 -0700
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bora Akyol <akyol@pluris.com>
CC: Tony Li <tli@Procket.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <14657.53536.422247.469955@redd235.procket.com> <3941D763.69C42D6A@pluris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bora,

Let me try to reply with what I think will happen .. I am sure Tony will
correct me if needed :).

> 1. Do the RSVP messages for the second (hierarchical) tunnel get forwarded via the
> previously established LSP or go hop by hop?

I think there are two cases: 

A. If in your diagram B-E is within one administrative domain you don't want
your customers to establish TE in your core (A-F) therefor the A-F RSVP Path
should travel inside the B-E tunnel.

B. If in your diagram all routers are inside the same administrative domain B
should process RSVP Path messages as usual and forward in further according to
ERO they carry.

So I think the answer is - it depends on implementation - but I think in
practice both options could be usefull.
 
> 2. What happens to the bandwidth reserved for the original tunnel when a
> hierarchical tunnel rides over it?

In short: The allocated bandwith for the outer tunnel is the one which is used.

Notice that a classical example of hierarchical tunnel is a simple fast reroute
feature. 1..N "inner" LSPs go via the backup tunnel by just adding one more
label on the top of the current stack. During the reroute procedure (under link
or node failure) the only bandwith used on the backup path is the one
allocated/reserved by the backup tunnel. The inner tunnel's reservation should
not matter.

> 3. In the following example:
> 
> A-->B               E-->F
>           \              /
>            C---->D
> 
> Let there be an initial tunnel established between B & E with the ILMs from B to E
> as follows
> 
> B--C: 23
> C--D: 34
> D--E: 45
> 
> Let us also assume that we want to establish a second tunnel from A to F.
> 
> When a PATH message goes from A to F, how does B, C, D, E know that this is a
> hierarchical tunnel vs a regular tunnel (related to question 1 above).
>
> What exactly are the steps that are performed?

See question (a).
 
R.

> Bora
> 
> Tony Li wrote:
> 
> >  | How does one establish hierarchical tunnels using RSVP-TE?
> >  |
> >  | I know that the label object can be deeper than one label, but you need more
> >  | than this to establish hierarchical tunnels.
> >
> > A hierarchical tunnel requires the participation of at least two LSRs.  The
> > operation of the LSR creating the innermost tunnel is straightforward and
> > is unchanged from what has been endlessly discussed here.
> >
> > For an LSR to create an outer tunnel, it simply creates another tunnel and
> > specifies MPLS as the L3PID.  It then forwards packets received on the
> > inner tunnel by pushing a label for the outer tunnel.  The RSVP control
> > traffic for the inner tunnel is also forwarded through the outer tunnel
> > after first being encapsulated with a null IP label.
> >
> > Recurse, ad nauseum.
> >
> > Simple, really.  ;-)
> >
> > Tony



From owner-mpls@UU.NET  Sat Jun 10 11:16:29 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09174
	for <mpls-archive@lists.ietf.org>; Sat, 10 Jun 2000 11:16:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiszl02663;
	Sat, 10 Jun 2000 15:16:31 GMT
Received: by mail-control.mail.uu.net 
	id QQiszl10646
	for mpls-outgoing; Sat, 10 Jun 2000 15:16:02 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiszl10615
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 15:15:55 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiszl11506
	for <mpls@UU.NET>; Sat, 10 Jun 2000 11:15:09 -0400 (EDT)
Received: from alpha.dtix.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.dtix.com [198.62.174.1])
	id QQiszl23856
	for <mpls@UU.NET>; Sat, 10 Jun 2000 15:15:08 GMT
Received: from madhukar (beta.dtix.com [198.62.174.3])
	by alpha.dtix.com (8.9.3/8.8.7) with SMTP id KAA22235;
	Sat, 10 Jun 2000 10:29:36 -0400
Message-ID: <001901bfd2ed$eb850a30$cfae3ec6@dtix.com>
From: "madhukar khare" <mkhare@dtix.com>
To: <raszuk@cisco.com>, "Bora Akyol" <akyol@pluris.com>
Cc: "Tony Li" <tli@Procket.com>, "'mpls@uu.net'" <mpls@UU.NET>
References: <14657.53536.422247.469955@redd235.procket.com> <3941D763.69C42D6A@pluris.com> <3941E00D.22820214@cisco.com>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Date: Sat, 10 Jun 2000 11:09:47 -0400
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 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

How does this relate to OSPF areas and BGP, how would the routing protocols
be deployed in such a case?
or is there no specific relationship?

-madhukar

------------------------------------

Madhukar Khare
Digital Technology
Bedford MA 01730

mkhare@dtix.com

----- Original Message -----
From: "Robert Raszuk" <raszuk@cisco.com>
To: "Bora Akyol" <akyol@pluris.com>
Cc: "Tony Li" <tli@Procket.com>; "'mpls@uu.net'" <mpls@UU.NET>
Sent: Saturday, June 10, 2000 2:28 AM
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE


> Bora,
>
> Let me try to reply with what I think will happen .. I am sure Tony will
> correct me if needed :).
>
> > 1. Do the RSVP messages for the second (hierarchical) tunnel get
forwarded via the
> > previously established LSP or go hop by hop?
>
> I think there are two cases:
>
> A. If in your diagram B-E is within one administrative domain you don't
want
> your customers to establish TE in your core (A-F) therefor the A-F RSVP
Path
> should travel inside the B-E tunnel.
>
> B. If in your diagram all routers are inside the same administrative
domain B
> should process RSVP Path messages as usual and forward in further
according to
> ERO they carry.
>
> So I think the answer is - it depends on implementation - but I think in
> practice both options could be usefull.
>
> > 2. What happens to the bandwidth reserved for the original tunnel when a
> > hierarchical tunnel rides over it?
>
> In short: The allocated bandwith for the outer tunnel is the one which is
used.
>
> Notice that a classical example of hierarchical tunnel is a simple fast
reroute
> feature. 1..N "inner" LSPs go via the backup tunnel by just adding one
more
> label on the top of the current stack. During the reroute procedure (under
link
> or node failure) the only bandwith used on the backup path is the one
> allocated/reserved by the backup tunnel. The inner tunnel's reservation
should
> not matter.
>
> > 3. In the following example:
> >
> > A-->B               E-->F
> >           \              /
> >            C---->D
> >
> > Let there be an initial tunnel established between B & E with the ILMs
from B to E
> > as follows
> >
> > B--C: 23
> > C--D: 34
> > D--E: 45
> >
> > Let us also assume that we want to establish a second tunnel from A to
F.
> >
> > When a PATH message goes from A to F, how does B, C, D, E know that this
is a
> > hierarchical tunnel vs a regular tunnel (related to question 1 above).
> >
> > What exactly are the steps that are performed?
>
> See question (a).
>
> R.
>
> > Bora
> >
> > Tony Li wrote:
> >
> > >  | How does one establish hierarchical tunnels using RSVP-TE?
> > >  |
> > >  | I know that the label object can be deeper than one label, but you
need more
> > >  | than this to establish hierarchical tunnels.
> > >
> > > A hierarchical tunnel requires the participation of at least two LSRs.
The
> > > operation of the LSR creating the innermost tunnel is straightforward
and
> > > is unchanged from what has been endlessly discussed here.
> > >
> > > For an LSR to create an outer tunnel, it simply creates another tunnel
and
> > > specifies MPLS as the L3PID.  It then forwards packets received on the
> > > inner tunnel by pushing a label for the outer tunnel.  The RSVP
control
> > > traffic for the inner tunnel is also forwarded through the outer
tunnel
> > > after first being encapsulated with a null IP label.
> > >
> > > Recurse, ad nauseum.
> > >
> > > Simple, really.  ;-)
> > >
> > > Tony



From owner-mpls@UU.NET  Sat Jun 10 11:41:07 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09362
	for <mpls-archive@lists.ietf.org>; Sat, 10 Jun 2000 11:41:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiszm16660;
	Sat, 10 Jun 2000 15:41:09 GMT
Received: by mail-control.mail.uu.net 
	id QQiszm11882
	for mpls-outgoing; Sat, 10 Jun 2000 15:40:42 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiszm11811
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 15:40:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiszm00679
	for <mpls@uu.net>; Sat, 10 Jun 2000 11:40:15 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiszm16049
	for <mpls@uu.net>; Sat, 10 Jun 2000 15:40:14 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA13317
	for mpls@uu.net; Sat, 10 Jun 2000 11:40:14 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiszm11788
	for <mpls@mail-control.mail.uu.net>; Sat, 10 Jun 2000 15:39:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiszm13701
	for <mpls@UU.NET>; Sat, 10 Jun 2000 11:39:28 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQiszm12340
	for <mpls@UU.NET>; Sat, 10 Jun 2000 15:39:27 GMT
Received: from cisco.com (rraszuk-dsl4.cisco.com [10.19.31.93])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA21925;
	Sat, 10 Jun 2000 08:37:48 -0700 (PDT)
Message-ID: <39425E96.3E3122F9@cisco.com>
Date: Sat, 10 Jun 2000 08:28:22 -0700
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: madhukar khare <mkhare@dtix.com>
CC: Bora Akyol <akyol@pluris.com>, Tony Li <tli@Procket.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <14657.53536.422247.469955@redd235.procket.com> <3941D763.69C42D6A@pluris.com> <3941E00D.22820214@cisco.com> <001901bfd2ed$eb850a30$cfae3ec6@dtix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Madhukar,

It doesn't relate to BGP at all (at least I don't know of any implementation
using BGP for TE - I think I saw one draft on it somewhere).

Multiarea LSPs is an interested topic on it's own and really should be
discussed separately. Although somehow related to this thread could be using
outer LSP in the core for interarea LSPs. In that case there could be two
scenarios:

1. We are not avertising the outer LSP tunnel as link:

All issues reg multi-area LSP need to be considered. Depending on the selected
scheme this may or may not require changes/extensions to the IGPs. 

It is up to the ABR's implementation to handle the incoming RSVP Path from one
area/level. 

A. It could forward it inside the preestablished core LSP,
B. It could run spf and build the ERO for it's own core,
C. It could glue the LSPs using a LDP label,
D. It could even drop the RSVP Path :) if non of the above is implemented.

2. We have implemented LSP advertisemnt as a link
(draft-kompella-mpls-optical-00.txt):

That obviously requires extensions to IGPs. At least I think of a few scenarios
where the idea presented in this draft could be used for regular TE (nothing to
do with 
optical networks). I think presenting them here is bit too early.

R.


> madhukar khare wrote:
> 
> How does this relate to OSPF areas and BGP, how would the routing protocols
> be deployed in such a case?
> or is there no specific relationship?
> 
> -madhukar
> 
> ------------------------------------
> 
> Madhukar Khare
> Digital Technology
> Bedford MA 01730
> 
> mkhare@dtix.com
> 
> ----- Original Message -----
> From: "Robert Raszuk" <raszuk@cisco.com>
> To: "Bora Akyol" <akyol@pluris.com>
> Cc: "Tony Li" <tli@Procket.com>; "'mpls@uu.net'" <mpls@UU.NET>
> Sent: Saturday, June 10, 2000 2:28 AM
> Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
> 
> > Bora,
> >
> > Let me try to reply with what I think will happen .. I am sure Tony will
> > correct me if needed :).
> >
> > > 1. Do the RSVP messages for the second (hierarchical) tunnel get
> forwarded via the
> > > previously established LSP or go hop by hop?
> >
> > I think there are two cases:
> >
> > A. If in your diagram B-E is within one administrative domain you don't
> want
> > your customers to establish TE in your core (A-F) therefor the A-F RSVP
> Path
> > should travel inside the B-E tunnel.
> >
> > B. If in your diagram all routers are inside the same administrative
> domain B
> > should process RSVP Path messages as usual and forward in further
> according to
> > ERO they carry.
> >
> > So I think the answer is - it depends on implementation - but I think in
> > practice both options could be usefull.
> >
> > > 2. What happens to the bandwidth reserved for the original tunnel when a
> > > hierarchical tunnel rides over it?
> >
> > In short: The allocated bandwith for the outer tunnel is the one which is
> used.
> >
> > Notice that a classical example of hierarchical tunnel is a simple fast
> reroute
> > feature. 1..N "inner" LSPs go via the backup tunnel by just adding one
> more
> > label on the top of the current stack. During the reroute procedure (under
> link
> > or node failure) the only bandwith used on the backup path is the one
> > allocated/reserved by the backup tunnel. The inner tunnel's reservation
> should
> > not matter.
> >
> > > 3. In the following example:
> > >
> > > A-->B               E-->F
> > >           \              /
> > >            C---->D
> > >
> > > Let there be an initial tunnel established between B & E with the ILMs
> from B to E
> > > as follows
> > >
> > > B--C: 23
> > > C--D: 34
> > > D--E: 45
> > >
> > > Let us also assume that we want to establish a second tunnel from A to
> F.
> > >
> > > When a PATH message goes from A to F, how does B, C, D, E know that this
> is a
> > > hierarchical tunnel vs a regular tunnel (related to question 1 above).
> > >
> > > What exactly are the steps that are performed?
> >
> > See question (a).
> >
> > R.
> >
> > > Bora
> > >
> > > Tony Li wrote:
> > >
> > > >  | How does one establish hierarchical tunnels using RSVP-TE?
> > > >  |
> > > >  | I know that the label object can be deeper than one label, but you
> need more
> > > >  | than this to establish hierarchical tunnels.
> > > >
> > > > A hierarchical tunnel requires the participation of at least two LSRs.
> The
> > > > operation of the LSR creating the innermost tunnel is straightforward
> and
> > > > is unchanged from what has been endlessly discussed here.
> > > >
> > > > For an LSR to create an outer tunnel, it simply creates another tunnel
> and
> > > > specifies MPLS as the L3PID.  It then forwards packets received on the
> > > > inner tunnel by pushing a label for the outer tunnel.  The RSVP
> control
> > > > traffic for the inner tunnel is also forwarded through the outer
> tunnel
> > > > after first being encapsulated with a null IP label.
> > > >
> > > > Recurse, ad nauseum.
> > > >
> > > > Simple, really.  ;-)
> > > >
> > > > Tony



From owner-mpls@UU.NET  Sun Jun 11 00:44:13 2000
Received: from wodc7-1.corprelay.mail.uu.net ([192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14795
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 00:44:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitbm14212;
	Sun, 11 Jun 2000 04:44:12 GMT
Received: by mail-control.mail.uu.net 
	id QQitbm22123
	for mpls-outgoing; Sun, 11 Jun 2000 04:43:56 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitbm22118
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 04:43:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitbm14101
	for <mpls@uu.net>; Sun, 11 Jun 2000 00:43:24 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitbm00338
	for <mpls@uu.net>; Sun, 11 Jun 2000 04:43:22 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA08516
	for mpls@uu.net; Sun, 11 Jun 2000 00:43:21 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitbm22097
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 04:42:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitbm14063
	for <mpls@UU.NET>; Sun, 11 Jun 2000 00:42:35 -0400 (EDT)
Received: from postal.redback.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postal.redback.com [155.53.12.9])
	id QQitbm29945
	for <mpls@UU.NET>; Sun, 11 Jun 2000 04:42:34 GMT
Received: from malt.redback.com (malt.redback.com [155.53.12.41])
	by postal.redback.com (Postfix) with ESMTP
	id 345152AA03; Sat, 10 Jun 2000 21:42:34 -0700 (PDT)
Received: (from rahul@localhost)
	by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id VAA08852;
	Sat, 10 Jun 2000 21:41:48 -0700 (PDT)
Date: Sat, 10 Jun 2000 21:41:48 -0700
From: Rahul Aggarwal <rahul@redback.com>
To: Bora Akyol <akyol@pluris.com>
Cc: Tony Li <tli@Procket.com>, "'mpls@uu.net'" <mpls@UU.NET>,
        kireeti@juniper.net
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Message-ID: <20000610214148.A8446@malt.redback.com>
References: <14657.53536.422247.469955@redd235.procket.com> <3941D763.69C42D6A@pluris.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <3941D763.69C42D6A@pluris.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
This pertains to the current thread as well as to: 
draft-kompella-mpls-optical.txt

A forwarding adjacency LSP (FA-LSP) is advertised into the
IGP. However from what I have seen 
there is no way to include a FA-LSP in an ERO.
Thus in the case being discussed if the LSP fron B to E 
is advertised as FA-LSP1 the ERO for the LSP
from A to F (LSP2) could include FA-LSP1. So the ERO could look
like: A->B->FA-LSP1->F. 

I guess it is possible to achieve the above by including
the path learned from the path sub-tlv for FA-LSP1 in 
the ERO for LSP2. Its also possible to specify a loose route
from B to E. However it seems like adding a ERO sub-object
to RSVP for including a FA-LSP may be more efficient
in some cases. 

Will appreciate any comments on this.

thanks,
rahul


 
On Fri, Jun 09, 2000 at 10:51:31PM -0700, Bora Akyol wrote:
> Tony
> 
> Thank you for the explanation. I have a few more questions.
> 
> 1. Do the RSVP messages for the second (hierarchical) tunnel get forwarded via the
> previously established LSP or go hop by hop?
> 
> 2. What happens to the bandwidth reserved for the original tunnel when a
> hierarchical tunnel rides over it?
> 
> 3. In the following example:
> 
> A-->B               E-->F
>           \              /
>            C---->D
> 
> Let there be an initial tunnel established between B & E with the ILMs from B to E
> as follows
> 
> B--C: 23
> C--D: 34
> D--E: 45
> 
> Let us also assume that we want to establish a second tunnel from A to F.
> 
> When a PATH message goes from A to F, how does B, C, D, E know that this is a
> hierarchical tunnel vs a regular tunnel (related to question 1 above).
> 
> What exactly are the steps that are performed?
> 
> I am asking these questions to make sure that I have the right understanding of
> this use of RSVP-TE, and I appreciate your answer.
> 
> Regards
> 
> Bora
> 
> 
> 
> 
> 
> Tony Li wrote:
> 
> >  | How does one establish hierarchical tunnels using RSVP-TE?
> >  |
> >  | I know that the label object can be deeper than one label, but you need more
> >  | than this to establish hierarchical tunnels.
> >
> > A hierarchical tunnel requires the participation of at least two LSRs.  The
> > operation of the LSR creating the innermost tunnel is straightforward and
> > is unchanged from what has been endlessly discussed here.
> >
> > For an LSR to create an outer tunnel, it simply creates another tunnel and
> > specifies MPLS as the L3PID.  It then forwards packets received on the
> > inner tunnel by pushing a label for the outer tunnel.  The RSVP control
> > traffic for the inner tunnel is also forwarded through the outer tunnel
> > after first being encapsulated with a null IP label.
> >
> > Recurse, ad nauseum.
> >
> > Simple, really.  ;-)
> >
> > Tony
> 
> 



From owner-mpls@UU.NET  Sun Jun 11 01:42:46 2000
Received: from wodc7-1.corprelay.mail.uu.net ([192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20250
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 01:42:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitbq28752;
	Sun, 11 Jun 2000 05:42:45 GMT
Received: by mail-control.mail.uu.net 
	id QQitbq04464
	for mpls-outgoing; Sun, 11 Jun 2000 05:42:13 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitbq04404
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 05:42:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitbq06084
	for <mpls@UU.NET>; Sun, 11 Jun 2000 01:41:51 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQitbq01501
	for <mpls@UU.NET>; Sun, 11 Jun 2000 05:41:50 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id WAA25624;
	Sat, 10 Jun 2000 22:41:49 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id WAA15960; Sat, 10 Jun 2000 22:41:48 -0700 (PDT)
Date: Sat, 10 Jun 2000 22:41:48 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006110541.WAA15960@kummer.juniper.net>
To: akyol@pluris.com, rahul@redback.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Cc: kireeti@juniper.net, mpls@UU.NET, tli@Procket.com
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Rahul,

> A forwarding adjacency LSP (FA-LSP) is advertised into the
> IGP. However from what I have seen 
> there is no way to include a FA-LSP in an ERO.

When an LSP is advertised into the IGP, it is given IP addresses
for the head and tail ends (this defaults to the router ids).  So,
to include the LSP in an ERO, just use those addresses.

A-->B         E-->F
     \       /
      C---->D

> Thus in the case being discussed if the LSP fron B to E 
> is advertised as FA-LSP1 the ERO for the LSP
> from A to F (LSP2) could include FA-LSP1. So the ERO could look
> like: A->B->FA-LSP1->F. 

The ERO could be (for example) A, B, E (strict!), F.  B being wise
to FA-LSPs realises that E is the end point of an LSP, and send the
Path message to E (either through the LSP, or by unicasting it).

To go back to prior questions:

> 1. Do the RSVP messages for the second (hierarchical) tunnel get
>    forwarded via the previously established LSP or go hop by hop?

Signalling hop-by-hop seems to negate some of the benefits of
tunneling through the LSP.  The alternatives are: signalling through
the LSP, and unicasting (*without router alert*) from B to E.

> 2. What happens to the bandwidth reserved for the original tunnel when a
>    hierarchical tunnel rides over it?

That's a good question.  With FA-LSPs, we thought that the original
LSP should be provisioned for the tunneled LSPs, so its bandwidth
doesn't change.  What changes is the bandwidth announced in the IGP
for the FA-LSP, especially the 'unreserved bandwidth'.

> 3. In the following example:

> When a PATH message goes from A to F, how does B, C, D, E know that
> this is a hierarchical tunnel vs a regular tunnel (related to question
> 1 above).

B and E have to know.  If the signalling is not hop-by-hop, there
is no need for C and D to know.

> What exactly are the steps that are performed?

One answer is laid out in the draft Yakov and I wrote.

Kireeti.


From owner-mpls@UU.NET  Sun Jun 11 02:08:57 2000
Received: from wodc7-2.corprelay.mail.uu.net ([192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26913
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 02:08:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitbs16977;
	Sun, 11 Jun 2000 06:08:56 GMT
Received: by mail-control.mail.uu.net 
	id QQitbs15067
	for mpls-outgoing; Sun, 11 Jun 2000 06:08:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitbs15062
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 06:08:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitbs21756
	for <mpls@uu.net>; Sun, 11 Jun 2000 02:08:10 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitbs16420
	for <mpls@uu.net>; Sun, 11 Jun 2000 06:08:09 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA13267
	for mpls@uu.net; Sun, 11 Jun 2000 02:08:08 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitbs15038
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 06:07:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitbs08736
	for <mpls@UU.NET>; Sun, 11 Jun 2000 02:07:14 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQitbs18302
	for <mpls@UU.NET>; Sun, 11 Jun 2000 06:07:14 GMT
Received: from cisco.com (rraszuk-dsl4.cisco.com [10.19.31.93])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA19847;
	Sat, 10 Jun 2000 23:06:39 -0700 (PDT)
Message-ID: <39432897.A4EA90D@cisco.com>
Date: Sat, 10 Jun 2000 22:50:15 -0700
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: akyol@pluris.com, rahul@redback.com, mpls@UU.NET, tli@Procket.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <200006110541.WAA15960@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Kireeti,

If you only can specify router_ids from FA-LSP in the ERO from A to F in the
case where there is more then one B-E LSP advertised as a link you don't have
too much of control which one to pick.

Therefor I would be in favour of defining new ERO sub-object to allow addition
of the FA-LSP id for the more granular path selection control from A point of
view.

R.

> Kireeti Kompella wrote:
> 
> Hi Rahul,
> 
> > A forwarding adjacency LSP (FA-LSP) is advertised into the
> > IGP. However from what I have seen
> > there is no way to include a FA-LSP in an ERO.
> 
> When an LSP is advertised into the IGP, it is given IP addresses
> for the head and tail ends (this defaults to the router ids).  So,
> to include the LSP in an ERO, just use those addresses.
> 
> A-->B         E-->F
>      \       /
>       C---->D
> 
> > Thus in the case being discussed if the LSP fron B to E
> > is advertised as FA-LSP1 the ERO for the LSP
> > from A to F (LSP2) could include FA-LSP1. So the ERO could look
> > like: A->B->FA-LSP1->F.
> 
> The ERO could be (for example) A, B, E (strict!), F.  B being wise
> to FA-LSPs realises that E is the end point of an LSP, and send the
> Path message to E (either through the LSP, or by unicasting it).
> 
> To go back to prior questions:
> 
> > 1. Do the RSVP messages for the second (hierarchical) tunnel get
> >    forwarded via the previously established LSP or go hop by hop?
> 
> Signalling hop-by-hop seems to negate some of the benefits of
> tunneling through the LSP.  The alternatives are: signalling through
> the LSP, and unicasting (*without router alert*) from B to E.
> 
> > 2. What happens to the bandwidth reserved for the original tunnel when a
> >    hierarchical tunnel rides over it?
> 
> That's a good question.  With FA-LSPs, we thought that the original
> LSP should be provisioned for the tunneled LSPs, so its bandwidth
> doesn't change.  What changes is the bandwidth announced in the IGP
> for the FA-LSP, especially the 'unreserved bandwidth'.
> 
> > 3. In the following example:
> 
> > When a PATH message goes from A to F, how does B, C, D, E know that
> > this is a hierarchical tunnel vs a regular tunnel (related to question
> > 1 above).
> 
> B and E have to know.  If the signalling is not hop-by-hop, there
> is no need for C and D to know.
> 
> > What exactly are the steps that are performed?
> 
> One answer is laid out in the draft Yakov and I wrote.
> 
> Kireeti.



From owner-mpls@UU.NET  Sun Jun 11 02:29:25 2000
Received: from wodc7-1.corprelay.mail.uu.net ([192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26990
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 02:29:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitbt04775;
	Sun, 11 Jun 2000 06:29:24 GMT
Received: by mail-control.mail.uu.net 
	id QQitbt16321
	for mpls-outgoing; Sun, 11 Jun 2000 06:28:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitbt16316
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 06:28:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitbt10668
	for <mpls@uu.net>; Sun, 11 Jun 2000 02:28:25 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitbt03976
	for <mpls@uu.net>; Sun, 11 Jun 2000 06:28:24 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA14194
	for mpls@uu.net; Sun, 11 Jun 2000 02:28:23 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitbt16299
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 06:27:56 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitbt10590
	for <mpls@UU.NET>; Sun, 11 Jun 2000 02:27:44 -0400 (EDT)
Received: from postal.redback.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postal.redback.com [155.53.12.9])
	id QQitbt03624
	for <mpls@UU.NET>; Sun, 11 Jun 2000 06:27:44 GMT
Received: from malt.redback.com (malt.redback.com [155.53.12.41])
	by postal.redback.com (Postfix) with ESMTP
	id 120182AA06; Sat, 10 Jun 2000 23:27:44 -0700 (PDT)
Received: (from rahul@localhost)
	by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id XAA09815;
	Sat, 10 Jun 2000 23:26:58 -0700 (PDT)
Date: Sat, 10 Jun 2000 23:26:58 -0700
From: Rahul Aggarwal <rahul@redback.com>
To: Kireeti Kompella <kireeti@juniper.net>
Cc: akyol@pluris.com, rahul@redback.com, mpls@UU.NET, tli@Procket.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Message-ID: <20000610232658.H9235@malt.redback.com>
References: <200006110541.WAA15960@kummer.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <200006110541.WAA15960@kummer.juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Kireeti,
Thanks for the response. I have a comment inline.

On Sat, Jun 10, 2000 at 10:41:48PM -0700, Kireeti Kompella wrote:
> Hi Rahul,
> 
> > A forwarding adjacency LSP (FA-LSP) is advertised into the
> > IGP. However from what I have seen 
> > there is no way to include a FA-LSP in an ERO.
> 
> When an LSP is advertised into the IGP, it is given IP addresses
> for the head and tail ends (this defaults to the router ids).  So,
> to include the LSP in an ERO, just use those addresses.
> 
> A-->B         E-->F
>      \       /
>       C---->D
> 
> > Thus in the case being discussed if the LSP fron B to E 
> > is advertised as FA-LSP1 the ERO for the LSP
> > from A to F (LSP2) could include FA-LSP1. So the ERO could look
> > like: A->B->FA-LSP1->F. 
> 
> The ERO could be (for example) A, B, E (strict!), F.  B being wise
> to FA-LSPs realises that E is the end point of an LSP, and send the
> Path message to E (either through the LSP, or by unicasting it).
> 

There are two cases:
1. B happens to be the edge of a domain (with the domain definition taken
from draft-kompella-mpls-optical-00.txt). In this case B knows that it has
to use a FA-LSP for this LSP request and it can look up the FA-LSP to use
or create one if it doesn't exist. Hence there is no value to explicitly
specifying a FA-LSP in the ERO.

2. All the links are in the same domain. In this case if B receives an 
ERO A, B, E (strict), F do we say that since E is a strict next hop and
is not adjacent to B, a LSP should be used to send it E ? Apparently there
is no other way to interpret this case other than sending an error back!
Furthermore if E is a loose next hop, should B use a LSP to send it to E
or should it just compute a route and add it to the ERO? It might be 
nice to have the flexibility to specify the usage of a FA-LSP explicitly
in such a case. 

Ofcourse as you described the desired behavior can be achieved
by having certain implicit processing rules (at A, the originator and B), 


thanks,
rahul



From owner-mpls@UU.NET  Sun Jun 11 02:33:36 2000
Received: from wodc7-2.corprelay.mail.uu.net ([192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27086
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 02:33:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitbu01882;
	Sun, 11 Jun 2000 06:33:35 GMT
Received: by mail-control.mail.uu.net 
	id QQitbu16558
	for mpls-outgoing; Sun, 11 Jun 2000 06:33:16 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitbu16553
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 06:33:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitbu11428
	for <mpls@uu.net>; Sun, 11 Jun 2000 02:33:04 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQitbu01391
	for <mpls@uu.net>; Sun, 11 Jun 2000 06:33:04 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id XAA27302;
	Sat, 10 Jun 2000 23:33:02 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id XAA16072; Sat, 10 Jun 2000 23:33:02 -0700 (PDT)
Date: Sat, 10 Jun 2000 23:33:02 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006110633.XAA16072@kummer.juniper.net>
To: raszuk@cisco.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Robert,

> If you only can specify router_ids from FA-LSP in the ERO from A to F in the
> case where there is more then one B-E LSP advertised as a link you don't have
> too much of control which one to pick.

Actually, the router ids are just the default.  You can IP-number each
B-E LSP differently, and thus have full control (at the cost of a few
IP addresses).

> Therefor I would be in favour of defining new ERO sub-object to allow
> additionof the FA-LSP id for the more granular path selection control
> from A point of view.

You would also have to advertise the FA-LSP ids into the IGP so that
A can use that when signalling.

Kireeti.


From owner-mpls@UU.NET  Sun Jun 11 04:13:19 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06096
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 04:13:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitbv16164;
	Sun, 11 Jun 2000 06:50:26 GMT
Received: by mail-control.mail.uu.net 
	id QQitbv17329
	for mpls-outgoing; Sun, 11 Jun 2000 06:49:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitbv17324
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 06:49:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitbv12942
	for <mpls@uu.net>; Sun, 11 Jun 2000 02:49:27 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitbv14304
	for <mpls@uu.net>; Sun, 11 Jun 2000 06:49:26 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA15596
	for mpls@uu.net; Sun, 11 Jun 2000 02:49:25 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitbv17307
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 06:48:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitbv12782
	for <mpls@uu.net>; Sun, 11 Jun 2000 02:48:25 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQitbv14755
	for <mpls@uu.net>; Sun, 11 Jun 2000 06:48:24 GMT
Received: from cisco.com (rraszuk-dsl1.cisco.com [10.19.31.90])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA21336;
	Sat, 10 Jun 2000 23:48:21 -0700 (PDT)
Message-ID: <3943365A.DAD44970@cisco.com>
Date: Sat, 10 Jun 2000 23:48:58 -0700
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <200006110633.XAA16072@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi Kireeti,

> Actually, the router ids are just the default.  You can IP-number each
> B-E LSP differently, and thus have full control (at the cost of a few
> IP addresses).

I knew you were going to propose this :) just after hitting send button. And I
think that this is a valid option. Maybe just not very elegant one from IP
address usage and configuration overhead point of view.

> You would also have to advertise the FA-LSP ids into the IGP so that
> A can use that when signalling.

Yes that's the price you would need to pay for the mentioned above elegancy.

It would be interesting to hear what would be user's opinion on this.

R.


> Kireeti Kompella wrote:
> 
> Hi Robert,
> 
> > If you only can specify router_ids from FA-LSP in the ERO from A to F in the
> > case where there is more then one B-E LSP advertised as a link you don't have
> > too much of control which one to pick.
> 
> Actually, the router ids are just the default.  You can IP-number each
> B-E LSP differently, and thus have full control (at the cost of a few
> IP addresses).
> 
> > Therefor I would be in favour of defining new ERO sub-object to allow
> > additionof the FA-LSP id for the more granular path selection control
> > from A point of view.
> 
> You would also have to advertise the FA-LSP ids into the IGP so that
> A can use that when signalling.
> 
> Kireeti.



From owner-mpls@UU.NET  Sun Jun 11 04:16:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06107
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 04:16:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitcb08026;
	Sun, 11 Jun 2000 08:16:33 GMT
Received: by mail-control.mail.uu.net 
	id QQitcb10818
	for mpls-outgoing; Sun, 11 Jun 2000 08:16:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitcb10762
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 08:16:06 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitcb05667
	for <mpls@UU.NET>; Sun, 11 Jun 2000 04:15:45 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQitcb07246
	for <mpls@UU.NET>; Sun, 11 Jun 2000 08:15:44 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id BAA00620;
	Sun, 11 Jun 2000 01:15:43 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id BAA16216; Sun, 11 Jun 2000 01:15:43 -0700 (PDT)
Date: Sun, 11 Jun 2000 01:15:43 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006110815.BAA16216@kummer.juniper.net>
To: kireeti@juniper.net, rahul@redback.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Cc: akyol@pluris.com, mpls@UU.NET, tli@Procket.com
Sender: owner-mpls@UU.NET
Precedence: bulk

> There are two cases:
> 1. B happens to be the edge of a domain (with the domain definition taken
> from draft-kompella-mpls-optical-00.txt). In this case B knows that it has
> to use a FA-LSP for this LSP request and it can look up the FA-LSP to use
> or create one if it doesn't exist. Hence there is no value to explicitly
> specifying a FA-LSP in the ERO.

That's the plan.

> 2. All the links are in the same domain. In this case if B receives an 
> ERO A, B, E (strict), F do we say that since E is a strict next hop and
> is not adjacent to B, a LSP should be used to send it E ? Apparently there
> is no other way to interpret this case other than sending an error back!
> Furthermore if E is a loose next hop, should B use a LSP to send it to E
> or should it just compute a route and add it to the ERO? It might be 
> nice to have the flexibility to specify the usage of a FA-LSP explicitly
> in such a case. 

Still works.  Domains simplify automatic creation of FA-LSPs; if
the FA-LSP already exists, you can use it by specifying its IP
address.

Kireeti.


From owner-mpls@UU.NET  Sun Jun 11 09:12:40 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07128
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 09:12:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitcu16829;
	Sun, 11 Jun 2000 13:12:42 GMT
Received: by mail-control.mail.uu.net 
	id QQitcu13193
	for mpls-outgoing; Sun, 11 Jun 2000 13:12:18 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitcu13188
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 13:12:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitcu21206
	for <mpls@UU.NET>; Sun, 11 Jun 2000 09:11:58 -0400 (EDT)
Received: from alemail1.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alemail1.lucent.com [192.11.221.161])
	id QQitcu28083
	for <mpls@UU.NET>; Sun, 11 Jun 2000 13:11:58 GMT
Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA09931
	for <mpls@UU.NET>; Sun, 11 Jun 2000 09:11:58 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA09927;
	Sun, 11 Jun 2000 09:11:56 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id JAA19670; Sun, 11 Jun 2000 09:11:54 -0400 (EDT)
Message-ID: <39439018.4561FC0@lucent.com>
Date: Sun, 11 Jun 2000 09:11:52 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: curtis@avici.com
CC: danny@tcb.net, mpls@UU.NET
Subject: Re: MPLS and fast reroute.
References: <200006100230.WAA19843@curtis-lt.avici.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


First, we don't do double protection, which means we'd better use only one
protection mechanism closed to SLA.

Second, as SONET APS and MPLS local-protect each has its own strongness and
weakness, the router/switch should be the decision maker as to which protection
mechanism to use. Extra intelligence should be added to router/switch to
aggregate traffic and choose the best way. This may require router/switch to
control the SONET/DWDM, which shouldn't be a problem in integrated
IP/ATM/SONET/DWDM products.

Third, SONET APS can go all the way down to VT1.5 level. 

Yangguang
> 
> Except for the fact that that would be grossly inefficient from a
> traffic engineering standpoint, this is a fine idea.
> 
> For example, if 10% of your traffic required the type of restoration
> offerred by APS or MPLS local-protect, then you'd spend a lot less
> accommodating your backup need with MPLS local-protect on the 10% of
> the LSPs than carving out separate lambdas for those SONET paths that
> were carrying traffic needing protection.
> 
> Curtis


From owner-mpls@UU.NET  Sun Jun 11 15:28:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09042
	for <mpls-archive@lists.ietf.org>; Sun, 11 Jun 2000 15:28:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitdt16911;
	Sun, 11 Jun 2000 19:28:34 GMT
Received: by mail-control.mail.uu.net 
	id QQitdt28204
	for mpls-outgoing; Sun, 11 Jun 2000 19:28:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitdt28199
	for <mpls@mail-control.mail.uu.net>; Sun, 11 Jun 2000 19:28:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitdt26795
	for <mpls@UU.NET>; Sun, 11 Jun 2000 15:27:55 -0400 (EDT)
Received: from mail-green.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103])
	id QQitdt16396
	for <mpls@UU.NET>; Sun, 11 Jun 2000 19:27:55 GMT
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 6A1BA1E007; Sun, 11 Jun 2000 15:27:55 -0400 (EDT)
Received: from research.att.com (fp-dialup31.research.att.com [135.207.32.222])
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id PAA06151;
	Sun, 11 Jun 2000 15:27:52 -0400 (EDT)
Message-ID: <3943E6F7.7DEF380E@research.att.com>
Date: Sun, 11 Jun 2000 15:22:31 -0400
From: Jennifer Yates <jyates@research.att.com>
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
Cc: curtis@avici.com, danny@tcb.net, mpls@UU.NET,
        Albert Greenberg <albert@research.att.com>, jyates@research.att.com
Subject: Re: MPLS and fast reroute.
References: <200006100230.WAA19843@curtis-lt.avici.com> <39439018.4561FC0@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

A description of an integrated IP/WDM architecture that incorporates all network
intelligence in a single layer (i.e. the IP layer) can be found at
http://www.research.att.com/~jyates/srso.html.  This architecture is similar to
that described here, in that all restoration decisions will be made at a single
layer, with lower layer failure indications being passed up to the higher decision
making layer.

An OFC publication titled "Smart Routers - Simple Optics: A Network Architecture
for IP over WDM" further describes this architecture, and can be found on the above
web site.

Jennnifer

Yangguang Xu wrote:

> First, we don't do double protection, which means we'd better use only one
> protection mechanism closed to SLA.
>
> Second, as SONET APS and MPLS local-protect each has its own strongness and
> weakness, the router/switch should be the decision maker as to which protection
> mechanism to use. Extra intelligence should be added to router/switch to
> aggregate traffic and choose the best way. This may require router/switch to
> control the SONET/DWDM, which shouldn't be a problem in integrated
> IP/ATM/SONET/DWDM products.
>
> Third, SONET APS can go all the way down to VT1.5 level.
>
> Yangguang
> >
> > Except for the fact that that would be grossly inefficient from a
> > traffic engineering standpoint, this is a fine idea.
> >
> > For example, if 10% of your traffic required the type of restoration
> > offerred by APS or MPLS local-protect, then you'd spend a lot less
> > accommodating your backup need with MPLS local-protect on the 10% of
> > the LSPs than carving out separate lambdas for those SONET paths that
> > were carrying traffic needing protection.
> >
> > Curtis



From owner-mpls@UU.NET  Mon Jun 12 06:45:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27824
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 06:45:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitgd06061;
	Mon, 12 Jun 2000 10:45:04 GMT
Received: by mail-control.mail.uu.net 
	id QQitgc05107
	for mpls-outgoing; Mon, 12 Jun 2000 10:44:35 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitgc05102
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 10:44:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitgc25972
	for <mpls@uu.net>; Mon, 12 Jun 2000 06:44:24 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitgc15294
	for <mpls@uu.net>; Mon, 12 Jun 2000 10:44:23 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA10156
	for mpls@uu.net; Mon, 12 Jun 2000 06:44:19 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitgc05083
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 10:44:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitgc29378
	for <mpls@uu.net>; Mon, 12 Jun 2000 06:43:40 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQitgc14927
	for <mpls@uu.net>; Mon, 12 Jun 2000 10:43:39 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27791;
	Mon, 12 Jun 2000 06:43:39 -0400 (EDT)
Message-Id: <200006121043.GAA27791@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-diff-ext-05.txt
Date: Mon, 12 Jun 2000 06:43:39 -0400
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		: MPLS Support of Differentiated Services
	Author(s)	: F. Le Faucheur,  L. Wu,  B. Davie,  S. Davari, 
                          P. Vaananen, R. Krishnan, P. Cheval,	J. Heinanen 
        Filename	: draft-ietf-mpls-diff-ext-05.txt
	Pages		: 58
	Date		: 09-Jun-00
	
This document defines a flexible solution for support of
Differentiated Services (Diff-Serv) over Multi-Protocol Label
Switching (MPLS) networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-05.txt

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-diff-ext-05.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-diff-ext-05.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:	<20000609131438.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-diff-ext-05.txt

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

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

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Mon Jun 12 06:45:48 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27836
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 06:45:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitgd16133;
	Mon, 12 Jun 2000 10:45:46 GMT
Received: by mail-control.mail.uu.net 
	id QQitgd05313
	for mpls-outgoing; Mon, 12 Jun 2000 10:45:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitgd05300
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 10:45:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitgc29430
	for <mpls@uu.net>; Mon, 12 Jun 2000 06:44:21 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitgc05578
	for <mpls@uu.net>; Mon, 12 Jun 2000 10:44:20 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA10157
	for mpls@uu.net; Mon, 12 Jun 2000 06:44:19 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitgc05084
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 10:44:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitgc29358
	for <mpls@uu.net>; Mon, 12 Jun 2000 06:43:24 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQitgc14807
	for <mpls@uu.net>; Mon, 12 Jun 2000 10:43:24 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27734;
	Mon, 12 Jun 2000 06:43:24 -0400 (EDT)
Message-Id: <200006121043.GAA27734@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: mpls@UU.NET, rem-conf@es.net
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-theimer-tcrtp-mpls-00.txt
Date: Mon, 12 Jun 2000 06:43:23 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Tunneling Multiplexed Compressed RTP in MPLS
	Author(s)	: T. Theimer
	Filename	: draft-theimer-tcrtp-mpls-00.txt
	Pages		: 10
	Date		: 09-Jun-00
	
This document describes a method to improve the bandwidth efficiency
of voice transmission over an IP/MPLS network by combining RTP
compression, PPP multiplexing and MPLS tunneling. This proposal does
not require any additions or modifications to existing protocols, and
therefore should be fully interoperable with existing implementations
of RTP compression and PPP multiplexing. It only requires specific
use of some attributes of MPLS signalling protocols to setup a pair
of unidirectional MPLS tunnels providing a bidirectional link for
compressed RTP over PPP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-theimer-tcrtp-mpls-00.txt

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-theimer-tcrtp-mpls-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-theimer-tcrtp-mpls-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.

--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:	<20000609131405.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-theimer-tcrtp-mpls-00.txt

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

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

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Mon Jun 12 10:36:59 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02862
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 10:36:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitgs18100;
	Mon, 12 Jun 2000 14:36:57 GMT
Received: by mail-control.mail.uu.net 
	id QQitgs27424
	for mpls-outgoing; Mon, 12 Jun 2000 14:36:09 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitgs27363
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 14:35:58 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitgs29573
	for <mpls@UU.NET>; Mon, 12 Jun 2000 10:35:23 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitgs16262
	for <mpls@UU.NET>; Mon, 12 Jun 2000 14:35:22 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id KAA13971; Mon, 12 Jun 2000 10:35:03 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA20277;
	Mon, 12 Jun 2000 10:35:02 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006121435.KAA20277@curtis-lt.avici.com>
To: Yangguang Xu <xuyg@lucent.com>
cc: curtis@avici.com, danny@tcb.net, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: MPLS and fast reroute. 
In-reply-to: Your message of "Sun, 11 Jun 2000 09:11:52 EDT."
             <39439018.4561FC0@lucent.com> 
Date: Mon, 12 Jun 2000 10:35:02 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <39439018.4561FC0@lucent.com>, Yangguang Xu writes:
> 
> Third, SONET APS can go all the way down to VT1.5 level. 

In order to make use of that capability the OC48c and OC192c router
interfaces that currently use SONET only as an encapsulation and feed
directly into the DWDM would have to be channelized and feed into an
ADM and break out the LSP (or set of LSP) that needed protection into
separate SONET channels.  It is worth noting that this prevents
sharing of bandwidth such that one class of service can use more than
its allocation if the other is underutilizing its allocation which is
one of the main reasons SONET is losing favor to IP.

I don't know anyone that is doing or planning to do this on the
backbone side.  I'm quite sure this is done on the access side (and is
one motivation for administrative colors in MPLS).  So perhaps we are
both right but I am concentrating on the backbone and you are
concentrationg on the access side.

Curtis


From owner-mpls@UU.NET  Mon Jun 12 10:59:32 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03367
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 10:59:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitgt09922;
	Mon, 12 Jun 2000 14:59:30 GMT
Received: by mail-control.mail.uu.net 
	id QQitgt28573
	for mpls-outgoing; Mon, 12 Jun 2000 14:59:09 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitgt28565
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 14:59:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitgt05430
	for <mpls@UU.NET>; Mon, 12 Jun 2000 10:56:55 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitgt07322
	for <mpls@UU.NET>; Mon, 12 Jun 2000 14:56:54 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id KAA15848; Mon, 12 Jun 2000 10:56:52 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA20329;
	Mon, 12 Jun 2000 10:57:15 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006121457.KAA20329@curtis-lt.avici.com>
To: Tony Li <tli@Procket.com>
cc: Bora Akyol <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Fri, 09 Jun 2000 22:24:48 PDT."
             <14657.53536.422247.469955@redd235.procket.com> 
Date: Mon, 12 Jun 2000 10:57:15 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <14657.53536.422247.469955@redd235.procket.com>, Tony Li writes:
> 
> 
>  | How does one establish hierarchical tunnels using RSVP-TE?
>  |  
>  | I know that the label object can be deeper than one label, but you need mo
> re
>  | than this to establish hierarchical tunnels.
> 
> 
> A hierarchical tunnel requires the participation of at least two LSRs.  The
> operation of the LSR creating the innermost tunnel is straightforward and
> is unchanged from what has been endlessly discussed here.
> 
> For an LSR to create an outer tunnel, it simply creates another tunnel and
> specifies MPLS as the L3PID.  It then forwards packets received on the
> inner tunnel by pushing a label for the outer tunnel.  The RSVP control
> traffic for the inner tunnel is also forwarded through the outer tunnel
> after first being encapsulated with a null IP label.
> 
> Recurse, ad nauseum.
> 
> Simple, really.  ;-)
> 
> Tony


Tony,

Two minor points.  

If the outer tunnel is constrained (by configuration) to accept only
inner tunnels with one L3PID, then that L3PID can be placed on the
outer tunnel.  If there are optimization possible for a particular
L3PID (IP src/dst hash to split loading along the way comes to mind
for IPv4) then putting the inner L3PID on the outer tunnel has
advantages.

No where have I seen a requirement to put a null label on traffic
destined to the egress LSR.  I had been assuming that if the IP packet
under the top label has the address of the router ID of the egress
under the outer label, then the packet would be delivered to the
egress.  If the egress required PHP, then the penultimate LSR would
put a null label on the control traffic for the the inner label and
the egress would POP the null label and see its own IP address.
Otherwise, the egress would see two null labels.

If I'm missing something and/or there will be any interoperability
problem with the way I intended to encapsulate control traffic inside
the outer label, please tell us about it.

Curtis


From owner-mpls@UU.NET  Mon Jun 12 11:24:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04124
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 11:24:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitgv13494;
	Mon, 12 Jun 2000 15:24:29 GMT
Received: by mail-control.mail.uu.net 
	id QQitgv09397
	for mpls-outgoing; Mon, 12 Jun 2000 15:24:09 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitgv09392
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 15:24:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitgv09506
	for <mpls@uu.net>; Mon, 12 Jun 2000 11:17:13 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitgv26992
	for <mpls@uu.net>; Mon, 12 Jun 2000 15:17:13 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA08012
	for mpls@uu.net; Mon, 12 Jun 2000 11:17:11 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitgv09025
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 15:16:42 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitgu08181
	for <mpls@UU.NET>; Mon, 12 Jun 2000 11:10:36 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQitgu20824
	for <mpls@UU.NET>; Mon, 12 Jun 2000 15:10:35 GMT
Received: from pluris.com (volsung.pluris.com [172.16.50.19])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id IAA09657;
	Mon, 12 Jun 2000 08:10:32 -0700 (PDT)
Message-ID: <3944FD1A.C93CE3C9@pluris.com>
Date: Mon, 12 Jun 2000 08:09:15 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: curtis@avici.com
CC: Tony Li <tli@Procket.com>, "'mpls@uu.net'" <mpls@UU.NET>,
        swallow@cisco.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <200006121457.KAA20329@curtis-lt.avici.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Moreover, is this material discussed in RSVP-TE, if not why not?
A discussion of hierarchical tunnels in that draft or an accompanying draft would
have been nice.

Bora


Curtis Villamizar wrote:

> In message <14657.53536.422247.469955@redd235.procket.com>, Tony Li writes:
> >
> >
> >  | How does one establish hierarchical tunnels using RSVP-TE?
> >  |
> >  | I know that the label object can be deeper than one label, but you need mo
> > re
> >  | than this to establish hierarchical tunnels.
> >
> >
> > A hierarchical tunnel requires the participation of at least two LSRs.  The
> > operation of the LSR creating the innermost tunnel is straightforward and
> > is unchanged from what has been endlessly discussed here.
> >
> > For an LSR to create an outer tunnel, it simply creates another tunnel and
> > specifies MPLS as the L3PID.  It then forwards packets received on the
> > inner tunnel by pushing a label for the outer tunnel.  The RSVP control
> > traffic for the inner tunnel is also forwarded through the outer tunnel
> > after first being encapsulated with a null IP label.
> >
> > Recurse, ad nauseum.
> >
> > Simple, really.  ;-)
> >
> > Tony
>
> Tony,
>
> Two minor points.
>
> If the outer tunnel is constrained (by configuration) to accept only
> inner tunnels with one L3PID, then that L3PID can be placed on the
> outer tunnel.  If there are optimization possible for a particular
> L3PID (IP src/dst hash to split loading along the way comes to mind
> for IPv4) then putting the inner L3PID on the outer tunnel has
> advantages.
>
> No where have I seen a requirement to put a null label on traffic
> destined to the egress LSR.  I had been assuming that if the IP packet
> under the top label has the address of the router ID of the egress
> under the outer label, then the packet would be delivered to the
> egress.  If the egress required PHP, then the penultimate LSR would
> put a null label on the control traffic for the the inner label and
> the egress would POP the null label and see its own IP address.
> Otherwise, the egress would see two null labels.
>
> If I'm missing something and/or there will be any interoperability
> problem with the way I intended to encapsulate control traffic inside
> the outer label, please tell us about it.
>
> Curtis




From owner-mpls@UU.NET  Mon Jun 12 11:46:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04761
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 11:46:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitgx26840;
	Mon, 12 Jun 2000 15:45:59 GMT
Received: by mail-control.mail.uu.net 
	id QQitgx10870
	for mpls-outgoing; Mon, 12 Jun 2000 15:45:29 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitgx10865
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 15:45:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitgw14606
	for <mpls@uu.net>; Mon, 12 Jun 2000 11:44:45 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQitgw01124
	for <mpls@uu.net>; Mon, 12 Jun 2000 15:44:44 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA13715
	for <mpls@uu.net>; Mon, 12 Jun 2000 08:44:53 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA22148 for mpls@uu.net; Mon, 12 Jun 2000 11:44:41 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitgw10347
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 15:39:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitgw13070
	for <mpls@uu.net>; Mon, 12 Jun 2000 11:32:48 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQitgw20273
	for <mpls@uu.net>; Mon, 12 Jun 2000 15:32:48 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <MJ3JNXBA>; Mon, 12 Jun 2000 11:30:31 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B8501BE68@xover1.hjinc.com>
From: "Friedeborn, William" <wfriedeb@netplane.com>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>,
        "Friedeborn, William"
	 <wfriedeb@netplane.com>
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan
	 <csrinivasan@tachion.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable
Date: Mon, 12 Jun 2000 11:30:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD483.26F2BDB0"
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_01BFD483.26F2BDB0
Content-Type: text/plain;
	charset="iso-8859-1"

What I am puzzeled about is the existence of the Tunnel objects on the
intermediate nodes that you are modeling. From section 2. in the
draft-ietf-mpls-te-mib-03.txt
 
 An explicitly routed LSP (ERLSP) is referred to as an
   MPLS tunnel.  It consists of one in-segment and/or one
   out-segment at the ingress/egress LSRs, each segment
   being associated with one MPLS interface.  These are
   also referred to as tunnel segments.  Additionally, at
   an intermediate LSR, we model a connection as
   consisting of one or more in-segments and/or one or
   more out-segments.  The binding or interconnection
   between in-segments and out-segments in performed
   using a cross-connect. These objects are defined in
   the MPLS Label Switch Router MIB [LSRMIB].
 
I took this to mean that the Tunnel objects can be brought into existence by
either an SNMP request or by a signaling entity at the ingress/egress nodes.
In the case of an SNMP request, the creation of the tunnel (MPLS_TE_MIB)
objects in the head end node would be the trigger that caused the creation
of the LSR-MIB objects in the head end, and kick off the protocols to signal
the lsp to the other nodes (assuming the SignalingProto object is LDP or
RSVP). In the intermediate nodes, the LSR-MIB objects are created till the
egress node is reached, at which point the Tunnel objects are created here
(as this is the egress end). (Actually, the sig proto reaches egress node,
Tunnel objects/LSR-MIB created and intermediate nodes filled in on return
trip). In the case where it is a signaling entity that is creating the
Tunnel objects, I could see that the ingress/egress node knows that the LSP
is an Originating/Terminating LSP and could create the Tunnel objects.
 
What is it in the signaling protocol (RSVP or LDP) that would tell the
intermediate node that the LSP being created should have objects other than
LSR-MIB objects created?
 
Thanks,
Bill
[Friedeborn, William]  -----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Friday, June 09, 2000 12:34 PM
To: Friedeborn, William
Cc: arun Viswanathan; cheenu Srinivasan
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable



At 12:24 PM 6/9/00 -0400, Friedeborn, William wrote:


Sorry for the long interval between the posting and this question. But, in
"draft-ietf-mpls-te-mib-03.txt"
 
7. Example of Tunnel Setup
 
   This section contains an example of which MIB objects
   should be modified if one would like to create
   loosely routed, unidirectional traffic engineered
   tunnel, which spans two hops of a simple network.
   Note that these objects should be created on the
   "head-end" LSR.
 
States that this is created on the head end LSR, how are the objects
propagated to the intermediate nodes in your scenario?


        Via the signaling protocol.

        --Tom






Thanks,
Bill 


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

From: Thomas D. Nadeau [ mailto:tnadeau@cisco.com <mailto:tnadeau@cisco.com>
] 

Sent: Friday, June 02, 2000 2:39 PM 

To: mpls@UU.NET 

Cc: Cheenu Srinivasan; arun Viswanathan 

Subject: Additional Index for TE-MIB: mplsTunnelTable



    Hi, 

I would like to modify the mplsTunnelEntry to include 

a few more objects as well as indexes. I wanted to 

bring these changes to the list for discussion before 

adding them to the TE MIB due to the fact that they 

constitute a significant change, and we did not want to 

surprise anyone. This change comes from my implementation 

experience with the current version of the MIB, so it is 

grounded in an actual implementation.



I would like to add five additional values to the mplsTunnelTable 

as well as augment the current indexes with two more indexes:



mplsTunnelSrcAddrType     INTEGER, 

mplsTunnelSrcAddrIPv4   InetAddresIPv4, 

mplsTunnelSrcAddrIPv6   InetAddresIPv6, 


     Now let me explain why. When you want to examine the tunnel
     entry at a midpoint, it is possible for tunnelId/tunnelInstance
     collisions to occur because the mplsTunnelId + mplsTunnelInstance
     variables are not guaranteed to be unique within an MPLS domain. 
     A simple example of this occurs when LSR A has tunnelId = 1, 
     tunnelInstance = 0 and LSR B has tunnelId = 1, tunnelInstance = 0
     which utilize the same next hop, LSR C. If one examines the 
     tunnel table at LSR C, it is impossible to distinguish both tunnels;
     hence, the third index. A fourth index is required because we need 
     to support V6 addresses.

     An additional benefit of the added indexes is that one can now
     sort tunnelEntries based on src address, which is quite useful
     at mid-points and tunnel tails. For this same reason, it might be
     useful to add the tunnel destination address to the indexes of
     this table as well.
      
     --Tom



------_=_NextPart_001_01BFD483.26F2BDB0
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.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=558244413-12062000>What I 
am puzzeled about is the existence of the Tunnel objects on the intermediate 
nodes <FONT color=#0000ff size=2>that you are modeling</FONT>. From section 2. 
in the draft-ietf-mpls-te-mib-03.txt</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=558244413-12062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=558244413-12062000>&nbsp;An explicitly routed LSP (ERLSP) is referred to 
as an<BR>&nbsp;&nbsp; MPLS tunnel.&nbsp; It consists of one in-segment and/or 
one<BR>&nbsp;&nbsp; out-segment at the ingress/egress LSRs, each 
segment<BR>&nbsp;&nbsp; being associated with one MPLS interface.&nbsp; These 
are<BR>&nbsp;&nbsp; also referred to as tunnel segments.&nbsp; Additionally, 
at<BR>&nbsp;&nbsp; an intermediate LSR, we model a connection as<BR>&nbsp;&nbsp; 
consisting of one or more in-segments and/or one or<BR>&nbsp;&nbsp; more 
out-segments.&nbsp; The binding or interconnection<BR>&nbsp;&nbsp; between 
in-segments and out-segments in performed<BR>&nbsp;&nbsp; using a cross-connect. 
These objects are defined in<BR>&nbsp;&nbsp; the MPLS Label Switch Router MIB 
[LSRMIB].</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=558244413-12062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=558244413-12062000>I took 
this to mean that the Tunnel objects can be brought into existence by either an 
SNMP request or by a signaling entity at the ingress/egress nodes. In the case 
of an SNMP request, the creation of the tunnel (MPLS_TE_MIB) objects in the head 
end node would be the trigger that caused the creation of the LSR-MIB objects in 
the head end, and kick off the protocols to signal the lsp to the other nodes 
(assuming the SignalingProto object is LDP or RSVP). In the intermediate nodes, 
the LSR-MIB objects are created till the egress node is reached, at which point 
the Tunnel objects are created here (as this is the egress end). (Actually, the 
sig proto reaches egress node, Tunnel objects/LSR-MIB created and intermediate 
nodes filled in on return trip). In the case where it is a signaling entity that 
is creating the Tunnel objects, I could see that the ingress/egress node knows 
that the LSP is an Originating/Terminating LSP and could create the Tunnel 
objects.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=558244413-12062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=558244413-12062000>What 
is it in the signaling protocol (RSVP or LDP) that would tell the intermediate 
node that the LSP being created should have objects other than LSR-MIB objects 
created?</SPAN></FONT></DIV>
<DIV><SPAN class=558244413-12062000></SPAN><FONT face=Tahoma></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN class=558244413-12062000><FONT 
color=#0000ff face=Arial>Thanks,</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><SPAN class=558244413-12062000></SPAN><FONT size=2><FONT 
color=#0000ff><FONT face=Arial><SPAN 
class=558244413-12062000>Bill</SPAN><BR><SPAN 
class=558244413-12062000>[Friedeborn, 
William]&nbsp;&nbsp;</SPAN></FONT></FONT>-----Original 
Message-----<BR><B>From:</B> Thomas D. Nadeau 
[mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Friday, June 09, 2000 12:34 
PM<BR><B>To:</B> Friedeborn, William<BR><B>Cc:</B> arun Viswanathan; cheenu 
Srinivasan<BR><B>Subject:</B> RE: Additional Index for TE-MIB: 
mplsTunnelTable<BR><BR></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>At 12:24 PM 6/9/00 -0400, 
  Friedeborn, William wrote:<BR>
  <BLOCKQUOTE cite type="cite"><FONT color=#0000ff face=arial size=2>Sorry for 
    the long interval between the posting and this question. But, in 
    "draft-ietf-mpls-te-mib-03.txt"</FONT><BR>&nbsp;<BR><FONT color=#0000ff 
    face=arial size=2>7. Example of Tunnel Setup</FONT><BR>&nbsp;<BR><FONT 
    color=#0000ff face=arial size=2>&nbsp;&nbsp; This section contains an 
    example of which MIB objects<BR>&nbsp;&nbsp; should be modified if one would 
    like to create<BR>&nbsp;&nbsp; loosely routed, unidirectional traffic 
    engineered<BR>&nbsp;&nbsp; tunnel, which spans two hops of a simple 
    network.<BR>&nbsp;&nbsp; Note that these objects should be created on 
    the<BR>&nbsp;&nbsp; "head-end" LSR.</FONT><BR>&nbsp;<BR><FONT color=#0000ff 
    face=arial size=2>States that this is created on the head end LSR, how are 
    the objects propagated to the intermediate nodes in your 
  scenario?</FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Via 
  the signaling 
  protocol.<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR>
  <BLOCKQUOTE cite type="cite"><BR><FONT color=#0000ff face=arial 
    size=2>Thanks,</FONT><BR><FONT color=#0000ff face=arial size=2>Bill</FONT> 
    <DL><FONT face=tahoma size=2>
      <DD>-----Original Message----- 
      <DD>From:</B> Thomas D. Nadeau [<A href="mailto:tnadeau@cisco.com" 
      eudora="autourl">mailto:tnadeau@cisco.com</A>] 
      <DD>Sent:</B> Friday, June 02, 2000 2:39 PM 
      <DD>To:</B> mpls@UU.NET 
      <DD>Cc:</B> Cheenu Srinivasan; arun Viswanathan 
      <DD>Subject:</B> Additional Index for TE-MIB: 
      mplsTunnelTable<BR><BR></FONT>
      <DD>&nbsp;&nbsp;&nbsp; Hi, 
      <DD>I would like to modify the mplsTunnelEntry to include 
      <DD>a few more objects as well as indexes. I wanted to 
      <DD>bring these changes to the list for discussion before 
      <DD>adding them to the TE MIB due to the fact that they 
      <DD>constitute a significant change, and we did not want to 
      <DD>surprise anyone. This change comes from my implementation 
      <DD>experience with the current version of the MIB, so it is 
      <DD>grounded in an actual implementation.<BR><BR>
      <DD>I would like to add five additional values to the mplsTunnelTable 
      <DD>as well as augment the current indexes with two more indexes:<BR><BR>
      <DD>mplsTunnelSrcAddrType&nbsp;&nbsp;&nbsp;&nbsp; INTEGER, 
      <DD>mplsTunnelSrcAddrIPv4<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB>InetAddresIPv4, 
      <DD>mplsTunnelSrcAddrIPv6<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB>InetAddresIPv6, 
      </DD></DL><BR>&nbsp;&nbsp;&nbsp;&nbsp; Now let me explain why. When you want 
    to examine the tunnel<BR>&nbsp;&nbsp;&nbsp;&nbsp; entry at a midpoint, it is 
    possible for tunnelId/tunnelInstance<BR>&nbsp;&nbsp;&nbsp;&nbsp; collisions 
    to occur because the mplsTunnelId + 
    mplsTunnelInstance<BR>&nbsp;&nbsp;&nbsp;&nbsp; variables are not guaranteed 
    to be unique within an MPLS domain. <BR>&nbsp;&nbsp;&nbsp;&nbsp; A simple 
    example of this occurs when LSR A has tunnelId = 1, 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp; tunnelInstance = 0 and LSR B has tunnelId = 1, 
    tunnelInstance = 0<BR>&nbsp;&nbsp;&nbsp;&nbsp; which utilize the same next 
    hop, LSR C. If one examines the <BR>&nbsp;&nbsp;&nbsp;&nbsp; tunnel table at 
    LSR C, it is impossible to distinguish both 
    tunnels;<BR>&nbsp;&nbsp;&nbsp;&nbsp; hence, the third index. A fourth index 
    is required because we need <BR>&nbsp;&nbsp;&nbsp;&nbsp; to support V6 
    addresses.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; An additional benefit of the 
    added indexes is that one can now<BR>&nbsp;&nbsp;&nbsp;&nbsp; sort 
    tunnelEntries based on src address, which is quite 
    useful<BR>&nbsp;&nbsp;&nbsp;&nbsp; at mid-points and tunnel tails. For this 
    same reason, it might be<BR>&nbsp;&nbsp;&nbsp;&nbsp; useful to add the 
    tunnel destination address to the indexes of<BR>&nbsp;&nbsp;&nbsp;&nbsp; 
    this table as well.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp; --Tom<BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFD483.26F2BDB0--



From owner-mpls@UU.NET  Mon Jun 12 12:25:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05924
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 12:25:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitgz04362;
	Mon, 12 Jun 2000 16:25:01 GMT
Received: by mail-control.mail.uu.net 
	id QQitgz22692
	for mpls-outgoing; Mon, 12 Jun 2000 16:24:11 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitgz22686
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 16:24:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitgz21190
	for <mpls@UU.NET>; Mon, 12 Jun 2000 12:17:52 -0400 (EDT)
Received: from babelbrox.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: babelbrox.axion.bt.co.uk [132.146.16.6])
	id QQitgz27592
	for <mpls@UU.NET>; Mon, 12 Jun 2000 16:17:51 GMT
Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) 
          by babelbrox (local) with SMTP; Mon, 12 Jun 2000 17:17:34 +0100
Received: from ip-engineering.bt.com 
          by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id RAA18203;
          Mon, 12 Jun 2000 17:17:34 +0100 (BST)
Message-Id: <200006121617.RAA18203@celiborn.ip-engineering.bt.com>
X-Mailer: exmh version 2.0.3 9/28/98
To: mpls@UU.NET
Subject: Re: OAM functionality 
         (Was: RE: can egress know the ingressof a packet?)
In-reply-to: Your message of "Fri, 09 Jun 2000 18:53:57 EDT." <200006092253.SAA19341@curtis-lt.avici.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 Jun 2000 17:17:34 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

A simple illustration of how iBGP in MPLS IP VPNs can become non-congruent
with the LSP; I use a route reflector.

If I have a LSP between PEs but I'm using BGP route reflectors (for scaling
because I have hundreds of PEs) then a LSR in the middle can fail but the
BGP session will stay up. If the LSR fails totally then I'll get my
traditional SNMP traps from neighboring LSRs (hopefully) BUT if only
the label switching bit failed and the CPU in the LSR stayed up I could find
that the LDP and L2 keepalives are still working, may be even IP process
switching, but the label "fast path" is down  How do I now
detect failure of the LSP?

Lets try counting packets in and out of the LSP, will that work?
No it won't! It may be that the customer only uses that LSP once a month,
 so with no traffic its difficult to tell the LSP is down. So you're going 
to get a fault report from the customer when they try to use it on the last
midnight of the month.


But I think we've agreed we need a continuity verfication function? 


It may be too futuristic to suggest that when network providers start
offering MPLS as a network service the network provider will never see
the IP addresses of the customers so anything using ping or traceroute
to a customer address is inappropriate.

Peter.




From owner-mpls@UU.NET  Mon Jun 12 13:22:03 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07322
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 13:22:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithd23119;
	Mon, 12 Jun 2000 17:22:02 GMT
Received: by mail-control.mail.uu.net 
	id QQithd05422
	for mpls-outgoing; Mon, 12 Jun 2000 17:21:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQithd05398
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 17:21:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQithd03118
	for <mpls@UU.NET>; Mon, 12 Jun 2000 13:21:03 -0400 (EDT)
Received: from redbaron.nexabit.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: d28.nexabit.com [209.6.34.253])
	id QQithd10100
	for <mpls@UU.NET>; Mon, 12 Jun 2000 17:21:02 GMT
Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4])
	by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id NAA14038;
	Mon, 12 Jun 2000 13:19:05 -0400
Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21)
	id <L9T52JB8>; Mon, 12 Jun 2000 13:19:04 -0400
Message-ID: <BAC9CCF04FEED311BD1D00062950ABB14ED82B@bandito.nexabit.com>
From: Dimitry Haskin <dhaskin@nexabit.com>
To: curtis@avici.com, Tony Li <tli@Procket.com>
Cc: Bora Akyol <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Mon, 12 Jun 2000 13:19:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis,

If I read you correctly, you're implying that both labeled and unlabeled IP
packets are encapsulated into the outer tunnel, i.e. the RSVP control
traffic is sent with a single MPLS header of outer tunnel. Is it correct? If
so, this is fine except that, as far as I know, some MPLS vendors (note that
it does not apply to the equipment I am most familiar with ;) would not be
able to handle this in their fast path. To support labeled and plain IP
packets in the same tunnel would require the fast path decision based on the
state of S-bit of the outer header which is problematic with some equipment.
In addition, I've heard that one particular vendor would not be able to
terminate MPLS tunnels unless it arrives with a Null IP label.

Dimitry 

> Tony Li writes:
> > 
> > 
> >  | How does one establish hierarchical tunnels using RSVP-TE?
> >  |  
> >  | I know that the label object can be deeper than one 
> label, but you need mo
> > re
> >  | than this to establish hierarchical tunnels.
> > 
> > 
> > A hierarchical tunnel requires the participation of at 
> least two LSRs.  The
> > operation of the LSR creating the innermost tunnel is 
> straightforward and
> > is unchanged from what has been endlessly discussed here.
> > 
> > For an LSR to create an outer tunnel, it simply creates 
> another tunnel and
> > specifies MPLS as the L3PID.  It then forwards packets 
> received on the
> > inner tunnel by pushing a label for the outer tunnel.  The 
> RSVP control
> > traffic for the inner tunnel is also forwarded through the 
> outer tunnel
> > after first being encapsulated with a null IP label.
> > 
> > Recurse, ad nauseum.
> > 
> > Simple, really.  ;-)
> > 
> > Tony
> 
> 
> Tony,
> 
> Two minor points.  
> 
> If the outer tunnel is constrained (by configuration) to accept only
> inner tunnels with one L3PID, then that L3PID can be placed on the
> outer tunnel.  If there are optimization possible for a particular
> L3PID (IP src/dst hash to split loading along the way comes to mind
> for IPv4) then putting the inner L3PID on the outer tunnel has
> advantages.
> 
> No where have I seen a requirement to put a null label on traffic
> destined to the egress LSR.  I had been assuming that if the IP packet
> under the top label has the address of the router ID of the egress
> under the outer label, then the packet would be delivered to the
> egress.  If the egress required PHP, then the penultimate LSR would
> put a null label on the control traffic for the the inner label and
> the egress would POP the null label and see its own IP address.
> Otherwise, the egress would see two null labels.
> 
> If I'm missing something and/or there will be any interoperability
> problem with the way I intended to encapsulate control traffic inside
> the outer label, please tell us about it.
> 
> Curtis
> 


From owner-mpls@UU.NET  Mon Jun 12 13:32:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07520
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 13:32:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithe02002;
	Mon, 12 Jun 2000 17:32:32 GMT
Received: by mail-control.mail.uu.net 
	id QQithe06229
	for mpls-outgoing; Mon, 12 Jun 2000 17:31:48 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQithe06224
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 17:31:43 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQithd04061
	for <mpls@uu.net>; Mon, 12 Jun 2000 13:27:45 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQithd16866
	for <mpls@uu.net>; Mon, 12 Jun 2000 17:27:44 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA28631
	for mpls@uu.net; Mon, 12 Jun 2000 13:27:41 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQithd05703
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 17:27:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithd03140
	for <mpls@UU.NET>; Mon, 12 Jun 2000 13:22:25 -0400 (EDT)
Received: from redd235.procket.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: flowpoint.procket.com [205.253.146.41])
	id QQithd23557
	for <mpls@UU.NET>; Mon, 12 Jun 2000 17:22:25 GMT
Received: (from tli@localhost)
	by redd235.procket.com (8.9.3/8.9.3) id KAA03839;
	Mon, 12 Jun 2000 10:21:51 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redd235.procket.com: tli set sender to tli@redd235.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14661.7215.77900.728386@redd235.procket.com>
Date: Mon, 12 Jun 2000 10:21:51 -0700 (PDT)
To: curtis@avici.com
Cc: Tony Li <tli@Procket.com>, Bora Akyol <akyol@pluris.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-Reply-To: <200006121457.KAA20329@curtis-lt.avici.com>
References: <14657.53536.422247.469955@redd235.procket.com>
	<200006121457.KAA20329@curtis-lt.avici.com>
X-Mailer: VM 6.75 under Emacs 20.4.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Curtis,

 | If the outer tunnel is constrained (by configuration) to accept only
 | inner tunnels with one L3PID, then that L3PID can be placed on the
 | outer tunnel.  If there are optimization possible for a particular
 | L3PID (IP src/dst hash to split loading along the way comes to mind
 | for IPv4) then putting the inner L3PID on the outer tunnel has
 | advantages.


I agree that this is also possible for implementations that want to parse
up the label stack.


 | No where have I seen a requirement to put a null label on traffic
 | destined to the egress LSR.


The requirement exists if you take the more general approach of specifying
an outer L3PID of MPLS and then wish to tunnel (otherwise unlabeled) RSVP.
Under the approach that you've proposed, this would not be necessary.

Tony



From owner-mpls@UU.NET  Mon Jun 12 13:35:56 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07571
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 13:35:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithe24738;
	Mon, 12 Jun 2000 17:35:55 GMT
Received: by mail-control.mail.uu.net 
	id QQithe06341
	for mpls-outgoing; Mon, 12 Jun 2000 17:35:20 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQithe06334
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 17:35:13 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithe04957
	for <mpls@UU.NET>; Mon, 12 Jun 2000 13:32:14 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQithe01654
	for <mpls@UU.NET>; Mon, 12 Jun 2000 17:32:13 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id MAA12780;
	Mon, 12 Jun 2000 12:31:58 -0500
Message-ID: <20000612123157.A12538@doit.wisc.edu>
Date: Mon, 12 Jun 2000 12:31:57 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: Dimitry Haskin <dhaskin@nexabit.com>, curtis@avici.com,
        Tony Li <tli@Procket.com>
Cc: Bora Akyol <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Reply-To: jleu@mindspring.com
References: <BAC9CCF04FEED311BD1D00062950ABB14ED82B@bandito.nexabit.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <BAC9CCF04FEED311BD1D00062950ABB14ED82B@bandito.nexabit.com>; from Dimitry Haskin on Mon, Jun 12, 2000 at 01:19:01PM -0400
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, Jun 12, 2000 at 01:19:01PM -0400, Dimitry Haskin wrote:
> Curtis,
> 
> If I read you correctly, you're implying that both labeled and unlabeled IP
> packets are encapsulated into the outer tunnel, i.e. the RSVP control
> traffic is sent with a single MPLS header of outer tunnel. Is it correct? If
> so, this is fine except that, as far as I know, some MPLS vendors (note that
> it does not apply to the equipment I am most familiar with ;) would not be

See draft-ietf-mpls-arch-06.txt

3.10. The Next Hop Label Forwarding Entry (NHLFE)
   ...
   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.
   ...

> able to handle this in their fast path. To support labeled and plain IP
> packets in the same tunnel would require the fast path decision based on the
> state of S-bit of the outer header which is problematic with some equipment.
> In addition, I've heard that one particular vendor would not be able to
> terminate MPLS tunnels unless it arrives with a Null IP label.

It seems the arch draft allows it, is this the same way others have interpreted
this?

Jim
-- 
James R. Leu


From owner-mpls@UU.NET  Mon Jun 12 14:29:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08576
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 14:29:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithh18827;
	Mon, 12 Jun 2000 18:29:33 GMT
Received: by mail-control.mail.uu.net 
	id QQithh19297
	for mpls-outgoing; Mon, 12 Jun 2000 18:28:57 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQithh19290
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 18:28:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQithg11934
	for <mpls@uu.net>; Mon, 12 Jun 2000 14:07:08 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQithg03110
	for <mpls@uu.net>; Mon, 12 Jun 2000 18:07:08 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA05580
	for mpls@uu.net; Mon, 12 Jun 2000 14:07:07 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQithg17573
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 18:06:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithf09243
	for <mpls@uu.net>; Mon, 12 Jun 2000 13:53:07 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQithf17613
	for <mpls@uu.net>; Mon, 12 Jun 2000 17:53:06 GMT
Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA03321
	for <mpls@uu.net>; Mon, 12 Jun 2000 13:53:05 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA22286 for <mpls@uu.net>; Mon, 12 Jun 2000 13:53:05 -0400 (EDT)
Message-Id: <200006121753.NAA22286@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Last Call on MPLS-Diff-Serv
Date: Mon, 12 Jun 2000 13:53:05 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message marks the beginning of a last call on 
draft-ietf-mpls-diff-ext-05.txt, MPLS Support of Differentiated
Services.

The last call ends June 26, 2000 at mid-night GMT.

...George


ps.  I was travelling when the last call for draft-ietf-mpls-lsr-mib-04.txt
     ended (on May 12) so if anyone was waiting for a message, this
     post script will have to do.

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






From owner-mpls@UU.NET  Mon Jun 12 14:54:18 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08940
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 14:54:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithj07628;
	Mon, 12 Jun 2000 18:54:17 GMT
Received: by mail-control.mail.uu.net 
	id QQithj20777
	for mpls-outgoing; Mon, 12 Jun 2000 18:53:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQithj20772
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 18:53:03 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQithi17826
	for <mpls@uu.net>; Mon, 12 Jun 2000 14:37:12 -0400 (EDT)
Received: from web5102.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5102.mail.yahoo.com [216.115.106.72])
	id QQithi24794
	for <mpls@uu.net>; Mon, 12 Jun 2000 18:37:10 GMT
Message-ID: <20000612183709.27103.qmail@web5102.mail.yahoo.com>
Received: from [169.144.16.187] by web5102.mail.yahoo.com; Mon, 12 Jun 2000 11:37:09 PDT
Date: Mon, 12 Jun 2000 11:37:09 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi
I had this doubt after reading 2.1.4.b of
draft-ietf-mpls-label-encaps-07:

[ it has expired, but no replacement yet ???, ditto
for MPLS ARCH document.. ]
[text from draft]
.....

The operation to be performed on the label stack
before 
forwarding; this operation may be to replace the ....
....
....

From this paragraph it would seem that the list of
operations allowed is:

1. Swap
2. Pop
3. Replace the top label with one or more additional
   entries on the stack. 

Does that mean that two pops cannot be performed ?
Surely this cannot be the case. Right ?

thanks
C.


--- "James R. Leu" <jleu@mindspring.com> wrote:
> On Mon, Jun 12, 2000 at 01:19:01PM -0400, Dimitry
> Haskin wrote:
> > Curtis,
> > 
> > If I read you correctly, you're implying that both
> labeled and unlabeled IP
> > packets are encapsulated into the outer tunnel,
> i.e. the RSVP control
> > traffic is sent with a single MPLS header of outer
> tunnel. Is it correct? If
> > so, this is fine except that, as far as I know,
> some MPLS vendors (note that
> > it does not apply to the equipment I am most
> familiar with ;) would not be
> 
> See draft-ietf-mpls-arch-06.txt
> 
> 3.10. The Next Hop Label Forwarding Entry (NHLFE)
>    ...
>    Note that at a given LSR, the packet's "next hop"
> might be that LSR
>    itself.  In this case, the LSR would need to pop
> the top level label,
>    and then "forward" the resulting packet to
> itself.  It would then
>    make another forwarding decision, based on what
> remains after the
>    label stacked is popped.  This may still be a
> labeled packet, or it
>    may be the native IP packet.
> 
>    This implies that in some cases the LSR may need
> to operate on the IP
>    header in order to forward the packet.
>    ...
> 
> > able to handle this in their fast path. To support
> labeled and plain IP
> > packets in the same tunnel would require the fast
> path decision based on the
> > state of S-bit of the outer header which is
> problematic with some equipment.
> > In addition, I've heard that one particular vendor
> would not be able to
> > terminate MPLS tunnels unless it arrives with a
> Null IP label.
> 
> It seems the arch draft allows it, is this the same
> way others have interpreted
> this?
> 
> Jim
> -- 
> James R. Leu


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Mon Jun 12 15:06:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09085
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 15:06:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithk25387;
	Mon, 12 Jun 2000 19:06:38 GMT
Received: by mail-control.mail.uu.net 
	id QQithk00653
	for mpls-outgoing; Mon, 12 Jun 2000 19:05:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQithk00639
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 19:05:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithj21897
	for <mpls@UU.NET>; Mon, 12 Jun 2000 14:57:34 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQithj14982
	for <mpls@UU.NET>; Mon, 12 Jun 2000 18:57:34 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 OAA18586;
	Mon, 12 Jun 2000 14:57:31 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23722;
	Mon, 12 Jun 2000 14:57:32 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <MR1YQRBC>; Mon, 12 Jun 2000 14:57:32 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CFE49434@whq-msgusr-02.fore.com>
From: "Punj, Arun" <Arun.Punj@marconi.com>
To: "'Chatur sharp'" <chatur_b@yahoo.com>, mpls@UU.NET
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE
Date: Mon, 12 Jun 2000 14:57:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

It seems you have slightly misinterpreted the draft.

What it says is that just by looking at the top label you cannot pop two
labels.

However at a given LSR you could pop two labels by first popping one label
and than forwarding it to yourself and than popping another if required.

Where forwarding to yourself really means you continue with parsing of the
label
stack of a packet.


hope it helps

-TL

-----Original Message-----
From: Chatur sharp [mailto:chatur_b@yahoo.com]
Sent: Monday, June 12, 2000 2:37 PM
To: mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE



Hi
I had this doubt after reading 2.1.4.b of
draft-ietf-mpls-label-encaps-07:

[ it has expired, but no replacement yet ???, ditto
for MPLS ARCH document.. ]
[text from draft]
.....

The operation to be performed on the label stack
before 
forwarding; this operation may be to replace the ....
....
....

From this paragraph it would seem that the list of
operations allowed is:

1. Swap
2. Pop
3. Replace the top label with one or more additional
   entries on the stack. 

Does that mean that two pops cannot be performed ?
Surely this cannot be the case. Right ?

thanks
C.


--- "James R. Leu" <jleu@mindspring.com> wrote:
> On Mon, Jun 12, 2000 at 01:19:01PM -0400, Dimitry
> Haskin wrote:
> > Curtis,
> > 
> > If I read you correctly, you're implying that both
> labeled and unlabeled IP
> > packets are encapsulated into the outer tunnel,
> i.e. the RSVP control
> > traffic is sent with a single MPLS header of outer
> tunnel. Is it correct? If
> > so, this is fine except that, as far as I know,
> some MPLS vendors (note that
> > it does not apply to the equipment I am most
> familiar with ;) would not be
> 
> See draft-ietf-mpls-arch-06.txt
> 
> 3.10. The Next Hop Label Forwarding Entry (NHLFE)
>    ...
>    Note that at a given LSR, the packet's "next hop"
> might be that LSR
>    itself.  In this case, the LSR would need to pop
> the top level label,
>    and then "forward" the resulting packet to
> itself.  It would then
>    make another forwarding decision, based on what
> remains after the
>    label stacked is popped.  This may still be a
> labeled packet, or it
>    may be the native IP packet.
> 
>    This implies that in some cases the LSR may need
> to operate on the IP
>    header in order to forward the packet.
>    ...
> 
> > able to handle this in their fast path. To support
> labeled and plain IP
> > packets in the same tunnel would require the fast
> path decision based on the
> > state of S-bit of the outer header which is
> problematic with some equipment.
> > In addition, I've heard that one particular vendor
> would not be able to
> > terminate MPLS tunnels unless it arrives with a
> Null IP label.
> 
> It seems the arch draft allows it, is this the same
> way others have interpreted
> this?
> 
> Jim
> -- 
> James R. Leu


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Mon Jun 12 16:00:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10019
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 16:00:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitho04401;
	Mon, 12 Jun 2000 20:00:24 GMT
Received: by mail-control.mail.uu.net 
	id QQithn04448
	for mpls-outgoing; Mon, 12 Jun 2000 19:59:44 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQithn04443
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 19:59:42 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithn02687
	for <mpls@uu.net>; Mon, 12 Jun 2000 15:50:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQithn06308
	for <mpls@uu.net>; Mon, 12 Jun 2000 19:50:37 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA22867
	for mpls@uu.net; Mon, 12 Jun 2000 15:50:37 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQithn03850
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 19:50:19 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithn03315
	for <mpls@UU.NET>; Mon, 12 Jun 2000 15:49:53 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQithn05442
	for <mpls@UU.NET>; Mon, 12 Jun 2000 19:49:53 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA09473;
	Mon, 12 Jun 2000 12:48:01 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <MRH70CP7>; Mon, 12 Jun 2000 12:48:39 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40601@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@avici.com'" <curtis@avici.com>, Tony Li <tli@Procket.com>
Cc: Bora Akyol <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Mon, 12 Jun 2000 12:48:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

What is an IP Null Label?

-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@avici.com]
>Sent: Monday, June 12, 2000 10:57 AM
>To: Tony Li
>Cc: Bora Akyol; 'mpls@uu.net'
>Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>
>In message <14657.53536.422247.469955@redd235.procket.com>, 
>Tony Li writes:
>> 
>> 
>>  | How does one establish hierarchical tunnels using RSVP-TE?
>>  |  
>>  | I know that the label object can be deeper than one 
>label, but you need mo
>> re
>>  | than this to establish hierarchical tunnels.
>> 
>> 
>> A hierarchical tunnel requires the participation of at least 
>two LSRs.  The
>> operation of the LSR creating the innermost tunnel is 
>straightforward and
>> is unchanged from what has been endlessly discussed here.
>> 
>> For an LSR to create an outer tunnel, it simply creates 
>another tunnel and
>> specifies MPLS as the L3PID.  It then forwards packets 
>received on the
>> inner tunnel by pushing a label for the outer tunnel.  The 
>RSVP control
>> traffic for the inner tunnel is also forwarded through the 
>outer tunnel
>> after first being encapsulated with a null IP label.
>> 
>> Recurse, ad nauseum.
>> 
>> Simple, really.  ;-)
>> 
>> Tony
>
>
>Tony,
>
>Two minor points.  
>
>If the outer tunnel is constrained (by configuration) to accept only
>inner tunnels with one L3PID, then that L3PID can be placed on the
>outer tunnel.  If there are optimization possible for a particular
>L3PID (IP src/dst hash to split loading along the way comes to mind
>for IPv4) then putting the inner L3PID on the outer tunnel has
>advantages.
>
>No where have I seen a requirement to put a null label on traffic
>destined to the egress LSR.  I had been assuming that if the IP packet
>under the top label has the address of the router ID of the egress
>under the outer label, then the packet would be delivered to the
>egress.  If the egress required PHP, then the penultimate LSR would
>put a null label on the control traffic for the the inner label and
>the egress would POP the null label and see its own IP address.
>Otherwise, the egress would see two null labels.
>
>If I'm missing something and/or there will be any interoperability
>problem with the way I intended to encapsulate control traffic inside
>the outer label, please tell us about it.
>
>Curtis
>



From owner-mpls@UU.NET  Mon Jun 12 16:35:17 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10741
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 16:35:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithq28084;
	Mon, 12 Jun 2000 20:35:13 GMT
Received: by mail-control.mail.uu.net 
	id QQithq16017
	for mpls-outgoing; Mon, 12 Jun 2000 20:34:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQithq16012
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 20:34:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitho07350
	for <mpls@uu.net>; Mon, 12 Jun 2000 16:12:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitho13157
	for <mpls@uu.net>; Mon, 12 Jun 2000 20:12:38 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA26518
	for mpls@uu.net; Mon, 12 Jun 2000 16:12:37 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitho14437
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 20:11:57 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQithn03248
	for <mpls@UU.NET>; Mon, 12 Jun 2000 15:53:52 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQithn29433
	for <mpls@UU.NET>; Mon, 12 Jun 2000 19:53:51 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA09659;
	Mon, 12 Jun 2000 12:50:31 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <MRH70CQZ>; Mon, 12 Jun 2000 12:51:09 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40602@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'curtis@avici.com'"
	 <curtis@avici.com>,
        "'Tony Li'" <tli@Procket.com>
Cc: "'Bora Akyol'" <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Mon, 12 Jun 2000 12:51:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Sorry,

Did you mean IPV4 or IPV6 Explicit Null Labels?

-Shahram

>-----Original Message-----
>From: Shahram Davari 
>Sent: Monday, June 12, 2000 3:49 PM
>To: 'curtis@avici.com'; Tony Li
>Cc: Bora Akyol; 'mpls@uu.net'
>Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>Hi,
>
>What is an IP Null Label?
>
>-Shahram
>
>>-----Original Message-----
>>From: Curtis Villamizar [mailto:curtis@avici.com]
>>Sent: Monday, June 12, 2000 10:57 AM
>>To: Tony Li
>>Cc: Bora Akyol; 'mpls@uu.net'
>>Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
>>
>>
>>
>>In message <14657.53536.422247.469955@redd235.procket.com>, 
>>Tony Li writes:
>>> 
>>> 
>>>  | How does one establish hierarchical tunnels using RSVP-TE?
>>>  |  
>>>  | I know that the label object can be deeper than one 
>>label, but you need mo
>>> re
>>>  | than this to establish hierarchical tunnels.
>>> 
>>> 
>>> A hierarchical tunnel requires the participation of at least 
>>two LSRs.  The
>>> operation of the LSR creating the innermost tunnel is 
>>straightforward and
>>> is unchanged from what has been endlessly discussed here.
>>> 
>>> For an LSR to create an outer tunnel, it simply creates 
>>another tunnel and
>>> specifies MPLS as the L3PID.  It then forwards packets 
>>received on the
>>> inner tunnel by pushing a label for the outer tunnel.  The 
>>RSVP control
>>> traffic for the inner tunnel is also forwarded through the 
>>outer tunnel
>>> after first being encapsulated with a null IP label.
>>> 
>>> Recurse, ad nauseum.
>>> 
>>> Simple, really.  ;-)
>>> 
>>> Tony
>>
>>
>>Tony,
>>
>>Two minor points.  
>>
>>If the outer tunnel is constrained (by configuration) to accept only
>>inner tunnels with one L3PID, then that L3PID can be placed on the
>>outer tunnel.  If there are optimization possible for a particular
>>L3PID (IP src/dst hash to split loading along the way comes to mind
>>for IPv4) then putting the inner L3PID on the outer tunnel has
>>advantages.
>>
>>No where have I seen a requirement to put a null label on traffic
>>destined to the egress LSR.  I had been assuming that if the IP packet
>>under the top label has the address of the router ID of the egress
>>under the outer label, then the packet would be delivered to the
>>egress.  If the egress required PHP, then the penultimate LSR would
>>put a null label on the control traffic for the the inner label and
>>the egress would POP the null label and see its own IP address.
>>Otherwise, the egress would see two null labels.
>>
>>If I'm missing something and/or there will be any interoperability
>>problem with the way I intended to encapsulate control traffic inside
>>the outer label, please tell us about it.
>>
>>Curtis
>>
>



From owner-mpls@UU.NET  Mon Jun 12 16:47:46 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10855
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 16:47:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithr06799;
	Mon, 12 Jun 2000 20:47:41 GMT
Received: by mail-control.mail.uu.net 
	id QQithr16891
	for mpls-outgoing; Mon, 12 Jun 2000 20:47:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQithr16886
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 20:47:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithp09930
	for <mpls@uu.net>; Mon, 12 Jun 2000 16:27:34 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQithp14887
	for <mpls@uu.net>; Mon, 12 Jun 2000 20:27:33 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA28671
	for mpls@uu.net; Mon, 12 Jun 2000 16:27:32 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQithp15554
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 20:27:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithp08606
	for <mpls@UU.NET>; Mon, 12 Jun 2000 16:17:41 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQithp04467
	for <mpls@UU.NET>; Mon, 12 Jun 2000 20:17:36 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA11549;
	Mon, 12 Jun 2000 13:15:46 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <MRH70C8A>; Mon, 12 Jun 2000 13:16:25 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40603@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Dimitry Haskin'" <dhaskin@nexabit.com>, curtis@avici.com,
        Tony Li
	 <tli@Procket.com>
Cc: Bora Akyol <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Mon, 12 Jun 2000 13:16:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Dimitry,

>-----Original Message-----
>From: Dimitry Haskin [mailto:dhaskin@nexabit.com]
>Sent: Monday, June 12, 2000 1:19 PM
>To: curtis@avici.com; Tony Li
>Cc: Bora Akyol; 'mpls@uu.net'
>Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>Curtis,
>
>If I read you correctly, you're implying that both labeled and 
>unlabeled IP
>packets are encapsulated into the outer tunnel, i.e. the RSVP control
>traffic is sent with a single MPLS header of outer tunnel. Is 
>it correct? If
>so, this is fine except that, as far as I know, some MPLS 
>vendors (note that
>it does not apply to the equipment I am most familiar with ;) 
>would not be
>able to handle this in their fast path. To support labeled and plain IP
>packets in the same tunnel would require the fast path 
>decision based on the
>state of S-bit of the outer header which is problematic with 
>some equipment.


Why is the state of the S-bit important in supporting non-labled ingress
packets?

-Shahram

>In addition, I've heard that one particular vendor would not be able to
>terminate MPLS tunnels unless it arrives with a Null IP label.
>
>Dimitry 
>
>> Tony Li writes:
>> > 
>> > 
>> >  | How does one establish hierarchical tunnels using RSVP-TE?
>> >  |  
>> >  | I know that the label object can be deeper than one 
>> label, but you need mo
>> > re
>> >  | than this to establish hierarchical tunnels.
>> > 
>> > 
>> > A hierarchical tunnel requires the participation of at 
>> least two LSRs.  The
>> > operation of the LSR creating the innermost tunnel is 
>> straightforward and
>> > is unchanged from what has been endlessly discussed here.
>> > 
>> > For an LSR to create an outer tunnel, it simply creates 
>> another tunnel and
>> > specifies MPLS as the L3PID.  It then forwards packets 
>> received on the
>> > inner tunnel by pushing a label for the outer tunnel.  The 
>> RSVP control
>> > traffic for the inner tunnel is also forwarded through the 
>> outer tunnel
>> > after first being encapsulated with a null IP label.
>> > 
>> > Recurse, ad nauseum.
>> > 
>> > Simple, really.  ;-)
>> > 
>> > Tony
>> 
>> 
>> Tony,
>> 
>> Two minor points.  
>> 
>> If the outer tunnel is constrained (by configuration) to accept only
>> inner tunnels with one L3PID, then that L3PID can be placed on the
>> outer tunnel.  If there are optimization possible for a particular
>> L3PID (IP src/dst hash to split loading along the way comes to mind
>> for IPv4) then putting the inner L3PID on the outer tunnel has
>> advantages.
>> 
>> No where have I seen a requirement to put a null label on traffic
>> destined to the egress LSR.  I had been assuming that if the 
>IP packet
>> under the top label has the address of the router ID of the egress
>> under the outer label, then the packet would be delivered to the
>> egress.  If the egress required PHP, then the penultimate LSR would
>> put a null label on the control traffic for the the inner label and
>> the egress would POP the null label and see its own IP address.
>> Otherwise, the egress would see two null labels.
>> 
>> If I'm missing something and/or there will be any interoperability
>> problem with the way I intended to encapsulate control traffic inside
>> the outer label, please tell us about it.
>> 
>> Curtis
>> 
>



From owner-mpls@UU.NET  Mon Jun 12 16:52:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10979
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 16:52:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithr10884;
	Mon, 12 Jun 2000 20:52:18 GMT
Received: by mail-control.mail.uu.net 
	id QQithr17113
	for mpls-outgoing; Mon, 12 Jun 2000 20:51:56 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQithr17108
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 20:51:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQithq13121
	for <mpls@uu.net>; Mon, 12 Jun 2000 16:44:34 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQithq04514
	for <mpls@uu.net>; Mon, 12 Jun 2000 20:44:34 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA01243
	for mpls@uu.net; Mon, 12 Jun 2000 16:44:33 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQithq16466
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 20:44:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithp09381
	for <mpls@UU.NET>; Mon, 12 Jun 2000 16:24:24 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQithp11660
	for <mpls@UU.NET>; Mon, 12 Jun 2000 20:24:19 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA11983;
	Mon, 12 Jun 2000 13:21:40 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <MRH70C08>; Mon, 12 Jun 2000 13:22:19 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40604@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Tony Li'" <tli@Procket.com>, curtis@avici.com
Cc: Bora Akyol <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Mon, 12 Jun 2000 13:22:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Toni,

The Encaps-draft says that the IPV4/6 Explicit Null Labels are only legal if
they are the sole label stack entry. However, in your example the RSVP
messages will have two labels, the outer label and the IPV4/6 Explicit Null
Label. Isn't this a violation of the Encaps-draft requirement?

Regards,
-Shahram

>-----Original Message-----
>From: Tony Li [mailto:tli@Procket.com]
>Sent: Monday, June 12, 2000 1:22 PM
>To: curtis@avici.com
>Cc: Tony Li; Bora Akyol; 'mpls@uu.net'
>Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>
>Curtis,
>
> | If the outer tunnel is constrained (by configuration) to accept only
> | inner tunnels with one L3PID, then that L3PID can be placed on the
> | outer tunnel.  If there are optimization possible for a particular
> | L3PID (IP src/dst hash to split loading along the way comes to mind
> | for IPv4) then putting the inner L3PID on the outer tunnel has
> | advantages.
>
>
>I agree that this is also possible for implementations that 
>want to parse
>up the label stack.
>
>
> | No where have I seen a requirement to put a null label on traffic
> | destined to the egress LSR.
>
>
>The requirement exists if you take the more general approach 
>of specifying
>an outer L3PID of MPLS and then wish to tunnel (otherwise 
>unlabeled) RSVP.
>Under the approach that you've proposed, this would not be necessary.
>
>Tony
>



From owner-mpls@UU.NET  Mon Jun 12 17:04:18 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11258
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 17:04:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiths22876;
	Mon, 12 Jun 2000 21:04:14 GMT
Received: by mail-control.mail.uu.net 
	id QQiths26923
	for mpls-outgoing; Mon, 12 Jun 2000 21:03:41 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiths26650
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 21:03:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQithr15847
	for <mpls@UU.NET>; Mon, 12 Jun 2000 16:58:57 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQithr17330
	for <mpls@UU.NET>; Mon, 12 Jun 2000 20:58:57 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 QAA28994;
	Mon, 12 Jun 2000 16:58:49 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24413;
	Mon, 12 Jun 2000 16:58:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <MR1YQWFN>; Mon, 12 Jun 2000 16:58:49 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CFE49439@whq-msgusr-02.fore.com>
From: "Punj, Arun" <Arun.Punj@marconi.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'curtis@avici.com'"
	 <curtis@avici.com>, Tony Li <tli@Procket.com>
Cc: Bora Akyol <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Mon, 12 Jun 2000 16:58:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I guess the reference is to MPLS label value 0 or 2 or 3, 
as mentioned in draft-ietf-mpls-label-encaps-07

-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Monday, June 12, 2000 3:49 PM
To: 'curtis@avici.com'; Tony Li
Cc: Bora Akyol; 'mpls@uu.net'
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 


Hi,

What is an IP Null Label?

-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@avici.com]
>Sent: Monday, June 12, 2000 10:57 AM
>To: Tony Li
>Cc: Bora Akyol; 'mpls@uu.net'
>Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>
>In message <14657.53536.422247.469955@redd235.procket.com>, 
>Tony Li writes:
>> 
>> 
>>  | How does one establish hierarchical tunnels using RSVP-TE?
>>  |  
>>  | I know that the label object can be deeper than one 
>label, but you need mo
>> re
>>  | than this to establish hierarchical tunnels.
>> 
>> 
>> A hierarchical tunnel requires the participation of at least 
>two LSRs.  The
>> operation of the LSR creating the innermost tunnel is 
>straightforward and
>> is unchanged from what has been endlessly discussed here.
>> 
>> For an LSR to create an outer tunnel, it simply creates 
>another tunnel and
>> specifies MPLS as the L3PID.  It then forwards packets 
>received on the
>> inner tunnel by pushing a label for the outer tunnel.  The 
>RSVP control
>> traffic for the inner tunnel is also forwarded through the 
>outer tunnel
>> after first being encapsulated with a null IP label.
>> 
>> Recurse, ad nauseum.
>> 
>> Simple, really.  ;-)
>> 
>> Tony
>
>
>Tony,
>
>Two minor points.  
>
>If the outer tunnel is constrained (by configuration) to accept only
>inner tunnels with one L3PID, then that L3PID can be placed on the
>outer tunnel.  If there are optimization possible for a particular
>L3PID (IP src/dst hash to split loading along the way comes to mind
>for IPv4) then putting the inner L3PID on the outer tunnel has
>advantages.
>
>No where have I seen a requirement to put a null label on traffic
>destined to the egress LSR.  I had been assuming that if the IP packet
>under the top label has the address of the router ID of the egress
>under the outer label, then the packet would be delivered to the
>egress.  If the egress required PHP, then the penultimate LSR would
>put a null label on the control traffic for the the inner label and
>the egress would POP the null label and see its own IP address.
>Otherwise, the egress would see two null labels.
>
>If I'm missing something and/or there will be any interoperability
>problem with the way I intended to encapsulate control traffic inside
>the outer label, please tell us about it.
>
>Curtis
>


From owner-mpls@UU.NET  Mon Jun 12 17:09:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11340
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 17:09:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiths25202;
	Mon, 12 Jun 2000 21:09:17 GMT
Received: by mail-control.mail.uu.net 
	id QQiths27445
	for mpls-outgoing; Mon, 12 Jun 2000 21:08:41 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiths27440
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 21:08:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiths18221
	for <mpls@uu.net>; Mon, 12 Jun 2000 17:08:14 -0400 (EDT)
Received: from web5104.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5104.mail.yahoo.com [216.115.106.74])
	id QQiths24188
	for <mpls@uu.net>; Mon, 12 Jun 2000 21:08:13 GMT
Message-ID: <20000612210812.16250.qmail@web5104.mail.yahoo.com>
Received: from [169.144.16.187] by web5104.mail.yahoo.com; Mon, 12 Jun 2000 14:08:12 PDT
Date: Mon, 12 Jun 2000 14:08:12 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

On the face of it what you say seems to be correct.

Could it be that draft should be interpreted as:

"As that there should be no more labels below a NULL
label. However, labels could be applied on top
of a NULL label. "




--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
wrote:
> Toni,
> 
> The Encaps-draft says that the IPV4/6 Explicit Null
> Labels are only legal if
> they are the sole label stack entry. However, in
> your example the RSVP
> messages will have two labels, the outer label and
> the IPV4/6 Explicit Null
> Label. Isn't this a violation of the Encaps-draft
> requirement?
> 
> Regards,
> -Shahram
> 
> >-----Original Message-----
> >From: Tony Li [mailto:tli@Procket.com]
> >Sent: Monday, June 12, 2000 1:22 PM
> >To: curtis@avici.com
> >Cc: Tony Li; Bora Akyol; 'mpls@uu.net'
> >Subject: Re: Hierarchical Tunnel Establishment in
> RSVP-TE 
> >
> >
> >
> >Curtis,
> >
> > | If the outer tunnel is constrained (by
> configuration) to accept only
> > | inner tunnels with one L3PID, then that L3PID
> can be placed on the
> > | outer tunnel.  If there are optimization
> possible for a particular
> > | L3PID (IP src/dst hash to split loading along
> the way comes to mind
> > | for IPv4) then putting the inner L3PID on the
> outer tunnel has
> > | advantages.
> >
> >
> >I agree that this is also possible for
> implementations that 
> >want to parse
> >up the label stack.
> >
> >
> > | No where have I seen a requirement to put a null
> label on traffic
> > | destined to the egress LSR.
> >
> >
> >The requirement exists if you take the more general
> approach 
> >of specifying
> >an outer L3PID of MPLS and then wish to tunnel
> (otherwise 
> >unlabeled) RSVP.
> >Under the approach that you've proposed, this would
> not be necessary.
> >
> >Tony
> >
> 


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Mon Jun 12 17:12:52 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11393
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 17:12:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiths00976;
	Mon, 12 Jun 2000 21:12:48 GMT
Received: by mail-control.mail.uu.net 
	id QQiths27740
	for mpls-outgoing; Mon, 12 Jun 2000 21:12:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiths27735
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 21:12:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiths18451
	for <mpls@UU.net>; Mon, 12 Jun 2000 17:11:17 -0400 (EDT)
Received: from solen.ce.chalmers.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: solen.ce.chalmers.se [129.16.20.244])
	id QQiths29530
	for <mpls@UU.net>; Mon, 12 Jun 2000 21:11:16 GMT
Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199])
	by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id XAA27761;
	Mon, 12 Jun 2000 23:11:15 +0200 (MET DST)
From: Florian-Daniel Otel <otel@ce.chalmers.se>
Received: (from otel@localhost)
	by rasputin.ce.chalmers.se (8.8.8/8.8.8) id XAA05485;
	Mon, 12 Jun 2000 23:11:15 +0200 (MEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14661.20979.88487.278221@rasputin.ce.chalmers.se>
Date: Mon, 12 Jun 2000 23:11:15 +0200 (MEST)
To: curtis@avici.com
Cc: mpls@UU.NET
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-Reply-To: <200006121401.KAA20223@curtis-lt.avici.com>
References: <14658.3783.932849.484837@rasputin.ce.chalmers.se>
	<200006121401.KAA20223@curtis-lt.avici.com>
X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid
Reply-To: otel@ce.chalmers.se
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


> In message <14658.3783.932849.484837@rasputin.ce.chalmers.se>, Florian-Daniel O
> tel writes:
>> 
>> 
>> Curtis,
>> 
>> I was pondering a bit about you LQM proposal. AFAIK PPP LQM requires
>> that you have special LQM payload, signaled as such by the LCP
>> Protocol/PayloadID header field  (I don't recall right now the exact
>> name). Bringing this to MPLS, you're proposing:
>> -To signal LQM packet via some reserved (read: OAM) label. E.g. ala
>> 'modes' proposed by Ben.
>> -Payload carrying e.g. LSP counters. Well, how do you propose
>> to have this ? Keeping the same label stack and putting a 'special'
>> payload (oh Lord.....!!) ?  Extending ICMP w/ a special packet type to
>> carry LQM info ? In both these cases don't you need to pop (and save)
>> the _whole_ label stack ?!! How about the reverse (i.e. response)
>> traffic ? 
>> 
>> Best regards,
>> 
>> Florian.
>> 
>> P.S. I took this 'rather'  off-list as both issues might be a question
>> of personal understanding  and sound really scary... :)


> To signal LQM you would use a reserved label and a special payload.
> The payload would identify an LSP and contain the exact count of
> packets and octets sent on that LSP at the time the LQM packet was
> sent and at the time the packet was received.  To be absolutely
> accurate, the counters would have to be sampled by hardware before
> inserting the packet into the data stream and before diverting the
> packet to software on the receiving side.

> This does require hardware change in order to be accurate.  It
> requires that counter be moved into packet payload when a specific
> label is encountered at an ingress and egress.

> An inaccurate measurement can be made by placing the counters into the
> packet in software at the ingress and sampling the counters at the
> egress after the packet was diverted.  LQM works by subtracting the
> results from two samplings.  If the queue lengths differ in the
> samplings, the differences will have some inaccuracy.  If the
> samplings are 1 second apart, and the maximum queue depth is 100ms,
> the error could be at most 10%.  This is not sufficient for loss
> measurement, but fine for connectivity (if hardware had a problem but
> LQM packets arrived intact, the sending counters would advance and the
> receive counters would not.  Loss measurements over the entire LSP
> could be made by subtracting samplings farther apart, for example 600
> seconds (10 minutes) would be expected to be accurate to at least 0.1%
> (sample interval 6,000 times the maximum queue depth).  This would be
> sufficient for most (but not all) SLAs and much more accurate than
> trying to probe the network with pings or lots of OAM packets.

> For PPP LQM there could only be forward traffic, no reverse traffic.
> Only the egress would know what the loss rate was.  I'm assuming that
> the NMS would sample the counters directly or that the egress would
> generate traps if connectivity was lost or loss exceeded threshholds.

> Curtis


> ps- The suggestion that LQM be divorced from PPP and made more
> generally available is not a new one.  It goes back as far as 1995 and
> maybe earlier.  The NSFNET played around with a user land application
> known as PMLQM (poor mans LQM, because it had no support in the
> hardware) for use with non-PPP serial links.  The UDP packet load was
> too high for a host to send probe packets and access to counters was
> slow enough (could be inaccurate by seconds) that the work never
> progress beyond the NSF test network.  In that case the sampling of
> counters by the router's own control software was sufficiently skewed
> in time that it was decided to stick to subtracting counters obtained
> from SNMP.  Some time later there was discussion of putting some form
> of LQM into IP as an IP header option such that loss over ATM VCs
> could be accurately measured (since cell loss rates didn't translate
> into packet loss due to "packet shredding" effects).


Well, I'll put it bluntly (as I almost always tend to do):

IMHO this sounds too complicated, requiring hardw. assistance (as yourself
mentioned) and lot of overhead processing. The claimed payoff ?
Millisecond resolution per LSP (unidirectional) for packet counters. 


What you are proposing reminds me the story behind IP TTL field:
Remember that it was supposed to be decremented both at ingress and
egress and now IPv6 recognized the common practice  and made it a
simple hop count ? Well, you can argue that this  OAM we're talking
about and the overhead for this type of traffic is acceptable. But yet
again, my whole point was that (AFAIG) people tend to cut corners when
it comes to hairy (read: requiring extensive processing) things. So,
as Neil also noted, this seems to be  over-engineering.


With kind regards,

Florian.


P.S. Forgot to mention: Assuming that you get this done and you do get
millisecond (or whatever. Read: _small_) resolution packet counters,
using this information e.g. to compute jitter, packet delay, etc. is
computationally expensive and i cannot tell how relevant it would be
relative to the transmission ambiguities (e.g. relative queuing time)
at each intermediate hop. 


From owner-mpls@UU.NET  Mon Jun 12 17:16:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11427
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 17:16:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitht01242;
	Mon, 12 Jun 2000 21:16:07 GMT
Received: by mail-control.mail.uu.net 
	id QQitht28065
	for mpls-outgoing; Mon, 12 Jun 2000 21:15:43 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitht28058
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 21:15:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitht19103
	for <mpls@uu.net>; Mon, 12 Jun 2000 17:15:09 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitht00344
	for <mpls@uu.net>; Mon, 12 Jun 2000 21:15:08 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA07448
	for mpls@uu.net; Mon, 12 Jun 2000 17:15:07 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiths27859
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 21:14:35 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiths19344
	for <mpls@UU.net>; Mon, 12 Jun 2000 17:14:14 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQiths02447
	for <mpls@UU.net>; Mon, 12 Jun 2000 21:14:13 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA15601
	for <mpls@UU.net>; Mon, 12 Jun 2000 14:14:13 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <MRH70DZL>; Mon, 12 Jun 2000 14:14:51 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40606@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'mpls@UU.net'" <mpls@UU.NET>
Subject: FW: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Mon, 12 Jun 2000 14:14:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Chatur,

I don't think so. Since in case of label= 1, the draft says:

"A value of 1 represents the "Router Alert Label".  This label value is
legal anywhere in the label stack except at the bottom."

So in case of Label=2,4 they could have written: "nowhere except at the
bottom". 

-Shahram

>-----Original Message-----
>From: Chatur sharp [mailto:chatur_b@yahoo.com]
>Sent: Monday, June 12, 2000 5:08 PM
>To: Shahram Davari
>Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>On the face of it what you say seems to be correct.
>
>Could it be that draft should be interpreted as:
>
>"As that there should be no more labels below a NULL
>label. However, labels could be applied on top
>of a NULL label. "
>
>
>
>
>--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
>wrote:
>> Toni,
>> 
>> The Encaps-draft says that the IPV4/6 Explicit Null
>> Labels are only legal if
>> they are the sole label stack entry. However, in
>> your example the RSVP
>> messages will have two labels, the outer label and
>> the IPV4/6 Explicit Null
>> Label. Isn't this a violation of the Encaps-draft
>> requirement?
>> 
>> Regards,
>> -Shahram
>> 
>> >-----Original Message-----
>> >From: Tony Li [mailto:tli@Procket.com]
>> >Sent: Monday, June 12, 2000 1:22 PM
>> >To: curtis@avici.com
>> >Cc: Tony Li; Bora Akyol; 'mpls@uu.net'
>> >Subject: Re: Hierarchical Tunnel Establishment in
>> RSVP-TE 
>> >
>> >
>> >
>> >Curtis,
>> >
>> > | If the outer tunnel is constrained (by
>> configuration) to accept only
>> > | inner tunnels with one L3PID, then that L3PID
>> can be placed on the
>> > | outer tunnel.  If there are optimization
>> possible for a particular
>> > | L3PID (IP src/dst hash to split loading along
>> the way comes to mind
>> > | for IPv4) then putting the inner L3PID on the
>> outer tunnel has
>> > | advantages.
>> >
>> >
>> >I agree that this is also possible for
>> implementations that 
>> >want to parse
>> >up the label stack.
>> >
>> >
>> > | No where have I seen a requirement to put a null
>> label on traffic
>> > | destined to the egress LSR.
>> >
>> >
>> >The requirement exists if you take the more general
>> approach 
>> >of specifying
>> >an outer L3PID of MPLS and then wish to tunnel
>> (otherwise 
>> >unlabeled) RSVP.
>> >Under the approach that you've proposed, this would
>> not be necessary.
>> >
>> >Tony
>> >
>> 
>
>
>=====
>I am willing to learn,  if you care to teach.
>I am willing to teach, if you care to learn.
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Photos -- now, 100 FREE prints!
>http://photos.yahoo.com
>



From owner-mpls@UU.NET  Mon Jun 12 18:15:44 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12188
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 18:15:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQithx03729;
	Mon, 12 Jun 2000 22:15:35 GMT
Received: by mail-control.mail.uu.net 
	id QQithx11425
	for mpls-outgoing; Mon, 12 Jun 2000 22:15:12 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQithx11420
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 22:15:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQithw29158
	for <mpls@uu.net>; Mon, 12 Jun 2000 18:14:50 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQithw03000
	for <mpls@uu.net>; Mon, 12 Jun 2000 22:14:48 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA14780
	for mpls@uu.net; Mon, 12 Jun 2000 18:14:48 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQithw11225
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 22:14:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQithw00319
	for <mpls@UU.NET>; Mon, 12 Jun 2000 18:14:21 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQithw11072
	for <mpls@UU.NET>; Mon, 12 Jun 2000 22:14:20 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id PAA19356;
	Mon, 12 Jun 2000 15:12:14 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <MRH701SW>; Mon, 12 Jun 2000 15:12:53 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40607@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Tony Li'" <tli@Procket.com>, Bora Akyol <akyol@pluris.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE
Date: Mon, 12 Jun 2000 15:12:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Tony,

Since an S-bit=0 indicates that the encapsulated packet is an MPLS packet,
can't we conclude that L3PID is used only for the identification of L3? In
other words it is possible to tunnel both labeled and unlabeled packets
through the same MPLS tunnel (i.e., with the same outer label)?

If this is true then you don't need to set the L3PID=MPLS for the outer
tunnel. Instead you can set the L3PID=IP and use the same tunnel for the
tunneled MPLS packets as well as tunneled RSVP messages. 


Regards,
-Shahram 

>-----Original Message-----
>From: Tony Li [mailto:tli@Procket.com]
>Sent: Saturday, June 10, 2000 1:25 AM
>To: Bora Akyol
>Cc: 'mpls@uu.net'
>Subject: Hierarchical Tunnel Establishment in RSVP-TE
>
>
>
>
> | How does one establish hierarchical tunnels using RSVP-TE?
> |  
> | I know that the label object can be deeper than one label, 
>but you need more
> | than this to establish hierarchical tunnels.
>
>
>A hierarchical tunnel requires the participation of at least 
>two LSRs.  The
>operation of the LSR creating the innermost tunnel is 
>straightforward and
>is unchanged from what has been endlessly discussed here.
>
>For an LSR to create an outer tunnel, it simply creates 
>another tunnel and
>specifies MPLS as the L3PID.  It then forwards packets received on the
>inner tunnel by pushing a label for the outer tunnel.  The RSVP control
>traffic for the inner tunnel is also forwarded through the outer tunnel
>after first being encapsulated with a null IP label.
>
>Recurse, ad nauseum.
>
>Simple, really.  ;-)
>
>Tony
>



From owner-mpls@UU.NET  Mon Jun 12 19:04:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12825
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 19:04:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitia10930;
	Mon, 12 Jun 2000 23:04:47 GMT
Received: by mail-control.mail.uu.net 
	id QQitia23188
	for mpls-outgoing; Mon, 12 Jun 2000 23:04:19 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitia23183
	for <mpls@mail-control.mail.uu.net>; Mon, 12 Jun 2000 23:04:16 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitia05729
	for <mpls@UU.NET>; Mon, 12 Jun 2000 19:04:08 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQitia10347
	for <mpls@UU.NET>; Mon, 12 Jun 2000 23:04:07 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCCSJV>; Mon, 12 Jun 2000 16:10:09 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690773@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Tony Li'"
	 <tli@Procket.com>, Bora Akyol <akyol@pluris.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE
Date: Mon, 12 Jun 2000 16:10:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram/Tony,

	I think we may be glossing over some of the
complexities in this discussion.

	In the diagram given earlier:

A -- B -.           .- E -- F   
         `- C -- D -'             

We want to create an outer tunnel from B to E to
transport MPLS labeled packets in the inner tunnel
from A to F.  Two sets of RSVP-TE messages would be
required: those going from A to F (the inner tunnel) 
and those going from B to E (the outer tunnel).  The
RSVP-TE messages associated with the inner tunnel 
would be transported using the labels associated with
the outer tunnel in going from B to E. The RSVP-TE
messages associated with the outer tunnel would be
either transported using raw IP or using LSP(s) with
E (and B) as LSP destinations - in other words, yet
another set of LSPs.

	For RSVP-TE messages being used to support the
inner tunnel, Shahram is correct - no special label
is needed by E.  This is because E is the egress for
the outer tunnel and either D will pop the label for
the outer tunnel, or E will.  Whether D is asked to
do a PHP for the outer tunnel or not depends on the
capabilities of D as an LSR/LER.  Whether or not an
explicit NULL label is required by E depends on the
capabilities of E.  For example, for some traffic 
going through the outer tunnel, E may choose to ask
B to do a PHP for an inner tunnel (yet another one)
that - for instance - goes from A to E.  This would
also produce IP encapsulated packets inside the outer
tunnel LSP.  If LSR D is doing PHP for the outer 
tunnel, it must be able to distinguish when it is 
popping the last label and when it is not so that it 
will produce the correct L2 encapsulation for the 
link from D to E.  Once it has done this, then E will 
be able to demux labeled and unlabeled traffic 
received from D.

	Both simpler and more complex than discussion
seemed to make it out to be...

--
Eric Gray

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Monday, June 12, 2000 3:13 PM
> To: 'Tony Li'; Bora Akyol
> Cc: 'mpls@uu.net'
> Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE
> 
> 
> Hi Tony,
> 
> Since an S-bit=0 indicates that the encapsulated packet is an 
> MPLS packet,
> can't we conclude that L3PID is used only for the 
> identification of L3? In
> other words it is possible to tunnel both labeled and 
> unlabeled packets
> through the same MPLS tunnel (i.e., with the same outer label)?
> 
> If this is true then you don't need to set the L3PID=MPLS for 
> the outer
> tunnel. Instead you can set the L3PID=IP and use the same 
> tunnel for the
> tunneled MPLS packets as well as tunneled RSVP messages. 
> 
> 
> Regards,
> -Shahram 
> 
> >-----Original Message-----
> >From: Tony Li [mailto:tli@Procket.com]
> >Sent: Saturday, June 10, 2000 1:25 AM
> >To: Bora Akyol
> >Cc: 'mpls@uu.net'
> >Subject: Hierarchical Tunnel Establishment in RSVP-TE
> >
> >
> >
> >
> > | How does one establish hierarchical tunnels using RSVP-TE?
> > |  
> > | I know that the label object can be deeper than one label, 
> >but you need more
> > | than this to establish hierarchical tunnels.
> >
> >
> >A hierarchical tunnel requires the participation of at least 
> >two LSRs.  The
> >operation of the LSR creating the innermost tunnel is 
> >straightforward and
> >is unchanged from what has been endlessly discussed here.
> >
> >For an LSR to create an outer tunnel, it simply creates 
> >another tunnel and
> >specifies MPLS as the L3PID.  It then forwards packets 
> received on the
> >inner tunnel by pushing a label for the outer tunnel.  The 
> RSVP control
> >traffic for the inner tunnel is also forwarded through the 
> outer tunnel
> >after first being encapsulated with a null IP label.
> >
> >Recurse, ad nauseum.
> >
> >Simple, really.  ;-)
> >
> >Tony
> >
> 


From owner-mpls@UU.NET  Mon Jun 12 20:28:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13445
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 20:28:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitif00749;
	Tue, 13 Jun 2000 00:28:49 GMT
Received: by mail-control.mail.uu.net 
	id QQitif07442
	for mpls-outgoing; Tue, 13 Jun 2000 00:28:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitif07437
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 00:28:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitif18327
	for <mpls@uu.net>; Mon, 12 Jun 2000 20:28:11 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitif01133
	for <mpls@uu.net>; Tue, 13 Jun 2000 00:28:09 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA25560
	for mpls@uu.net; Mon, 12 Jun 2000 20:28:03 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitif07424
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 00:27:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitif18232
	for <mpls@UU.NET>; Mon, 12 Jun 2000 20:27:13 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQitif00612
	for <mpls@UU.NET>; Tue, 13 Jun 2000 00:27:13 GMT
Received: from pluris.com (volsung.pluris.com [172.16.50.19])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA23274;
	Mon, 12 Jun 2000 17:27:10 -0700 (PDT)
Message-ID: <39457FD8.D2801D35@pluris.com>
Date: Mon, 12 Jun 2000 17:27:04 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <EGray@zaffire.com>
CC: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Tony Li'" <tli@Procket.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <9A564CC874B5D3118FB9009027B0A662690773@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I would agree with Eric here.

Since I started this thread, about three alternate (maybe complementary
approaches) to doing hierarchical tunnels with RSVP-TE got proposed:

1) Tony Li's email suggested that one can use RSVP-TE by tunneling the
RSVP messages between A and F via the tunnel between B&E.

2) There was a suggestion of using directed LDP over the first tunnel to
establish the second tunnel.

3) And finally a reference to draft-kompella-*** came out, which I admit
I haven't read yet, but will probably do tonight.

I think this topic deserves farther discussion. We are NOT writing a
research paper here, but trying to produce working, interoperable code.
So those that have this working in a network, lab, demo etc; please come
forward and speak up.

Do we need to have an informational ID on this?

Bora


Eric Gray wrote:

> Shahram/Tony,
>
>         I think we may be glossing over some of the
> complexities in this discussion.
>
>         In the diagram given earlier:
>
> A -- B -.           .- E -- F
>          `- C -- D -'
>
> We want to create an outer tunnel from B to E to
> transport MPLS labeled packets in the inner tunnel
> from A to F.  Two sets of RSVP-TE messages would be
> required: those going from A to F (the inner tunnel)
> and those going from B to E (the outer tunnel).  The
> RSVP-TE messages associated with the inner tunnel
> would be transported using the labels associated with
> the outer tunnel in going from B to E. The RSVP-TE
> messages associated with the outer tunnel would be
> either transported using raw IP or using LSP(s) with
> E (and B) as LSP destinations - in other words, yet
> another set of LSPs.
>
>         For RSVP-TE messages being used to support the
> inner tunnel, Shahram is correct - no special label
> is needed by E.  This is because E is the egress for
> the outer tunnel and either D will pop the label for
> the outer tunnel, or E will.  Whether D is asked to
> do a PHP for the outer tunnel or not depends on the
> capabilities of D as an LSR/LER.  Whether or not an
> explicit NULL label is required by E depends on the
> capabilities of E.  For example, for some traffic
> going through the outer tunnel, E may choose to ask
> B to do a PHP for an inner tunnel (yet another one)
> that - for instance - goes from A to E.  This would
> also produce IP encapsulated packets inside the outer
> tunnel LSP.  If LSR D is doing PHP for the outer
> tunnel, it must be able to distinguish when it is
> popping the last label and when it is not so that it
> will produce the correct L2 encapsulation for the
> link from D to E.  Once it has done this, then E will
> be able to demux labeled and unlabeled traffic
> received from D.
>
>         Both simpler and more complex than discussion
> seemed to make it out to be...
>
> --
> Eric Gray
>
> > -----Original Message-----
> > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > Sent: Monday, June 12, 2000 3:13 PM
> > To: 'Tony Li'; Bora Akyol
> > Cc: 'mpls@uu.net'
> > Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE
> >
> >
> > Hi Tony,
> >
> > Since an S-bit=0 indicates that the encapsulated packet is an
> > MPLS packet,
> > can't we conclude that L3PID is used only for the
> > identification of L3? In
> > other words it is possible to tunnel both labeled and
> > unlabeled packets
> > through the same MPLS tunnel (i.e., with the same outer label)?
> >
> > If this is true then you don't need to set the L3PID=MPLS for
> > the outer
> > tunnel. Instead you can set the L3PID=IP and use the same
> > tunnel for the
> > tunneled MPLS packets as well as tunneled RSVP messages.
> >
> >
> > Regards,
> > -Shahram
> >
> > >-----Original Message-----
> > >From: Tony Li [mailto:tli@Procket.com]
> > >Sent: Saturday, June 10, 2000 1:25 AM
> > >To: Bora Akyol
> > >Cc: 'mpls@uu.net'
> > >Subject: Hierarchical Tunnel Establishment in RSVP-TE
> > >
> > >
> > >
> > >
> > > | How does one establish hierarchical tunnels using RSVP-TE?
> > > |
> > > | I know that the label object can be deeper than one label,
> > >but you need more
> > > | than this to establish hierarchical tunnels.
> > >
> > >
> > >A hierarchical tunnel requires the participation of at least
> > >two LSRs.  The
> > >operation of the LSR creating the innermost tunnel is
> > >straightforward and
> > >is unchanged from what has been endlessly discussed here.
> > >
> > >For an LSR to create an outer tunnel, it simply creates
> > >another tunnel and
> > >specifies MPLS as the L3PID.  It then forwards packets
> > received on the
> > >inner tunnel by pushing a label for the outer tunnel.  The
> > RSVP control
> > >traffic for the inner tunnel is also forwarded through the
> > outer tunnel
> > >after first being encapsulated with a null IP label.
> > >
> > >Recurse, ad nauseum.
> > >
> > >Simple, really.  ;-)
> > >
> > >Tony
> > >
> >




From owner-mpls@UU.NET  Mon Jun 12 20:40:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13611
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 20:40:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitig08597;
	Tue, 13 Jun 2000 00:40:10 GMT
Received: by mail-control.mail.uu.net 
	id QQitig07904
	for mpls-outgoing; Tue, 13 Jun 2000 00:39:50 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitig07899
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 00:39:43 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitig16974
	for <mpls@uu.net>; Mon, 12 Jun 2000 20:39:26 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitig07972
	for <mpls@uu.net>; Tue, 13 Jun 2000 00:39:25 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA26547
	for mpls@uu.net; Mon, 12 Jun 2000 20:39:24 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitig07876
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 00:38:58 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitig19752
	for <mpls@UU.NET>; Mon, 12 Jun 2000 20:38:46 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQitig08103
	for <mpls@UU.NET>; Tue, 13 Jun 2000 00:38:45 GMT
Received: from localhost (yakov@localhost)
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA00366;
	Mon, 12 Jun 2000 17:37:17 -0700 (PDT)
Message-Id: <200006130037.RAA00366@omega.cisco.com>
To: Bora Akyol <akyol@pluris.com>
cc: Eric Gray <EGray@zaffire.com>,
        "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Tony Li'" <tli@Procket.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Mon, 12 Jun 2000 17:27:04 PDT."
             <39457FD8.D2801D35@pluris.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <363.960856636.1@cisco.com>
Date: Mon, 12 Jun 2000 17:37:17 -0700
From: Yakov Rekhter <yakov@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Bora,

> Since I started this thread, about three alternate (maybe complementary
> approaches) to doing hierarchical tunnels with RSVP-TE got proposed:
> 
> 1) Tony Li's email suggested that one can use RSVP-TE by tunneling the
> RSVP messages between A and F via the tunnel between B&E.
> 
> 2) There was a suggestion of using directed LDP over the first tunnel to
> establish the second tunnel.
> 
> 3) And finally a reference to draft-kompella-*** came out, which I admit
> I haven't read yet, but will probably do tonight.
> 
> I think this topic deserves farther discussion. We are NOT writing a
> research paper here, but trying to produce working, interoperable code.
> So those that have this working in a network, lab, demo etc; please come
> forward and speak up.
> 
> Do we need to have an informational ID on this?

If yes, then one way to address this would be extract the relevant
parts out of draft-kompella-*** and turn it into an Internet Draft on
its own.

Yakov.



From owner-mpls@UU.NET  Mon Jun 12 20:43:46 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13665
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 20:43:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitig10925;
	Tue, 13 Jun 2000 00:43:42 GMT
Received: by mail-control.mail.uu.net 
	id QQitig08130
	for mpls-outgoing; Tue, 13 Jun 2000 00:43:10 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitig08125
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 00:42:55 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitig20359
	for <mpls@uu.net>; Mon, 12 Jun 2000 20:42:38 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitig11211
	for <mpls@uu.net>; Tue, 13 Jun 2000 00:42:38 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA27118
	for mpls@uu.net; Mon, 12 Jun 2000 20:42:37 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitig08088
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 00:41:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitig20268
	for <mpls@UU.NET>; Mon, 12 Jun 2000 20:41:37 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQitig09722
	for <mpls@UU.NET>; Tue, 13 Jun 2000 00:41:37 GMT
Received: from pluris.com (volsung.pluris.com [172.16.50.19])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA23610;
	Mon, 12 Jun 2000 17:41:28 -0700 (PDT)
Message-ID: <39458336.75FF6B35@pluris.com>
Date: Mon, 12 Jun 2000 17:41:27 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yakov Rekhter <yakov@cisco.com>
CC: Eric Gray <EGray@zaffire.com>,
        "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Tony Li'" <tli@Procket.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <200006130037.RAA00366@omega.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I would agree to a document that would result in a clear understanding of this
subject. I would also agree to help edit/co-author it (what is 1 less hour of
sleep per night anyway ;-)

Bora


Yakov Rekhter wrote:

> Bora,
>
> > Since I started this thread, about three alternate (maybe complementary
> > approaches) to doing hierarchical tunnels with RSVP-TE got proposed:
> >
> > 1) Tony Li's email suggested that one can use RSVP-TE by tunneling the
> > RSVP messages between A and F via the tunnel between B&E.
> >
> > 2) There was a suggestion of using directed LDP over the first tunnel to
> > establish the second tunnel.
> >
> > 3) And finally a reference to draft-kompella-*** came out, which I admit
> > I haven't read yet, but will probably do tonight.
> >
> > I think this topic deserves farther discussion. We are NOT writing a
> > research paper here, but trying to produce working, interoperable code.
> > So those that have this working in a network, lab, demo etc; please come
> > forward and speak up.
> >
> > Do we need to have an informational ID on this?
>
> If yes, then one way to address this would be extract the relevant
> parts out of draft-kompella-*** and turn it into an Internet Draft on
> its own.
>
> Yakov.




From owner-mpls@UU.NET  Mon Jun 12 23:38:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17255
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 23:38:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitis13401;
	Tue, 13 Jun 2000 03:38:01 GMT
Received: by mail-control.mail.uu.net 
	id QQitis17138
	for mpls-outgoing; Tue, 13 Jun 2000 03:37:41 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitis17133
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 03:37:37 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitis07488
	for <mpls@UU.NET>; Mon, 12 Jun 2000 23:37:29 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitis02883
	for <mpls@UU.NET>; Tue, 13 Jun 2000 03:37:28 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id XAA11487; Mon, 12 Jun 2000 23:37:28 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id XAA21264;
	Mon, 12 Jun 2000 23:37:34 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006130337.XAA21264@curtis-lt.avici.com>
To: Peter Willis <pjw@ip-engineering.bt.com>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-reply-to: Your message of "Mon, 12 Jun 2000 17:17:34 BST."
             <200006121617.RAA18203@celiborn.ip-engineering.bt.com> 
Date: Mon, 12 Jun 2000 23:37:34 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200006121617.RAA18203@celiborn.ip-engineering.bt.com>, Peter Willis
 writes:
> 
> Lets try counting packets in and out of the LSP, will that work?
> No it won't! It may be that the customer only uses that LSP once a month,
>  so with no traffic its difficult to tell the LSP is down. So you're going 
> to get a fault report from the customer when they try to use it on the last
> midnight of the month.

If exactly zero packets are sent, then a small number of probe packets
can be added to make sure the traffic is non-zero.

If so, then perhaps a "data-sink" label is needed just to allow probe
packets to be silently discarded after the last label being measured
is popped.

Curtis



From owner-mpls@UU.NET  Mon Jun 12 23:42:21 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17300
	for <mpls-archive@lists.ietf.org>; Mon, 12 Jun 2000 23:42:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitis16206;
	Tue, 13 Jun 2000 03:42:18 GMT
Received: by mail-control.mail.uu.net 
	id QQitis17497
	for mpls-outgoing; Tue, 13 Jun 2000 03:41:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitis17491
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 03:41:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitis08003
	for <mpls@UU.net>; Mon, 12 Jun 2000 23:41:22 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitis06221
	for <mpls@UU.net>; Tue, 13 Jun 2000 03:41:21 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id XAA11729; Mon, 12 Jun 2000 23:41:20 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id XAA21280;
	Mon, 12 Jun 2000 23:41:42 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006130341.XAA21280@curtis-lt.avici.com>
To: otel@ce.chalmers.se
cc: curtis@avici.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?) 
In-reply-to: Your message of "Mon, 12 Jun 2000 23:11:15 +0200."
             <14661.20979.88487.278221@rasputin.ce.chalmers.se> 
Date: Mon, 12 Jun 2000 23:41:42 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <14661.20979.88487.278221@rasputin.ce.chalmers.se>, Florian-Daniel O
tel writes:
> 
> > An inaccurate measurement can be made by placing the counters into the
> > packet in software at the ingress and sampling the counters at the
> > egress after the packet was diverted.  LQM works by subtracting the
> > results from two samplings.  If the queue lengths differ in the
> > samplings, the differences will have some inaccuracy.  If the
> > samplings are 1 second apart, and the maximum queue depth is 100ms,
> > the error could be at most 10%.  This is not sufficient for loss
> > measurement, but fine for connectivity (if hardware had a problem but
> > LQM packets arrived intact, the sending counters would advance and the
> > receive counters would not.  Loss measurements over the entire LSP
> > could be made by subtracting samplings farther apart, for example 600
> > seconds (10 minutes) would be expected to be accurate to at least 0.1%
> > (sample interval 6,000 times the maximum queue depth).  This would be
> > sufficient for most (but not all) SLAs and much more accurate than
> > trying to probe the network with pings or lots of OAM packets.
> 
> Well, I'll put it bluntly (as I almost always tend to do):
> 
> IMHO this sounds too complicated, requiring hardw. assistance (as yourself
> mentioned) and lot of overhead processing. The claimed payoff ?
> Millisecond resolution per LSP (unidirectional) for packet counters. 

The paragraph above explains how to get reasonable measurements
without hardware assist.

The benefit is very accurate loss measurements without adding probe
traffic.

> What you are proposing reminds me the story behind IP TTL field:
> Remember that it was supposed to be decremented both at ingress and
> egress and now IPv6 recognized the common practice  and made it a
> simple hop count ? Well, you can argue that this  OAM we're talking
> about and the overhead for this type of traffic is acceptable. But yet
> again, my whole point was that (AFAIG) people tend to cut corners when
> it comes to hairy (read: requiring extensive processing) things. So,
> as Neil also noted, this seems to be  over-engineering.

That leaves us with just a single OAM packet type, a continuity probe.

Curtis


From owner-mpls@UU.NET  Tue Jun 13 00:07:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17490
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 00:07:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitiu25178;
	Tue, 13 Jun 2000 04:07:10 GMT
Received: by mail-control.mail.uu.net 
	id QQitiu28700
	for mpls-outgoing; Tue, 13 Jun 2000 04:06:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitiu28694
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 04:06:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitiu15197
	for <mpls@UU.NET>; Tue, 13 Jun 2000 00:06:20 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitiu24444
	for <mpls@UU.NET>; Tue, 13 Jun 2000 04:06:19 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id AAA12939; Tue, 13 Jun 2000 00:06:18 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id AAA21352;
	Tue, 13 Jun 2000 00:06:39 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006130406.AAA21352@curtis-lt.avici.com>
To: Dimitry Haskin <dhaskin@nexabit.com>
cc: curtis@avici.com, Tony Li <tli@Procket.com>, Bora Akyol <akyol@pluris.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Mon, 12 Jun 2000 13:19:01 EDT."
             <BAC9CCF04FEED311BD1D00062950ABB14ED82B@bandito.nexabit.com> 
Date: Tue, 13 Jun 2000 00:06:39 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <BAC9CCF04FEED311BD1D00062950ABB14ED82B@bandito.nexabit.com>, Dimitr
y Haskin writes:
> Curtis,
> 
> If I read you correctly, you're implying that both labeled and unlabeled IP
> packets are encapsulated into the outer tunnel, i.e. the RSVP control
> traffic is sent with a single MPLS header of outer tunnel. Is it correct? If
> so, this is fine except that, as far as I know, some MPLS vendors (note that
> it does not apply to the equipment I am most familiar with ;) would not be
> able to handle this in their fast path. To support labeled and plain IP
> packets in the same tunnel would require the fast path decision based on the
> state of S-bit of the outer header which is problematic with some equipment.
> In addition, I've heard that one particular vendor would not be able to
> terminate MPLS tunnels unless it arrives with a Null IP label.
> 
> Dimitry 


Yes, this is what I meant.  The L3PID simply indicates what is under
the label stack, not what is under the top label.

It sounds like there needs to be some wording added to the drafts to
indicate how to deal with equipment that is limited in this way.  In
particular, draft-ietf-mpls-rsvp-lsp-tunnel-05.txt should have some
means to signal back to the ingress these limitations, or if we want
to be backward compatible with equipment that has these limitations,
we can just make the limitation the default and signal lack of this
limitation.  A sub-TLV in the IGP would be fine since it is not a per
LSP limitation but a per interface (assuming someone might make newer
interfaces that remove the limitation).

It would be quite easy to set up an outer LSP so that the inner
control traffic got a null label.  Always putting a null label over an
IP packet that is being used as control for the inner tunnel is
slightly wasteful, but not a big deal.

Does this means that one (or both) of those routers can't accept an
L3PID that indicates what is under the entire label stack?

Curtis


From owner-mpls@UU.NET  Tue Jun 13 00:18:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17533
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 00:18:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitiv08357;
	Tue, 13 Jun 2000 04:17:58 GMT
Received: by mail-control.mail.uu.net 
	id QQitiv29524
	for mpls-outgoing; Tue, 13 Jun 2000 04:17:41 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitiv29519
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 04:17:33 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitiv16785
	for <mpls@UU.NET>; Tue, 13 Jun 2000 00:17:20 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitiv03054
	for <mpls@UU.NET>; Tue, 13 Jun 2000 04:17:20 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id AAA13537; Tue, 13 Jun 2000 00:17:11 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id AAA21388;
	Tue, 13 Jun 2000 00:17:18 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006130417.AAA21388@curtis-lt.avici.com>
To: Chatur sharp <chatur_b@yahoo.com>
cc: mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Mon, 12 Jun 2000 11:37:09 PDT."
             <20000612183709.27103.qmail@web5102.mail.yahoo.com> 
Date: Tue, 13 Jun 2000 00:17:18 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <20000612183709.27103.qmail@web5102.mail.yahoo.com>, Chatur sharp wr
ites:
> 
> Hi
> I had this doubt after reading 2.1.4.b of
> draft-ietf-mpls-label-encaps-07:
> 
> [ it has expired, but no replacement yet ???, ditto
> for MPLS ARCH document.. ]
> [text from draft]
> .....
> 
> The operation to be performed on the label stack
> before 
> forwarding; this operation may be to replace the ....
> ....
> ....
> 
> From this paragraph it would seem that the list of
> operations allowed is:
> 
> 1. Swap
> 2. Pop
> 3. Replace the top label with one or more additional
>    entries on the stack. 
> 
> Does that mean that two pops cannot be performed ?
> Surely this cannot be the case. Right ?
> 
> thanks
> C.


Two POPs are needed to terminate a VPN tunnel.  Three might be needed
if the outer tunnel on the VPN took its last hop through a FA-PSC.

Curtis


From owner-mpls@UU.NET  Tue Jun 13 02:59:18 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00063
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 02:59:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitjf02295;
	Tue, 13 Jun 2000 06:59:11 GMT
Received: by mail-control.mail.uu.net 
	id QQitjf26883
	for mpls-outgoing; Tue, 13 Jun 2000 06:58:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitjf26878
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 06:58:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitjf05067
	for <mpls@uu.net>; Tue, 13 Jun 2000 02:58:44 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQitjf01932
	for <mpls@uu.net>; Tue, 13 Jun 2000 06:58:44 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id XAA19076;
	Mon, 12 Jun 2000 23:58:39 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id XAA20801; Mon, 12 Jun 2000 23:58:39 -0700 (PDT)
Date: Mon, 12 Jun 2000 23:58:39 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006130658.XAA20801@kummer.juniper.net>
To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

> Two POPs are needed to terminate a VPN tunnel.

Not if you use PHP.  You start popping one hop earlier, e.g., if
X is the PE attached to the customer, and Y the penultimate hop,
Y pops the "outer label" and forwards the packet with the "inner
label" identifying the VPN to X.  X looks at the inner (only!)
label, pops it and knows which customer to forward the packet to.

Corner case: a one-hop LSP carrying VPN info: don't put any "outer
label" in this case.

> Three might be needed
> if the outer tunnel on the VPN took its last hop through a FA-PSC.

Picture time:

    A ---- B ==== C ==== D ==== E ~~~~ customer
            <-43-  <-28-  <--3-
    <--71-- <-------- 3 -------

    <-- 32 for VPN to customer --

There's an FA-LSP from B to E.  E sends D an implicit NULL label,
D sends C label 28, C sends B 43.

Now, there's another LSP that wants to tunnel through the above
FA-LSP.  This LSP has 2 hops, A->B and B->E.  E sends B label 3,
B sends A label 71.

A and E agree on label 32 for the VPN.

The label stack for a packet to the customer is as follows:

    A ---- B ==== C ==== D ==== E ~~~~ customer
              43     28
       71
       32     32     32     32

Note that 71 -> 43 is not really a swap as much as a pop (PHP),
followed by a push (equivalent, but you get there differently).

It is interesting to first work out the case where the tunneled
LSP terminates beyond the tail of the FA-LSP, as the above example
is another 'corner case'.

Kireeti.


From owner-mpls@UU.NET  Tue Jun 13 05:48:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01239
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 05:48:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitjr13361;
	Tue, 13 Jun 2000 09:48:41 GMT
Received: by mail-control.mail.uu.net 
	id QQitjr05009
	for mpls-outgoing; Tue, 13 Jun 2000 09:48:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitjr05004
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 09:48:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitjr24114
	for <mpls@UU.NET>; Tue, 13 Jun 2000 05:48:11 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQitjr12919
	for <mpls@UU.NET>; Tue, 13 Jun 2000 09:48:10 GMT
Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP;
          Tue, 13 Jun 2000 10:44:21 +0100
Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWBMLBR>; Tue, 13 Jun 2000 10:44:06 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16076@mbddmknt01.hc.bt.com>
To: kireeti@juniper.net, curtis@avici.com
Cc: mpls@UU.NET
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE
Date: Tue, 13 Jun 2000 10:44:04 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Observation/plea:

I am getting increasingly concerned that we have an MPLS trail object, ie an
LSP, but that the trail termination points (either source or sink) seem to
be a movable feast depending on (i) different people's interpetation of the
IDs produced to date, and/or (ii) the functional behaviour that is being
considered.  Can I therefore make the plea that if a further informational
ID is produced to clarify these matters (which Bora orginally suggested)
that we make sure that there is architectural consistency across all
functional behaviour wrt to where the trail termination points are.

Regards, Neil

> -----Original Message-----
> From:	Kireeti Kompella [SMTP:kireeti@juniper.net]
> Sent:	Tuesday, June 13, 2000 7:59 AM
> To:	curtis@avici.com
> Cc:	mpls@UU.NET
> Subject:	Re: Hierarchical Tunnel Establishment in RSVP-TE
> 
> > Two POPs are needed to terminate a VPN tunnel.
> 
> Not if you use PHP.  You start popping one hop earlier, e.g., if
> X is the PE attached to the customer, and Y the penultimate hop,
> Y pops the "outer label" and forwards the packet with the "inner
> label" identifying the VPN to X.  X looks at the inner (only!)
> label, pops it and knows which customer to forward the packet to.
> 
> Corner case: a one-hop LSP carrying VPN info: don't put any "outer
> label" in this case.
> 
> > Three might be needed
> > if the outer tunnel on the VPN took its last hop through a FA-PSC.
> 
> Picture time:
> 
>     A ---- B ==== C ==== D ==== E ~~~~ customer
>             <-43-  <-28-  <--3-
>     <--71-- <-------- 3 -------
> 
>     <-- 32 for VPN to customer --
> 
> There's an FA-LSP from B to E.  E sends D an implicit NULL label,
> D sends C label 28, C sends B 43.
> 
> Now, there's another LSP that wants to tunnel through the above
> FA-LSP.  This LSP has 2 hops, A->B and B->E.  E sends B label 3,
> B sends A label 71.
> 
> A and E agree on label 32 for the VPN.
> 
> The label stack for a packet to the customer is as follows:
> 
>     A ---- B ==== C ==== D ==== E ~~~~ customer
>               43     28
>        71
>        32     32     32     32
> 
> Note that 71 -> 43 is not really a swap as much as a pop (PHP),
> followed by a push (equivalent, but you get there differently).
> 
> It is interesting to first work out the case where the tunneled
> LSP terminates beyond the tail of the FA-LSP, as the above example
> is another 'corner case'.
> 
> Kireeti.


From owner-mpls@UU.NET  Tue Jun 13 09:00:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06056
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 09:00:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitke17072;
	Tue, 13 Jun 2000 13:00:30 GMT
Received: by mail-control.mail.uu.net 
	id QQitkd16369
	for mpls-outgoing; Tue, 13 Jun 2000 12:59:57 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitkd16362
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 12:59:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitkd09872
	for <mpls@uu.net>; Tue, 13 Jun 2000 08:59:39 -0400 (EDT)
Received: from ihemlsrv.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQitkd11600
	for <mpls@uu.net>; Tue, 13 Jun 2000 12:59:39 GMT
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA17927
	for <mpls@uu.net>; Tue, 13 Jun 2000 08:59:39 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA17915
	for <mpls@uu.net>; Tue, 13 Jun 2000 08:59:38 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id IAA07189; Tue, 13 Jun 2000 08:59:37 -0400 (EDT)
Message-ID: <39463039.A42EDA6F@lucent.com>
Date: Tue, 13 Jun 2000 08:59:37 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: CR-LDP timer
References: <200006130406.AAA21352@curtis-lt.avici.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi,

Similar questions of CR-LDP: 

Why CR-LDP doesn't define timer like T301, 303 etc. in Q.2931 for LSP setup?
What's the underlying assumption that LSP doesn't need these timers? How can
CR-LDP guarantee the mapping response will eventually arrive for certain label
request?

Thanks,

Yangguang


From owner-mpls@UU.NET  Tue Jun 13 09:04:56 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06252
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 09:04:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitke15017;
	Tue, 13 Jun 2000 13:04:52 GMT
Received: by mail-control.mail.uu.net 
	id QQitke22026
	for mpls-outgoing; Tue, 13 Jun 2000 13:04:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitke22021
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 13:04:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitke10991
	for <mpls@UU.NET>; Tue, 13 Jun 2000 09:04:08 -0400 (EDT)
Received: from web5103.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5103.mail.yahoo.com [216.115.106.73])
	id QQitke14517
	for <mpls@UU.NET>; Tue, 13 Jun 2000 13:04:07 GMT
Message-ID: <20000613130407.2233.qmail@web5103.mail.yahoo.com>
Received: from [169.144.16.187] by web5103.mail.yahoo.com; Tue, 13 Jun 2000 06:04:07 PDT
Date: Tue, 13 Jun 2000 06:04:07 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
Subject: Re: FW: Hierarchical Tunnel Establishment in RSVP-TE 
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'mpls@UU.net'" <mpls@UU.NET>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,
So what is the interpretation for the draft. 

"That you can apply NULL label only iff it is
the only label present in the label stack. "

Tony could we have clarification from you on 
the draft.

C.

--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
wrote:
> Chatur,
> 
> I don't think so. Since in case of label= 1, the
> draft says:
> 
> "A value of 1 represents the "Router Alert Label". 
> This label value is
> legal anywhere in the label stack except at the
> bottom."
> 
> So in case of Label=2,4 they could have written:
> "nowhere except at the
> bottom". 
> 
> -Shahram
> 
> >-----Original Message-----
> >From: Chatur sharp [mailto:chatur_b@yahoo.com]
> >Sent: Monday, June 12, 2000 5:08 PM
> >To: Shahram Davari
> >Subject: RE: Hierarchical Tunnel Establishment in
> RSVP-TE 
> >
> >
> >On the face of it what you say seems to be correct.
> >
> >Could it be that draft should be interpreted as:
> >
> >"As that there should be no more labels below a
> NULL
> >label. However, labels could be applied on top
> >of a NULL label. "
> >
> >
> >
> >
> >--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >wrote:
> >> Toni,
> >> 
> >> The Encaps-draft says that the IPV4/6 Explicit
> Null
> >> Labels are only legal if
> >> they are the sole label stack entry. However, in
> >> your example the RSVP
> >> messages will have two labels, the outer label
> and
> >> the IPV4/6 Explicit Null
> >> Label. Isn't this a violation of the Encaps-draft
> >> requirement?
> >> 
> >> Regards,
> >> -Shahram
> >> 
> >> >-----Original Message-----
> >> >From: Tony Li [mailto:tli@Procket.com]
> >> >Sent: Monday, June 12, 2000 1:22 PM
> >> >To: curtis@avici.com
> >> >Cc: Tony Li; Bora Akyol; 'mpls@uu.net'
> >> >Subject: Re: Hierarchical Tunnel Establishment
> in
> >> RSVP-TE 
> >> >
> >> >
> >> >
> >> >Curtis,
> >> >
> >> > | If the outer tunnel is constrained (by
> >> configuration) to accept only
> >> > | inner tunnels with one L3PID, then that L3PID
> >> can be placed on the
> >> > | outer tunnel.  If there are optimization
> >> possible for a particular
> >> > | L3PID (IP src/dst hash to split loading along
> >> the way comes to mind
> >> > | for IPv4) then putting the inner L3PID on the
> >> outer tunnel has
> >> > | advantages.
> >> >
> >> >
> >> >I agree that this is also possible for
> >> implementations that 
> >> >want to parse
> >> >up the label stack.
> >> >
> >> >
> >> > | No where have I seen a requirement to put a
> null
> >> label on traffic
> >> > | destined to the egress LSR.
> >> >
> >> >
> >> >The requirement exists if you take the more
> general
> >> approach 
> >> >of specifying
> >> >an outer L3PID of MPLS and then wish to tunnel
> >> (otherwise 
> >> >unlabeled) RSVP.
> >> >Under the approach that you've proposed, this
> would
> >> not be necessary.
> >> >
> >> >Tony
> >> >
> >> 
> >
> >
> >=====
> >I am willing to learn,  if you care to teach.
> >I am willing to teach, if you care to learn.
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Photos -- now, 100 FREE prints!
> >http://photos.yahoo.com
> >
> 


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Tue Jun 13 09:36:14 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07717
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 09:36:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitkg16089;
	Tue, 13 Jun 2000 13:36:09 GMT
Received: by mail-control.mail.uu.net 
	id QQitkg28143
	for mpls-outgoing; Tue, 13 Jun 2000 13:35:31 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitkg28136
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 13:35:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitkg24430
	for <mpls@UU.NET>; Tue, 13 Jun 2000 09:35:05 -0400 (EDT)
Received: from osf1.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: osf1.gmu.edu [129.174.1.13])
	id QQitkg06943
	for <mpls@UU.NET>; Tue, 13 Jun 2000 13:35:05 GMT
Received: from localhost (rpapneja@localhost)
	by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA29060;
	Tue, 13 Jun 2000 09:35:00 -0400 (EDT)
Date: Tue, 13 Jun 2000 09:35:00 -0400 (EDT)
From: Rajiv Papneja <rpapneja@osf1.gmu.edu>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'mpls@UU.net'" <mpls@UU.NET>, chatur_b@yahoo.com
Subject: Re: FW: Hierarchical Tunnel Establishment in RSVP-TE 
In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B40606@nt-exchange-bby.pmc-sierra.bc.ca>
Message-ID: <Pine.OSF.4.21.0006130932330.28566-100000@osf1.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Sharam,

  Hi Sharam,

   According to the draft on label encapsulation, for the label
values (0 or 2) this is true that the values would be legal if
and only if they are the sole label stack entries, indicating that the
label stack must be popped and forwarding should be based on the IPv4 or
IPv6 header. However, does this draft mention that when the label
value is 4, it should be "nowhere except at the bottom of the stack?" If
you refer to the draft-ietf-mpls-label-encaps-07.txt, section 4 part v, it
states that values 4-15 are reserved but it does not mention about the
positioning of these values, top or the bottom of the stack. Please
correct me if I have misunderstood or missed something here.

 Regards       

 Rajiv


On Mon, 12 Jun 2000, Shahram Davari wrote:

> Chatur,
> 
> I don't think so. Since in case of label= 1, the draft says:
> 
> "A value of 1 represents the "Router Alert Label".  This label value is
> legal anywhere in the label stack except at the bottom."
> 
> So in case of Label=2,4 they could have written: "nowhere except at the
> bottom". 
> 
> -Shahram
> 
> >-----Original Message-----
> >From: Chatur sharp [mailto:chatur_b@yahoo.com]
> >Sent: Monday, June 12, 2000 5:08 PM
> >To: Shahram Davari
> >Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
> >
> >
> >On the face of it what you say seems to be correct.
> >
> >Could it be that draft should be interpreted as:
> >
> >"As that there should be no more labels below a NULL
> >label. However, labels could be applied on top
> >of a NULL label. "
> >
> >
> >
> >
> >--- Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >wrote:
> >> Toni,
> >> 
> >> The Encaps-draft says that the IPV4/6 Explicit Null
> >> Labels are only legal if
> >> they are the sole label stack entry. However, in
> >> your example the RSVP
> >> messages will have two labels, the outer label and
> >> the IPV4/6 Explicit Null
> >> Label. Isn't this a violation of the Encaps-draft
> >> requirement?
> >> 
> >> Regards,
> >> -Shahram
> >> 
> >> >-----Original Message-----
> >> >From: Tony Li [mailto:tli@Procket.com]
> >> >Sent: Monday, June 12, 2000 1:22 PM
> >> >To: curtis@avici.com
> >> >Cc: Tony Li; Bora Akyol; 'mpls@uu.net'
> >> >Subject: Re: Hierarchical Tunnel Establishment in
> >> RSVP-TE 
> >> >
> >> >
> >> >
> >> >Curtis,
> >> >
> >> > | If the outer tunnel is constrained (by
> >> configuration) to accept only
> >> > | inner tunnels with one L3PID, then that L3PID
> >> can be placed on the
> >> > | outer tunnel.  If there are optimization
> >> possible for a particular
> >> > | L3PID (IP src/dst hash to split loading along
> >> the way comes to mind
> >> > | for IPv4) then putting the inner L3PID on the
> >> outer tunnel has
> >> > | advantages.
> >> >
> >> >
> >> >I agree that this is also possible for
> >> implementations that 
> >> >want to parse
> >> >up the label stack.
> >> >
> >> >
> >> > | No where have I seen a requirement to put a null
> >> label on traffic
> >> > | destined to the egress LSR.
> >> >
> >> >
> >> >The requirement exists if you take the more general
> >> approach 
> >> >of specifying
> >> >an outer L3PID of MPLS and then wish to tunnel
> >> (otherwise 
> >> >unlabeled) RSVP.
> >> >Under the approach that you've proposed, this would
> >> not be necessary.
> >> >
> >> >Tony
> >> >
> >> 
> >
> >
> >=====
> >I am willing to learn,  if you care to teach.
> >I am willing to teach, if you care to learn.
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Photos -- now, 100 FREE prints!
> >http://photos.yahoo.com
> >
> 
> 



From owner-mpls@UU.NET  Tue Jun 13 09:48:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08051
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 09:48:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitkh18008;
	Tue, 13 Jun 2000 13:48:06 GMT
Received: by mail-control.mail.uu.net 
	id QQitkh28829
	for mpls-outgoing; Tue, 13 Jun 2000 13:47:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitkh28822
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 13:47:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitkh19222
	for <mpls@uu.net>; Tue, 13 Jun 2000 09:47:05 -0400 (EDT)
Received: from ihemlsrv.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQitkh17061
	for <mpls@uu.net>; Tue, 13 Jun 2000 13:47:05 GMT
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA05841
	for <mpls@uu.net>; Tue, 13 Jun 2000 09:47:04 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA05822
	for <mpls@uu.net>; Tue, 13 Jun 2000 09:47:04 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id JAA13078; Tue, 13 Jun 2000 09:47:03 -0400 (EDT)
Message-ID: <39463B57.C56089A7@lucent.com>
Date: Tue, 13 Jun 2000 09:47:03 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: CR-LDP timer
References: <20000613132839.15896.qmail@web5102.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Please see further questions below:
 
Chatur sharp wrote:
> 
> It runs on TCP, which provides this garuntee. Incase
> response is not received the TCP times out. Much like
> T301 etc.

Anything can happens. What happens if TCP session is OK, but CR-LDP packets are
dropped some place, for example, buggy CR-LDP code? Are we sure that TCP is
enough? Do we have any requirement for CR-LSP setup time? Any requirements from
service provider?


> A couple of points to remember are :
> 1. Q.2931 is a UNI i/f where message from
>    one user (caller) are carried by the network
>    ( through possibly multiple hps ) to the second
>    user ( receiver).
> 
>    LDP is not like that it is really Peer to Peer.
>    So protection for individual calls is not really
>    required. ( Although it would be desirable for
>    some other purpose )
> 
> 2. Typically TELCO protocols have more reliability
>    redundancy built into the stack than datacom world.
> 
>

First, I should say PNNI.

Second, MPLS is mainly defined for core data network, where reliability is as
important as any traditional Telco network. PNNI or Q.2931 is a little bit too
complicated, however, I think timer is still needed for CR-LSP setup.

Yangguang


From owner-mpls@UU.NET  Tue Jun 13 09:59:02 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08430
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 09:59:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitkh03627;
	Tue, 13 Jun 2000 13:58:58 GMT
Received: by mail-control.mail.uu.net 
	id QQitkh29584
	for mpls-outgoing; Tue, 13 Jun 2000 13:58:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitkh29538
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 13:58:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitkh29096
	for <mpls@uu.net>; Tue, 13 Jun 2000 09:57:55 -0400 (EDT)
Received: from web5104.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5104.mail.yahoo.com [216.115.106.74])
	id QQitkh02731
	for <mpls@uu.net>; Tue, 13 Jun 2000 13:57:55 GMT
Message-ID: <20000613135754.29617.qmail@web5104.mail.yahoo.com>
Received: from [169.144.16.187] by web5104.mail.yahoo.com; Tue, 13 Jun 2000 06:57:54 PDT
Date: Tue, 13 Jun 2000 06:57:54 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
Subject: Re: CR-LDP timer
To: Yangguang Xu <xuyg@lucent.com>
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


--- Yangguang Xu <xuyg@lucent.com> wrote:
> Thanks,
> 
> See my further question below,
> 
> > It runs on TCP, which provides this garuntee.
> Incase
> > response is not received the TCP times out. Much
> like
> > T301 etc.
> 
> What happens if TCP session is still OK, however
> CR-LDP messages are lost at
> some place, for example, the CR-LDP code drops
> messages mistakenly? Anything can
This is exactly the reliability redundancy I was
talking about. These assumption are made in the
erstwhile TELCO current B-ISDN world. 

But really if you look at it, its a Byzantine problem.
How many levels of reliability you could use and
should use are two different things. I am not saying
to assume that packets can be dropped between TCP and
LDP is right or wrong. But I do know that this 
assumption is not made in datacom world.

> happen. Are we sure TCP is enough? Also do we have
> time requirement for CR-LSP
> setup? Any requirement from service provider?


> 
> > A couple of points to remember are :
> > 1. Q.2931 is a UNI i/f where message from
> >    one user (caller) are carried by the network
> >    ( through possibly multiple hps ) to the second
> >    user ( receiver).
> > 
> >    LDP is not like that it is really Peer to Peer.
> >    So protection for individual calls is not
> really
> >    required. ( Although it would be desirable for
> >    some other purpose )
> > 
> > 2. Typically TELCO protocols have more reliability
> >    redundancy built into the stack than datacom
> world.
> > 
> 
> First, I guess I should say PNNI.  
Q.2931 is UNI although message set it reused at PNNI.

> 
> Second, datacom equipment is moving to core. MPLS is
> defined mainly for core
> network. Reliability should be as important as
Telco.

I guess again we are comparing the assumption made
by two different kind of network technologies.


One more thing I may add, is that a session between
two LDP peers is really like a call in B-ISDN world.
Thus protecting it using on TCP timer seems fine,
although not very desirable in all the cases.


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Tue Jun 13 10:17:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09178
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 10:17:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitkj12968;
	Tue, 13 Jun 2000 14:17:18 GMT
Received: by mail-control.mail.uu.net 
	id QQitkj10535
	for mpls-outgoing; Tue, 13 Jun 2000 14:16:40 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitkj10530
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 14:16:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitkj25055
	for <mpls@UU.NET>; Tue, 13 Jun 2000 10:15:53 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitkj15911
	for <mpls@UU.NET>; Tue, 13 Jun 2000 14:15:53 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id KAA09600; Tue, 13 Jun 2000 10:15:49 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA21875;
	Tue, 13 Jun 2000 10:15:49 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006131415.KAA21875@curtis-lt.avici.com>
To: Kireeti Kompella <kireeti@juniper.net>
cc: curtis@avici.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Mon, 12 Jun 2000 23:58:39 PDT."
             <200006130658.XAA20801@kummer.juniper.net> 
Date: Tue, 13 Jun 2000 10:15:49 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200006130658.XAA20801@kummer.juniper.net>, Kireeti Kompella writes:
> > Two POPs are needed to terminate a VPN tunnel.
> 
> Not if you use PHP.  You start popping one hop earlier, e.g., if
> X is the PE attached to the customer, and Y the penultimate hop,
> Y pops the "outer label" and forwards the packet with the "inner
> label" identifying the VPN to X.  X looks at the inner (only!)
> label, pops it and knows which customer to forward the packet to.
> 
> Corner case: a one-hop LSP carrying VPN info: don't put any "outer
> label" in this case.
> 
> > Three might be needed
> > if the outer tunnel on the VPN took its last hop through a FA-PSC.
> 
> Picture time:
> 
>     A ---- B ==== C ==== D ==== E ~~~~ customer
>             <-43-  <-28-  <--3-
>     <--71-- <-------- 3 -------
> 
>     <-- 32 for VPN to customer --
> 
> There's an FA-LSP from B to E.  E sends D an implicit NULL label,
> D sends C label 28, C sends B 43.
> 
> Now, there's another LSP that wants to tunnel through the above
> FA-LSP.  This LSP has 2 hops, A->B and B->E.  E sends B label 3,
> B sends A label 71.
> 
> A and E agree on label 32 for the VPN.
> 
> The label stack for a packet to the customer is as follows:
> 
>     A ---- B ==== C ==== D ==== E ~~~~ customer
>               43     28
>        71
>        32     32     32     32
> 
> Note that 71 -> 43 is not really a swap as much as a pop (PHP),
> followed by a push (equivalent, but you get there differently).
> 
> It is interesting to first work out the case where the tunneled
> LSP terminates beyond the tail of the FA-LSP, as the above example
> is another 'corner case'.
> 
> Kireeti.


Kireeti,

PHP does remove POPs and make it easier to implement an egress LSR but
it makes it very hard to collect statistics of packets and bytes
received on an LSP at the egress.  Recall the discussion of OAM and
loss measurements.  There is no way to count at the egress if the
labels are lost.  Therefore in your example there is no way to
determine loss over the FA-PSC tunnel or over the tunnel from A-E.

Curtis


From owner-mpls@UU.NET  Tue Jun 13 10:31:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09727
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 10:31:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitkk25899;
	Tue, 13 Jun 2000 14:31:40 GMT
Received: by mail-control.mail.uu.net 
	id QQitkk12190
	for mpls-outgoing; Tue, 13 Jun 2000 14:31:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitkk12104
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 14:30:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitkk27778
	for <mpls@UU.NET>; Tue, 13 Jun 2000 10:30:24 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQitkk26452
	for <mpls@UU.NET>; Tue, 13 Jun 2000 14:30:24 GMT
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Tue, 13 Jun 2000 09:27:29 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id MZ8LK605; Tue, 13 Jun 2000 10:27:59 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id LQHBMWW6; Tue, 13 Jun 2000 10:27:55 -0400
Message-ID: <394644EC.55517D36@americasm01.nt.com>
Date: Tue, 13 Jun 2000 10:27:57 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
CC: mpls@UU.NET
Subject: Re: CR-LDP timer
References: <20000613132839.15896.qmail@web5102.mail.yahoo.com> <39463B57.C56089A7@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

While we are on the topic of setup timers, is there a timer in RSVP-TE which times
how long a PSB exists without a corresponding RSB. That is, should RSVP-TE start a
timer after creating a PSB upon processing of a PATH message. If a corresponding
RSB is not created within specified time, i.e. RESV message doesn't arrive within
that time,  then the PSB is declared "uncompleted" and potentially destroyed,
maybe even PATH_TEAR generated upstream.

Such a timer would be useful in particular since a while back it was indicated on
the mailing list that bandwidth reservations for RSVP-TE are done on the
PATH message as opposed to on the RESV message as in classical RSVP. Such timer
would thus prevent PSBs from unnecessarily holding onto bandwidth for long periods
of time.

I agree with Yangguang that a concern about setup timer for both CR-LDP and
RSVP-TE is valid to ensure that once LABEL_REQUEST or PATH messages are launched
then LABEL_MAPPING or RESV (or error) messages arrive within a predefined time or
else the LSP establishment is aborted.

Darek


Yangguang Xu wrote:

> Please see further questions below:
>
> Chatur sharp wrote:
> >
> > It runs on TCP, which provides this garuntee. Incase
> > response is not received the TCP times out. Much like
> > T301 etc.
>
> Anything can happens. What happens if TCP session is OK, but CR-LDP packets are
> dropped some place, for example, buggy CR-LDP code? Are we sure that TCP is
> enough? Do we have any requirement for CR-LSP setup time? Any requirements from
> service provider?
>
> > A couple of points to remember are :
> > 1. Q.2931 is a UNI i/f where message from
> >    one user (caller) are carried by the network
> >    ( through possibly multiple hps ) to the second
> >    user ( receiver).
> >
> >    LDP is not like that it is really Peer to Peer.
> >    So protection for individual calls is not really
> >    required. ( Although it would be desirable for
> >    some other purpose )
> >
> > 2. Typically TELCO protocols have more reliability
> >    redundancy built into the stack than datacom world.
> >
> >
>
> First, I should say PNNI.
>
> Second, MPLS is mainly defined for core data network, where reliability is as
> important as any traditional Telco network. PNNI or Q.2931 is a little bit too
> complicated, however, I think timer is still needed for CR-LSP setup.
>
> Yangguang



From owner-mpls@UU.NET  Tue Jun 13 12:34:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14103
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 12:34:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitks07828;
	Tue, 13 Jun 2000 16:34:03 GMT
Received: by mail-control.mail.uu.net 
	id QQitks09502
	for mpls-outgoing; Tue, 13 Jun 2000 16:33:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitks09497
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 16:33:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitks02030
	for <mpls@UU.NET>; Tue, 13 Jun 2000 12:33:03 -0400 (EDT)
Received: from qtech1.quarrytech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: email.quarrytech.com [4.17.144.4])
	id QQitks06930
	for <mpls@UU.NET>; Tue, 13 Jun 2000 16:33:03 GMT
Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.21)
	id <KXL8FK71>; Tue, 13 Jun 2000 12:31:21 -0400
Message-ID: <496A8683261CD211BF6C0008C733261A48D202@email.quarrytech.com>
From: "Abes, Andi" <aabes@quarrytech.com>
To: curtis@avici.com, Kireeti Kompella <kireeti@juniper.net>
Cc: mpls@UU.NET
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Tue, 13 Jun 2000 12:31:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis,

The PHP options brings up a question that I've asked a 
long time ago, but went un-answered:
Are "inner" labels restricted to be from the "platform"
label pool ?
Are there implementations that use "per-interface" label 
pools to allocate inner labels ?

It is concivable that an implementation will choose to
define an LSP (or set of them) as an interface. And, on
top of this interface manage a "per-interface" label pool.
This can help simplify routing for example.

If this is allowed, then the PHP solution will break, since
only the outer label identifys the incomming "interface".

Andi.




>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@avici.com]
>Sent: Tuesday, June 13, 2000 10:16 AM
>To: Kireeti Kompella
>Cc: curtis@avici.com; mpls@UU.NET
>Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
>
>
>
>In message <200006130658.XAA20801@kummer.juniper.net>, Kireeti 
>Kompella writes:
>> > Two POPs are needed to terminate a VPN tunnel.
>> 
>> Not if you use PHP.  You start popping one hop earlier, e.g., if
>> X is the PE attached to the customer, and Y the penultimate hop,
>> Y pops the "outer label" and forwards the packet with the "inner
>> label" identifying the VPN to X.  X looks at the inner (only!)
>> label, pops it and knows which customer to forward the packet to.
>> 
>> Corner case: a one-hop LSP carrying VPN info: don't put any "outer
>> label" in this case.
>> 
>> > Three might be needed
>> > if the outer tunnel on the VPN took its last hop through a FA-PSC.
>> 
>> Picture time:
>> 
>>     A ---- B ==== C ==== D ==== E ~~~~ customer
>>             <-43-  <-28-  <--3-
>>     <--71-- <-------- 3 -------
>> 
>>     <-- 32 for VPN to customer --
>> 
>> There's an FA-LSP from B to E.  E sends D an implicit NULL label,
>> D sends C label 28, C sends B 43.
>> 
>> Now, there's another LSP that wants to tunnel through the above
>> FA-LSP.  This LSP has 2 hops, A->B and B->E.  E sends B label 3,
>> B sends A label 71.
>> 
>> A and E agree on label 32 for the VPN.
>> 
>> The label stack for a packet to the customer is as follows:
>> 
>>     A ---- B ==== C ==== D ==== E ~~~~ customer
>>               43     28
>>        71
>>        32     32     32     32
>> 
>> Note that 71 -> 43 is not really a swap as much as a pop (PHP),
>> followed by a push (equivalent, but you get there differently).
>> 
>> It is interesting to first work out the case where the tunneled
>> LSP terminates beyond the tail of the FA-LSP, as the above example
>> is another 'corner case'.
>> 
>> Kireeti.
>
>
>Kireeti,
>
>PHP does remove POPs and make it easier to implement an egress LSR but
>it makes it very hard to collect statistics of packets and bytes
>received on an LSP at the egress.  Recall the discussion of OAM and
>loss measurements.  There is no way to count at the egress if the
>labels are lost.  Therefore in your example there is no way to
>determine loss over the FA-PSC tunnel or over the tunnel from A-E.
>
>Curtis
>


From owner-mpls@UU.NET  Tue Jun 13 13:28:28 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16043
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 13:28:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitkv10698;
	Tue, 13 Jun 2000 17:28:22 GMT
Received: by mail-control.mail.uu.net 
	id QQitkv22414
	for mpls-outgoing; Tue, 13 Jun 2000 17:27:46 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitkv22390
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 17:27:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitkv11815
	for <mpls@UU.NET>; Tue, 13 Jun 2000 13:24:22 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQitkv19701
	for <mpls@UU.NET>; Tue, 13 Jun 2000 17:24:21 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18015;
	Tue, 13 Jun 2000 10:24:23 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA29787; Tue, 13 Jun 2000 13:24:09 -0400 (EDT)
Message-Id: <200006131724.NAA29787@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'Tony Li'" <tli@Procket.com>, curtis@avici.com,
        Bora Akyol <akyol@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of Mon, 12 Jun 2000 13:22:16 -0700.
             <336ECDAFDF7DD311B9E30090277AEE4101B40604@nt-exchange-bby.pmc-sierra.bc.ca> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 13 Jun 2000 13:24:08 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Shahram> The Encaps-draft says that the IPV4/6 Explicit Null Labels are only
Shahram> legal if they are the sole label stack entry.

It does say that, but I think that is just a mistake.  This restriction will
be removed in the next draft. 


From owner-mpls@UU.NET  Tue Jun 13 14:19:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18224
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 14:19:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitkz01056;
	Tue, 13 Jun 2000 18:19:24 GMT
Received: by mail-control.mail.uu.net 
	id QQitkz05302
	for mpls-outgoing; Tue, 13 Jun 2000 18:18:47 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitkz05297
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 18:18:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitkz22299
	for <mpls@UU.NET>; Tue, 13 Jun 2000 14:17:16 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQitkz18662
	for <mpls@UU.NET>; Tue, 13 Jun 2000 18:17:15 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCCTNQ>; Tue, 13 Jun 2000 11:23:17 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690786@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Eric Rosen'" <erosen@cisco.com>
Cc: "'Tony Li'" <tli@Procket.com>, "'Curtis Villamizar'" <curtis@avici.com>,
        Bora Akyol <akyol@pluris.com>, "'MPLS Mailing list'" <mpls@UU.NET>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Tue, 13 Jun 2000 11:23:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

	I am not sure it should be removed.  Perhaps
its should either be extended, or reduced.  If the
restriction is eliminated entirely, then so should
the concept of Explicit NULL labels be removed. It
might be more work to take out this restriction
then it would be to remove Explicit NULL labels.

	It is possible that an implementation may
rely on this usage when its upstream neighbor is
not able to perform PHP.  Having separate labels
for IPv4 and IPv6 Explicit NULL makes sense for
an implementation that wants to be certain which
encapsulation follows the label to be popped.

	We can argue that it is up to the local
implementation to use labels that allow it to 
distinguish the underlying encapsulation in the
"pop and look again" mode.  In that case, because
labels are downstream allocated, it was NEVER
necessary to define well known values for IPv4
and IPv6 Explicit NULL labels.  An implementation
is free to use ANY label - or set of labels - to 
accomplish this function.

	However, because we have 2 forms of Explicit
NULL labels - one for IPv4 and another for IPv6 -
there are problems with allowing either Explicit
NULL label to be followed by additional labels in
a label stack:

o	What does it mean to have an IPv4 Explicit
	NULL label as opposed to an IPv6 Explicit
	NULL label when either one could be followed
	by an MPLS label stack?
	o	Does it mean that - should you want to
		look beyond the stack, you will find
		an IPv4 L3 header?
	o	What happens if more than one Explicit
		NULL label appears in the same stack
		and one is for IPv4 and the other for 
		IPv6?
o	Why not define another well known Explicit 
	NULL label for the "followed by more labels"
	case?
o	Is it ever legal for an ingress to mix and 
	match - for example - IPv4 and labeled data
	packets on the same LSP?
	o	this will work at the egress - for the
		same reason it works at the penultimate
		hop - because the Explicit NULL label
		either will or will not have the bottom
		of stack bit set;
	o	will every implementation look at the
		bottom of stack bit when they receive
		an IPv4 Explicit NULL label?

	Because it is likely that some implementations
may have built this restriction in (by ignoring the
bottom of stack bit for Explicit NULL labels), it will
be necessary to include a means to allow the egress to
force the ingress to use distinct LSPs for labeled and
unlabeled packets.  

	How would this be done using current signaling 
protocols?

	Finally, why did we define well known Explicit
NULL labels for IPv4 and IPv6 in the first place?
Since the labels are allocated by the implementation
that has to interpret them, that implementation could
choose to use any labels (or sets of labels) it wants
to.  There must have been some reason for deciding to
use well-known values.  What was it?

--
Eric Gray
		


> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Tuesday, June 13, 2000 10:24 AM
> To: Shahram Davari
> Cc: 'Tony Li'; curtis@avici.com; Bora Akyol; 'mpls@uu.net'
> Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
> 
> 
> 
> Shahram> The Encaps-draft says that the IPV4/6 Explicit Null 
> Labels are only
> Shahram> legal if they are the sole label stack entry.
> 
> It does say that, but I think that is just a mistake.  This 
> restriction will
> be removed in the next draft. 
> 


From owner-mpls@UU.NET  Tue Jun 13 14:31:54 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18450
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 14:31:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitla10489;
	Tue, 13 Jun 2000 18:31:49 GMT
Received: by mail-control.mail.uu.net 
	id QQitla06087
	for mpls-outgoing; Tue, 13 Jun 2000 18:30:48 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitla06056
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 18:30:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitkz24323
	for <mpls@UU.NET>; Tue, 13 Jun 2000 14:27:17 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQitkz26273
	for <mpls@UU.NET>; Tue, 13 Jun 2000 18:27:17 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA11642;
	Tue, 13 Jun 2000 11:26:58 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA00032; Tue, 13 Jun 2000 14:26:48 -0400 (EDT)
Message-Id: <200006131826.OAA00032@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: Eric Gray <EGray@zaffire.com>
cc: "'Tony Li'" <tli@Procket.com>, "'Curtis Villamizar'" <curtis@avici.com>,
        Bora Akyol <akyol@pluris.com>, "'MPLS Mailing list'" <mpls@UU.NET>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of Tue, 13 Jun 2000 11:23:17 -0700.
             <9A564CC874B5D3118FB9009027B0A662690786@ICARIAN> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 13 Jun 2000 14:26:48 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


My proposal is to replace the requirement that explicit nulls only appear as
the sole  label on the stack with  the requirement that they  only appear at
the bottom of the stack. 

This doesn't change the fact that the S bit needs to be on when these labels
appear. 

We used well-known values so that an implementation wouldn't have to look up
the label in  its database of allocated label entries, only  to find that it
then needs  to look up  an IP destination  address.  Checking a  label value
against a  couple of well  known values is  much simpler than doing  a table
lookup. 
 




From owner-mpls@UU.NET  Tue Jun 13 15:02:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19152
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 15:02:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitlc23625;
	Tue, 13 Jun 2000 19:02:33 GMT
Received: by mail-control.mail.uu.net 
	id QQitlc14076
	for mpls-outgoing; Tue, 13 Jun 2000 19:02:11 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitlc13997
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 19:02:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitlb16660
	for <mpls@UU.NET>; Tue, 13 Jun 2000 14:55:40 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQitlb18229
	for <mpls@UU.NET>; Tue, 13 Jun 2000 18:55:39 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCCTQ6>; Tue, 13 Jun 2000 12:01:41 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690789@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Eric Rosen'" <erosen@cisco.com>
Cc: "'Tony Li'" <tli@Procket.com>, "'Curtis Villamizar'" <curtis@avici.com>,
        Bora Akyol <akyol@pluris.com>, "'MPLS Mailing list'" <mpls@UU.NET>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Tue, 13 Jun 2000 12:01:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

	See below.

You wrote (in part): 
> 
> My proposal is to replace the requirement that explicit nulls 
> only appear as the sole label on the stack with the requirement 
> that they only appear at the bottom of the stack. 
> 
> This doesn't change the fact that the S bit needs to be on 
> when these labels appear. 

Aha.  I guess I'm guilty of reading this meaning
into the existing text, since labels do not "appear"
until higher level labels are removed.  However, I
agree on re-reading the text that the current words
are just wrong.

The words -

   "This label value is only legal when it is the 
    sole label stack entry." 

- should be changed to something like -

   "This label value is only legal when it is at 
    the bottom of the label stack."

 - in both Explicit NULL labels.

> 
> We used well-known values so that an implementation wouldn't 
> have to look up the label in its database of allocated label 
> entries, only to find that it then needs to look up an IP 
> destination  address.  Checking a label value against a 
> couple of well known values is  much simpler than doing a 
> table lookup. 


No, duh.  :-)

My point is that the actual values may be chosen
by the implementation.  The fact that the specific
value of '0' or '2' is assigned to an upstream LSR
peer for a particular FEC has no more information
content than the fact that the hop count in the
message is '1'.  The upstream LSR simply stores
this label just like any other label and uses it
the same way, too.  Hence the value chosen by an
implementation could just as easily have been the
lucky-lotto numbers of the lead system designer.

>  
> 
> 

Eric Gray


From owner-mpls@UU.NET  Tue Jun 13 15:16:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19719
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 15:16:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitld14045;
	Tue, 13 Jun 2000 19:16:23 GMT
Received: by mail-control.mail.uu.net 
	id QQitld18893
	for mpls-outgoing; Tue, 13 Jun 2000 19:15:57 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitld18884
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 19:15:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitlc18685
	for <mpls@uu.net>; Tue, 13 Jun 2000 15:05:21 -0400 (EDT)
Received: from web5102.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5102.mail.yahoo.com [216.115.106.72])
	id QQitlc06195
	for <mpls@uu.net>; Tue, 13 Jun 2000 19:05:20 GMT
Message-ID: <20000613190520.4491.qmail@web5102.mail.yahoo.com>
Received: from [169.144.16.187] by web5102.mail.yahoo.com; Tue, 13 Jun 2000 12:05:20 PDT
Date: Tue, 13 Jun 2000 12:05:20 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
To: erosen@cisco.com
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram and Eric( Gray and Rosen)

This is exactly, what we discussed on the mailing
list yesterday. And it seems to hold all the threads
togather.

However, the concern is this: is it just a quick
fix solution/explaination or was this the intent 
of the draft in the first place ?

I guess it is time for anyone using NULL label as
the sole label to SPEAK UP.

C.




--- Eric Rosen <erosen@cisco.com> wrote:
> 
> My proposal is to replace the requirement that
> explicit nulls only appear as
> the sole  label on the stack with  the requirement
> that they  only appear at
> the bottom of the stack. 
> 
> This doesn't change the fact that the S bit needs to
> be on when these labels
> appear. 
> 
> We used well-known values so that an implementation
> wouldn't have to look up
> the label in  its database of allocated label
> entries, only  to find that it
> then needs  to look up  an IP destination  address. 
> Checking a  label value
> against a  couple of well  known values is  much
> simpler than doing  a table
> lookup. 
>  
> 
> 


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com


From owner-mpls@UU.NET  Tue Jun 13 15:32:18 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20014
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 15:32:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitle26449;
	Tue, 13 Jun 2000 19:31:56 GMT
Received: by mail-control.mail.uu.net 
	id QQitle20014
	for mpls-outgoing; Tue, 13 Jun 2000 19:31:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitle20009
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 19:31:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitle06943
	for <mpls@uu.net>; Tue, 13 Jun 2000 15:30:31 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitle25337
	for <mpls@uu.net>; Tue, 13 Jun 2000 19:30:30 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA09376
	for mpls@uu.net; Tue, 13 Jun 2000 15:30:29 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitld19923
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 19:29:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitld06645
	for <mpls@UU.NET>; Tue, 13 Jun 2000 15:29:25 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQitld14410
	for <mpls@UU.NET>; Tue, 13 Jun 2000 19:29:25 GMT
Received: from localhost (yakov@localhost)
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA04931
	for <mpls@UU.NET>; Tue, 13 Jun 2000 12:29:24 -0700 (PDT)
Message-Id: <200006131929.MAA04931@omega.cisco.com>
To: mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Tue, 13 Jun 2000 12:05:20 PDT."
             <20000613190520.4491.qmail@web5102.mail.yahoo.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4929.960924564.1@cisco.com>
Date: Tue, 13 Jun 2000 12:29:24 -0700
From: Yakov Rekhter <yakov@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Folks,

Given the recent e-mail exchange on the topic of hierarchical
tunnel establishment in RSVP-TE, and given that most (but probably
not all) the relevant material is covered under the notion of
Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
I wonder whether there would be any objections agains extracting
all the relevant material, filling the missing pieces (if any),
and turning the result into a MPLS WG document. 

Yakov.



From owner-mpls@UU.NET  Tue Jun 13 15:55:03 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20627
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 15:55:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitlf14014;
	Tue, 13 Jun 2000 19:55:00 GMT
Received: by mail-control.mail.uu.net 
	id QQitlf20968
	for mpls-outgoing; Tue, 13 Jun 2000 19:54:39 GMT
Received: from neserve0.corp.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88])
	id QQitlf20963
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 19:54:28 GMT
Received: by neserve0.corp.us.uu.net 
	id QQitlf26285;
	Tue, 13 Jun 2000 15:54:19 -0400 (EDT)
Date: Tue, 13 Jun 2000 15:54:14 -0400
From: Daniel Awduche <awduche@UU.NET>
To: Yakov Rekhter <yakov@cisco.com>
Cc: mpls@UU.NET, Daniel Awduche <awduche@UU.NET>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Message-ID: <20000613155414.B1317@uu.net>
References: <20000613190520.4491.qmail@web5102.mail.yahoo.com> <200006131929.MAA04931@omega.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200006131929.MAA04931@omega.cisco.com>; from yakov@cisco.com on Tue, Jun 13, 2000 at 12:29:24PM -0700
Sender: owner-mpls@UU.NET
Precedence: bulk

The FA concept clearly has independent interest, besides the 
original optical application. In fact, it is needed in certain
operational contexts today. Therefore, it's a good idea to
document it separately, and include additional relevant details 
not shown in draft-kompella-optical-mpls-00.txt, so that, 
hopefully, interoperable implementations can be derived

Cheers,
/Dan

On Tue, Jun 13, 2000 at 12:29:24PM -0700, Yakov Rekhter wrote:
> Folks,
> 
> Given the recent e-mail exchange on the topic of hierarchical
> tunnel establishment in RSVP-TE, and given that most (but probably
> not all) the relevant material is covered under the notion of
> Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
> I wonder whether there would be any objections agains extracting
> all the relevant material, filling the missing pieces (if any),
> and turning the result into a MPLS WG document. 
> 
> Yakov.


From owner-mpls@UU.NET  Tue Jun 13 16:24:32 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21642
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 16:24:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitlh26708;
	Tue, 13 Jun 2000 20:24:27 GMT
Received: by mail-control.mail.uu.net 
	id QQitlh02564
	for mpls-outgoing; Tue, 13 Jun 2000 20:23:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitlh02554
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 20:23:19 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitlh03002
	for <mpls@UU.NET>; Tue, 13 Jun 2000 16:19:01 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQitlh22766
	for <mpls@UU.NET>; Tue, 13 Jun 2000 20:19:00 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCCTWQ>; Tue, 13 Jun 2000 13:25:03 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269078A@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Yakov Rekhter'" <yakov@cisco.com>
Cc: "'MPLS Mail list'" <mpls@UU.NET>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Tue, 13 Jun 2000 13:25:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,

	Good idea!  Now who bells the cat?

--
Eric Gray

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@cisco.com]
> Sent: Tuesday, June 13, 2000 12:29 PM
> To: mpls@UU.NET
> Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
> 
> 
> Folks,
> 
> Given the recent e-mail exchange on the topic of hierarchical
> tunnel establishment in RSVP-TE, and given that most (but probably
> not all) the relevant material is covered under the notion of
> Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
> I wonder whether there would be any objections agains extracting
> all the relevant material, filling the missing pieces (if any),
> and turning the result into a MPLS WG document. 
> 
> Yakov.
> 


From owner-mpls@UU.NET  Tue Jun 13 17:56:08 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23686
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 17:56:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitln27640;
	Tue, 13 Jun 2000 21:56:05 GMT
Received: by mail-control.mail.uu.net 
	id QQitln17914
	for mpls-outgoing; Tue, 13 Jun 2000 21:55:49 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitln17909
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 21:55:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitln20574
	for <mpls@uu.net>; Tue, 13 Jun 2000 17:55:34 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitln09763
	for <mpls@uu.net>; Tue, 13 Jun 2000 21:55:34 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA00384
	for mpls@uu.net; Tue, 13 Jun 2000 17:55:33 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitln17856
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 21:55:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitln06157
	for <mpls@UU.NET>; Tue, 13 Jun 2000 17:54:47 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQitln09243
	for <mpls@UU.NET>; Tue, 13 Jun 2000 21:54:46 GMT
Received: from pluris.com (root@lightning.pluris.com [172.16.55.100])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA19332;
	Tue, 13 Jun 2000 14:54:44 -0700 (PDT)
Message-ID: <3946ADA3.AF22C724@pluris.com>
Date: Tue, 13 Jun 2000 14:54:43 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yakov Rekhter <yakov@cisco.com>
CC: mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <200006131929.MAA04931@omega.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I would support this.

Bora


Yakov Rekhter wrote:

> Folks,
>
> Given the recent e-mail exchange on the topic of hierarchical
> tunnel establishment in RSVP-TE, and given that most (but probably
> not all) the relevant material is covered under the notion of
> Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
> I wonder whether there would be any objections agains extracting
> all the relevant material, filling the missing pieces (if any),
> and turning the result into a MPLS WG document.
>
> Yakov.




From owner-mpls@UU.NET  Tue Jun 13 19:36:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24963
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 19:36:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitlu10059;
	Tue, 13 Jun 2000 23:36:20 GMT
Received: by mail-control.mail.uu.net 
	id QQitlu12904
	for mpls-outgoing; Tue, 13 Jun 2000 23:36:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitlu12861
	for <mpls@mail-control.mail.uu.net>; Tue, 13 Jun 2000 23:35:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitlu04601
	for <mpls@UU.NET>; Tue, 13 Jun 2000 19:35:40 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQitlu26253
	for <mpls@UU.NET>; Tue, 13 Jun 2000 23:35:40 GMT
Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP;
          Wed, 14 Jun 2000 00:34:35 +0100
Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2651.88) 
          id <MCGXG1FP>; Wed, 14 Jun 2000 00:34:26 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B16082@mbddmknt01.hc.bt.com>
To: curtis@avici.com, kireeti@juniper.net
Cc: mpls@UU.NET
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Wed, 14 Jun 2000 00:34:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis is making an important observation towards the end of his comments
below.........which, if we remove the specific case that is being considered
here, boils down to the more generic question 'where is the LSP trail
termination point?'.  Further, I was just looking through
draft-ietf-mpls-diff-ext-05.txt and several issues struck me that are all
related to the discussion here.  For example (this is not exhaustive).

Since the LSP trail termination is a movable feast (thanks to the notion of
PHP) then this will impact:
-	defect processing...and indeed OAM functional arch [The point that
Curtis makes below]
-	restoration/prot-sw processing.....since this is dependent on above,
and of course knowing where the correct source/sink end points of the LSP
are
-	QoS processing....since this is dependent on above
-	TTL processing ....though this is an orthogonal issue
-	DS processing.......which is what draft-ietf-mpls-diff-ext-05.txt
discusses.

One final observation......in draft-ietf-mpls-diff-ext-05.txt it says that
the choice of the 'uniform' or 'pipe' model is done on a LSR basis.  I have
the concern that this may need to be done on a per LSP basis (and not on a
per LSR basis).  If true, this will get very messy on interworking and might
incur significant configuration problems.

Regards, Neil



> -----Original Message-----
> From:	Curtis Villamizar [SMTP:curtis@avici.com]
> Sent:	Tuesday, June 13, 2000 3:16 PM
> To:	Kireeti Kompella
> Cc:	curtis@avici.com; mpls@UU.NET
> Subject:	Re: Hierarchical Tunnel Establishment in RSVP-TE 
> 
> 
> In message <200006130658.XAA20801@kummer.juniper.net>, Kireeti Kompella
> writes:
> > > Two POPs are needed to terminate a VPN tunnel.
> > 
> > Not if you use PHP.  You start popping one hop earlier, e.g., if
> > X is the PE attached to the customer, and Y the penultimate hop,
> > Y pops the "outer label" and forwards the packet with the "inner
> > label" identifying the VPN to X.  X looks at the inner (only!)
> > label, pops it and knows which customer to forward the packet to.
> > 
> > Corner case: a one-hop LSP carrying VPN info: don't put any "outer
> > label" in this case.
> > 
> > > Three might be needed
> > > if the outer tunnel on the VPN took its last hop through a FA-PSC.
> > 
> > Picture time:
> > 
> >     A ---- B ==== C ==== D ==== E ~~~~ customer
> >             <-43-  <-28-  <--3-
> >     <--71-- <-------- 3 -------
> > 
> >     <-- 32 for VPN to customer --
> > 
> > There's an FA-LSP from B to E.  E sends D an implicit NULL label,
> > D sends C label 28, C sends B 43.
> > 
> > Now, there's another LSP that wants to tunnel through the above
> > FA-LSP.  This LSP has 2 hops, A->B and B->E.  E sends B label 3,
> > B sends A label 71.
> > 
> > A and E agree on label 32 for the VPN.
> > 
> > The label stack for a packet to the customer is as follows:
> > 
> >     A ---- B ==== C ==== D ==== E ~~~~ customer
> >               43     28
> >        71
> >        32     32     32     32
> > 
> > Note that 71 -> 43 is not really a swap as much as a pop (PHP),
> > followed by a push (equivalent, but you get there differently).
> > 
> > It is interesting to first work out the case where the tunneled
> > LSP terminates beyond the tail of the FA-LSP, as the above example
> > is another 'corner case'.
> > 
> > Kireeti.
> 
> 
> Kireeti,
> 
> PHP does remove POPs and make it easier to implement an egress LSR but
> it makes it very hard to collect statistics of packets and bytes
> received on an LSP at the egress.  Recall the discussion of OAM and
> loss measurements.  There is no way to count at the egress if the
> labels are lost.  Therefore in your example there is no way to
> determine loss over the FA-PSC tunnel or over the tunnel from A-E.
> 
> Curtis


From owner-mpls@UU.NET  Tue Jun 13 20:04:17 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25282
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 20:04:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitlw26625;
	Wed, 14 Jun 2000 00:04:13 GMT
Received: by mail-control.mail.uu.net 
	id QQitlw23970
	for mpls-outgoing; Wed, 14 Jun 2000 00:03:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitlw23941
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 00:03:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitlw24792
	for <mpls@uu.net>; Tue, 13 Jun 2000 20:03:16 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQitlw25983
	for <mpls@uu.net>; Wed, 14 Jun 2000 00:03:16 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA01607
	for <mpls@uu.net>; Tue, 13 Jun 2000 20:03:09 -0400 (EDT)
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 UAA05956
	for <mpls@uu.net>; Tue, 13 Jun 2000 20:03:10 -0400 (EDT)
Message-ID: <3946CBEC.C141CB6B@marconi.com>
Date: Tue, 13 Jun 2000 20:03:56 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: RSVP: Proper behavior when an interface goes down
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

When an interface goes down (either administratively or otherwise), and
there is an outstanding RSVP-TE session (path and maybe resv) on that
interface, what specifically shoudl happen.

Obviously, any Path and Resv that was received on that post should be
torn down.  (Possibly after a delay, to dampen the effects of possible
interface flapping.)

What I'm unclear on is if a PathErr should be sent as well.

If a Path arrives with an ERO object, and there is no route to the
next-hop in the ERO, a PathErr message is sent out (with Routing Problem
as the error code and and an appropriate error value).

Now, if there is a Path already established, and the outgoing interface
goes down, such that the next-hop from the ERO is no longer reachable,
should the switch send this PathErr message back to the sender?

Or should it do nothing and rely exclusively on the local IGP to
propagate the network topology change back to the sender, which can then
take action (like initiate a make-before-break reroute, or something
else.)

-- David


From owner-mpls@UU.NET  Tue Jun 13 20:10:26 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25377
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 20:10:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitlw17265;
	Wed, 14 Jun 2000 00:10:21 GMT
Received: by mail-control.mail.uu.net 
	id QQitlw24476
	for mpls-outgoing; Wed, 14 Jun 2000 00:09:56 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitlw24471
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 00:09:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitlw08643
	for <mpls@UU.NET>; Tue, 13 Jun 2000 20:09:42 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQitlw16614
	for <mpls@UU.NET>; Wed, 14 Jun 2000 00:09:41 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA15533;
	Tue, 13 Jun 2000 17:09:20 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id RAA23169; Tue, 13 Jun 2000 17:09:20 -0700 (PDT)
Date: Tue, 13 Jun 2000 17:09:20 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006140009.RAA23169@kummer.juniper.net>
To: curtis@avici.com, kireeti@juniper.net, neil.2.harrison@bt.com
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

> Observation/plea:
> 
> I am getting increasingly concerned that we have an MPLS trail object, ie an
> LSP, but that the trail termination points (either source or sink) seem to
> be a movable feast depending on (i) different people's interpetation of the
> IDs produced to date, and/or (ii) the functional behaviour that is being
> considered.  Can I therefore make the plea that if a further informational
> ID is produced to clarify these matters (which Bora orginally suggested)
> that we make sure that there is architectural consistency across all
> functional behaviour wrt to where the trail termination points are.

I don't think that the LSP termination point is a movable feast.
However, there *are* three types of terminations: PHP, label 0 (for
IPv4), and a regular (i.e., non-reserved) label.  Implementations
seem to be converging on the first (PHP), but that might just be
tunnel vision on my part.  Using a real label requires something
along the lines of "pop, send packet back to self, do another lookup"
which may or may not be acceptable as a normal mode of operation.

Note that in either the PHP or label 0 cases, almost all useful info
about the LSP carrying the packet is lost (we just had a thread of
discussion on this).  LSP stats at the egress (for example) are a
victim of PHP/label 0.

However, if the reason for wanting to know which LSP the packet came
in on is OAM, then there are other solutions (e.g., having the OAM
packet carry this info), in which case PHP or label 0 works fine
for data packets.

Kireeti.


From owner-mpls@UU.NET  Tue Jun 13 20:48:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25812
	for <mpls-archive@lists.ietf.org>; Tue, 13 Jun 2000 20:48:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitlz09508;
	Wed, 14 Jun 2000 00:48:04 GMT
Received: by mail-control.mail.uu.net 
	id QQitlz26596
	for mpls-outgoing; Wed, 14 Jun 2000 00:47:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitlz26591
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 00:47:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitlz00429
	for <mpls@UU.NET>; Tue, 13 Jun 2000 20:47:17 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitlz20733
	for <mpls@UU.NET>; Wed, 14 Jun 2000 00:47:09 GMT
Received: from avici.com (swdev23.avici.com [10.1.2.229])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id UAA26684; Tue, 13 Jun 2000 20:47:01 -0400 (EDT)
Message-Id: <200006140047.UAA26684@mailhost.avici.com>
X-Mailer: exmh version 2.1.1 10/15/1999
From: Markus Jork <mjork@avici.com>
To: mpls@UU.NET
Cc: David Charlap <david.charlap@marconi.com>
Subject: Re: RSVP: Proper behavior when an interface goes down 
In-reply-to: Your message of "Tue, 13 Jun 2000 20:03:56 EDT."
             <3946CBEC.C141CB6B@marconi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 13 Jun 2000 20:47:00 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

David,

> If a Path arrives with an ERO object, and there is no route to the
> next-hop in the ERO, a PathErr message is sent out (with Routing Problem
> as the error code and and an appropriate error value).
> 
> Now, if there is a Path already established, and the outgoing interface
> goes down, such that the next-hop from the ERO is no longer reachable,
> should the switch send this PathErr message back to the sender?
> 
> Or should it do nothing and rely exclusively on the local IGP to
> propagate the network topology change back to the sender, which can then
> take action (like initiate a make-before-break reroute, or something
> else.)

Sending the PathErr message immediately is the right thing to do
because it provides the tunnel ingress with timely feedback that the LSP
went down.

Markus



From owner-mpls@UU.NET  Wed Jun 14 01:06:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01208
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 01:06:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitmq03683;
	Wed, 14 Jun 2000 05:06:08 GMT
Received: by mail-control.mail.uu.net 
	id QQitmq26084
	for mpls-outgoing; Wed, 14 Jun 2000 05:05:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitmq26067
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 05:05:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitmq02407
	for <mpls@uu.net>; Wed, 14 Jun 2000 01:05:32 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQitmq21290
	for <mpls@uu.net>; Wed, 14 Jun 2000 05:05:25 GMT
Received: from Seth (seth [165.133.13.20])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id KAA16188
	for <mpls@uu.net>; Wed, 14 Jun 2000 10:30:00 -0600 (GMT)
Message-ID: <006801bfd5ec$84a27260$140d85a5@dti.daewoo.co.kr>
From: "Naveen Seth" <seth@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: Egress Targeted Label Assignment
Date: Wed, 14 Jun 2000 10:37:14 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0065_01BFD5EC.81107200"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01BFD5EC.81107200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

In the case of egress targeted LSPs, the mpls architecture mentions =
possible ways for finding the egress by the ingress.

In the case of link state routing algorithm, it mentions that the =
routing algorithm provides enough information to the ingress to =
determine the egress.

I am not very sure how to achieve this kind of interoperability. Does it =
also imply that the IGP(Link State) and MPLS components have to be =
tightly coupled?

Any help in this regard....

thanks
Naveen

------=_NextPart_000_0065_01BFD5EC.81107200
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY background=3D"" bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>In the case of egress targeted LSPs, the mpls =
architecture=20
mentions possible ways for finding the egress by the =
ingress.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>In the case of link state routing algorithm, it =
mentions that=20
the routing algorithm provides enough information to the ingress to =
determine=20
the egress.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I am not very sure how to achieve this kind of=20
interoperability. Does it also imply that the IGP(Link State) and MPLS=20
components have to be tightly coupled?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Any help in this regard....</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>thanks</FONT></DIV>
<DIV><FONT size=3D2>Naveen</FONT></DIV></BODY></HTML>

------=_NextPart_000_0065_01BFD5EC.81107200--



From owner-mpls@UU.NET  Wed Jun 14 06:59:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15221
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 06:59:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitnn08314;
	Wed, 14 Jun 2000 10:59:46 GMT
Received: by mail-control.mail.uu.net 
	id QQitnn26779
	for mpls-outgoing; Wed, 14 Jun 2000 10:59:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitnn26774
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 10:59:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitnn12534
	for <mpls@uu.net>; Wed, 14 Jun 2000 06:59:00 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitnn07659
	for <mpls@uu.net>; Wed, 14 Jun 2000 10:59:00 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA14755
	for mpls@uu.net; Wed, 14 Jun 2000 06:58:59 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitnn26761
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 10:58:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitnn12466
	for <mpls@uu.net>; Wed, 14 Jun 2000 06:58:28 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQitnn07336
	for <mpls@uu.net>; Wed, 14 Jun 2000 10:58:28 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15101;
	Wed, 14 Jun 2000 06:58:27 -0400 (EDT)
Message-Id: <200006141058.GAA15101@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-applic-01.txt
Date: Wed, 14 Jun 2000 06:58:26 -0400
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		: LDP Applicability
	Author(s)	: B. Thomas, E. Gray
	Filename	: draft-ietf-mpls-ldp-applic-01.txt
	Pages		: 6
	Date		: 13-Jun-00
	
Multiprotocol Label Switching (MPLS) is a method for forwarding
packets that uses short, fixed-length values carried by packets,
called labels, to determine packet nexthops ([MPLS-FRAMEWORK],
[MPLS-ARCH]).  A fundamental concept in MPLS is that two Label
Switching Routers (LSRs) must agree on the meaning of the labels used
to forward traffic between and through them.  This common
understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of
label bindings it has made.  This document describes the
applicability of a set of such procedures called LDP (for Label
Distribution Protocol) [LDP] by which LSRs distribute labels to
support MPLS forwarding along normally routed paths.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-applic-01.txt

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-applic-01.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-applic-01.txt

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

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

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Wed Jun 14 07:47:08 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16395
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 07:47:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitnr04964;
	Wed, 14 Jun 2000 11:47:03 GMT
Received: by mail-control.mail.uu.net 
	id QQitnr08773
	for mpls-outgoing; Wed, 14 Jun 2000 11:46:25 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitnr08766
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 11:46:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitnr17844
	for <mpls@UU.NET>; Wed, 14 Jun 2000 07:46:08 -0400 (EDT)
Received: from cosmos.lgic.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [210.112.199.115])
	id QQitnr04250
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:46:06 GMT
Received: from AEC010W ([150.150.56.10]) by cosmos.lgic.co.kr (8.8.8/8.8.8) with SMTP id UAA20741 for <mpls@UU.NET>; Wed, 14 Jun 2000 20:44:15 +0900 (KST)
Message-ID: <007001bfd5f6$35011e00$0a389696@rex.lgic.co.kr>
Reply-To: "Yongjun Im" <yjim@lgic.co.kr>
From: "Yongjun Im" <yjim@lgic.co.kr>
To: <mpls@UU.NET>
Subject: Interoperability among Label Encoding.
Date: Wed, 14 Jun 2000 20:45:19 +0900
Organization: LG Information & Communications
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4029.2901
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id HAA16395

Dear Sir/Madam,

I have some questions about interoperability among 
MPLS label encoding.

The following paragraphs are cited from "draft-ietf-mpls-arch-06.txt".

"3.25.3. Interoperability among Encoding Techniques
   
   Unfortunately, ATM switches have no capability for translating from
   one encoding technique to another.  The MPLS architecture therefore
   requires that whenever it is possible for two ATM switches to be
   successive LSRs along a level m LSP for some packet, that those two
   ATM switches use the same encoding technique.

   Naturally there will be MPLS networks which contain a combination of
   ATM switches operating as LSRs, and other LSRs which operate using an
   MPLS shim header. In such networks there may be some LSRs which have
   ATM interfaces as well as "MPLS Shim" interfaces. This is one example
   of an LSR with different label stack encodings on different hops.
   Such an LSR may swap off an ATM encoded label stack on an incoming
   interface and replace it with an MPLS shim header encoded label stack
   on the outgoing interface."


The following figure shows an example of interoperability among
shim header(e.g, POS, GbE etc) and ATM header(vpi/vci).
        
        R1------R2------R3                 R6-----R7-----R8.
                                        \              /   
                                        R4------R5                                               
         Shim Header                ATM          Shim Header .
            (POS)                                             (GbE)
        
In the example, LSP consists of LSR R1,R2,..,R7,R8.
R1 and R2 have only POS interfaces.
R4 and R5 have only ATM interfaces.
R7 and R8 have only Gigabit Ethernet interfaces.
R3 have POS and ATM interfaces.
R6 have ATM and GbE interfaces.

Q1: 
When LSR R3 receives a shim-labled packet from R2,
does it swaps off a shim header(POS) on an incoming interface,
encapsulate an IP packet(or fragment) with AAL5 (including ATM shim header),
and forward the segmented cells including ATM label(vpi/vci) to R4 ?

Q2: 
When LSR R5 receives a ATM-labled packet from R5,
does it swaps off a ATM label on an incoming interface,
reassemble AAL5 packet (including shim header),
swap off a AAL5 shim header,
encapsulate an IP packet with MAC frame(including new shim header),
and forwards the MAC frame to R7 ?

Any response will be appreciated.

Thanks in advance.

Best regards.

Yongjun 
   
-----------------------------------------------------------------
Yong-Jun Im (in Korean: ÀÓ¿ëÁØ)
Research Engineer
Digital Switching System Lab., LGIC R&D Center
533, Hogye-dong, Dongan-gu, Anyang-shi, Kyonggi-do, 431-080, KOREA
E-mail) yjim@lgic.co.kr  Office) +82-343-450-7750
Fax) +82-343-450-7009   Mobile) +82-11-201-8248
-----------------------------------------------------------------


From owner-mpls@UU.NET  Wed Jun 14 09:20:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19467
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 09:20:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitnx12985;
	Wed, 14 Jun 2000 13:20:14 GMT
Received: by mail-control.mail.uu.net 
	id QQitnx02947
	for mpls-outgoing; Wed, 14 Jun 2000 13:19:43 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitnx02942
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 13:19:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitnx09395
	for <mpls@UU.NET>; Wed, 14 Jun 2000 09:19:23 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitnx01863
	for <mpls@UU.NET>; Wed, 14 Jun 2000 13:19:23 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id JAA02324; Wed, 14 Jun 2000 09:19:20 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id JAA23398;
	Wed, 14 Jun 2000 09:19:46 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006141319.JAA23398@curtis-lt.avici.com>
To: "Abes, Andi" <aabes@quarrytech.com>
cc: curtis@avici.com, Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Tue, 13 Jun 2000 12:31:18 EDT."
             <496A8683261CD211BF6C0008C733261A48D202@email.quarrytech.com> 
Date: Wed, 14 Jun 2000 09:19:46 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <496A8683261CD211BF6C0008C733261A48D202@email.quarrytech.com>, "Abes
, Andi" writes:
> Curtis,
> 
> The PHP options brings up a question that I've asked a 
> long time ago, but went un-answered:
> Are "inner" labels restricted to be from the "platform"
> label pool ?
> Are there implementations that use "per-interface" label 
> pools to allocate inner labels ?
> 
> It is concivable that an implementation will choose to
> define an LSP (or set of them) as an interface. And, on
> top of this interface manage a "per-interface" label pool.
> This can help simplify routing for example.
> 
> If this is allowed, then the PHP solution will break, since
> only the outer label identifys the incomming "interface".
> 
> Andi.


I makes sense for the inner labels to be per platform because the
outer label can be rerouted and end up coming in on another interface.
If that reroute occurs cleanly (make before break), it should not be
nessecary to reroute the inner labels.

Curtis


From owner-mpls@UU.NET  Wed Jun 14 09:30:19 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19793
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 09:30:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitny20385;
	Wed, 14 Jun 2000 13:30:15 GMT
Received: by mail-control.mail.uu.net 
	id QQitnx03459
	for mpls-outgoing; Wed, 14 Jun 2000 13:29:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitnx03454
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 13:29:41 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitnx04585
	for <mpls@UU.NET>; Wed, 14 Jun 2000 09:29:34 -0400 (EDT)
Received: from nero.doit.wisc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQitnx19622
	for <mpls@UU.NET>; Wed, 14 Jun 2000 13:29:34 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id IAA14141;
	Wed, 14 Jun 2000 08:29:29 -0500
Message-ID: <20000614082929.B14081@doit.wisc.edu>
Date: Wed, 14 Jun 2000 08:29:29 -0500
From: "James R. Leu" <jleu@mindspring.com>
To: curtis@avici.com, "Abes, Andi" <aabes@quarrytech.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Reply-To: jleu@mindspring.com
References: <496A8683261CD211BF6C0008C733261A48D202@email.quarrytech.com> <200006141319.JAA23398@curtis-lt.avici.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <200006141319.JAA23398@curtis-lt.avici.com>; from Curtis Villamizar on Wed, Jun 14, 2000 at 09:19:46AM -0400
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:
<snip>

> I makes sense for the inner labels to be per platform because the
> outer label can be rerouted and end up coming in on another interface.
> If that reroute occurs cleanly (make before break), it should not be
> nessecary to reroute the inner labels.
> 
> Curtis

Are your saying that an ILM will have labels from multiple labelspaces?
That would require the label manager to do co-ordination of every label
allocation.

Or, are you saying that you have a special outer label which points to a new
ILM for all future lookups?  Depending how you implement this it will break the
proccesing when it is "IPv4 or label" under the top label.
(plus I don't think hardware implementors will like this approach)

Jim
-- 
James R. Leu


From owner-mpls@UU.NET  Wed Jun 14 09:55:51 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20730
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 09:55:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitnz08695;
	Wed, 14 Jun 2000 13:55:47 GMT
Received: by mail-control.mail.uu.net 
	id QQitnz05248
	for mpls-outgoing; Wed, 14 Jun 2000 13:55:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitnz05239
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 13:55:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitnz09697
	for <mpls@UU.NET>; Wed, 14 Jun 2000 09:54:44 -0400 (EDT)
Received: from nausicaa.coritel.it by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [193.205.242.5])
	id QQitnz26066
	for <mpls@UU.NET>; Wed, 14 Jun 2000 13:54:32 GMT
Received: from coritel.it ([160.80.81.146])
	by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id PAA01202
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:45:32 +0200 (MET DST)
Message-ID: <39478E8E.2D6260DE@coritel.it>
Date: Wed, 14 Jun 2000 15:54:23 +0200
From: Alessandro Bosco <bosco@coritel.it>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Information about optical routing in MPLS net.
Content-Type: multipart/mixed;
 boundary="------------F525A1AC69A17EF485D8DB4C"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

Dear Sir/Madam,

I have some questions about routing within an optical MPLS networks
(MPLS/MPL(ambda)S).

In the draft "Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control With Optical Cross-connects", it is affirmed the
following phrase:

" The proposed OXC control plane uses the IGP extensions for MPLS
traffic engineering to distribute relevant optical transport network
state information, including topology state information. This state
information is subsequently used by a constraint-based routing system to
compute paths for point-to-point optical channels through the optical
transport network."

I would like to know if:

a. Considering explicit paths calculation through an optical MPLS
network, ingress
    routers or third part tools, at the input of the network, will still
calculate the
    entire path (ingress to egress router), considering links within the
optical domain
    too?

b. Or, "new" OXCs, that use a control plane extended from MPLS traffic
    engineering control module, will be able to do optical routing, I
mean optical path
    calculation at the input of optical domain?

c. In the MPL(ambda)s framework, "new" OXCs has to be seen like optical
    routers?

Any response will be very appreciated.

Thanks in advance.

Best regards.

Alessandro

--------------F525A1AC69A17EF485D8DB4C
Content-Type: text/x-vcard; charset=us-ascii;
 name="bosco.vcf"
Content-Description: Card for Alessandro Bosco
Content-Disposition: attachment;
 filename="bosco.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Bosco;Alessandro
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:bosco@coritel.it
fn:Alessandro Bosco
end:vcard

--------------F525A1AC69A17EF485D8DB4C--



From owner-mpls@UU.NET  Wed Jun 14 11:05:15 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24430
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:05:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitoe26723;
	Wed, 14 Jun 2000 15:05:09 GMT
Received: by mail-control.mail.uu.net 
	id QQitoe24824
	for mpls-outgoing; Wed, 14 Jun 2000 15:04:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitoe24609
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:04:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitod28216
	for <mpls@UU.NET>; Wed, 14 Jun 2000 10:55:22 -0400 (EDT)
Received: from osf1.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: osf1.gmu.edu [129.174.1.13])
	id QQitod09090
	for <mpls@UU.NET>; Wed, 14 Jun 2000 14:55:20 GMT
Received: from localhost (rpapneja@localhost)
	by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id KAA21170;
	Wed, 14 Jun 2000 10:54:00 -0400 (EDT)
Date: Wed, 14 Jun 2000 10:54:00 -0400 (EDT)
From: Rajiv Papneja <rpapneja@osf1.gmu.edu>
To: Yongjun Im <yjim@lgic.co.kr>
cc: mpls@UU.NET
Subject: Re: Interoperability among Label Encoding.
In-Reply-To: <007001bfd5f6$35011e00$0a389696@rex.lgic.co.kr>
Message-ID: <Pine.OSF.4.21.0006141014080.10269-100000@osf1.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id LAA24430

On Wed, 14 Jun 2000, Yongjun Im wrote:

Hi Yongjun,

 In the scenario you discussed here, probably you mean that the R4 and R5
are having LC-ATM interfaces (constituting an ATM-LSR domain) that
forwards cells between these interfaces using labels carried in the VCI
or VCI/VPI fields, without reassembling cells into the frames before
forwarding and if I am correct R3 and R6 are the members of the Edge Set
of an ATM-LSR domain.

 For both of your questions please refer to the draft
draft-ietf-mpls-atm-03.txt section 8, 9 and 10 if you are using LDP in the
setup you mentioned.


 Regards
 Rajiv       


> Dear Sir/Madam,
> 
> I have some questions about interoperability among 
> MPLS label encoding.
> 
> The following paragraphs are cited from "draft-ietf-mpls-arch-06.txt".
> 
> "3.25.3. Interoperability among Encoding Techniques
>    
>    Unfortunately, ATM switches have no capability for translating from
>    one encoding technique to another.  The MPLS architecture therefore
>    requires that whenever it is possible for two ATM switches to be
>    successive LSRs along a level m LSP for some packet, that those two
>    ATM switches use the same encoding technique.
> 
>    Naturally there will be MPLS networks which contain a combination of
>    ATM switches operating as LSRs, and other LSRs which operate using an
>    MPLS shim header. In such networks there may be some LSRs which have
>    ATM interfaces as well as "MPLS Shim" interfaces. This is one example
>    of an LSR with different label stack encodings on different hops.
>    Such an LSR may swap off an ATM encoded label stack on an incoming
>    interface and replace it with an MPLS shim header encoded label stack
>    on the outgoing interface."
> 
> 
> The following figure shows an example of interoperability among
> shim header(e.g, POS, GbE etc) and ATM header(vpi/vci).
>         
>         R1------R2------R3                 R6-----R7-----R8.
>                                         \              /   
>                                         R4------R5                                               
>          Shim Header                ATM          Shim Header .
>             (POS)                                             (GbE)
>         
> In the example, LSP consists of LSR R1,R2,..,R7,R8.
> R1 and R2 have only POS interfaces.
> R4 and R5 have only ATM interfaces.
> R7 and R8 have only Gigabit Ethernet interfaces.
> R3 have POS and ATM interfaces.
> R6 have ATM and GbE interfaces.
> 
> Q1: 
> When LSR R3 receives a shim-labled packet from R2,
> does it swaps off a shim header(POS) on an incoming interface,
> encapsulate an IP packet(or fragment) with AAL5 (including ATM shim header),
> and forward the segmented cells including ATM label(vpi/vci) to R4 ?
> 
> Q2: 
> When LSR R5 receives a ATM-labled packet from R5,
> does it swaps off a ATM label on an incoming interface,
> reassemble AAL5 packet (including shim header),
> swap off a AAL5 shim header,
> encapsulate an IP packet with MAC frame(including new shim header),
> and forwards the MAC frame to R7 ?
> 
> Any response will be appreciated.
> 
> Thanks in advance.
> 
> Best regards.
> 
> Yongjun 
>    
> -----------------------------------------------------------------
> Yong-Jun Im (in Korean: ÀÓ¿ëÁØ)
> Research Engineer
> Digital Switching System Lab., LGIC R&D Center
> 533, Hogye-dong, Dongan-gu, Anyang-shi, Kyonggi-do, 431-080, KOREA
> E-mail) yjim@lgic.co.kr  Office) +82-343-450-7750
> Fax) +82-343-450-7009   Mobile) +82-11-201-8248
> -----------------------------------------------------------------
> 

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4700
email: rpapneja@osf1.gmu.edu
********************************




From owner-mpls@UU.NET  Wed Jun 14 11:09:20 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24608
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:09:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitoe19329;
	Wed, 14 Jun 2000 15:09:16 GMT
Received: by mail-control.mail.uu.net 
	id QQitoe28428
	for mpls-outgoing; Wed, 14 Jun 2000 15:08:35 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitoe28232
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:08:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitoe25627
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:08:04 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQitoe29252
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:08:04 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA20246;
	Wed, 14 Jun 2000 08:08:12 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA02959; Wed, 14 Jun 2000 11:08:01 -0400 (EDT)
Message-Id: <200006141508.LAA02959@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: "Abes, Andi" <aabes@quarrytech.com>
cc: curtis@avici.com, Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of Tue, 13 Jun 2000 12:31:18 -0400.
             <496A8683261CD211BF6C0008C733261A48D202@email.quarrytech.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 14 Jun 2000 11:08:01 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Andi> The PHP options brings up a question that I've asked a 
Andi> long time ago, but went un-answered:
Andi> Are "inner" labels restricted to be from the "platform"
Andi> label pool ?

The only restriction is that you need to be able to interpret the label. 

If you always use a per-platform  label space only, you never have a problem
with this. 

If you want to  use a per-interface label space, you need  to do whatever it
takes to ensure that when you receive  a packet whose top label is from that
space, you  will be  able to determine  that the  label is from  that space.
This really means that you need to  be able to determine which of your label
distribution peers put the label on.

Andi> Are there implementations that use "per-interface" label 
Andi> pools to allocate inner labels ?

Andi> It is concivable that an implementation will choose to
Andi> define an LSP (or set of them) as an interface. And, on
Andi> top of this interface manage a "per-interface" label pool.
Andi> This can help simplify routing for example. 

In general, a router needs to know  which interface a packet came in on.  If
you are  treating an LSP as an  interface, therefore, you cannot  do PHP for
that LSP, or  you won't be able to  tell that an arriving packet  came in on
this interface.  In  this case, there is no reason why  the label beneath it
might not be from a per-interface label space; once you know the "interface"
over which the packet arrived, you know who put on the next label. 

However, depending on how you are setting up the LSP interface, you may want
the top label to come from a platform-specific space.

Andi> If this is allowed, then the PHP solution will break, since
Andi> only the outer label identifys the incoming "interface". 

The LSR on the receiving end  of the "interface" always has complete control
over whether  PHP is done, so  nothing breaks if the  implementation is done
correctly. 


From owner-mpls@UU.NET  Wed Jun 14 11:18:56 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24948
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:18:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitof07186;
	Wed, 14 Jun 2000 15:18:52 GMT
Received: by mail-control.mail.uu.net 
	id QQitof00779
	for mpls-outgoing; Wed, 14 Jun 2000 15:18:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitof00774
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:18:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitof27720
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:17:31 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQitof06061
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:17:30 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA28209;
	Wed, 14 Jun 2000 08:17:39 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA02988; Wed, 14 Jun 2000 11:17:28 -0400 (EDT)
Message-Id: <200006141517.LAA02988@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: jleu@mindspring.com
cc: curtis@avici.com, "Abes, Andi" <aabes@quarrytech.com>,
        Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of Wed, 14 Jun 2000 08:29:29 -0500.
             <20000614082929.B14081@doit.wisc.edu> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 14 Jun 2000 11:17:28 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Jim> Are your saying that an ILM will have labels from multiple labelspaces?
Jim> That would require the label manager to do co-ordination of every label
Jim> allocation. 

In general, if you are  supporting a platform-specific label space, and also
supporting  one or  more per-interface  label spaces,  the platform-specific
label space will need to be distinct from the per-interface label spaces. 

I think  that the simplest thing is  just to use a  per-platform label space
(except in ATM,  of course).  You can still maintain the  notion that only a
subset of the  labels have been assigned to each  of your label distribution
peers, and  you can still  drop a packet  that arrives on a  given interface
with a top label  that wasn't assigned to the peer at  the other end of that
interface. 

Jim> Or, are you saying that you  have a special outer label which points to
Jim> a new ILM for all future lookups?  

As long as the platform-space  is distinct from the interface-space, you can
implement a single lookup table.

Jim> Depending how you  implement this it will break  the proccesing when it
Jim> is "IPv4 or label" under the top label. 

I would recommend that you implement it correctly rather than incorrectly ;-)

Jim> (plus I don't think hardware implementors will like this approach)

The  lookup tables  are set  up by  software, the  hardware guys  don't care
what's in them. 




From owner-mpls@UU.NET  Wed Jun 14 11:26:48 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25136
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:26:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitof12986;
	Wed, 14 Jun 2000 15:26:43 GMT
Received: by mail-control.mail.uu.net 
	id QQitof01541
	for mpls-outgoing; Wed, 14 Jun 2000 15:26:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitof01536
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:26:19 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitof29630
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:26:02 -0400 (EDT)
Received: from hoemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQitof12332
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:26:01 GMT
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA23263
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:26:01 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA23249;
	Wed, 14 Jun 2000 11:26:00 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA14968; Wed, 14 Jun 2000 11:25:59 -0400 (EDT)
Message-ID: <3947A408.3FB6285B@lucent.com>
Date: Wed, 14 Jun 2000 11:26:00 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alessandro Bosco <bosco@coritel.it>
CC: mpls@UU.NET
Subject: Re: Information about optical routing in MPLS net.
References: <39478E8E.2D6260DE@coritel.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Please see comments below:

> 
> a. Considering explicit paths calculation through an optical MPLS
> network, ingress
>     routers or third part tools, at the input of the network, will still
> calculate the
>     entire path (ingress to egress router), considering links within the
> optical domain
>     too?
> 

There have been discussions about this before. My personal opinion is that
having router control optical domain is not feasible both technically and
practically. 


> b. Or, "new" OXCs, that use a control plane extended from MPLS traffic
>     engineering control module, will be able to do optical routing, I
> mean optical path
>     calculation at the input of optical domain?


This is what I support. Optical path can be set up either through topology
driven, real-time traffic driven or traffic pattern driven. There have to be
extra functions and intelligence at the intersection of data domain and optical
domain. ODSI addresses some issues already. I am now thinking how COPS could be
extended to apply here. Any people interested in this topic?


> c. In the MPL(ambda)s framework, "new" OXCs has to be seen like optical
>     routers?
> 

If you mean optical router as optical packet router, then I don't think so.

Yangguang


From owner-mpls@UU.NET  Wed Jun 14 11:31:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25283
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:31:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitog16802;
	Wed, 14 Jun 2000 15:31:15 GMT
Received: by mail-control.mail.uu.net 
	id QQitog01900
	for mpls-outgoing; Wed, 14 Jun 2000 15:30:45 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitog01895
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:30:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitog05295
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:30:23 -0400 (EDT)
Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p1.globespan.net [209.191.59.250])
	id QQitog04959
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:30:23 GMT
Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21)
	id <M8JFXQ3V>; Wed, 14 Jun 2000 11:29:44 -0400
Message-ID: <4D0A8ECBDC8AD211BD0900A0C9EBC13301CCDD29@rambo.globespan.net>
From: Helpdesk MIS <AdminLogs@globespan.net>
Reply-To: jleu@mindspring.com
To: Ficon fils <Fils@globespan.net>
Cc: Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Date: Wed, 14 Jun 2000 11:29:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD615.5D2498C0"
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_01BFD615.5D2498C0
Content-Type: text/plain;
	charset="iso-8859-1"

From: James R. Leu

On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:
<snip>

> I makes sense for the inner labels to be per platform because the
> outer label can be rerouted and end up coming in on another interface.
> If that reroute occurs cleanly (make before break), it should not be
> nessecary to reroute the inner labels.
> 
> Curtis

Are your saying that an ILM will have labels from multiple labelspaces?
That would require the label manager to do co-ordination of every label
allocation.

Or, are you saying that you have a special outer label which points to a new
ILM for all future lookups?  Depending how you implement this it will break
the
proccesing when it is "IPv4 or label" under the top label.
(plus I don't think hardware implementors will like this approach)

Jim
-- 
James R. Leu

------_=_NextPart_001_01BFD615.5D2498C0
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.2650.12">
<TITLE>Re: Hierarchical Tunnel Establishment in RSVP-TE</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>From: James R. Leu</FONT>
</P>

<P><FONT SIZE=2>On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:</FONT>
<BR><FONT SIZE=2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=2>&gt; I makes sense for the inner labels to be per platform because the</FONT>
<BR><FONT SIZE=2>&gt; outer label can be rerouted and end up coming in on another interface.</FONT>
<BR><FONT SIZE=2>&gt; If that reroute occurs cleanly (make before break), it should not be</FONT>
<BR><FONT SIZE=2>&gt; nessecary to reroute the inner labels.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Curtis</FONT>
</P>

<P><FONT SIZE=2>Are your saying that an ILM will have labels from multiple labelspaces?</FONT>
<BR><FONT SIZE=2>That would require the label manager to do co-ordination of every label</FONT>
<BR><FONT SIZE=2>allocation.</FONT>
</P>

<P><FONT SIZE=2>Or, are you saying that you have a special outer label which points to a new</FONT>
<BR><FONT SIZE=2>ILM for all future lookups?&nbsp; Depending how you implement this it will break the</FONT>
<BR><FONT SIZE=2>proccesing when it is &quot;IPv4 or label&quot; under the top label.</FONT>
<BR><FONT SIZE=2>(plus I don't think hardware implementors will like this approach)</FONT>
</P>

<P><FONT SIZE=2>Jim</FONT>
<BR><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>James R. Leu</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD615.5D2498C0--


From owner-mpls@UU.NET  Wed Jun 14 11:31:52 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25318
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:31:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitog06143;
	Wed, 14 Jun 2000 15:31:49 GMT
Received: by mail-control.mail.uu.net 
	id QQitog02024
	for mpls-outgoing; Wed, 14 Jun 2000 15:31:25 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitog02016
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:31:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitog05475
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:31:00 -0400 (EDT)
Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p1.globespan.net [209.191.59.250])
	id QQitog05455
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:31:00 GMT
Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21)
	id <M8JFXQ38>; Wed, 14 Jun 2000 11:30:23 -0400
Message-ID: <4D0A8ECBDC8AD211BD0900A0C9EBC13301CCDD2A@rambo.globespan.net>
From: Helpdesk MIS <AdminLogs@globespan.net>
Reply-To: jleu@mindspring.com
To: curtis@avici.com, "Abes, Andi" <aabes@quarrytech.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Date: Wed, 14 Jun 2000 11:30:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD615.74638640"
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_01BFD615.74638640
Content-Type: text/plain;
	charset="iso-8859-1"

From: James R. Leu

On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:
<snip>

> I makes sense for the inner labels to be per platform because the
> outer label can be rerouted and end up coming in on another interface.
> If that reroute occurs cleanly (make before break), it should not be
> nessecary to reroute the inner labels.
> 
> Curtis

Are your saying that an ILM will have labels from multiple labelspaces?
That would require the label manager to do co-ordination of every label
allocation.

Or, are you saying that you have a special outer label which points to a new
ILM for all future lookups?  Depending how you implement this it will break
the
proccesing when it is "IPv4 or label" under the top label.
(plus I don't think hardware implementors will like this approach)

Jim
-- 
James R. Leu

------_=_NextPart_001_01BFD615.74638640
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.2650.12">
<TITLE>Re: Hierarchical Tunnel Establishment in RSVP-TE</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>From: James R. Leu</FONT>
</P>

<P><FONT SIZE=2>On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:</FONT>
<BR><FONT SIZE=2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=2>&gt; I makes sense for the inner labels to be per platform because the</FONT>
<BR><FONT SIZE=2>&gt; outer label can be rerouted and end up coming in on another interface.</FONT>
<BR><FONT SIZE=2>&gt; If that reroute occurs cleanly (make before break), it should not be</FONT>
<BR><FONT SIZE=2>&gt; nessecary to reroute the inner labels.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Curtis</FONT>
</P>

<P><FONT SIZE=2>Are your saying that an ILM will have labels from multiple labelspaces?</FONT>
<BR><FONT SIZE=2>That would require the label manager to do co-ordination of every label</FONT>
<BR><FONT SIZE=2>allocation.</FONT>
</P>

<P><FONT SIZE=2>Or, are you saying that you have a special outer label which points to a new</FONT>
<BR><FONT SIZE=2>ILM for all future lookups?&nbsp; Depending how you implement this it will break the</FONT>
<BR><FONT SIZE=2>proccesing when it is &quot;IPv4 or label&quot; under the top label.</FONT>
<BR><FONT SIZE=2>(plus I don't think hardware implementors will like this approach)</FONT>
</P>

<P><FONT SIZE=2>Jim</FONT>
<BR><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>James R. Leu</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD615.74638640--


From owner-mpls@UU.NET  Wed Jun 14 11:35:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25416
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:35:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitog20233;
	Wed, 14 Jun 2000 15:35:54 GMT
Received: by mail-control.mail.uu.net 
	id QQitog02270
	for mpls-outgoing; Wed, 14 Jun 2000 15:35:25 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitog02259
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:35:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitog06203
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:34:54 -0400 (EDT)
Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p1.globespan.net [209.191.59.250])
	id QQitog08315
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:34:54 GMT
Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21)
	id <M8JFXQQV>; Wed, 14 Jun 2000 11:34:16 -0400
Message-ID: <4D0A8ECBDC8AD211BD0900A0C9EBC13301CCDD2D@rambo.globespan.net>
From: Helpdesk MIS <AdminLogs@globespan.net>
Reply-To: curtis@avici.com
To: Sameer Shah <sshah@globespan.net>
Cc: curtis@avici.com, Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Wed, 14 Jun 2000 11:34:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD615.FF6AA660"
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_01BFD615.FF6AA660
Content-Type: text/plain;
	charset="iso-8859-1"

From: Curtis Villamizar


In message <496A8683261CD211BF6C0008C733261A48D202@email.quarrytech.com>,
"Abes
, Andi" writes:
> Curtis,
> 
> The PHP options brings up a question that I've asked a 
> long time ago, but went un-answered:
> Are "inner" labels restricted to be from the "platform"
> label pool ?
> Are there implementations that use "per-interface" label 
> pools to allocate inner labels ?
> 
> It is concivable that an implementation will choose to
> define an LSP (or set of them) as an interface. And, on
> top of this interface manage a "per-interface" label pool.
> This can help simplify routing for example.
> 
> If this is allowed, then the PHP solution will break, since
> only the outer label identifys the incomming "interface".
> 
> Andi.


I makes sense for the inner labels to be per platform because the
outer label can be rerouted and end up coming in on another interface.
If that reroute occurs cleanly (make before break), it should not be
nessecary to reroute the inner labels.

Curtis

------_=_NextPart_001_01BFD615.FF6AA660
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.2650.12">
<TITLE>Re: Hierarchical Tunnel Establishment in RSVP-TE </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>From: Curtis Villamizar</FONT>
</P>
<BR>

<P><FONT SIZE=2>In message &lt;496A8683261CD211BF6C0008C733261A48D202@email.quarrytech.com&gt;, &quot;Abes</FONT>
<BR><FONT SIZE=2>, Andi&quot; writes:</FONT>
<BR><FONT SIZE=2>&gt; Curtis,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The PHP options brings up a question that I've asked a </FONT>
<BR><FONT SIZE=2>&gt; long time ago, but went un-answered:</FONT>
<BR><FONT SIZE=2>&gt; Are &quot;inner&quot; labels restricted to be from the &quot;platform&quot;</FONT>
<BR><FONT SIZE=2>&gt; label pool ?</FONT>
<BR><FONT SIZE=2>&gt; Are there implementations that use &quot;per-interface&quot; label </FONT>
<BR><FONT SIZE=2>&gt; pools to allocate inner labels ?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It is concivable that an implementation will choose to</FONT>
<BR><FONT SIZE=2>&gt; define an LSP (or set of them) as an interface. And, on</FONT>
<BR><FONT SIZE=2>&gt; top of this interface manage a &quot;per-interface&quot; label pool.</FONT>
<BR><FONT SIZE=2>&gt; This can help simplify routing for example.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If this is allowed, then the PHP solution will break, since</FONT>
<BR><FONT SIZE=2>&gt; only the outer label identifys the incomming &quot;interface&quot;.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Andi.</FONT>
</P>
<BR>

<P><FONT SIZE=2>I makes sense for the inner labels to be per platform because the</FONT>
<BR><FONT SIZE=2>outer label can be rerouted and end up coming in on another interface.</FONT>
<BR><FONT SIZE=2>If that reroute occurs cleanly (make before break), it should not be</FONT>
<BR><FONT SIZE=2>nessecary to reroute the inner labels.</FONT>
</P>

<P><FONT SIZE=2>Curtis</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD615.FF6AA660--


From owner-mpls@UU.NET  Wed Jun 14 11:36:11 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25429
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:36:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitog09171;
	Wed, 14 Jun 2000 15:36:03 GMT
Received: by mail-control.mail.uu.net 
	id QQitog02275
	for mpls-outgoing; Wed, 14 Jun 2000 15:35:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitog02260
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:35:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitog06175
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:34:43 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitog08212
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:34:43 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id LAA13627; Wed, 14 Jun 2000 11:34:41 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA23728;
	Wed, 14 Jun 2000 11:35:04 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006141535.LAA23728@curtis-lt.avici.com>
To: neil.2.harrison@bt.com
cc: curtis@avici.com, kireeti@juniper.net, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Wed, 14 Jun 2000 00:34:24 BST."
             <B9571FDEBD3DD21181E500606DD5EE0507B16082@mbddmknt01.hc.bt.com> 
Date: Wed, 14 Jun 2000 11:35:04 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B9571FDEBD3DD21181E500606DD5EE0507B16082@mbddmknt01.hc.bt.com>, nei
l.2.harrison@bt.com writes:
> Curtis is making an important observation towards the end of his comments
> below.........which, if we remove the specific case that is being considered
> here, boils down to the more generic question 'where is the LSP trail
> termination point?'.  Further, I was just looking through
> draft-ietf-mpls-diff-ext-05.txt and several issues struck me that are all
> related to the discussion here.  For example (this is not exhaustive).

Since there may be some confusion about the reasons for doing or not
doing PHP, I'd like to provide a little more detail on some of these
tradeoffs.


> Since the LSP trail termination is a movable feast (thanks to the notion of
> PHP) then this will impact:
> -	defect processing...and indeed OAM functional arch [The point that
> Curtis makes below]

Pasted back here:

> > PHP does remove POPs and make it easier to implement an egress LSR but
> > it makes it very hard to collect statistics of packets and bytes
> > received on an LSP at the egress.  Recall the discussion of OAM and
> > loss measurements.  There is no way to count at the egress if the
> > labels are lost.  Therefore in your example there is no way to
> > determine loss over the FA-PSC tunnel or over the tunnel from A-E.


> -	restoration/prot-sw processing.....since this is dependent on above,
> and of course knowing where the correct source/sink end points of the LSP
> are

Restoration is not dependent on the above unless there is a disconnect
between signaling and forwarding as was discussed on the OAM thread.
If hardware and software are still working (ie: internal parity is
working, software hasn't gone insane), then defects in transmission
(ie: SONET layer detects fault) will be restored within 10s of msec if
local-protect is enabled and regardless of whether local protect is
used signaling will be sent to the ingress (path tear and IGP
flooding).  This is also why OAM has not been perceived as a need (not
until recently, and perhaps not with sufficient consensus).

> -	QoS processing....since this is dependent on above

This can be a problem.  If the same DSCP means something different
when it comes from two different ingress interfaces, then the
classification of traffic is lost when the PHP pop occurs.  This is
significant if that classification is needed by the egress LSR, since
it can no longer be recovered.

> -	TTL processing ....though this is an orthogonal issue

This seems to only affect the way TTL hiding is done (ie: decrementing
the IP TTL only once for the whole tunnel).

> -	DS processing.......which is what draft-ietf-mpls-diff-ext-05.txt
> discusses.
> 
> One final observation......in draft-ietf-mpls-diff-ext-05.txt it says that
> the choice of the 'uniform' or 'pipe' model is done on a LSR basis.  I have
> the concern that this may need to be done on a per LSP basis (and not on a
> per LSR basis).  If true, this will get very messy on interworking and might
> incur significant configuration problems.
> 
> Regards, Neil

The draft does preclude setting uniform or pipe on a per LSP basis.
This would need to be signalled.  The ingress should be able to
request one or the other.  The egress can then reject a request for
the model requested if it cannot support it (if the router is
configured for the other and does not have per LSP capability or the
router only supports one model).  The ingress can then decide whether
to accept the alternate model or not bring up the LSP.

I'm not sure that this flexibility is needed.  It may be better if the
wording in draft-ietf-mpls-diff-ext-05.txt declared the signaling to
set uniform or pipe on a per LSP basis as out of scope rather than
precluding it so that a later document can define the signaling if
there is a need.

Curtis


From owner-mpls@UU.NET  Wed Jun 14 11:47:52 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25752
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:47:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitoh28791;
	Wed, 14 Jun 2000 15:47:49 GMT
Received: by mail-control.mail.uu.net 
	id QQitoh03572
	for mpls-outgoing; Wed, 14 Jun 2000 15:47:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitoh03559
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:47:19 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitoh04189
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:47:06 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitoh28159
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:47:06 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id LAA14717; Wed, 14 Jun 2000 11:47:04 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id LAA23749;
	Wed, 14 Jun 2000 11:47:29 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006141547.LAA23749@curtis-lt.avici.com>
To: Kireeti Kompella <kireeti@juniper.net>
cc: curtis@avici.com, neil.2.harrison@bt.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Tue, 13 Jun 2000 17:09:20 PDT."
             <200006140009.RAA23169@kummer.juniper.net> 
Date: Wed, 14 Jun 2000 11:47:29 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200006140009.RAA23169@kummer.juniper.net>, Kireeti Kompella writes:
> > Observation/plea:
> > 
> > I am getting increasingly concerned that we have an MPLS trail object, ie a
> n
> > LSP, but that the trail termination points (either source or sink) seem to
> > be a movable feast depending on (i) different people's interpetation of the
> > IDs produced to date, and/or (ii) the functional behaviour that is being
> > considered.  Can I therefore make the plea that if a further informational
> > ID is produced to clarify these matters (which Bora orginally suggested)
> > that we make sure that there is architectural consistency across all
> > functional behaviour wrt to where the trail termination points are.
> 
> I don't think that the LSP termination point is a movable feast.
> However, there *are* three types of terminations: PHP, label 0 (for
> IPv4), and a regular (i.e., non-reserved) label.  Implementations
> seem to be converging on the first (PHP), but that might just be
> tunnel vision on my part.  Using a real label requires something
> along the lines of "pop, send packet back to self, do another lookup"
> which may or may not be acceptable as a normal mode of operation.

You do seem to have tunnel vision.  Others support using a real label.
PHP offers some drawbacks and no benefits for architectures that can
handle a real label with no performance hit.  The egress can decide to
request PHP on an inner label if the depth of the label POP would be
enough to cause a performance hit (the VPN is inside a TE tunnel
inside a PSC-1, inside a PSC-2, etc, all terminating at the same
egress).  For some routers the lookup is fast enough to POP a few
labels before slowing down a 40 byte IP packet with shims on it.

> Note that in either the PHP or label 0 cases, almost all useful info
> about the LSP carrying the packet is lost (we just had a thread of
> discussion on this).  LSP stats at the egress (for example) are a
> victim of PHP/label 0.
> 
> However, if the reason for wanting to know which LSP the packet came
> in on is OAM, then there are other solutions (e.g., having the OAM
> packet carry this info), in which case PHP or label 0 works fine
> for data packets.
> 
> Kireeti.

With PHP you can only count OAM packets, not packets received.  If the
purpose is to accurately measure loss through an LSP (for example, one
carrying an AF class), then PHP requires you to send enough OAM
traffic to make a significant sampling, which could be a lot.  If OAM
is for continuity testing only, then PHP is not a problem for OAM.

Curtis


From owner-mpls@UU.NET  Wed Jun 14 11:54:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25948
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 11:54:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitoh21961;
	Wed, 14 Jun 2000 15:53:51 GMT
Received: by mail-control.mail.uu.net 
	id QQitoh04130
	for mpls-outgoing; Wed, 14 Jun 2000 15:53:08 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitoh04118
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 15:52:55 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitoh05537
	for <mpls@UU.NET>; Wed, 14 Jun 2000 11:52:30 -0400 (EDT)
Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p1.globespan.net [209.191.59.250])
	id QQitoh21088
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:52:29 GMT
Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21)
	id <M8JFXQW9>; Wed, 14 Jun 2000 11:51:52 -0400
Message-ID: <4D0A8ECBDC8AD211BD0900A0C9EBC13301C23D09@rambo.globespan.net>
From: Helpdesk MIS <AdminLogs@globespan.net>
Reply-To: Yongjun Im <yjim@lgic.co.kr>
To: mpls@UU.NET
Subject: Interoperability among Label Encoding.
Date: Wed, 14 Jun 2000 11:51:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD618.740F30D8"
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_01BFD618.740F30D8
Content-Type: text/plain;
	charset="KS_C_5601-1987"
Content-Transfer-Encoding: quoted-printable

From:  Yongjun Im

Dear Sir/Madam,

I have some questions about interoperability among=20
MPLS label encoding.

The following paragraphs are cited from "draft-ietf-mpls-arch-06.txt".

"3.25.3. Interoperability among Encoding Techniques
  =20
   Unfortunately, ATM switches have no capability for translating from
   one encoding technique to another.  The MPLS architecture therefore
   requires that whenever it is possible for two ATM switches to be
   successive LSRs along a level m LSP for some packet, that those two
   ATM switches use the same encoding technique.

   Naturally there will be MPLS networks which contain a combination of
   ATM switches operating as LSRs, and other LSRs which operate using =
an
   MPLS shim header. In such networks there may be some LSRs which have
   ATM interfaces as well as "MPLS Shim" interfaces. This is one =
example
   of an LSR with different label stack encodings on different hops.
   Such an LSR may swap off an ATM encoded label stack on an incoming
   interface and replace it with an MPLS shim header encoded label =
stack
   on the outgoing interface."


The following figure shows an example of interoperability among
shim header(e.g, POS, GbE etc) and ATM header(vpi/vci).
       =20
        R1------R2------R3                 R6-----R7-----R8.
                                        \              /  =20
                                        R4------R5

         Shim Header                ATM          Shim Header .
            (POS)                                             (GbE)
       =20
In the example, LSP consists of LSR R1,R2,..,R7,R8.
R1 and R2 have only POS interfaces.
R4 and R5 have only ATM interfaces.
R7 and R8 have only Gigabit Ethernet interfaces.
R3 have POS and ATM interfaces.
R6 have ATM and GbE interfaces.

Q1:=20
When LSR R3 receives a shim-labled packet from R2,
does it swaps off a shim header(POS) on an incoming interface,
encapsulate an IP packet(or fragment) with AAL5 (including ATM shim =
header),
and forward the segmented cells including ATM label(vpi/vci) to R4 ?

Q2:=20
When LSR R5 receives a ATM-labled packet from R5,
does it swaps off a ATM label on an incoming interface,
reassemble AAL5 packet (including shim header),
swap off a AAL5 shim header,
encapsulate an IP packet with MAC frame(including new shim header),
and forwards the MAC frame to R7 ?

Any response will be appreciated.

Thanks in advance.

Best regards.

Yongjun=20
  =20
-----------------------------------------------------------------
Yong-Jun Im (in Korean: =C0=D3=BF=EB=C1=D8)
Research Engineer
Digital Switching System Lab., LGIC R&D Center
533, Hogye-dong, Dongan-gu, Anyang-shi, Kyonggi-do, 431-080, KOREA
E-mail) yjim@lgic.co.kr  Office) +82-343-450-7750
Fax) +82-343-450-7009   Mobile) +82-11-201-8248
-----------------------------------------------------------------

------_=_NextPart_001_01BFD618.740F30D8
Content-Type: text/html;
	charset="KS_C_5601-1987"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DKS_C_5601-1987">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Interoperability among Label Encoding.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>From:&nbsp; Yongjun Im</FONT>
</P>

<P><FONT SIZE=3D2>Dear Sir/Madam,</FONT>
</P>

<P><FONT SIZE=3D2>I have some questions about interoperability among =
</FONT>
<BR><FONT SIZE=3D2>MPLS label encoding.</FONT>
</P>

<P><FONT SIZE=3D2>The following paragraphs are cited from =
&quot;draft-ietf-mpls-arch-06.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>&quot;3.25.3. Interoperability among Encoding =
Techniques</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Unfortunately, ATM switches have no =
capability for translating from</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; one encoding technique to =
another.&nbsp; The MPLS architecture therefore</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; requires that whenever it is possible =
for two ATM switches to be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; successive LSRs along a level m LSP for =
some packet, that those two</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ATM switches use the same encoding =
technique.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Naturally there will be MPLS networks =
which contain a combination of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ATM switches operating as LSRs, and =
other LSRs which operate using an</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; MPLS shim header. In such networks =
there may be some LSRs which have</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; ATM interfaces as well as &quot;MPLS =
Shim&quot; interfaces. This is one example</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; of an LSR with different label stack =
encodings on different hops.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Such an LSR may swap off an ATM encoded =
label stack on an incoming</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; interface and replace it with an MPLS =
shim header encoded label stack</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; on the outgoing interface.&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The following figure shows an example of =
interoperability among</FONT>
<BR><FONT SIZE=3D2>shim header(e.g, POS, GbE etc) and ATM =
header(vpi/vci).</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
R1------R2------R3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R6-----R7-----R8.</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; =
\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; /&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; =
R4------R5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Shim =
Header&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; =
ATM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Shim Header =
.</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =
(POS)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (GbE)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>In the example, LSP consists of LSR =
R1,R2,..,R7,R8.</FONT>
<BR><FONT SIZE=3D2>R1 and R2 have only POS interfaces.</FONT>
<BR><FONT SIZE=3D2>R4 and R5 have only ATM interfaces.</FONT>
<BR><FONT SIZE=3D2>R7 and R8 have only Gigabit Ethernet =
interfaces.</FONT>
<BR><FONT SIZE=3D2>R3 have POS and ATM interfaces.</FONT>
<BR><FONT SIZE=3D2>R6 have ATM and GbE interfaces.</FONT>
</P>

<P><FONT SIZE=3D2>Q1: </FONT>
<BR><FONT SIZE=3D2>When LSR R3 receives a shim-labled packet from =
R2,</FONT>
<BR><FONT SIZE=3D2>does it swaps off a shim header(POS) on an incoming =
interface,</FONT>
<BR><FONT SIZE=3D2>encapsulate an IP packet(or fragment) with AAL5 =
(including ATM shim header),</FONT>
<BR><FONT SIZE=3D2>and forward the segmented cells including ATM =
label(vpi/vci) to R4 ?</FONT>
</P>

<P><FONT SIZE=3D2>Q2: </FONT>
<BR><FONT SIZE=3D2>When LSR R5 receives a ATM-labled packet from =
R5,</FONT>
<BR><FONT SIZE=3D2>does it swaps off a ATM label on an incoming =
interface,</FONT>
<BR><FONT SIZE=3D2>reassemble AAL5 packet (including shim =
header),</FONT>
<BR><FONT SIZE=3D2>swap off a AAL5 shim header,</FONT>
<BR><FONT SIZE=3D2>encapsulate an IP packet with MAC frame(including =
new shim header),</FONT>
<BR><FONT SIZE=3D2>and forwards the MAC frame to R7 ?</FONT>
</P>

<P><FONT SIZE=3D2>Any response will be appreciated.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks in advance.</FONT>
</P>

<P><FONT SIZE=3D2>Best regards.</FONT>
</P>

<P><FONT SIZE=3D2>Yongjun </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
--</FONT>
<BR><FONT SIZE=3D2>Yong-Jun Im (in Korean: =C0=D3=BF=EB=C1=D8)</FONT>
<BR><FONT SIZE=3D2>Research Engineer</FONT>
<BR><FONT SIZE=3D2>Digital Switching System Lab., LGIC R&amp;D =
Center</FONT>
<BR><FONT SIZE=3D2>533, Hogye-dong, Dongan-gu, Anyang-shi, Kyonggi-do, =
431-080, KOREA</FONT>
<BR><FONT SIZE=3D2>E-mail) yjim@lgic.co.kr&nbsp; Office) =
+82-343-450-7750</FONT>
<BR><FONT SIZE=3D2>Fax) +82-343-450-7009&nbsp;&nbsp; Mobile) =
+82-11-201-8248</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
--</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD618.740F30D8--


From owner-mpls@UU.NET  Wed Jun 14 13:54:08 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29927
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 13:54:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitop12938;
	Wed, 14 Jun 2000 17:54:00 GMT
Received: by mail-control.mail.uu.net 
	id QQitop01824
	for mpls-outgoing; Wed, 14 Jun 2000 17:52:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitop01819
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 17:52:55 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitop29453
	for <mpls@UU.NET>; Wed, 14 Jun 2000 13:49:00 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQitop09863
	for <mpls@UU.NET>; Wed, 14 Jun 2000 17:49:00 GMT
Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP;
          Wed, 14 Jun 2000 18:01:57 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWF0CPR>; Wed, 14 Jun 2000 18:01:45 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B1609C@mbddmknt01.hc.bt.com>
To: xuyg@lucent.com, bosco@coritel.it
Cc: mpls@UU.NET, andy.bd.reid@bt.com, alan.mcguire@bt.com
Subject: RE: Information about optical routing in MPLS net.
Date: Wed, 14 Jun 2000 18:01:45 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

[Harrison,N,Neil,INC1 X]  <snip>
AB wrote: 
> > a. Considering explicit paths calculation through an optical MPLS
> > network, ingress
> >     routers or third part tools, at the input of the network, will still
> > calculate the
> >     entire path (ingress to egress router), considering links within the
> > optical domain
> >     too?
> > 
	[Harrison,N,Neil,INC1 X]  YX answered: 
> There have been discussions about this before. My personal opinion is that
> having router control optical domain is not feasible both technically and
> practically. 
> 
	[Harrison,N,Neil,INC1 X]  I would like to support YX's comments here
based on a practical observation:

	The optical L1 will have many client layers it needs to support.
For example, operators may have:
	-	large BW clients supported directly off the L1
	-	less coarse BW clients supported off trad L2 technologies,
eg FR and ATM....and even with MPLS VPNs it is almost certain that some
customers will still want hard BW partitioned L2 services for many reasons
(eg to get othogonal and robust availability SLAS and QoS SLAs, to run their
own customised DiffServ regimes, etc)
	-	PSTN clients
	-	MPLS/IP clients

	The addressable trail access points of each of these clients are not
congruent with each other.  Therefore they cannot be congruent with the L1
addressable trail access points.  Architecturally, the (inter-node) links in
a client layer are created from trails in the server layer........that is,
the L1 addressable trail termination points are only mid-points in the
client layer trails.  Another way of looking at this is that L1 forms an
important TE function for its clients, since by definition it creates their
topologies.

	Hence, any operator wishing to support a multiple set of client
layers cannot afford to have the optical L1 linked to any one of the
addressing regimes of a single client layer.  It therefore follows that the
optical L1 needs to be able to choose best-of-breed for its control-plane
wrt addressing, routing protocol and signalling protocol.......though the
latter 2 facets can re-use technologies they are not operating in the same
addressing space.

	Hope this makes sense.

	Neil



From owner-mpls@UU.NET  Wed Jun 14 14:03:59 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00362
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 14:03:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitoq02546;
	Wed, 14 Jun 2000 18:03:54 GMT
Received: by mail-control.mail.uu.net 
	id QQitoq11843
	for mpls-outgoing; Wed, 14 Jun 2000 18:03:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitoq11806
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 18:03:33 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitoq00966
	for <mpls@uu.net>; Wed, 14 Jun 2000 14:00:00 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: red.juniper.net [208.197.169.254])
	id QQitop16942
	for <mpls@uu.net>; Wed, 14 Jun 2000 17:59:59 GMT
Received: from kummer.juniper.net (kummer.juniper.net [208.197.169.197])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA28066;
	Wed, 14 Jun 2000 10:59:59 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA25318; Wed, 14 Jun 2000 10:59:58 -0700 (PDT)
Date: Wed, 14 Jun 2000 10:59:58 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006141759.KAA25318@kummer.juniper.net>
To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis,

> You do seem to have tunnel vision.  Others support using a real label.

That's good to know.  Can you enumerate some of the 'others'?
What was the primary motivation?

Fortunately, an egress is in charge of its destiny, at least as far
as the last label is concerned.  As you point out, an egress can
(with some forethought) request PHP if the label stack gets too deep.

> With PHP you can only count OAM packets, not packets received.  If the
> purpose is to accurately measure loss through an LSP (for example, one
> carrying an AF class), then PHP requires you to send enough OAM
> traffic to make a significant sampling, which could be a lot.  If OAM
> is for continuity testing only, then PHP is not a problem for OAM.

Agreed.

Kireeti.


From owner-mpls@UU.NET  Wed Jun 14 15:58:36 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03289
	for <mpls-archive@lists.ietf.org>; Wed, 14 Jun 2000 15:58:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitox09401;
	Wed, 14 Jun 2000 19:58:26 GMT
Received: by mail-control.mail.uu.net 
	id QQitox29131
	for mpls-outgoing; Wed, 14 Jun 2000 19:57:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitox29123
	for <mpls@mail-control.mail.uu.net>; Wed, 14 Jun 2000 19:57:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitox23768
	for <mpls@UU.NET>; Wed, 14 Jun 2000 15:57:31 -0400 (EDT)
Received: from redes.unam.mx by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cuk.redes.unam.mx [132.248.204.49])
	id QQitox08598
	for <mpls@UU.NET>; Wed, 14 Jun 2000 19:57:31 GMT
Received: from redes.unam.mx (andromeda.redes.unam.mx [132.248.204.31])
	by redes.unam.mx (8.9.3/8.9.3) with ESMTP id OAA10314
	for <mpls@UU.NET>; Wed, 14 Jun 2000 14:57:07 -0500 (CDT)
Message-ID: <3947F0FC.6C097D86@redes.unam.mx>
Date: Wed, 14 Jun 2000 14:54:20 -0600
From: Cesar Olvera <cesar@redes.unam.mx>
Organization: DT-DGSCA-UNAM
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: MPLS testing procedures
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I am working in the MPLS at UNAM Research Group, a National Autonomous 
Universtity of Mexico (UNAM) Working Group formed to discuss issues 
related to MPLS.

Are there some testing procedures for both conformance and 
interoperability on MPLS?. 

Thanks

Cesar Olvera
Interoperability Lab Manager
Networks Subdirection, Telecommunications Direction
DGSCA-UNAM
MEXICO


From owner-mpls@UU.NET  Thu Jun 15 06:42:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26245
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 06:42:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitre19140;
	Thu, 15 Jun 2000 10:42:17 GMT
Received: by mail-control.mail.uu.net 
	id QQitre19300
	for mpls-outgoing; Thu, 15 Jun 2000 10:41:48 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitre19295
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 10:41:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitre20582
	for <mpls@uu.net>; Thu, 15 Jun 2000 06:41:33 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitre18599
	for <mpls@uu.net>; Thu, 15 Jun 2000 10:41:33 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA28463
	for mpls@uu.net; Thu, 15 Jun 2000 06:41:32 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitre19232
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 10:41:07 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitre20520
	for <mpls@uu.net>; Thu, 15 Jun 2000 06:40:52 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQitre29091
	for <mpls@uu.net>; Thu, 15 Jun 2000 10:40:51 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26127;
	Thu, 15 Jun 2000 06:40:50 -0400 (EDT)
Message-Id: <200006151040.GAA26127@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-fr-05.txt
Date: Thu, 15 Jun 2000 06:40:49 -0400
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		: Use of Label Switching on Frame Relay Networks Specification
	Author(s)	: A. Malis, A. Conta, P. Doolan
	Filename	: draft-ietf-mpls-fr-05.txt
	Pages		: 25
	Date		: 14-Jun-00
	
This  document  defines  the  model  and   generic   mechanisms   for
Multiprotocol  Label  Switching on Frame Relay networks. Furthermore,
it  extends  and  clarifies  portions  of  the  Multiprotocol   Label
Switching Architecture described in [ARCH] and the Label Distribution
Protocol (LDP) described in [LDP] relative to Frame  Relay  Networks.
MPLS  enables  the  use  of  Frame  Relay Switches as Label Switching
Routers (LSRs).

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

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-fr-05.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-fr-05.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:	<20000614110612.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-fr-05.txt

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

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

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Thu Jun 15 09:44:55 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01837
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 09:44:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitrq06060;
	Thu, 15 Jun 2000 13:43:13 GMT
Received: by mail-control.mail.uu.net 
	id QQitrq01675
	for mpls-outgoing; Thu, 15 Jun 2000 13:42:31 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitrq01667
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 13:42:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitrq19443
	for <mpls@UU.net>; Thu, 15 Jun 2000 09:42:15 -0400 (EDT)
Received: from students.itb.ac.id by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: students.ITB.ac.id [167.205.22.114])
	id QQitrq16087
	for <mpls@UU.net>; Thu, 15 Jun 2000 13:42:08 GMT
Received: (qmail 56409 invoked by uid 1210); 15 Jun 2000 13:35:19 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 15 Jun 2000 13:35:19 -0000
Date: Thu, 15 Jun 2000 20:35:18 +0700 (JAVT)
From: From MountIsland With Love <ahsanul@students.itb.ac.id>
To: mpls@UU.NET
Subject: parameter QoS in mpls network
Message-ID: <Pine.BSF.4.05.10006152032070.55027-100000@students.itb.ac.id>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hei dear...
can you tell me how many parameter of Quality of Service (QoS)
in the mpls networks
And where I can get the algorithm of the parameter QoS in mpls
That's very important to me because right now I am studying the QoS 
in mpls networks for my research

thanks you
 

                         --------------------------
                          KEEP PATIENT AND SILENT
                        TRUST YOURSELF IN EVERYTHING
                       -------------------------------          
                        
                        Bandung Institut of Technology                                       
                                 



From owner-mpls@UU.NET  Thu Jun 15 10:58:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03878
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 10:58:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitrv07357;
	Thu, 15 Jun 2000 14:57:09 GMT
Received: by mail-control.mail.uu.net 
	id QQitrv16029
	for mpls-outgoing; Thu, 15 Jun 2000 14:56:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitrv16024
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 14:56:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitrv29595
	for <mpls@uu.net>; Thu, 15 Jun 2000 10:56:23 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitrv06672
	for <mpls@uu.net>; Thu, 15 Jun 2000 14:56:21 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA22457
	for mpls@uu.net; Thu, 15 Jun 2000 10:56:19 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitrv15899
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 14:55:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitrv29428
	for <mpls@UU.NET>; Thu, 15 Jun 2000 10:55:19 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQitrv05861
	for <mpls@UU.NET>; Thu, 15 Jun 2000 14:55:18 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA10058;
	Thu, 15 Jun 2000 07:53:36 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <MRH8ADHH>; Thu, 15 Jun 2000 07:54:20 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40622@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'From MountIsland With Love'" <ahsanul@students.itb.ac.id>, mpls@UU.NET
Subject: RE: parameter QoS in mpls network
Date: Thu, 15 Jun 2000 07:54:12 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

MPLS is a forwarding layer and is independent of QoS. So there is no MPLS
QoS parameter. 

-Shahram

>-----Original Message-----
>From: From MountIsland With Love [mailto:ahsanul@students.itb.ac.id]
>Sent: Thursday, June 15, 2000 9:35 AM
>To: mpls@UU.NET
>Subject: parameter QoS in mpls network
>
>
>Hei dear...
>can you tell me how many parameter of Quality of Service (QoS)
>in the mpls networks
>And where I can get the algorithm of the parameter QoS in mpls
>That's very important to me because right now I am studying the QoS 
>in mpls networks for my research
>
>thanks you
> 
>
>                         --------------------------
>                          KEEP PATIENT AND SILENT
>                        TRUST YOURSELF IN EVERYTHING
>                       -------------------------------          
>                        
>                        Bandung Institut of Technology         
>                              
>                                 
>



From owner-mpls@UU.NET  Thu Jun 15 11:08:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04269
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 11:08:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitrw14570;
	Thu, 15 Jun 2000 15:06:43 GMT
Received: by mail-control.mail.uu.net 
	id QQitrw23311
	for mpls-outgoing; Thu, 15 Jun 2000 15:06:11 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitrw22811
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:05:55 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitrw01677
	for <mpls@UU.NET>; Thu, 15 Jun 2000 11:05:09 -0400 (EDT)
Received: from students.itb.ac.id by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: students.ITB.ac.id [167.205.22.114])
	id QQitrw01724
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:05:05 GMT
Received: (qmail 64291 invoked by uid 1210); 15 Jun 2000 15:04:53 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 15 Jun 2000 15:04:53 -0000
Date: Thu, 15 Jun 2000 22:04:53 +0700 (JAVT)
From: From MountIsland With Love <ahsanul@students.itb.ac.id>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: mpls@UU.NET
Subject: RE: parameter QoS in mpls network
In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B40622@nt-exchange-bby.pmc-sierra.bc.ca>
Message-ID: <Pine.BSF.4.05.10006152203430.64058-100000@students.itb.ac.id>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

but what about committed access rate (car) or WFQ
are there the parameter QoS in mpls???
thanks

                         --------------------------
                          KEEP PATIENT AND SILENT
                        TRUST YOURSELF IN EVERYTHING
                       -------------------------------          
                        
                        Bandung Institut of Technology                                       
                                 

On Thu, 15 Jun 2000, Shahram Davari wrote:

> MPLS is a forwarding layer and is independent of QoS. So there is no MPLS
> QoS parameter. 
> 
> -Shahram
> 
> >-----Original Message-----
> >From: From MountIsland With Love [mailto:ahsanul@students.itb.ac.id]
> >Sent: Thursday, June 15, 2000 9:35 AM
> >To: mpls@UU.NET
> >Subject: parameter QoS in mpls network
> >
> >
> >Hei dear...
> >can you tell me how many parameter of Quality of Service (QoS)
> >in the mpls networks
> >And where I can get the algorithm of the parameter QoS in mpls
> >That's very important to me because right now I am studying the QoS 
> >in mpls networks for my research
> >
> >thanks you
> > 
> >
> >                         --------------------------
> >                          KEEP PATIENT AND SILENT
> >                        TRUST YOURSELF IN EVERYTHING
> >                       -------------------------------          
> >                        
> >                        Bandung Institut of Technology         
> >                              
> >                                 
> >
> 



From owner-mpls@UU.NET  Thu Jun 15 11:15:48 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04549
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 11:15:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitrw20104;
	Thu, 15 Jun 2000 15:14:03 GMT
Received: by mail-control.mail.uu.net 
	id QQitrw27074
	for mpls-outgoing; Thu, 15 Jun 2000 15:13:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitrw27056
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:13:35 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitrw03188
	for <mpls@uu.net>; Thu, 15 Jun 2000 11:12:49 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitrw07269
	for <mpls@uu.net>; Thu, 15 Jun 2000 15:12:46 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA25903
	for mpls@uu.net; Thu, 15 Jun 2000 11:12:43 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitrw26931
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:12:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitrw02780
	for <mpls@uu.net>; Thu, 15 Jun 2000 11:10:52 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQitrw05740
	for <mpls@uu.net>; Thu, 15 Jun 2000 15:10:52 GMT
Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA09250 for <mpls@uu.net>; Thu, 15 Jun 2000 11:10:51 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA20492 for <mpls@uu.net>; Thu, 15 Jun 2000 11:10:50 -0400 (EDT)
Message-Id: <200006151510.LAA20492@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Close of last call on LDP
Date: Thu, 15 Jun 2000 11:10:50 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

The last call on LDP closed at midnight GMT.

...George

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






From owner-mpls@UU.NET  Thu Jun 15 11:24:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04800
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 11:24:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitrx26751;
	Thu, 15 Jun 2000 15:22:36 GMT
Received: by mail-control.mail.uu.net 
	id QQitrx27863
	for mpls-outgoing; Thu, 15 Jun 2000 15:22:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitrx27852
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:21:57 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitrx10098
	for <mpls@uu.net>; Thu, 15 Jun 2000 11:21:45 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQitrx13885
	for <mpls@uu.net>; Thu, 15 Jun 2000 15:21:44 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA20076
	for <mpls@uu.net>; Thu, 15 Jun 2000 08:21:54 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA04997 for mpls@uu.net; Thu, 15 Jun 2000 11:21:42 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitrw26316
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:08:59 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitrw07195
	for <mpls@UU.NET>; Thu, 15 Jun 2000 11:08:40 -0400 (EDT)
Received: from scallop.baynetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns5.baynetworks.com [194.133.90.101])
	id QQitrw04147
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:08:39 GMT
Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84])
	by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id RAA23541;
	Thu, 15 Jun 2000 17:13:23 +0200 (MET DST)
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6])
	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id LAA15867;
	Thu, 15 Jun 2000 11:13:31 -0400 (EDT)
Received: from bubba.engeast (bubba [192.168.136.194])
	by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP
	id LAA09721; Thu, 15 Jun 2000 11:08:34 -0400
	for 
Received: by bubba.engeast (SMI-8.6/SMI-SVR4)
	id LAA08218; Thu, 15 Jun 2000 11:08:33 -0400
From: dwilder@baynetworks.com (David Wilder)
Message-Id: <200006151508.LAA08218@bubba.engeast>
Subject: Re: MPLS testing procedures
In-Reply-To: <3947F0FC.6C097D86@redes.unam.mx> from Cesar Olvera at "Jun 14,
 2000 02:54:20 pm"
To: Cesar Olvera <cesar@redes.unam.mx>
Date: Thu, 15 Jun 2000 11:08:33 -0400 (EDT)
CC: mpls@UU.NET
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
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

Cesar,

The best place to start would be at the UNH web site @ www.iol.unh.com.
They wrote MPLS interoperability test plans for LDP, CRLDP and RSVP.

In addition, I think it is time to look into forming an MPLS Test
sub-group like the one created under the ATM Forum.

Dave

> I am working in the MPLS at UNAM Research Group, a National Autonomous 
> Universtity of Mexico (UNAM) Working Group formed to discuss issues 
> related to MPLS.
> 
> Are there some testing procedures for both conformance and 
> interoperability on MPLS?. 
> 
> Thanks
> 
> Cesar Olvera
> Interoperability Lab Manager
> Networks Subdirection, Telecommunications Direction
> DGSCA-UNAM
> MEXICO




From owner-mpls@UU.NET  Thu Jun 15 11:30:30 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04990
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 11:30:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitrx18974;
	Thu, 15 Jun 2000 15:28:48 GMT
Received: by mail-control.mail.uu.net 
	id QQitrx28480
	for mpls-outgoing; Thu, 15 Jun 2000 15:28:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitrx28466
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:28:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitrx06311
	for <mpls@uu.net>; Thu, 15 Jun 2000 11:28:04 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitrx00726
	for <mpls@uu.net>; Thu, 15 Jun 2000 15:28:02 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA29414
	for mpls@uu.net; Thu, 15 Jun 2000 11:28:00 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitrx28389
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:27:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitrx06139
	for <mpls@UU.NET>; Thu, 15 Jun 2000 11:27:22 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQitrx00279
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:27:21 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA11933;
	Thu, 15 Jun 2000 08:26:47 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <MRH8ADVG>; Thu, 15 Jun 2000 08:27:31 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40623@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'From MountIsland With Love'" <ahsanul@students.itb.ac.id>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: mpls@UU.NET
Subject: RE: parameter QoS in mpls network
Date: Thu, 15 Jun 2000 08:27:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

If you are talking about per-LSP BW reservation, I don't consider that an
MPLS QoS. This QoS is essentially either per-flow Intserv QoS, or
per-flow-signaled aggregate Diffserv QoS.

In other words MPLS signaling (RSVP-TE, CR-LDP) gives you the ability to
signal BW, but there are other protocol layers that provide the QoS, not
MPLS. In other words MPLS in orthogonal to QoS but it facilitates providing
QoS.

-Shahram

>-----Original Message-----
>From: From MountIsland With Love [mailto:ahsanul@students.itb.ac.id]
>Sent: Thursday, June 15, 2000 11:05 AM
>To: Shahram Davari
>Cc: mpls@UU.NET
>Subject: RE: parameter QoS in mpls network
>
>
>but what about committed access rate (car) or WFQ
>are there the parameter QoS in mpls???
>thanks
>
>                         --------------------------
>                          KEEP PATIENT AND SILENT
>                        TRUST YOURSELF IN EVERYTHING
>                       -------------------------------          
>                        
>                        Bandung Institut of Technology         
>                              
>                                 
>
>On Thu, 15 Jun 2000, Shahram Davari wrote:
>
>> MPLS is a forwarding layer and is independent of QoS. So 
>there is no MPLS
>> QoS parameter. 
>> 
>> -Shahram
>> 
>> >-----Original Message-----
>> >From: From MountIsland With Love [mailto:ahsanul@students.itb.ac.id]
>> >Sent: Thursday, June 15, 2000 9:35 AM
>> >To: mpls@UU.NET
>> >Subject: parameter QoS in mpls network
>> >
>> >
>> >Hei dear...
>> >can you tell me how many parameter of Quality of Service (QoS)
>> >in the mpls networks
>> >And where I can get the algorithm of the parameter QoS in mpls
>> >That's very important to me because right now I am studying the QoS 
>> >in mpls networks for my research
>> >
>> >thanks you
>> > 
>> >
>> >                         --------------------------
>> >                          KEEP PATIENT AND SILENT
>> >                        TRUST YOURSELF IN EVERYTHING
>> >                       -------------------------------          
>> >                        
>> >                        Bandung Institut of Technology         
>> >                              
>> >                                 
>> >
>> 
>



From owner-mpls@UU.NET  Thu Jun 15 11:33:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05148
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 11:33:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitry03671;
	Thu, 15 Jun 2000 15:31:43 GMT
Received: by mail-control.mail.uu.net 
	id QQitry28772
	for mpls-outgoing; Thu, 15 Jun 2000 15:31:09 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitry28741
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:30:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitry06790
	for <mpls@UU.NET>; Thu, 15 Jun 2000 11:30:35 -0400 (EDT)
Received: from hawaii.globewebs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hawaii.globewebs.com [199.202.42.148])
	id QQitry02582
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:30:35 GMT
Received: from uklozms02.Teleglobe.CA (uklozms02.Teleglobe.CA [172.25.81.11])
	by hawaii.globewebs.com (8.8.8/8.8.8) with ESMTP id LAA06173;
	Thu, 15 Jun 2000 11:44:55 -0400 (EDT)
Received: by uklozms02.Teleglobe.CA with Internet Mail Service (5.5.2448.0)
	id <MZ0D21N0>; Thu, 15 Jun 2000 16:15:58 +0100
Message-ID: <04BCD7586FEDD3119C0B00A0C9E4605F2C04D8@uklozms02.Teleglobe.CA>
From: "Hallgren, Michael" <michael.hallgren@teleglobe.com>
To: "'dwilder@baynetworks.com'" <dwilder@baynetworks.com>,
        Cesar Olvera
	 <cesar@redes.unam.mx>
Cc: mpls@UU.NET
Subject: RE: MPLS testing procedures
Date: Thu, 15 Jun 2000 16:15:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Dave,


>Cesar,
>
>The best place to start would be at the UNH web site @ >www.iol.unh.com.

No A RR. But likely to be very interesting,...


mh

>They wrote MPLS interoperability test plans for LDP, CRLDP >and RSVP.
>
>In addition, I think it is time to look into forming an MPLS >Test
>sub-group like the one created under the ATM Forum.
>
>Dave

> I am working in the MPLS at UNAM Research Group, a National Autonomous 
> Universtity of Mexico (UNAM) Working Group formed to discuss issues 
> related to MPLS.
> 
> Are there some testing procedures for both conformance and 
> interoperability on MPLS?. 
> 
> Thanks
> 
> Cesar Olvera
> Interoperability Lab Manager
> Networks Subdirection, Telecommunications Direction
> DGSCA-UNAM
> MEXICO



From owner-mpls@UU.NET  Thu Jun 15 11:38:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05280
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 11:38:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitry07698;
	Thu, 15 Jun 2000 15:37:06 GMT
Received: by mail-control.mail.uu.net 
	id QQitry29271
	for mpls-outgoing; Thu, 15 Jun 2000 15:36:26 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitry29205
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:36:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitry07728
	for <mpls@UU.NET>; Thu, 15 Jun 2000 11:35:32 -0400 (EDT)
Received: from iol.unh.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mars.iol.unh.edu [132.177.121.222])
	id QQitry06434
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:35:32 GMT
Received: (from rdb@localhost)
	by iol.unh.edu (8.9.3/8.9.3) id LAA16137;
	Thu, 15 Jun 2000 11:35:26 -0400 (EDT)
From: Rob Blais <rdb@iol.unh.edu>
Message-Id: <200006151535.LAA16137@iol.unh.edu>
Subject: Re: MPLS testing procedures
To: dwilder@baynetworks.com (David Wilder)
Date: Thu, 15 Jun 2000 11:35:25 -0400 (EDT)
Cc: cesar@redes.unam.mx (Cesar Olvera), mpls@UU.NET
In-Reply-To: <200006151508.LAA08218@bubba.engeast> from "David Wilder" at Jun 15, 2000 11:08:33 AM
X-Mailer: ELM [version 2.5 PL3]
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

Thanks, Dave, but it's www.iol.unh.edu.  I'd be making a lot more money
if it were a .com.  :)

Our LDP interoperability test suite is about 85-90% complete and should
be on the website soon.  Others will follow for RSVP-TE, CR-LDP, BGP4-TE,
IS-IS-TE, and whatever else comes down the line, as we get them finished.
We've also started some preliminary work on conformance tests, but those
typically have to wait until there is a finished specification or at least
a stable RFC.  It's very difficult to demonstrate conformance to drafts that
change every few weeks. 

[soapbox]
We welcome any and all public comment and encourage all other testing
facilities to make their test suites available for public comment, as well.
As with standards, the only way to ensure that the tests are consistent
and complete is to make them open.  Our intent is to submit ours as
contributions to the MPLS Forum and any other applicable organization
once they are in a more stable and complete state. 
[/soapbox]

/rob

---------------------------------------------------------------------
Rob Blais                  rdb@iol.unh.edu          "The Internet?
MPLS Consortium Manager    Phone: 603-862-4569       Is that thing
ATM Operations Manager     Fax:   603-862-4181       still around?"
UNH InterOperability Lab   http://www.iol.unh.edu/   -Homer Simpson
 
> Cesar,
> 
> The best place to start would be at the UNH web site @ www.iol.unh.com.
> They wrote MPLS interoperability test plans for LDP, CRLDP and RSVP.
> 
> In addition, I think it is time to look into forming an MPLS Test
> sub-group like the one created under the ATM Forum.
> 
> Dave
> 
> > I am working in the MPLS at UNAM Research Group, a National Autonomous 
> > Universtity of Mexico (UNAM) Working Group formed to discuss issues 
> > related to MPLS.
> > 
> > Are there some testing procedures for both conformance and 
> > interoperability on MPLS?. 
> > 
> > Thanks
> > 
> > Cesar Olvera
> > Interoperability Lab Manager
> > Networks Subdirection, Telecommunications Direction
> > DGSCA-UNAM
> > MEXICO
> 
> 



From owner-mpls@UU.NET  Thu Jun 15 11:52:39 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05768
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 11:52:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitrz18032;
	Thu, 15 Jun 2000 15:50:57 GMT
Received: by mail-control.mail.uu.net 
	id QQitrz00480
	for mpls-outgoing; Thu, 15 Jun 2000 15:50:26 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitrz00452
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 15:50:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitrz16052
	for <mpls@UU.NET>; Thu, 15 Jun 2000 11:50:05 -0400 (EDT)
Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQitrz17222
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:50:05 GMT
Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4)
	id LAA16347; Thu, 15 Jun 2000 11:43:32 -0400
Message-ID: <3948F9AC.9FDBEB46@tellium.com>
Date: Thu, 15 Jun 2000 11:43:40 -0400
From: Bala Rajagopalan <braja@tellium.com>
Organization: Tellium
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
CC: Alessandro Bosco <bosco@coritel.it>, mpls@UU.NET
Subject: Re: Information about optical routing in MPLS net.
References: <39478E8E.2D6260DE@coritel.it> <3947A408.3FB6285B@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


There is a draft that describes some of the routing choices for IP over optical.
Please see  http://www.ietf.org/internet-drafts/draft-prs-optical-routing-00.ps

Regards,

Bala

Yangguang Xu wrote:

> Please see comments below:
>
> >
> > a. Considering explicit paths calculation through an optical MPLS
> > network, ingress
> >     routers or third part tools, at the input of the network, will still
> > calculate the
> >     entire path (ingress to egress router), considering links within the
> > optical domain
> >     too?
> >
>
> There have been discussions about this before. My personal opinion is that
> having router control optical domain is not feasible both technically and
> practically.
>
> > b. Or, "new" OXCs, that use a control plane extended from MPLS traffic
> >     engineering control module, will be able to do optical routing, I
> > mean optical path
> >     calculation at the input of optical domain?
>
> This is what I support. Optical path can be set up either through topology
> driven, real-time traffic driven or traffic pattern driven. There have to be
> extra functions and intelligence at the intersection of data domain and optical
> domain. ODSI addresses some issues already. I am now thinking how COPS could be
> extended to apply here. Any people interested in this topic?
>
> > c. In the MPL(ambda)s framework, "new" OXCs has to be seen like optical
> >     routers?
> >
>
> If you mean optical router as optical packet router, then I don't think so.
>
> Yangguang

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com




From owner-mpls@UU.NET  Thu Jun 15 12:12:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06332
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 12:12:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsa01914;
	Thu, 15 Jun 2000 16:10:44 GMT
Received: by mail-control.mail.uu.net 
	id QQitsa11258
	for mpls-outgoing; Thu, 15 Jun 2000 16:10:11 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitsa11223
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 16:10:00 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsa20057
	for <mpls@UU.NET>; Thu, 15 Jun 2000 12:09:33 -0400 (EDT)
Received: from thumper.research.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thumper.research.telcordia.com [128.96.41.1])
	id QQitsa17025
	for <mpls@UU.NET>; Thu, 15 Jun 2000 16:09:31 GMT
Received: from clapp-nb.research.telcordia.com (pptpin01 [192.4.9.226])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e5FG9Pd03729;
	Thu, 15 Jun 2000 12:09:26 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000615120736.00ba8210@mailee.research.telcordia.com>
X-Sender: clapp@mailee.research.telcordia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 15 Jun 2000 12:09:19 -0400
To: Yangguang Xu <xuyg@lucent.com>
From: George Clapp <clapp@research.telcordia.com>
Subject: Re: Information about optical routing in MPLS net.
Cc: mpls@UU.NET
In-Reply-To: <3947A408.3FB6285B@lucent.com>
References: <39478E8E.2D6260DE@coritel.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 11:26 AM 6/14/00 -0400, Yangguang Xu wrote:
>Please see comments below:
>
> >
> > a. Considering explicit paths calculation through an optical MPLS
> > network, ingress
> >     routers or third part tools, at the input of the network, will still
> > calculate the
> >     entire path (ingress to egress router), considering links within the
> > optical domain
> >     too?
> >
>
>There have been discussions about this before. My personal opinion is that
>having router control optical domain is not feasible both technically and
>practically.

Could you give some examples of why it's not feasible?

Thanks,
George Clapp
voice     973-829-4610
email     clapp@research.telcordia.com



From owner-mpls@UU.NET  Thu Jun 15 12:16:32 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06523
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 12:16:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsa05285;
	Thu, 15 Jun 2000 16:14:51 GMT
Received: by mail-control.mail.uu.net 
	id QQitsa11805
	for mpls-outgoing; Thu, 15 Jun 2000 16:14:18 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsa11800
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 16:14:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsa21023
	for <mpls@uu.net>; Thu, 15 Jun 2000 12:14:01 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitsa04556
	for <mpls@uu.net>; Thu, 15 Jun 2000 16:13:58 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA07839
	for mpls@uu.net; Thu, 15 Jun 2000 12:13:56 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsa11714
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 16:13:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsa20850
	for <mpls@UU.NET>; Thu, 15 Jun 2000 12:13:06 -0400 (EDT)
Received: from drawbridge.ascend.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: drawbridge.ascend.com [198.4.92.1])
	id QQitsa03969
	for <mpls@UU.NET>; Thu, 15 Jun 2000 16:13:03 GMT
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5])
	by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id JAA27553
	for <mpls@UU.NET>; Thu, 15 Jun 2000 09:05:54 -0700 (PDT)
Received: from russet.ascend.com by fw-ext.ascend.com
          via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 15 Jun 2000 16:13:01 UT
Received: from porky (porky.ascend.com [192.207.23.83])
	by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id JAA14465
	for <mpls@UU.NET>; Thu, 15 Jun 2000 09:13:01 -0700 (PDT)
Received: from ascend.com by ascend.com
Message-Id: <4.3.2.7.2.20000615110309.00d60840@alpo.casc.com>
X-Sender: amalis@alpo.casc.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 15 Jun 2000 11:05:27 -0400
To: mpls@UU.NET
From: "Andrew G. Malis" <amalis@lucent.com>
Subject: Fwd: I-D ACTION:draft-ietf-mpls-fr-05.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

The only change from -04 was removing all mention of 17-bit DLCIs, which 
are no longer supported by the Frame Relay Forum.  Only 10-bit and 23-bit 
DLCIs are now included.

Cheers,
Andy

------- Begin of Forwarded Message -------
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-fr-05.txt
Date: Thu, 15 Jun 2000 06:40:49 -0400
Sender: owner-mpls@UU.NET

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		: Use of Label Switching on Frame Relay Networks Specification
	Author(s)	: A. Malis, A. Conta, P. Doolan
	Filename	: draft-ietf-mpls-fr-05.txt
	Pages		: 25
	Date		: 14-Jun-00
	
This  document  defines  the  model  and   generic   mechanisms   for
Multiprotocol  Label  Switching on Frame Relay networks. Furthermore,
it  extends  and  clarifies  portions  of  the  Multiprotocol   Label
Switching Architecture described in [ARCH] and the Label Distribution
Protocol (LDP) described in [LDP] relative to Frame  Relay  Networks.
MPLS  enables  the  use  of  Frame  Relay Switches as Label Switching
Routers (LSRs).

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

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-fr-05.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-fr-05.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.
Content-Type: text/plain
Content-ID:	<20000614110612.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-fr-05.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-fr-05.txt>

------- End of Forwarded Message ------- 




From owner-mpls@UU.NET  Thu Jun 15 12:17:09 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06553
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 12:17:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsb05997;
	Thu, 15 Jun 2000 16:15:27 GMT
Received: by mail-control.mail.uu.net 
	id QQitsa11852
	for mpls-outgoing; Thu, 15 Jun 2000 16:14:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitsa11845
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 16:14:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsa15156
	for <mpls@uu.net>; Thu, 15 Jun 2000 12:14:00 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitsa20393
	for <mpls@uu.net>; Thu, 15 Jun 2000 16:13:58 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA07829
	for mpls@uu.net; Thu, 15 Jun 2000 12:13:55 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsa11713
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 16:13:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsa20871
	for <mpls@UU.NET>; Thu, 15 Jun 2000 12:13:12 -0400 (EDT)
Received: from drawbridge.ascend.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: drawbridge.ascend.com [198.4.92.1])
	id QQitsa04037
	for <mpls@UU.NET>; Thu, 15 Jun 2000 16:13:10 GMT
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5])
	by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id JAA27566;
	Thu, 15 Jun 2000 09:05:58 -0700 (PDT)
Received: from russet.ascend.com by fw-ext.ascend.com
          via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 15 Jun 2000 16:13:06 UT
Received: from porky (porky.ascend.com [192.207.23.83])
	by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id JAA14486;
	Thu, 15 Jun 2000 09:13:05 -0700 (PDT)
Received: from ascend.com by ascend.com
Message-Id: <4.3.2.7.2.20000615120826.00dcff00@alpo.casc.com>
X-Sender: amalis@alpo.casc.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 15 Jun 2000 12:09:54 -0400
To: Eric Gray <EGray@zaffire.com>
From: "Andrew G. Malis" <amalis@lucent.com>
Subject: RE: Last Call for LDP
Cc: "'Joan Cucchiara'" <JCucchiara@Brixnet.com>,
        "'MPLS Mailing list'" <mpls@UU.NET>,
        "'Bob Thomas'" <rhthomas@cisco.com>
In-Reply-To: <9A564CC874B5D3118FB9009027B0A662690762@ICARIAN>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

This has been corrected in draft-ietf-mpls-fr-05.txt (which now only 
supports 10- and 23-bit DLCIs).

Cheers,
Andy

--------

At 6/8/00 01:51 PM -0700, Eric Gray wrote:
>Joan,
>
>         I had heard the same from Andy Malis.
>That's why I was a little surprised to discover
>that this same issue exists in the latest draft
>for MPLS over Frame Relay.
>
>         I think that LDP needs to be consistent
>with the Frame Relay MPLS draft.  I'm not sure
>which should be fixed...
>
>--
>Eric Gray
>
> > -----Original Message-----
> > From: Cucchiara, Joan [mailto:JCucchiara@Brixnet.com]
> > Sent: Thursday, June 08, 2000 12:29 PM
> > To: 'rhthomas@cisco.com'
> > Cc: 'mpls@uu.net'
> > Subject: RE: Last Call for LDP
> >
> >
> >
> > Bob,
> >
> > My understanding is that the Frame Relay Forum has
> > dropped support for 17-bit DLCIs.  The LDP MIB and
> > LSR MIB (drafts) are not supporting 17-bit FrameRelay
> > labels.
> >
> > I would like to request that references to 17-bit DLCI
> > Frame Relay labels be removed from the LDP Specification.
> > Admittedly, this was not an issue during the prior last
> > call because the 17-bit FR DLCIs were still being supported
> > by the FRF during that time.
> >
> > This change would more closely align the LDP spec with the
> > LDP MIB and LSR MIB.




From owner-mpls@UU.NET  Thu Jun 15 13:10:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08401
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 13:10:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitse26885;
	Thu, 15 Jun 2000 17:08:53 GMT
Received: by mail-control.mail.uu.net 
	id QQitse25446
	for mpls-outgoing; Thu, 15 Jun 2000 17:08:18 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitse25438
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 17:08:11 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitse01196
	for <mpls@UU.NET>; Thu, 15 Jun 2000 13:07:55 -0400 (EDT)
From: darren.freeland@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQitse10112
	for <mpls@UU.NET>; Thu, 15 Jun 2000 17:07:55 GMT
Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP;
          Thu, 15 Jun 2000 17:28:48 +0100
Received: by cbtlipnt01.btlabs.bt.co.uk 
          with Internet Mail Service (5.5.2651.88) id <M358BNAT>;
          Thu, 15 Jun 2000 17:28:47 +0100
Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C211@mbtlipnt01.btlabs.bt.co.uk>
To: clapp@research.telcordia.com, xuyg@lucent.com
Cc: mpls@UU.NET
Subject: RE: Information about optical routing in MPLS net.
Date: Thu, 15 Jun 2000 17:28:16 +0100
X-Mailer: Internet Mail Service (5.5.2651.88)
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I would support the view that having the router control the optical domain
is not good.  This comes down to a simple desire to see an optical layer
which is open to ALL clients - not just IP.  Of course it is possible to
allow the router to control the optical layer ... however, this idea
overlooks the fact that an operator may wish to carry many other clients
across an optical network.

Regards,

Darren Freeland
Networks Analyst
BT Adastral Park

-----Original Message-----
From: George Clapp [mailto:clapp@research.telcordia.com]
Sent: 15 June 2000 17:09
To: Yangguang Xu
Cc: mpls@UU.NET
Subject: Re: Information about optical routing in MPLS net.


At 11:26 AM 6/14/00 -0400, Yangguang Xu wrote:
>Please see comments below:
>
> >
> > a. Considering explicit paths calculation through an optical MPLS
> > network, ingress
> >     routers or third part tools, at the input of the network, will still
> > calculate the
> >     entire path (ingress to egress router), considering links within the
> > optical domain
> >     too?
> >
>
>There have been discussions about this before. My personal opinion is that
>having router control optical domain is not feasible both technically and
>practically.

Could you give some examples of why it's not feasible?

Thanks,
George Clapp
voice     973-829-4610
email     clapp@research.telcordia.com


From owner-mpls@UU.NET  Thu Jun 15 13:31:35 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09355
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 13:31:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsf26898;
	Thu, 15 Jun 2000 17:29:55 GMT
Received: by mail-control.mail.uu.net 
	id QQitsf27249
	for mpls-outgoing; Thu, 15 Jun 2000 17:29:35 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsf27244
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 17:29:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsf05083
	for <mpls@UU.NET>; Thu, 15 Jun 2000 13:29:10 -0400 (EDT)
Received: from auemail2.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail2.lucent.com [192.11.223.163])
	id QQitsf12925
	for <mpls@UU.NET>; Thu, 15 Jun 2000 17:29:09 GMT
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA15798
	for <mpls@UU.NET>; Thu, 15 Jun 2000 13:29:09 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA15787;
	Thu, 15 Jun 2000 13:29:08 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA07446; Thu, 15 Jun 2000 13:29:07 -0400 (EDT)
Message-ID: <39491262.2175976F@lucent.com>
Date: Thu, 15 Jun 2000 13:29:06 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: clapp@research.telcordia.com
CC: darren.freeland@bt.com, mpls@UU.NET
Subject: Re: Information about optical routing in MPLS net.
References: <71DA16F18D32D2119A1D0000F8FE9A940920C211@mbtlipnt01.btlabs.bt.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Following the point from Darren, 

Optical layer is open to ALL clients, e.g. ATM, TDM, SONET/SDH and IP. If you
don't like the client/server model, optical network can also be viewed as a
cloud, which can be tunneled through (please refer to "Hierarchical Tunnel
Establishment in RSVP-TE" discussion). No matter what, optical network try to
achieve true networking rather than simple connectivity or bandwidth. It's as
complicated as pure IP network with many concerns that are unique to optical
domain. Also its protocol will evolve mainly independently from IP (sure will be
affected by IP). So I think IP router should focus more on how to request
service from optical domain than to directly control it.

Yangguang


darren.freeland@bt.com wrote:
> 
> I would support the view that having the router control the optical domain
> is not good.  This comes down to a simple desire to see an optical layer
> which is open to ALL clients - not just IP.  Of course it is possible to
> allow the router to control the optical layer ... however, this idea
> overlooks the fact that an operator may wish to carry many other clients
> across an optical network.
> 
> Regards,
> 
> Darren Freeland
> Networks Analyst
> BT Adastral Park
> 
> -----Original Message-----
> From: George Clapp [mailto:clapp@research.telcordia.com]
> Sent: 15 June 2000 17:09
> To: Yangguang Xu
> Cc: mpls@UU.NET
> Subject: Re: Information about optical routing in MPLS net.
> 
> At 11:26 AM 6/14/00 -0400, Yangguang Xu wrote:
> >Please see comments below:
> >
> > >
> > > a. Considering explicit paths calculation through an optical MPLS
> > > network, ingress
> > >     routers or third part tools, at the input of the network, will still
> > > calculate the
> > >     entire path (ingress to egress router), considering links within the
> > > optical domain
> > >     too?
> > >
> >
> >There have been discussions about this before. My personal opinion is that
> >having router control optical domain is not feasible both technically and
> >practically.
> 
> Could you give some examples of why it's not feasible?
> 
> Thanks,
> George Clapp
> voice     973-829-4610
> email     clapp@research.telcordia.com


From owner-mpls@UU.NET  Thu Jun 15 13:47:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09968
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 13:47:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsh25860;
	Thu, 15 Jun 2000 17:45:48 GMT
Received: by mail-control.mail.uu.net 
	id QQitsh28421
	for mpls-outgoing; Thu, 15 Jun 2000 17:45:16 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsh28411
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 17:45:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsg08482
	for <mpls@UU.NET>; Thu, 15 Jun 2000 13:44:55 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitsg25174
	for <mpls@UU.NET>; Thu, 15 Jun 2000 17:44:55 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id NAA24006; Thu, 15 Jun 2000 13:44:53 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id NAA25101;
	Thu, 15 Jun 2000 13:45:19 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006151745.NAA25101@curtis-lt.avici.com>
To: jleu@mindspring.com
cc: curtis@avici.com, "Abes, Andi" <aabes@quarrytech.com>,
        Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Wed, 14 Jun 2000 08:29:29 CDT."
             <20000614082929.B14081@doit.wisc.edu> 
Date: Thu, 15 Jun 2000 13:45:18 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <20000614082929.B14081@doit.wisc.edu>, "James R. Leu" writes:
> On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:
> <snip>
> 
> > I makes sense for the inner labels to be per platform because the
> > outer label can be rerouted and end up coming in on another interface.
> > If that reroute occurs cleanly (make before break), it should not be
> > nessecary to reroute the inner labels.
> > 
> > Curtis
> 
> Are your saying that an ILM will have labels from multiple labelspaces?
> That would require the label manager to do co-ordination of every label
> allocation.

By global I meant platform-specific.  There is no need at all to
coordinate label allocation across LSR.  An LSR many be using both
platform-specific and interface-specific labels.  This is not a hard
problem.

Curtis


From owner-mpls@UU.NET  Thu Jun 15 14:23:31 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11115
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 14:23:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsj25008;
	Thu, 15 Jun 2000 18:21:49 GMT
Received: by mail-control.mail.uu.net 
	id QQitsj10235
	for mpls-outgoing; Thu, 15 Jun 2000 18:21:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitsj10210
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 18:21:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsj09856
	for <mpls@UU.NET>; Thu, 15 Jun 2000 14:21:12 -0400 (EDT)
Received: from cplane.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: jersey.cplane.com [63.193.105.226])
	id QQitsj03017
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:21:11 GMT
Received: (qmail 1650 invoked from network); 15 Jun 2000 17:04:23 -0000
Received: from unknown (HELO texas.cplane.com) (unknown)
  by unknown with SMTP; 15 Jun 2000 17:04:23 -0000
Received: (qmail 8736 invoked from network); 15 Jun 2000 18:21:08 -0000
Received: from unknown (HELO cplane.com) (unknown)
  by unknown with SMTP; 15 Jun 2000 18:21:08 -0000
Message-ID: <39491E92.B7DEE05F@cplane.com>
Date: Thu, 15 Jun 2000 11:21:06 -0700
From: Mukul Katiyar <mukul@cplane.com>
Reply-To: mukul@cplane.com
Organization: Cplane Inc
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: curtis@avici.com
CC: jleu@mindspring.com, "Abes, Andi" <aabes@quarrytech.com>,
        Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <200006151745.NAA25101@curtis-lt.avici.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis Villamizar wrote:
> 
> In message <20000614082929.B14081@doit.wisc.edu>, "James R. Leu" writes:
> > On Wed, Jun 14, 2000 at 09:19:46AM -0400, Curtis Villamizar wrote:
> > <snip>
> >
> > > I makes sense for the inner labels to be per platform because the
> > > outer label can be rerouted and end up coming in on another interface.
> > > If that reroute occurs cleanly (make before break), it should not be
> > > nessecary to reroute the inner labels.
> > >
> > > Curtis
> >
> > Are your saying that an ILM will have labels from multiple labelspaces?
> > That would require the label manager to do co-ordination of every label
> > allocation.
> 
> By global I meant platform-specific.  There is no need at all to
> coordinate label allocation across LSR.  An LSR many be using both
> platform-specific and interface-specific labels.  This is not a hard
> problem.
> 


Protection of LSPs using label stacking will
 imply that the inner most labels be allocated
on a per platform basis. This it self places a constrain on the
label space to be global from which all those LSPs that may be
protected with label stacking to allocate their labels from.
IMHO this is a probelm considering that LSPs which may need
protection (label allocated from global Label space) could co-exist 
with those which may not (not necessarily from global space).
Please correct me if I am missing some thing.
-Mukul

> Curtis


From owner-mpls@UU.NET  Thu Jun 15 14:29:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11205
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 14:29:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsj28945;
	Thu, 15 Jun 2000 18:27:23 GMT
Received: by mail-control.mail.uu.net 
	id QQitsj10610
	for mpls-outgoing; Thu, 15 Jun 2000 18:26:49 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitsj10599
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 18:26:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsj10704
	for <mpls@uu.net>; Thu, 15 Jun 2000 14:26:07 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitsj06172
	for <mpls@uu.net>; Thu, 15 Jun 2000 18:26:07 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id OAA27752; Thu, 15 Jun 2000 14:26:06 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id OAA25193;
	Thu, 15 Jun 2000 14:26:30 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006151826.OAA25193@curtis-lt.avici.com>
To: Kireeti Kompella <kireeti@juniper.net>
cc: curtis@avici.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Wed, 14 Jun 2000 10:59:58 PDT."
             <200006141759.KAA25318@kummer.juniper.net> 
Date: Thu, 15 Jun 2000 14:26:30 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200006141759.KAA25318@kummer.juniper.net>, Kireeti Kompella writes:
> Curtis,
> 
> > You do seem to have tunnel vision.  Others support using a real label.
> 
> That's good to know.  Can you enumerate some of the 'others'?
> What was the primary motivation?

Avici is one.  We always send a real label unless you have an older
card that we no longer ship in which case PHP is needed.  I'll let
others speak for themselves.

> Fortunately, an egress is in charge of its destiny, at least as far
> as the last label is concerned.  As you point out, an egress can
> (with some forethought) request PHP if the label stack gets too deep.

Right.  Toss a packet as malformed if that number of POPs is exceeded
so as not to blow wire rate lookup.  Since an LSR controls its own
destiny in this regard, any packet with too many POPs is malformed.
Allow the user to configure a higher limit on the POP depth if average
payload size is significantly greater than 40 on their network.  With
this scheme the inner LSP (labels closer to the bottom of the stack
and the LSP that are last to be set up) will have PHP after the POP
limit is exceeded.  At the egress counters will be available for the
outer LSP only (the ones that don't use PHP).

> > With PHP you can only count OAM packets, not packets received.  If the
> > purpose is to accurately measure loss through an LSP (for example, one
> > carrying an AF class), then PHP requires you to send enough OAM
> > traffic to make a significant sampling, which could be a lot.  If OAM
> > is for continuity testing only, then PHP is not a problem for OAM.
> 
> Agreed.
> 
> Kireeti.

Thanks,

Curtis


From owner-mpls@UU.NET  Thu Jun 15 14:32:03 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11322
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 14:32:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsk01501;
	Thu, 15 Jun 2000 18:30:26 GMT
Received: by mail-control.mail.uu.net 
	id QQitsk10825
	for mpls-outgoing; Thu, 15 Jun 2000 18:30:02 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitsj10796
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 18:29:59 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsj11432
	for <mpls@uu.net>; Thu, 15 Jun 2000 14:29:35 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitsj00638
	for <mpls@uu.net>; Thu, 15 Jun 2000 18:29:32 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA29940
	for mpls@uu.net; Thu, 15 Jun 2000 14:29:31 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsj10753
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 18:28:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsj18613
	for <mpls@UU.NET>; Thu, 15 Jun 2000 14:28:44 -0400 (EDT)
Received: from redd235.procket.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: flowpoint.procket.com [205.253.146.41])
	id QQitsj08044
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:28:44 GMT
Received: (from tli@localhost)
	by redd235.procket.com (8.9.3/8.9.3) id LAA01695;
	Thu, 15 Jun 2000 11:28:38 -0700
X-Confidential: Procket Confidential/Need to know
X-Authentication-Warning: redd235.procket.com: tli set sender to tli@redd235.procket.com using -f
From: Tony Li <tli@Procket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14665.8278.417504.514266@redd235.procket.com>
Date: Thu, 15 Jun 2000 11:28:38 -0700 (PDT)
To: darren.freeland@bt.com
Cc: clapp@research.telcordia.com, xuyg@lucent.com, mpls@UU.NET
Subject: RE: Information about optical routing in MPLS net.
In-Reply-To: <56654961@toto.iv>
X-Mailer: VM 6.75 under Emacs 20.4.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


 | I would support the view that having the router control the optical domain
 | is not good.  This comes down to a simple desire to see an optical layer
 | which is open to ALL clients - not just IP.  Of course it is possible to
 | allow the router to control the optical layer ... however, this idea
 | overlooks the fact that an operator may wish to carry many other clients
 | across an optical network.


The optical plane clearly needs a control plane that provides a (lambda)
routing and signaling infrastructure.  This infrastructure is fundamentally
similar to the routing and signaling technology that we're already using
for MPLS.  Now, we can choose to re-invent this technology, or we can
leverage the technology that we have already have developed and have
started to deploy.

Note that this argument is completely independent of the nature of the
optical client.  Nothing here precludes non-IP usage of the optical core.
It would simply use the IP network as the out-of-band control plane.

Regards,
Tony






From owner-mpls@UU.NET  Thu Jun 15 14:44:40 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11561
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 14:44:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsk18153;
	Thu, 15 Jun 2000 18:43:04 GMT
Received: by mail-control.mail.uu.net 
	id QQitsk11897
	for mpls-outgoing; Thu, 15 Jun 2000 18:42:42 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitsk11885
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 18:42:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsk13989
	for <mpls@UU.NET>; Thu, 15 Jun 2000 14:42:08 -0400 (EDT)
Received: from u-mail.rd.francetelecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63])
	id QQitsk17428
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:42:08 GMT
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
	id <KG0FP5L9>; Thu, 15 Jun 2000 11:39:15 -0700
Message-ID: <337055FBC675D311A85D00508B5A9C4F254306@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
	 <sergio.catanzariti@rd.francetelecom.com>
To: "'Tony Li'" <tli@Procket.com>
Cc: clapp@research.telcordia.com, xuyg@lucent.com, mpls@UU.NET,
        darren.freeland@bt.com
Subject: RE: Information about optical routing in MPLS net.
Date: Thu, 15 Jun 2000 11:39:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD6F9.01DC8736"
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_01BFD6F9.01DC8736
Content-Type: text/plain


	> It would simply use the IP network as the out-of-band control
plane.

Fully agree on the advantages. But, this is still an open problem rather
than an acceptable and stable solution, at least in today carriers
operational models.

Sergio

> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com 
> --------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From:	Tony Li [SMTP:tli@Procket.com]
> Sent:	Thursday, June 15, 2000 11:29 AM
> To:	darren.freeland@bt.com
> Cc:	clapp@research.telcordia.com; xuyg@lucent.com; mpls@UU.NET
> Subject:	RE: Information about optical routing in MPLS net.
> 
> 
>  | I would support the view that having the router control the optical
> domain
>  | is not good.  This comes down to a simple desire to see an optical
> layer
>  | which is open to ALL clients - not just IP.  Of course it is possible
> to
>  | allow the router to control the optical layer ... however, this idea
>  | overlooks the fact that an operator may wish to carry many other
> clients
>  | across an optical network.
> 
> 
> The optical plane clearly needs a control plane that provides a (lambda)
> routing and signaling infrastructure.  This infrastructure is
> fundamentally
> similar to the routing and signaling technology that we're already using
> for MPLS.  Now, we can choose to re-invent this technology, or we can
> leverage the technology that we have already have developed and have
> started to deploy.
> 
> Note that this argument is completely independent of the nature of the
> optical client.  Nothing here precludes non-IP usage of the optical core.
> It would simply use the IP network as the out-of-band control plane.
> 
> Regards,
> Tony
> 
> 
> 

------_=_NextPart_001_01BFD6F9.01DC8736
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Information about optical routing in MPLS net.</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Courier New">&gt; It would simply use the IP =
network as the out-of-band control plane.</FONT>
</P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Fully agree on the advantages. But, =
this is still an open problem rather than an acceptable and stable =
solution, at least in today carriers operational models.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sergio</FONT>
</P>
<UL>
<P><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sergio =
Catanzariti</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Senior Project =
Manager, Technology Integration</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">France Telecom =
R&amp;D </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">1000 Marina =
Boulevard Suite 300 </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brisbane CA =
94005</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tel. =
650-875-1526</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Fax. =
650-875-1505</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">email:sergio.catanzariti@rd.francetelecom.com =
</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
</P>
<BR>

<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tony Li [SMTP:tli@Procket.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, June 15, 2000 11:29 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">darren.freeland@bt.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">clapp@research.telcordia.com; xuyg@lucent.com; =
mpls@UU.NET</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: Information about optical =
routing in MPLS net.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;| I would support the view =
that having the router control the optical domain</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;| is not good.&nbsp; This =
comes down to a simple desire to see an optical layer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;| which is open to ALL =
clients - not just IP.&nbsp; Of course it is possible to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;| allow the router to =
control the optical layer ... however, this idea</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;| overlooks the fact that =
an operator may wish to carry many other clients</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;| across an optical =
network.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The optical plane clearly needs =
a control plane that provides a (lambda)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">routing and signaling =
infrastructure.&nbsp; This infrastructure is fundamentally</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">similar to the routing and =
signaling technology that we're already using</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">for MPLS.&nbsp; Now, we can =
choose to re-invent this technology, or we can</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">leverage the technology that we =
have already have developed and have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">started to deploy.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Note that this argument is =
completely independent of the nature of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">optical client.&nbsp; Nothing =
here precludes non-IP usage of the optical core.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">It would simply use the IP =
network as the out-of-band control plane.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tony</FONT>
</P>
<BR>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFD6F9.01DC8736--


From owner-mpls@UU.NET  Thu Jun 15 14:53:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11745
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 14:53:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsl16774;
	Thu, 15 Jun 2000 18:51:54 GMT
Received: by mail-control.mail.uu.net 
	id QQitsl12524
	for mpls-outgoing; Thu, 15 Jun 2000 18:51:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitsl12475
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 18:51:11 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsl15567
	for <mpls@uu.net>; Thu, 15 Jun 2000 14:50:14 -0400 (EDT)
Received: from rout-LRC-01.lrc.deene.ufu.br by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: rout-lrc-01.lrc.deene.ufu.br [200.19.152.13])
	id QQitsl20794
	for <mpls@uu.net>; Thu, 15 Jun 2000 18:46:43 GMT
Received: from lrc.deene.ufu.br (200.19.148.215) by rout-LRC-01.lrc.deene.ufu.br
 (EMWAC SMTPRS 0.80) with SMTP id <B0000035064@rout-LRC-01.lrc.deene.ufu.br>;
 Thu, 15 Jun 2000 15:47:57 -0300
Message-ID: <394925A2.A6748AAD@lrc.deene.ufu.br>
Date: Thu, 15 Jun 2000 15:51:14 -0300
From: Daniela Cunha <daniela@lrc.deene.ufu.br>
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: How a LER really works?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi,
Do you know where I can get the step-by-step functions performaded by
the LER in a MPLS domain?
I need the details about the functions performed, the status of the
packet in each stage when passing through an LER...
Sorry if it is a stupid question and easy to find, but I've already
tried but I didn't get.

Thank you very much
Regards
Daniela



From owner-mpls@UU.NET  Thu Jun 15 15:14:50 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12296
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 15:14:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsm01357;
	Thu, 15 Jun 2000 19:13:15 GMT
Received: by mail-control.mail.uu.net 
	id QQitsm23352
	for mpls-outgoing; Thu, 15 Jun 2000 19:12:53 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitsm23343
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 19:12:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsm19739
	for <mpls@uu.net>; Thu, 15 Jun 2000 15:11:34 -0400 (EDT)
Received: from rout-LRC-01.lrc.deene.ufu.br by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: rout-lrc-01.lrc.deene.ufu.br [200.19.152.13])
	id QQitsm08291
	for <mpls@uu.net>; Thu, 15 Jun 2000 19:11:21 GMT
Received: from lrc.deene.ufu.br (200.19.148.215) by rout-LRC-01.lrc.deene.ufu.br
 (EMWAC SMTPRS 0.80) with SMTP id <B0000035076@rout-LRC-01.lrc.deene.ufu.br>;
 Thu, 15 Jun 2000 16:12:42 -0300
Message-ID: <39492B6F.A26A7800@lrc.deene.ufu.br>
Date: Thu, 15 Jun 2000 16:15:59 -0300
From: Daniela Cunha <daniela@lrc.deene.ufu.br>
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: How does a LER really work?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
Do you know where I can get the step-by-step functions performaded by
the LER in a MPLS domain?
I need the details about the functions performed, the status of the
packet in each stage when passing through an LER...
Sorry if it is a stupid question and easy to find, but I've already
tried but I didn't get.

Thank you very much
Regards
Daniela



From owner-mpls@UU.NET  Thu Jun 15 15:17:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12352
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 15:17:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsn03491;
	Thu, 15 Jun 2000 19:16:09 GMT
Received: by mail-control.mail.uu.net 
	id QQitsn23632
	for mpls-outgoing; Thu, 15 Jun 2000 19:15:33 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsn23621
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 19:15:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsn27703
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:15:03 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQitsn02682
	for <mpls@UU.NET>; Thu, 15 Jun 2000 19:15:01 GMT
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Thu, 15 Jun 2000 14:12:54 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id M0V6N1MS; Thu, 15 Jun 2000 15:13:22 -0400
Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id L5HL8RP2; Thu, 15 Jun 2000 15:13:05 -0400
Message-ID: <39492AC1.EA4D8C9@americasm01.nt.com>
Date: Thu, 15 Jun 2000 15:13:05 -0400
From: "Peter Ashwood-Smith" <petera@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: CATANZARITI Sergio FTR&D/TI <sergio.catanzariti@rd.francetelecom.com>
CC: "'Tony Li'" <tli@Procket.com>, clapp@research.telcordia.com,
        xuyg@lucent.com, mpls@UU.NET, darren.freeland@bt.com
Subject: Re: Information about optical routing in MPLS net.
References: <337055FBC675D311A85D00508B5A9C4F254306@u-mail.rd.francetelecom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

>      > It would simply use the IP network as the out-of-band control plane.
> 
> Fully agree on the advantages. But, this is still an open problem rather than an acceptable and stable solution, at
> least in today carriers operational models.
> 
> Sergio

    What you are seeing is a recognition by many folks that a PATH regardless of
what we call the labels can be controlled by MPLS (if the MPLS protocols are 
suitibly generalized). What actually goes over these paths can be anything. After
all, that is the "MP" part of "MPLS".

    Constraint based, distributed source routing with an OSPF/IS-IS style 
topology database are the preferred solution to path oriented routing problems
and have been used for a number of years now in ATM and proprietary systems
so it is only natural to extend them to Optical networks.

    Cheers,

    Peter Ashwood-Smith


From owner-mpls@UU.NET  Thu Jun 15 15:30:59 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12602
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 15:30:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsn13661;
	Thu, 15 Jun 2000 19:29:25 GMT
Received: by mail-control.mail.uu.net 
	id QQitsn24430
	for mpls-outgoing; Thu, 15 Jun 2000 19:28:55 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitsn24425
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 19:28:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsn00665
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:28:41 -0400 (EDT)
Received: from c000.snv.cp.net by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: c000-h001.c000.snv.cp.net [209.228.32.65])
	id QQitsn21203
	for <mpls@UU.NET>; Thu, 15 Jun 2000 19:28:40 GMT
Received: (cpmta 10365 invoked from network); 15 Jun 2000 12:28:39 -0700
Received: from dhcp196.altasoft.com (HELO am) (204.242.142.196)
  by smtp.ipoptical.com with SMTP; 15 Jun 2000 12:28:39 -0700
X-Sent: 15 Jun 2000 19:28:39 GMT
From: "alex.mondrus" <alex.mondrus@ipoptical.com>
To: "Daniela Cunha" <daniela@lrc.deene.ufu.br>, <mpls@UU.NET>
Subject: RE: How a LER really works?
Date: Thu, 15 Jun 2000 15:36:39 -0400
Message-ID: <NEBBLJNJKMBINGNCIHNKGEJNCAAA.alex.mondrus@ipoptical.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <394925A2.A6748AAD@lrc.deene.ufu.br>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Daniela:

It will be a good start->

http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-state-03.txt


Alex Mondrus
www.ipoptical.com

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Daniela
Cunha
Sent: Thursday, June 15, 2000 2:51 PM
To: mpls@UU.NET
Subject: How a LER really works?



Hi,
Do you know where I can get the step-by-step functions performaded by
the LER in a MPLS domain?
I need the details about the functions performed, the status of the
packet in each stage when passing through an LER...
Sorry if it is a stupid question and easy to find, but I've already
tried but I didn't get.

Thank you very much
Regards
Daniela




From owner-mpls@UU.NET  Thu Jun 15 15:39:49 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12791
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 15:39:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitso20275;
	Thu, 15 Jun 2000 19:38:11 GMT
Received: by mail-control.mail.uu.net 
	id QQitso24964
	for mpls-outgoing; Thu, 15 Jun 2000 19:37:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitso24959
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 19:37:41 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitso25299
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:37:18 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQitso19513
	for <mpls@UU.NET>; Thu, 15 Jun 2000 19:37:18 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id PAA03857; Thu, 15 Jun 2000 15:37:17 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id PAA25282;
	Thu, 15 Jun 2000 15:37:27 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200006151937.PAA25282@curtis-lt.avici.com>
To: darren.freeland@bt.com
cc: clapp@research.telcordia.com, xuyg@lucent.com, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: Information about optical routing in MPLS net. 
In-reply-to: Your message of "Thu, 15 Jun 2000 17:28:16 BST."
             <71DA16F18D32D2119A1D0000F8FE9A940920C211@mbtlipnt01.btlabs.bt.co.uk> 
Date: Thu, 15 Jun 2000 15:37:27 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <71DA16F18D32D2119A1D0000F8FE9A940920C211@mbtlipnt01.btlabs.bt.co.uk
>, darren.freeland@bt.com writes:
> I would support the view that having the router control the optical domain
> is not good.  This comes down to a simple desire to see an optical layer
> which is open to ALL clients - not just IP.  Of course it is possible to
> allow the router to control the optical layer ... however, this idea
> overlooks the fact that an operator may wish to carry many other clients
> across an optical network.
> 
> Regards,
> 
> Darren Freeland
> Networks Analyst
> BT Adastral Park
> 
> -----Original Message-----
> From: George Clapp [mailto:clapp@research.telcordia.com]
> ... 
> Could you give some examples of why it's not feasible?



Please refer to draft-kompella-mpls-optical-00.txt.

Consider the following example usage.

In the optical core, the optical switches acting as LSR would
advertise the available paths as FSC or LSC tunnels.  The LSR routers
adjacent to the optical core can create PSC over the FSC or LSC
tunnels.  These non-optical LSR will initially (and some people think
always) have no control over the routing of the FSC and LSC tunnels.

If there is a regional distribution of traffic, the core will be
attached to access routers.  This may be using LSC and/or TDM tunnels
again controlled by the optical switches acting as LSR.  The core and
access routers can create PSC to get from the core to the region.

End-to-end tunnels can take 3 hops, one through the near PSC from
access router to core, one through a PSC across the core, and the last
through the PSC across the far region to the destination access
router.

VPN tunnels are signaled via BGP.  These ride inside the e2e tunnels
but as currently implemented use LDP.  This implies that we ween the
VPN tunnels from LDP or do LDP inside the e2e tunnels.  This doesn't
scale as well as just having an RSVP-TE adjacency through the regional
PSC to the core.

Any type of traffic can run through this type of traffic engineered
network within the VPNs.  MPLS-TE provides a means to signal across
multiple optical domains of different type, without requiring all of
the LSR to know anything at all about how to router within any of the
optical domains themselves.

Curtis

ps- I'd be happy to contribute to the usage draft that is being split
out from draft-kompella-mpls-optical-00.txt.


From owner-mpls@UU.NET  Thu Jun 15 15:41:59 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12834
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 15:41:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitso29690;
	Thu, 15 Jun 2000 19:40:25 GMT
Received: by mail-control.mail.uu.net 
	id QQitso25050
	for mpls-outgoing; Thu, 15 Jun 2000 19:40:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitso25041
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 19:40:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitso25744
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:39:28 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQitso28780
	for <mpls@UU.NET>; Thu, 15 Jun 2000 19:39:28 GMT
Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id PAA26657;
	Thu, 15 Jun 2000 15:39:28 -0400
Received: (from jleu@localhost)
	by localhost.laurelnetworks.com (8.9.3/8.9.3) id PAA02106;
	Thu, 15 Jun 2000 15:39:27 -0400
Date: Thu, 15 Jun 2000 15:39:27 -0400
From: "James R. Leu" <jleu@laurelnetworks.com>
To: Daniela Cunha <daniela@lrc.deene.ufu.br>
Cc: mpls@UU.NET
Subject: Re: How does a LER really work?
Message-ID: <20000615153927.A1061@laurelnetworks.com>
Reply-To: jleu@laurelnetworks.com
References: <39492B6F.A26A7800@lrc.deene.ufu.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <39492B6F.A26A7800@lrc.deene.ufu.br>; from daniela@lrc.deene.ufu.br on Thu, Jun 15, 2000 at 04:15:59PM -0300
Organization: Laurel Networks
Sender: owner-mpls@UU.NET
Precedence: bulk

Would sample implementations help you?

MPLS for Linux:  ftp://nero.doit.wisc.edu/pub/mpls/
NIST Switch (FreeBSD):  http://is2.antd.nist.gov/pub/nistswitch/

Jim
-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com

On Thu, Jun 15, 2000 at 04:15:59PM -0300, Daniela Cunha wrote:
> Hi,
> Do you know where I can get the step-by-step functions performaded by
> the LER in a MPLS domain?
> I need the details about the functions performed, the status of the
> packet in each stage when passing through an LER...
> Sorry if it is a stupid question and easy to find, but I've already
> tried but I didn't get.
> 
> Thank you very much
> Regards
> Daniela



From owner-mpls@UU.NET  Thu Jun 15 15:46:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12948
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 15:46:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitso25264;
	Thu, 15 Jun 2000 19:44:43 GMT
Received: by mail-control.mail.uu.net 
	id QQitso25440
	for mpls-outgoing; Thu, 15 Jun 2000 19:44:07 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitso25432
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 19:44:05 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitso03767
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:44:00 -0400 (EDT)
Received: from osf1.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: osf1.gmu.edu [129.174.1.13])
	id QQitso24723
	for <mpls@UU.NET>; Thu, 15 Jun 2000 19:44:00 GMT
Received: from localhost (rpapneja@localhost)
	by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA05395;
	Thu, 15 Jun 2000 15:43:48 -0400 (EDT)
Date: Thu, 15 Jun 2000 15:43:48 -0400 (EDT)
From: Rajiv Papneja <rpapneja@osf1.gmu.edu>
To: Cesar Olvera <cesar@redes.unam.mx>
cc: mpls@UU.NET
Subject: Re: MPLS testing procedures
In-Reply-To: <3947F0FC.6C097D86@redes.unam.mx>
Message-ID: <Pine.OSF.4.21.0006151523480.12282-100000@osf1.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


 Hi Cesar,

  The Advanced Internet Lab (AIL) at George Mason University was
formed by an initial research grant from UUNET Technologies which
provided funding to undertake construction of this state-of-the-art
laboratory.  The laboratory provides an independent testing and
research facility for emerging and novel technology products. 
Currently, AIL encompasses activities related to multivendor
interoperability testing for implementation of advanced
features in MPLS and other IP technologies.  Also, it brings together
networking equipment suppliers, ISPs, and relevant entities to help
shape and propel this industry.

  AIL's comprehensive interoperability testing program is currently
focussed on MPLS and is developed from the "AIL MPLS core capability
set" derived from copious input from the industry.  The program includes
test plans for:
 
      1) Traffic Engineering over MPLS
      2) LDP
      3) RSVP-TE
      4) CR-LDP
      5) IS-IS (including TE extensions)
      6) OSPF  (including TE extensions)
      7) BGP-4/MPLS
      8) ATM-LSRs
      9) Other requirement driven specific tests.

  The test plans noted above are ready and documented, but because of
binding the test plans noted above are ready and documented, but because
of binding Non-Disclosure agreements with the sponsors of the lab, the
plans are not available for public review.  However, the precedent AIL
core capability set will be available on our homepage in the near future.

  Sponsors of the lab include major router vendors, ISPs and test
equipment manufacturers.

  For further information regarding the functioning and sponsorship of the
Advanced Internet Lab, please visit our web site at http://ail.gmu.edu/.  

  Regards

  Rajiv Papneja
                      




On Wed, 14 Jun 2000, Cesar Olvera wrote:

> I am working in the MPLS at UNAM Research Group, a National Autonomous 
> Universtity of Mexico (UNAM) Working Group formed to discuss issues 
> related to MPLS.
> 
> Are there some testing procedures for both conformance and 
> interoperability on MPLS?. 
> 
> Thanks
> 
> Cesar Olvera
> Interoperability Lab Manager
> Networks Subdirection, Telecommunications Direction
> DGSCA-UNAM
> MEXICO
> 

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4700
email: rpapneja@osf1.gmu.edu
********************************



From owner-mpls@UU.NET  Thu Jun 15 15:49:35 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12993
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 15:49:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsp05206;
	Thu, 15 Jun 2000 19:47:57 GMT
Received: by mail-control.mail.uu.net 
	id QQitsp25836
	for mpls-outgoing; Thu, 15 Jun 2000 19:47:25 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitsp25827
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 19:47:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsp04368
	for <mpls@UU.NET>; Thu, 15 Jun 2000 15:47:00 -0400 (EDT)
Received: from bastion4.mail.sprint.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bastion4.mail.sprint.com [208.4.28.132])
	id QQitsp27140
	for <mpls@UU.NET>; Thu, 15 Jun 2000 19:47:00 GMT
Received: from sii01.mail.sprint.com by bastion4.mail.sprint.com with ESMTP for mpls@UU.NET; Thu, 15 Jun 2000 14:46:59 -0500
Received: from [144.223.128.84] by sii01.mail.sprint.com with ESMTP; Thu, 15 Jun 2000 14:46:46 -0500
Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.74.2.74])
	by kcopmh01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id OAA01105
	for <mpls@UU.NET>; Thu, 15 Jun 2000 14:46:44 -0500 (CDT)
From: Mark Jones <Mark.Jones@mail.sprint.com>
Received: from localhost (root@localhost)
	by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id OAA20266
	for <mpls@UU.NET>; Thu, 15 Jun 2000 14:46:44 -0500 (CDT)
X-OpenMail-Hops: 1
Date: Thu, 15 Jun 2000 14:46:43 -0500
Message-Id: <H00017a80991bb93.0961098402.kcopmp04@MHS>
Subject: RE: Re: Information about optical routing in MPLS net.
TO: mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/mixed;
  boundary="openmail-part-224044fc-00000001"
Sender: owner-mpls@UU.NET
Precedence: bulk

--openmail-part-224044fc-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

[My apologies for the long post.]

The complete control of the optical network by IP routers may be 
interesting, but it's not practical in a real 
multi-service/multi-client network.  At Sprint we have two perspectives 
on what the next optical network will look like.  One is that the 
optical network will consist of an all-optical core (my personal 
perspective).  In this case, the optical network may be controlled by 
client devices, but I see that as unlikely for many reasons (many of 
which were expressed well by Neil Harrison in his post on the subject 
yesterday).  The other option is that the optical network nodes will be 
mega-multi-service devices that will be fully IP capable.  In that case 
the nodes may look like an IP routers to clients and full "peer" 
communications is probably likely.

Either way, the IETF efforts regarding optical network control should 
not ignore the standardization of the optical network itself.  
Regardless of how many drafts and RFCs are generated, most of the 
optical transport expertise is not in the IETF.  Though it's tempting 
for every standards body to standardize the world, we all benefit most 
if each sticks with standards where one has the most subject matter 
experts.

Coordinated efforts to standardize the optical transport network are 
underway in ITU-T SG13, ITU-T SG15, T1X1, T1M1, and many other 
standards development organizations.  Efforts in those bodies are just 
now beginning to look at signaling and control plane issues.  It is a 
common view in those groups that MPLS, with extensions for optical 
network management, may become the control plane protocol of choice.  
However, I haven't seen any communication between this body and those 
transport groups.  How can we expect control anything when we aren't 
communicating with the groups on the other side of the control plane 
interface?  (Within companies this is happening, I know, but I'm afraid 
that even there communications are limited between the different 
departments.)

My point is that the IETF efforts need to focus on the requirements for 
the management interface and work with the transport standards groups 
to reach agreement on how this common control plane will supply the 
necessary information for communications both directions (client 
network elements to optical network and visa versa).  All these groups 
are now working via e-mail distributions lists, so it's not that 
complicated.

T1X1 and ITU-T are beginning to define what has been called an 
"Automatically Switched Optical Network."  The rough first draft of an 
ITU-T standard on the subject is publicly available at 
ftp://ftp.t1.org/pub/t1x1/x1.5/0x151280.doc.  Perhaps the IETF work in 
this area could provide useful input to help reach a common goal, a 
common control plane for dynamic connections over an optical network.  
The next meeting of T1X1 is July 11-14, in Ottawa, Ontario, Canada 
(http://www.t1.org/t1x1/_x1-man.htm).  No membership or registration is 
required for attendance.  More information on T1X1 is available from 
the T1X1 homepage at http://www.t1.org/t1x1/t1x1.htm.  I stress T1X1, 
because the ITU-T requires full membership for attendance at meetings 
or participation on their e-mail exploders.

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-534-5247
mark.jones@mail.sprint.com


-----Original Message-----
From: xuyg [mailto:xuyg@lucent.com]
Sent: Thursday, June 15, 2000 12:29 PM
To: clapp
Cc: xuyg; darren.freeland; mpls
Subject: FW: Re: Information about optical routing in MPLS net.



Following the point from Darren, 

Optical layer is open to ALL clients, e.g. ATM, TDM, SONET/SDH and IP. 
If you
don't like the client/server model, optical network can also be viewed 
as a
cloud, which can be tunneled through (please refer to "Hierarchical 
Tunnel
Establishment in RSVP-TE" discussion). No matter what, optical network 
try to
achieve true networking rather than simple connectivity or bandwidth. 
It's as
complicated as pure IP network with many concerns that are unique to 
optical
domain. Also its protocol will evolve mainly independently from IP 
(sure will be
affected by IP). So I think IP router should focus more on how to 
request
service from optical domain than to directly control it.

Yangguang


darren.freeland@bt.com wrote:
> 
> I would support the view that having the router control the optical 
domain
> is not good.  This comes down to a simple desire to see an optical 
layer
> which is open to ALL clients - not just IP.  Of course it is possible 
to
> allow the router to control the optical layer ... however, this idea
> overlooks the fact that an operator may wish to carry many other 
clients
> across an optical network.
> 
> Regards,
> 
> Darren Freeland
> Networks Analyst
> BT Adastral Park
> 
> -----Original Message-----
> From: George Clapp [mailto:clapp@research.telcordia.com]
> Sent: 15 June 2000 17:09
> To: Yangguang Xu
> Cc: mpls@UU.NET
> Subject: Re: Information about optical routing in MPLS net.
> 
> At 11:26 AM 6/14/00 -0400, Yangguang Xu wrote:
> >Please see comments below:
> >
> > >
> > > a. Considering explicit paths calculation through an optical MPLS
> > > network, ingress
> > >     routers or third part tools, at the input of the network, 
will still
> > > calculate the
> > >     entire path (ingress to egress router), considering links 
within the
> > > optical domain
> > >     too?
> > >
> >
> >There have been discussions about this before. My personal opinion 
is that
> >having router control optical domain is not feasible both 
technically and
> >practically.
> 
> Could you give some examples of why it's not feasible?
> 
> Thanks,
> George Clapp
> voice     973-829-4610
> email     clapp@research.telcordia.com

--openmail-part-224044fc-00000001--



From owner-mpls@UU.NET  Thu Jun 15 16:08:29 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13623
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 16:08:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsq10816;
	Thu, 15 Jun 2000 20:06:55 GMT
Received: by mail-control.mail.uu.net 
	id QQitsq06465
	for mpls-outgoing; Thu, 15 Jun 2000 20:06:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsq06450
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 20:06:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsq08455
	for <mpls@UU.NET>; Thu, 15 Jun 2000 16:06:04 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQitsq10127
	for <mpls@UU.NET>; Thu, 15 Jun 2000 20:06:04 GMT
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA00594
	for <mpls@UU.NET>; Thu, 15 Jun 2000 16:06:04 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA00586;
	Thu, 15 Jun 2000 16:06:03 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id QAA27645; Thu, 15 Jun 2000 16:06:03 -0400 (EDT)
Message-ID: <39493729.D0726944@lucent.com>
Date: Thu, 15 Jun 2000 16:06:01 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Li <tli@Procket.com>
CC: darren.freeland@bt.com, clapp@research.telcordia.com, mpls@UU.NET
Subject: Re: Information about optical routing in MPLS net.
References: <14665.8278.417504.514266@redd235.procket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Our argument is not about control plane design but how data control plane
interwork with optical control plane. Even they are totally identical, they
could actually run parallel without knowing each other. 

Regarding to protocol design, I fully support to leverage MPLS, BGP and OSPF for
optical control plane. However, down to details, it's hard to only "extend"
existing protocols without modifying it. Main protocol design can be reuse, but
its content, details and infrastructure to build upon are quite different.

Yangguang 

Tony Li wrote:
> 
>  | I would support the view that having the router control the optical domain
>  | is not good.  This comes down to a simple desire to see an optical layer
>  | which is open to ALL clients - not just IP.  Of course it is possible to
>  | allow the router to control the optical layer ... however, this idea
>  | overlooks the fact that an operator may wish to carry many other clients
>  | across an optical network.
> 
> The optical plane clearly needs a control plane that provides a (lambda)
> routing and signaling infrastructure.  This infrastructure is fundamentally
> similar to the routing and signaling technology that we're already using
> for MPLS.  Now, we can choose to re-invent this technology, or we can
> leverage the technology that we have already have developed and have
> started to deploy.
> 
> Note that this argument is completely independent of the nature of the
> optical client.  Nothing here precludes non-IP usage of the optical core.
> It would simply use the IP network as the out-of-band control plane.
> 
> Regards,
> Tony


From owner-mpls@UU.NET  Thu Jun 15 16:17:22 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13827
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 16:17:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsr27338;
	Thu, 15 Jun 2000 20:15:49 GMT
Received: by mail-control.mail.uu.net 
	id QQitsr07273
	for mpls-outgoing; Thu, 15 Jun 2000 20:15:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitsr07266
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 20:15:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsq04187
	for <mpls@uu.net>; Thu, 15 Jun 2000 16:14:58 -0400 (EDT)
Received: from thumper.research.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thumper.research.telcordia.com [128.96.41.1])
	id QQitsq18893
	for <mpls@uu.net>; Thu, 15 Jun 2000 20:14:24 GMT
Received: from clapp-nb.research.telcordia.com (pptpin01 [192.4.9.226])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e5FJOwd13087;
	Thu, 15 Jun 2000 15:24:59 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000615150826.00bc68d0@mailee.research.telcordia.com>
X-Sender: clapp@mailee.research.telcordia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 15 Jun 2000 15:24:53 -0400
To: Tony Li <tli@Procket.com>
From: George Clapp <clapp@research.telcordia.com>
Subject: RE: Information about optical routing in MPLS net.
Cc: mpls@UU.NET
In-Reply-To: <14665.8278.417504.514266@redd235.procket.com>
References: <56654961@toto.iv>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

I agree with the notion of optical equipment reusing IP control protocols 
to manage the network, but to what extent will routers that are clients of 
an optical network manage that network?  The ODSI is defining an interface 
(using MPLS signaling protocols) to enable a router to manage an optical 
channel, and they say that ATM switches and SONET ADMs can do the same.

Managing a channel isn't the same thing as managing a network, but it's a 
beginning.  How far do people think it will go?

George Clapp
voice     973-829-4610
email     clapp@research.telcordia.com

At 11:28 AM 6/15/00 -0700, you wrote:

>  | I would support the view that having the router control the optical domain
>  | is not good.  This comes down to a simple desire to see an optical layer
>  | which is open to ALL clients - not just IP.  Of course it is possible to
>  | allow the router to control the optical layer ... however, this idea
>  | overlooks the fact that an operator may wish to carry many other clients
>  | across an optical network.
>
>
>The optical plane clearly needs a control plane that provides a (lambda)
>routing and signaling infrastructure.  This infrastructure is fundamentally
>similar to the routing and signaling technology that we're already using
>for MPLS.  Now, we can choose to re-invent this technology, or we can
>leverage the technology that we have already have developed and have
>started to deploy.
>
>Note that this argument is completely independent of the nature of the
>optical client.  Nothing here precludes non-IP usage of the optical core.
>It would simply use the IP network as the out-of-band control plane.
>
>Regards,
>Tony



From owner-mpls@UU.NET  Thu Jun 15 17:04:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14584
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 17:04:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsu21527;
	Thu, 15 Jun 2000 21:03:03 GMT
Received: by mail-control.mail.uu.net 
	id QQitsu16628
	for mpls-outgoing; Thu, 15 Jun 2000 21:02:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitsu15885
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 21:02:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsu13309
	for <mpls@UU.NET>; Thu, 15 Jun 2000 17:01:57 -0400 (EDT)
Received: from mail2.itu.int by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail2.itu.ch [156.106.192.18])
	id QQitsu00783
	for <mpls@UU.NET>; Thu, 15 Jun 2000 21:01:57 GMT
Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21)
	id <M5YTY4SZ>; Thu, 15 Jun 2000 22:58:15 +0200
Message-ID: <DA5558CC09AED311ABE10000778D757F4C2DBD@mailsrv.itu.ch>
From: "Shaw, Robert" <Robert.Shaw@itu.int>
To: "'Mark Jones'" <Mark.Jones@mail.sprint.com>, mpls@UU.NET
Subject: RE: Re: Information about optical routing in MPLS net.
Date: Thu, 15 Jun 2000 23:01:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

> Either way, the IETF efforts regarding optical network control should 
> not ignore the standardization of the optical network itself.  
> Regardless of how many drafts and RFCs are generated, most of the 
> optical transport expertise is not in the IETF.  Though it's tempting 

It's a general problem. A lot of IETFers aren't familiar with ITU-T 
IP-related work... :-)

For example, for only the 2 ITU-T Study Groups you mention (13 and 15),
I'll give a brief summary of their current work as it relates to IP 
and a few references (some of which are only available to ITU-T members 
through password access):

ITU-T Study Group 13

Study Group 13 (http://www.itu.int/ITU-T/com13/index.html) is 
the ITU-T lead Study Group on IP. In this role, SG 13 maintains 
the "ITU IP Project Description" describing the status of ITU-T 
IP-related activities and specific study "Questions". The last
version of this from their February/March 2000 meeting is 
available at 
http://www.itu.int/ITU-T/com13/ip/documents/pl-22.doc in Word (.pdf
for the PDF version). SG 13 has also defined a framework 
for the "Y" Series of Recommendations that cover ITU-T IP-related 
standardization activities (see 
http://www.itu.int/ITU-T/com13/ip/y1000.html). The report of 
SG 13's last meeting in February/March 2000 contains considerable 
detail on the scope of ITU-T's IP-related work (see
http://www.itu.int/itudoc/itu-t/com13/reports/report2/r068.html).

At its March 2000 meeting, SG13 approved Recommendation Y.1310: 
Transport of IP over ATM in Public Networks (see 
http://www.itu.int/newsroom/press/releases/2000/01NP.html)

Study Group 13 has a number of ongoing IP-related standardization 
projects (most in the ro68.html report above) including, inter 
alia: 

* Y.iptc: Traffic control and congestion control in IP networks;
* Y.1231: IP access network architecture;
* Y.1241: IP transfer capability for the support of IP-based services;
* Y.1310.1: IP Virtual Private Networks;
* Y.1310.2: IP-MPLS transfer and control protocols;
* Y.1401: General requirements for interworking with IP-based networks;
* Y.1530: Call processing performance for voice service in hybrid IP 
          networks; 
* Y.1540: IP packet transfer and availability performance parameters;
* Y.1541: IP performance objectives and allocations (relates to QoS 
          classes); 
* Y.17oam: Operations and Maintenance ("OAM") and protection switching 
           for IP-based networks.

ITU-T Study Group 15

Study Group 15 (http://www.itu.int/ITU-T/com15/index.html) is active 
in standardization in the area of transport networks, systems and 
equipment. It is the lead Study Group on Access Network Transport 
("ANT") and co-coordinates with Study Groups 4, 6 and 13 ITU-T 
activities related to the Optical Transport Network ("OTN") and 
Optical Networking technologies. During the last study period (ITU
parlance for 4 years), SG 15 revised eight and prepared one new 
Question (this is sort of an IETF wg charter) reflecting the shift 
in the telecommunications environment towards networks optimized 
for the transport of IP-type traffic.
 
Since then, SG 15 has carried out significant standardization work 
related to high-speed network access over copper wire loops using 
Digital Subscriber Line ("DSL") and optical fiber technologies, 
Synchronous Digital Hierarchy ("SDH") and the OTN. These have 
enabled the deployment and management of optical access networks 
for delivery of broadband services to both residential and 
business customers. 

For example, to facilitate network access over ordinary telephone 
subscriber lines, a set of six DSL-related Recommendations (G.990 
Series) have provided for multi-Megabit/s access to the Internet, 
private IP-based networks and other data network architectures. 
In the area of SDH, new and revised Recommendations have provided 
for high-capacity network protection and restoration, carriage of 
40 Gbps client signals and SDH network management. With regard to 
optical systems, new Recommendations have been prepared for single 
channel optical systems with bit rates up to 40 Gbps and for 
multichannel Dense Wave Division Multiplexing ("DWDM") optical 
systems. Significant progress has also been made on a new Network 
Node Interface ("NNI") specification for the OTN. Further advances 
have been made on completing Recommendations dealing with optical 
submarine cable systems and optical components and sub-systems.

SG 15 is proposing a broad suite of further work related to IP-based 
networks including, inter alia:  

* enhancement of several SG 15 Recommendations (e.g., G.983.1 and 
G.983.2) dealing with broadband optical access systems based on 
Passive Optical Networks ("PON") to better accommodate IP traffic;

* study the need for enhancements of xDSL Recommendations to optimize 
the transport of IP and IP-based services;

* study General Switched Telephone Network/Internet Protocol gateway 
equipment known as "Transport Network Equipment for Interconnecting 
the GSTN to networks optimized for Internet protocol and ATM 
Networks" ("TIGIN");

* work on optical transport of Internet packets ("IP over WDM", 
planned as Y.1330 ).

At its April 2000 meeting, SG 15 determined a new Recommendation 
G.871 on the "Framework for Optical Transport Network Recommendations" 
providing an overview of ITU-T Recommendations on different aspects of 
OTNs, the framework for their development, and a time frame for the 
development of updated or new Recommendations.  

Bob
--
Robert Shaw <robert.shaw@itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
 



From owner-mpls@UU.NET  Thu Jun 15 18:01:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15523
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 18:01:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsy27727;
	Thu, 15 Jun 2000 22:00:07 GMT
Received: by mail-control.mail.uu.net 
	id QQitsx24294
	for mpls-outgoing; Thu, 15 Jun 2000 21:59:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitsx24287
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 21:59:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsx22469
	for <mpls@UU.NET>; Thu, 15 Jun 2000 17:59:01 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQitsx26808
	for <mpls@UU.NET>; Thu, 15 Jun 2000 21:59:01 GMT
Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP;
          Thu, 15 Jun 2000 22:58:29 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWGBKPW>; Thu, 15 Jun 2000 22:58:15 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B160B0@mbddmknt01.hc.bt.com>
To: tli@Procket.com
Cc: mpls@UU.NET
Subject: RE: Information about optical routing in MPLS net.
Date: Thu, 15 Jun 2000 22:58:15 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Tony,

Please re-read my mail of yesterday.  I agree with what you are saying wrt
the routing protocol and signalling protocol of the L1 where we can re-use
existing technologies.....indeed, we would be seeking best-of-breed in this
respect.  But these are only 2 facets of the control plane.  Addressing in
the L1, which is the 3rd major facet of the control plane, cannot be the
same as any of its clients.  This is a 'truth' since the (addressable) trail
entities of the L1 only form link connections (ie a partition of a client
layer trail), and hence only co-locate with a client layer trail mid-point,
in any of the client layers.  Indeed, flexible client layer topology
construction (which is in essence  a part of the TE story - see Note) is a
key purpose of the L1 (besides supplying direct high BW customers).

Client layer trail span - between addressable access points
	<----------------------------------------->
	O--------O-----------------O-----------O
		|		|
		|		|
		0-----0----0-----0
		<------------------>
Server layer trail span - between its addressable access points

Note - TE has 3 time/granularity-scales:
-	physical duct/media build-out - large timescale, large
granularity....this is an operator's planning cycle for *all* its client
layer forcasts
-	L1 flexing of trails to create client layer topologies - medium
timescale, medium granularity....we need this to cater for uncertainty in
traffic vector forecasts in *each* specific client layer
-	within-layer techniques to bypass normal routing protocol, eg using
RSVP/CR_LDP say if we are considering only the MPLS client layer....we need
this for ad hoc traffic re-distribution at smaller timescales (eg during
failures, unexpected near-term congestion and other reasons, eg QoS related
facets).

I cannot honestly believe anyone who understands what is being stated above
wrt the L1 addressing can dispute it......especially any operators.

Regards, Neil

> -----Original Message-----
> From:	Tony Li [SMTP:tli@Procket.com]
> Sent:	Thursday, June 15, 2000 7:29 PM
> To:	darren.freeland@bt.com
> Cc:	clapp@research.telcordia.com; xuyg@lucent.com; mpls@UU.NET
> Subject:	RE: Information about optical routing in MPLS net.
> 
> 
>  | I would support the view that having the router control the optical
> domain
>  | is not good.  This comes down to a simple desire to see an optical
> layer
>  | which is open to ALL clients - not just IP.  Of course it is possible
> to
>  | allow the router to control the optical layer ... however, this idea
>  | overlooks the fact that an operator may wish to carry many other
> clients
>  | across an optical network.
> 
> 
> The optical plane clearly needs a control plane that provides a (lambda)
> routing and signaling infrastructure.  This infrastructure is
> fundamentally
> similar to the routing and signaling technology that we're already using
> for MPLS.  Now, we can choose to re-invent this technology, or we can
> leverage the technology that we have already have developed and have
> started to deploy.
> 
> Note that this argument is completely independent of the nature of the
> optical client.  Nothing here precludes non-IP usage of the optical core.
> It would simply use the IP network as the out-of-band control plane.
> 
> Regards,
> Tony
> 
> 
> 


From owner-mpls@UU.NET  Thu Jun 15 18:13:18 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15821
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 18:13:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsy06210;
	Thu, 15 Jun 2000 22:11:45 GMT
Received: by mail-control.mail.uu.net 
	id QQitsy05072
	for mpls-outgoing; Thu, 15 Jun 2000 22:11:10 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitsy05046
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 22:11:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitsy02895
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:10:47 -0400 (EDT)
Received: from u-mail.rd.francetelecom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: u-mail.rd.francetelecom.com [208.25.178.63])
	id QQitsy04719
	for <mpls@UU.NET>; Thu, 15 Jun 2000 22:10:46 GMT
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
	id <KG0FP5VX>; Thu, 15 Jun 2000 15:08:04 -0700
Message-ID: <337055FBC675D311A85D00508B5A9C4F254307@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
	 <sergio.catanzariti@rd.francetelecom.com>
To: "'Peter Ashwood-Smith'" <petera@nortelnetworks.com>
Cc: "'Tony Li'" <tli@Procket.com>, clapp@research.telcordia.com,
        xuyg@lucent.com, mpls@UU.NET, darren.freeland@bt.com,
        CATANZARITI Sergio FTR&D/TI <sergio.catanzariti@rd.francetelecom.com>
Subject: RE: Information about optical routing in MPLS net.
Date: Thu, 15 Jun 2000 15:08:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFD716.2D02A0A4"
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_01BFD716.2D02A0A4
Content-Type: text/plain

Mine was not an MPLS/IP biased opinion. I was only trying to say that using
IP to carry full-fledged control plane information for a multi-client
optical network is not an assumption validated enough today to be accepted
as a basis for a universal (key adjective) Optical Internetworking control
model and mechanisms. Again, at least in carriers PMOs. This has nothing to
do with the multi-protocol (mainly data plane) support of MPLS. 

Sergio

> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com 
> --------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From:	Peter Ashwood-Smith [SMTP:petera@nortelnetworks.com]
> Sent:	Thursday, June 15, 2000 12:13 PM
> To:	CATANZARITI Sergio FTR&D/TI
> Cc:	'Tony Li'; clapp@research.telcordia.com; xuyg@lucent.com;
> mpls@UU.NET; darren.freeland@bt.com
> Subject:	Re: Information about optical routing in MPLS net.
> 
> >      > It would simply use the IP network as the out-of-band control
> plane.
> > 
> > Fully agree on the advantages. But, this is still an open problem rather
> than an acceptable and stable solution, at
> > least in today carriers operational models.
> > 
> > Sergio
> 
>     What you are seeing is a recognition by many folks that a PATH
> regardless of
> what we call the labels can be controlled by MPLS (if the MPLS protocols
> are 
> suitibly generalized). What actually goes over these paths can be
> anything. After
> all, that is the "MP" part of "MPLS".
> 
>     Constraint based, distributed source routing with an OSPF/IS-IS style 
> topology database are the preferred solution to path oriented routing
> problems
> and have been used for a number of years now in ATM and proprietary
> systems
> so it is only natural to extend them to Optical networks.
> 
>     Cheers,
> 
>     Peter Ashwood-Smith

------_=_NextPart_001_01BFD716.2D02A0A4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Information about optical routing in MPLS net.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Mine was not an MPLS/IP biased =
opinion. I was only trying to say that using IP to carry full-fledged =
control plane information for a multi-client optical network is not an =
assumption validated enough today to be accepted as a basis for a =
universal (key adjective) Optical Internetworking control model and =
mechanisms. Again, at least in carriers PMOs. This has nothing to do =
with the multi-protocol (mainly data plane) support of MPLS. =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sergio</FONT>
</P>
<UL>
<P><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sergio =
Catanzariti</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Senior Project =
Manager, Technology Integration</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">France Telecom =
R&amp;D </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">1000 Marina =
Boulevard Suite 300 </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brisbane CA =
94005</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tel. =
650-875-1526</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Fax. =
650-875-1505</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">email:sergio.catanzariti@rd.francetelecom.com =
</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
</P>
<BR>

<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Peter Ashwood-Smith =
[SMTP:petera@nortelnetworks.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, June 15, 2000 12:13 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">CATANZARITI Sergio FTR&amp;D/TI</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'Tony Li'; clapp@research.telcordia.com; =
xuyg@lucent.com; mpls@UU.NET; darren.freeland@bt.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Information about optical =
routing in MPLS net.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; It would simply use the IP =
network as the out-of-band control plane.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; Fully agree on the =
advantages. But, this is still an open problem rather than an =
acceptable and stable solution, at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; least in today carriers =
operational models.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; Sergio</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp; What you are =
seeing is a recognition by many folks that a PATH regardless of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">what we call the labels can be =
controlled by MPLS (if the MPLS protocols are </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">suitibly generalized). What =
actually goes over these paths can be anything. After</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">all, that is the &quot;MP&quot; =
part of &quot;MPLS&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp; Constraint =
based, distributed source routing with an OSPF/IS-IS style </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">topology database are the =
preferred solution to path oriented routing problems</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">and have been used for a number =
of years now in ATM and proprietary systems</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">so it is only natural to extend =
them to Optical networks.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp; =
Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp; Peter =
Ashwood-Smith</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFD716.2D02A0A4--


From owner-mpls@UU.NET  Thu Jun 15 18:19:54 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15960
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 18:19:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitsz19863;
	Thu, 15 Jun 2000 22:18:20 GMT
Received: by mail-control.mail.uu.net 
	id QQitsz06110
	for mpls-outgoing; Thu, 15 Jun 2000 22:18:06 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitsz06095
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 22:17:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitsz25360
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:17:26 -0400 (EDT)
Received: from bastion4.mail.sprint.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bastion4.mail.sprint.com [208.4.28.132])
	id QQitsz19194
	for <mpls@UU.NET>; Thu, 15 Jun 2000 22:17:25 GMT
Received: from sii01.mail.sprint.com by bastion4.mail.sprint.com with ESMTP for mpls@UU.NET; Thu, 15 Jun 2000 17:17:25 -0500
Received: from [144.223.128.84] by sii01.mail.sprint.com with ESMTP; Thu, 15 Jun 2000 17:17:20 -0500
Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.74.2.74])
	by kcopmh01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id RAA20992;
	Thu, 15 Jun 2000 17:17:19 -0500 (CDT)
From: Mark Jones <Mark.Jones@mail.sprint.com>
Received: from localhost (root@localhost)
	by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id RAA26334;
	Thu, 15 Jun 2000 17:17:19 -0500 (CDT)
X-OpenMail-Hops: 1
Date: Thu, 15 Jun 2000 17:17:18 -0500
Message-Id: <H00017a80992f616.0961107437.kcopmp04@MHS>
Subject: RE: RE: Information about optical routing in MPLS net.
TO: clapp@research.telcordia.com
CC: mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/mixed;
  boundary="openmail-part-22457fd8-00000001"
Sender: owner-mpls@UU.NET
Precedence: bulk

--openmail-part-22457fd8-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Only time will be able to answer these questions.

Here's one perspective from a person who claims some expertise in 
optical networking.  Hopefully, the industry will settle on a common 
control plane to facilitate messaging between layers, but one layer is 
unlikely to have full control of another.  Small homogeneous networks 
may be the exceptions.  There are too many complexities in network 
management of different layers to expect multiple layers to collapse 
under one control plane (though the protocols in each may be the same).

The ODSI and OIF may define just such an interface, but unless carriers 
accept it as a reasonable solution to management of their networks, it 
won't be implemented on a large scale.  The ODSI and OIF have both been 
anxious to show quick results, regardless of whether they met the 
requirements of major customers.  I don't want to be too critical here, 
because the ODSI and OIF output may be exactly what we need in our 
networks, but the lack of rigor in development of their specifications 
concerns me.  The OIF has jumped to solutions from the beginning, 
without creating clear requirements for what network providers needed.  
So, issues like whether carriers wanted an IP router to be able to 
fully control an optical cross connect have been ignored.  (Sprint has 
not participated in the ODSI as far as I know.)

The two camps on this issue, even within Sprint, fall into those who 
love IP and those who only accept it as the primary growth protocol 
today.  The IP lovers want IP routers to have flexibility to fully 
control the optical network.  The other group is concerned by the 
history of router failures, IP's limited and complex traffic 
engineering, and the many other protocols that must be supported on a 
common transport infrastructure.  The decision of whether IP routers 
will have the ability to control an optical network may come down to a 
political decision as much as an economic or technical one. 

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-534-5247
mark.jones@mail.sprint.com


-----Original Message-----
From: clapp [mailto:clapp@research.telcordia.com]
Sent: Thursday, June 15, 2000 2:25 PM
To: tli
Cc: clapp; mpls
Subject: FW: RE: Information about optical routing in MPLS net.


I agree with the notion of optical equipment reusing IP control 
protocols 
to manage the network, but to what extent will routers that are clients 
of 
an optical network manage that network?  The ODSI is defining an 
interface 
(using MPLS signaling protocols) to enable a router to manage an 
optical 
channel, and they say that ATM switches and SONET ADMs can do the same.

Managing a channel isn't the same thing as managing a network, but it's 
a 
beginning.  How far do people think it will go?

George Clapp
voice     973-829-4610
email     clapp@research.telcordia.com

At 11:28 AM 6/15/00 -0700, you wrote:

>  | I would support the view that having the router control the 
optical domain
>  | is not good.  This comes down to a simple desire to see an optical 
layer
>  | which is open to ALL clients - not just IP.  Of course it is 
possible to
>  | allow the router to control the optical layer ... however, this 
idea
>  | overlooks the fact that an operator may wish to carry many other 
clients
>  | across an optical network.
>
>
>The optical plane clearly needs a control plane that provides a 
(lambda)
>routing and signaling infrastructure.  This infrastructure is 
fundamentally
>similar to the routing and signaling technology that we're already 
using
>for MPLS.  Now, we can choose to re-invent this technology, or we can
>leverage the technology that we have already have developed and have
>started to deploy.
>
>Note that this argument is completely independent of the nature of the
>optical client.  Nothing here precludes non-IP usage of the optical 
core.
>It would simply use the IP network as the out-of-band control plane.
>
>Regards,
>Tony


--openmail-part-22457fd8-00000001--



From owner-mpls@UU.NET  Thu Jun 15 18:32:09 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16293
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 18:32:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitta28176;
	Thu, 15 Jun 2000 22:30:36 GMT
Received: by mail-control.mail.uu.net 
	id QQitta07149
	for mpls-outgoing; Thu, 15 Jun 2000 22:30:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitta07138
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 22:30:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitta05759
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:30:02 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49])
	id QQitta19949
	for <mpls@UU.NET>; Thu, 15 Jun 2000 22:30:01 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jun 15 18:29:28 EDT 2000
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA25338;
	Thu, 15 Jun 2000 18:29:52 -0400 (EDT)
Message-ID: <394959A5.1083CD61@dnrc.bell-labs.com>
Date: Thu, 15 Jun 2000 15:33:09 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: mpls@UU.NET
Subject: Re: Information about optical routing in MPLS net.
References: <B9571FDEBD3DD21181E500606DD5EE0507B160B0@mbddmknt01.hc.bt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



neil.2.harrison@bt.com wrote:
	[..]
> Addressing in
> the L1, which is the 3rd major facet of the control plane, cannot be the
> same as any of its clients.

I think that statement claims more than is necessary for clarity in
this discussion. It may be explicitly observed that there's
nothing stopping Layer N from using endpoint addressing that is
syntactically similar to addresses from Layer N+1 (which some might
believe is excluded by the wording above). I could in principle build
a FOO transport network where all the nodes had 32 bit
addresses looking remarkably like IPv4 addresses, and build a regular
IPv4, IPv6, or ATM network on top of it. FOO would simply be a new link
layer as far as my 'regular' network was concerned. FOO could quite
easily also use IP-derived routing protocols to establish and maintain
edge to edge FOO paths (part of its control plane) between clients of
the FOO service (whether or not its data plane looked anything like
'conventional' packet-based IP)

cheers,
gja (who thinks the 6bone is an educational example...)
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Thu Jun 15 18:42:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16567
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 18:42:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitta26424;
	Thu, 15 Jun 2000 22:40:29 GMT
Received: by mail-control.mail.uu.net 
	id QQitta07769
	for mpls-outgoing; Thu, 15 Jun 2000 22:39:58 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitta07764
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 22:39:50 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitta28517
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:39:29 -0400 (EDT)
Received: from bastion1.mail.sprint.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bastion.mail.sprint.com [208.4.28.129])
	id QQitta25552
	for <mpls@UU.NET>; Thu, 15 Jun 2000 22:39:28 GMT
Received: from sii01.mail.sprint.com by bastion1.mail.sprint.com with ESMTP for mpls@UU.NET; Thu, 15 Jun 2000 17:39:28 -0500
Received: from [144.223.128.84] by sii01.mail.sprint.com with ESMTP; Thu, 15 Jun 2000 17:39:26 -0500
Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.74.2.74])
	by kcopmh01.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id RAA02497;
	Thu, 15 Jun 2000 17:39:25 -0500 (CDT)
From: Mark Jones <Mark.Jones@mail.sprint.com>
Received: from localhost (root@localhost)
	by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id RAA09178;
	Thu, 15 Jun 2000 17:39:24 -0500 (CDT)
X-OpenMail-Hops: 1
Date: Thu, 15 Jun 2000 17:39:24 -0500
Message-Id: <H00017a80992f61e.0961108763.kcopmp04@MHS>
Subject: RE: Re: Information about optical routing in MPLS net.
TO: Robert.Shaw@itu.int
CC: mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/mixed;
  boundary="openmail-part-22460dbd-00000001"
Sender: owner-mpls@UU.NET
Precedence: bulk

--openmail-part-22460dbd-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Thanks, Bob.

I'm sure the IP related work at the ITU-T is of most interest to the 
IETF.  I hope information like this will encourage more interworking of 
the IETF and the ITU-T.

However, I was trying to draw attention to the fact that many other 
groups are working on standardizing the optical network, which the IETF 
MPLS WG is expecting to manage.  As your summary shows, that work is 
not a function of the current ITU-T IP work.  IP is considered only as 
one of the many clients of the optical network in the current work.  
The optical network control plane discussions will soon become a big 
topic at T1X1 and the ITU-T, given the introduction of the G.ason work. 
 The IETF input and involvement might result in a common standard on 
the subject of the optical network control plane.

I mentioned the open policies of T1X1, because of the restrictions to 
participation in the ITU-T.  T1X1 has been coordinating U.S. input into 
the ITU-T standards work on optical networking, among other things. 

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-534-5247
mark.jones@mail.sprint.com


-----Original Message-----
From: Robert.Shaw [mailto:Robert.Shaw@itu.int]
Sent: Thursday, June 15, 2000 4:02 PM
To: Robert.Shaw; Jones, Mark L.; mpls
Subject: RE: Re: Information about optical routing in MPLS net.


> Either way, the IETF efforts regarding optical network control should 
> not ignore the standardization of the optical network itself.  
> Regardless of how many drafts and RFCs are generated, most of the 
> optical transport expertise is not in the IETF.  Though it's tempting 

It's a general problem. A lot of IETFers aren't familiar with ITU-T 
IP-related work... :-)

For example, for only the 2 ITU-T Study Groups you mention (13 and 15),
I'll give a brief summary of their current work as it relates to IP 
and a few references (some of which are only available to ITU-T members 
through password access):

ITU-T Study Group 13

Study Group 13 (http://www.itu.int/ITU-T/com13/index.html) is 
the ITU-T lead Study Group on IP. In this role, SG 13 maintains 
the "ITU IP Project Description" describing the status of ITU-T 
IP-related activities and specific study "Questions". The last
version of this from their February/March 2000 meeting is 
available at 
http://www.itu.int/ITU-T/com13/ip/documents/pl-22.doc in Word (.pdf
for the PDF version). SG 13 has also defined a framework 
for the "Y" Series of Recommendations that cover ITU-T IP-related 
standardization activities (see 
http://www.itu.int/ITU-T/com13/ip/y1000.html). The report of 
SG 13's last meeting in February/March 2000 contains considerable 
detail on the scope of ITU-T's IP-related work (see
http://www.itu.int/itudoc/itu-t/com13/reports/report2/r068.html).

At its March 2000 meeting, SG13 approved Recommendation Y.1310: 
Transport of IP over ATM in Public Networks (see 
http://www.itu.int/newsroom/press/releases/2000/01NP.html)

Study Group 13 has a number of ongoing IP-related standardization 
projects (most in the ro68.html report above) including, inter 
alia: 

* Y.iptc: Traffic control and congestion control in IP networks;
* Y.1231: IP access network architecture;
* Y.1241: IP transfer capability for the support of IP-based services;
* Y.1310.1: IP Virtual Private Networks;
* Y.1310.2: IP-MPLS transfer and control protocols;
* Y.1401: General requirements for interworking with IP-based networks;
* Y.1530: Call processing performance for voice service in hybrid IP 
          networks; 
* Y.1540: IP packet transfer and availability performance parameters;
* Y.1541: IP performance objectives and allocations (relates to QoS 
          classes); 
* Y.17oam: Operations and Maintenance ("OAM") and protection switching 
           for IP-based networks.

ITU-T Study Group 15

Study Group 15 (http://www.itu.int/ITU-T/com15/index.html) is active 
in standardization in the area of transport networks, systems and 
equipment. It is the lead Study Group on Access Network Transport 
("ANT") and co-coordinates with Study Groups 4, 6 and 13 ITU-T 
activities related to the Optical Transport Network ("OTN") and 
Optical Networking technologies. During the last study period (ITU
parlance for 4 years), SG 15 revised eight and prepared one new 
Question (this is sort of an IETF wg charter) reflecting the shift 
in the telecommunications environment towards networks optimized 
for the transport of IP-type traffic.
 
Since then, SG 15 has carried out significant standardization work 
related to high-speed network access over copper wire loops using 
Digital Subscriber Line ("DSL") and optical fiber technologies, 
Synchronous Digital Hierarchy ("SDH") and the OTN. These have 
enabled the deployment and management of optical access networks 
for delivery of broadband services to both residential and 
business customers. 

For example, to facilitate network access over ordinary telephone 
subscriber lines, a set of six DSL-related Recommendations (G.990 
Series) have provided for multi-Megabit/s access to the Internet, 
private IP-based networks and other data network architectures. 
In the area of SDH, new and revised Recommendations have provided 
for high-capacity network protection and restoration, carriage of 
40 Gbps client signals and SDH network management. With regard to 
optical systems, new Recommendations have been prepared for single 
channel optical systems with bit rates up to 40 Gbps and for 
multichannel Dense Wave Division Multiplexing ("DWDM") optical 
systems. Significant progress has also been made on a new Network 
Node Interface ("NNI") specification for the OTN. Further advances 
have been made on completing Recommendations dealing with optical 
submarine cable systems and optical components and sub-systems.

SG 15 is proposing a broad suite of further work related to IP-based 
networks including, inter alia:  

* enhancement of several SG 15 Recommendations (e.g., G.983.1 and 
G.983.2) dealing with broadband optical access systems based on 
Passive Optical Networks ("PON") to better accommodate IP traffic;

* study the need for enhancements of xDSL Recommendations to optimize 
the transport of IP and IP-based services;

* study General Switched Telephone Network/Internet Protocol gateway 
equipment known as "Transport Network Equipment for Interconnecting 
the GSTN to networks optimized for Internet protocol and ATM 
Networks" ("TIGIN");

* work on optical transport of Internet packets ("IP over WDM", 
planned as Y.1330 ).

At its April 2000 meeting, SG 15 determined a new Recommendation 
G.871 on the "Framework for Optical Transport Network Recommendations" 
providing an overview of ITU-T Recommendations on different aspects of 
OTNs, the framework for their development, and a time frame for the 
development of updated or new Recommendations.  

Bob
--
Robert Shaw <robert.shaw@itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
 


--openmail-part-22460dbd-00000001--



From owner-mpls@UU.NET  Thu Jun 15 18:52:18 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16811
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 18:52:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQittb02674;
	Thu, 15 Jun 2000 22:50:43 GMT
Received: by mail-control.mail.uu.net 
	id QQittb08703
	for mpls-outgoing; Thu, 15 Jun 2000 22:50:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQittb08695
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 22:50:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQittb08496
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:50:09 -0400 (EDT)
Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQittb09951
	for <mpls@UU.NET>; Thu, 15 Jun 2000 22:50:08 GMT
Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4)
	id SAA09734; Thu, 15 Jun 2000 18:43:59 -0400
Message-ID: <39495C38.D08987EB@tellium.com>
Date: Thu, 15 Jun 2000 18:44:08 -0400
From: Bala Rajagopalan <braja@tellium.com>
Organization: Tellium
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Jones <Mark.Jones@mail.sprint.com>
CC: clapp@research.telcordia.com, mpls@UU.NET
Subject: Re: Information about optical routing in MPLS net.
References: <H00017a80992f616.0961107437.kcopmp04@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello:

The problem is exactly as you describe:   clear requirements
to my knowledge, have not emerged from service providers regarding
services at the IP-optical interface. The OIF and ODSI have
assumed  certain service definitions, based on a common-sense
approach covering functionality that is assumed minimally required.
The UNI functionality being defined are based on
these service definitions. Presently, these service definitions do
not require external IP routers to "control" the optical network.
If these service definitions change, then the type and amount of
information
exchange required at the service interface would also change.
The OIF has initiated a task group of carrier representatives to examine
this issue.

It's clearly necessary to get the carrier input into the standardization
process in this area, wherever it occurs (including IETF). Given that many
new
developments have occured in a short time, the carriers may be more
focussed on managing an optical network internally, rather than worry
about the interface definitions. But life goes on in various forums
regardless!

Regards,

Bala





Mark Jones wrote:

> Only time will be able to answer these questions.
>
> Here's one perspective from a person who claims some expertise in
> optical networking.  Hopefully, the industry will settle on a common
> control plane to facilitate messaging between layers, but one layer is
> unlikely to have full control of another.  Small homogeneous networks
> may be the exceptions.  There are too many complexities in network
> management of different layers to expect multiple layers to collapse
> under one control plane (though the protocols in each may be the same).
>
> The ODSI and OIF may define just such an interface, but unless carriers
> accept it as a reasonable solution to management of their networks, it
> won't be implemented on a large scale.  The ODSI and OIF have both been
> anxious to show quick results, regardless of whether they met the
> requirements of major customers.  I don't want to be too critical here,
> because the ODSI and OIF output may be exactly what we need in our
> networks, but the lack of rigor in development of their specifications
> concerns me.  The OIF has jumped to solutions from the beginning,
> without creating clear requirements for what network providers needed.
> So, issues like whether carriers wanted an IP router to be able to
> fully control an optical cross connect have been ignored.  (Sprint has
> not participated in the ODSI as far as I know.)
>
> The two camps on this issue, even within Sprint, fall into those who
> love IP and those who only accept it as the primary growth protocol
> today.  The IP lovers want IP routers to have flexibility to fully
> control the optical network.  The other group is concerned by the
> history of router failures, IP's limited and complex traffic
> engineering, and the many other protocols that must be supported on a
> common transport infrastructure.  The decision of whether IP routers
> will have the ability to control an optical network may come down to a
> political decision as much as an economic or technical one.
>
> Mark Loyd Jones
> Sprint
> Technology Planning & Integration
> 913-534-5247
> mark.jones@mail.sprint.com
>
> -----Original Message-----
> From: clapp [mailto:clapp@research.telcordia.com]
> Sent: Thursday, June 15, 2000 2:25 PM
> To: tli
> Cc: clapp; mpls
> Subject: FW: RE: Information about optical routing in MPLS net.
>
> I agree with the notion of optical equipment reusing IP control
> protocols
> to manage the network, but to what extent will routers that are clients
> of
> an optical network manage that network?  The ODSI is defining an
> interface
> (using MPLS signaling protocols) to enable a router to manage an
> optical
> channel, and they say that ATM switches and SONET ADMs can do the same.
>
> Managing a channel isn't the same thing as managing a network, but it's
> a
> beginning.  How far do people think it will go?
>
> George Clapp
> voice     973-829-4610
> email     clapp@research.telcordia.com
>
> At 11:28 AM 6/15/00 -0700, you wrote:
>
> >  | I would support the view that having the router control the
> optical domain
> >  | is not good.  This comes down to a simple desire to see an optical
> layer
> >  | which is open to ALL clients - not just IP.  Of course it is
> possible to
> >  | allow the router to control the optical layer ... however, this
> idea
> >  | overlooks the fact that an operator may wish to carry many other
> clients
> >  | across an optical network.
> >
> >
> >The optical plane clearly needs a control plane that provides a
> (lambda)
> >routing and signaling infrastructure.  This infrastructure is
> fundamentally
> >similar to the routing and signaling technology that we're already
> using
> >for MPLS.  Now, we can choose to re-invent this technology, or we can
> >leverage the technology that we have already have developed and have
> >started to deploy.
> >
> >Note that this argument is completely independent of the nature of the
> >optical client.  Nothing here precludes non-IP usage of the optical
> core.
> >It would simply use the IP network as the out-of-band control plane.
> >
> >Regards,
> >Tony

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com




From owner-mpls@UU.NET  Thu Jun 15 18:54:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16876
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 18:54:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQittb04187;
	Thu, 15 Jun 2000 22:52:51 GMT
Received: by mail-control.mail.uu.net 
	id QQittb08955
	for mpls-outgoing; Thu, 15 Jun 2000 22:52:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQittb08945
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 22:52:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQittb08788
	for <mpls@UU.NET>; Thu, 15 Jun 2000 18:52:05 -0400 (EDT)
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQittb11203
	for <mpls@UU.NET>; Thu, 15 Jun 2000 22:52:05 GMT
Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP;
          Thu, 15 Jun 2000 23:51:47 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) 
          id <LVWGBL2S>; Thu, 15 Jun 2000 23:51:34 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0507B160B5@mbddmknt01.hc.bt.com>
To: gja@dnrc.bell-labs.com
Cc: mpls@UU.NET
Subject: RE: Information about optical routing in MPLS net.
Date: Thu, 15 Jun 2000 23:51:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Agreed, I should have been more clear/precise.....the addressing syntax can
be identical in *all* layers (if that is what one would like to see), but
the trails in each layer are not geographically congruent (with the key
point remaining that 'server layer trails create client layer links').

Thanks for pointing out this ambiguity Granville.

Neil

> -----Original Message-----
> From:	Grenville Armitage [SMTP:gja@dnrc.bell-labs.com]
> Sent:	Thursday, June 15, 2000 11:33 PM
> To:	neil.2.harrison@bt.com
> Cc:	mpls@UU.NET
> Subject:	Re: Information about optical routing in MPLS net.
> 
> 
> 
> neil.2.harrison@bt.com wrote:
> 	[..]
> > Addressing in
> > the L1, which is the 3rd major facet of the control plane, cannot be the
> > same as any of its clients.
> 
> I think that statement claims more than is necessary for clarity in
> this discussion. It may be explicitly observed that there's
> nothing stopping Layer N from using endpoint addressing that is
> syntactically similar to addresses from Layer N+1 (which some might
> believe is excluded by the wording above). I could in principle build
> a FOO transport network where all the nodes had 32 bit
> addresses looking remarkably like IPv4 addresses, and build a regular
> IPv4, IPv6, or ATM network on top of it. FOO would simply be a new link
> layer as far as my 'regular' network was concerned. FOO could quite
> easily also use IP-derived routing protocols to establish and maintain
> edge to edge FOO paths (part of its control plane) between clients of
> the FOO service (whether or not its data plane looked anything like
> 'conventional' packet-based IP)
> 
> cheers,
> gja (who thinks the 6bone is an educational example...)
> ________________________________________________________________________
> Grenville Armitage                    http://members.home.net/garmitage/
> Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Thu Jun 15 19:44:40 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17947
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 19:44:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitte03399;
	Thu, 15 Jun 2000 23:43:05 GMT
Received: by mail-control.mail.uu.net 
	id QQitte22887
	for mpls-outgoing; Thu, 15 Jun 2000 23:42:26 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitte22877
	for <mpls@mail-control.mail.uu.net>; Thu, 15 Jun 2000 23:42:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitte15238
	for <mpls@UU.NET>; Thu, 15 Jun 2000 19:42:08 -0400 (EDT)
Received: from mail-blue.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQitte02738
	for <mpls@UU.NET>; Thu, 15 Jun 2000 23:42:08 GMT
Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 9D1694CE11; Thu, 15 Jun 2000 19:42:04 -0400 (EDT)
Received: from pcalchiu (pclopez [135.207.131.94])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id TAA01610;
	Thu, 15 Jun 2000 19:41:01 -0400 (EDT)
Reply-To: <alchiu@research.att.com>
From: "Angela Chiu" <alchiu@research.att.com>
To: "'Mark Jones'" <Mark.Jones@mail.sprint.com>
Cc: <mpls@UU.NET>, <clapp@research.telcordia.com>
Subject: RE: RE: Information about optical routing in MPLS net.
Date: Thu, 15 Jun 2000 19:41:16 -0400
Message-ID: <002f01bfd723$336b7210$5e83cf87@pcalchiu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <H00017a80992f616.0961107437.kcopmp04@MHS>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark,

There may be demands for both models. For example, an established carrier
who provides services to all kinds of clients may choose to have the control
of the optical network within the network while having clients signal
requests only. On the other hand, a relatively new carrier who owns the
transport network that provides only IP service may want a more integrated
control by having IP clients provide limited control to the optical network
besides signaling requests. In order to provide proper controls, certain
information of the optical network (not the full information) may need to be
propagated to the IP clients. So it would be desirable to design a set of
protocols that are extendable to support both models.

Regards,

Angela Chiu

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mark
Jones
Sent: Thursday, June 15, 2000 6:17 PM
To: clapp@research.telcordia.com
Cc: mpls@UU.NET
Subject: RE: RE: Information about optical routing in MPLS net.


Only time will be able to answer these questions.

Here's one perspective from a person who claims some expertise in
optical networking.  Hopefully, the industry will settle on a common
control plane to facilitate messaging between layers, but one layer is
unlikely to have full control of another.  Small homogeneous networks
may be the exceptions.  There are too many complexities in network
management of different layers to expect multiple layers to collapse
under one control plane (though the protocols in each may be the same).

The ODSI and OIF may define just such an interface, but unless carriers
accept it as a reasonable solution to management of their networks, it
won't be implemented on a large scale.  The ODSI and OIF have both been
anxious to show quick results, regardless of whether they met the
requirements of major customers.  I don't want to be too critical here,
because the ODSI and OIF output may be exactly what we need in our
networks, but the lack of rigor in development of their specifications
concerns me.  The OIF has jumped to solutions from the beginning,
without creating clear requirements for what network providers needed.
So, issues like whether carriers wanted an IP router to be able to
fully control an optical cross connect have been ignored.  (Sprint has
not participated in the ODSI as far as I know.)

The two camps on this issue, even within Sprint, fall into those who
love IP and those who only accept it as the primary growth protocol
today.  The IP lovers want IP routers to have flexibility to fully
control the optical network.  The other group is concerned by the
history of router failures, IP's limited and complex traffic
engineering, and the many other protocols that must be supported on a
common transport infrastructure.  The decision of whether IP routers
will have the ability to control an optical network may come down to a
political decision as much as an economic or technical one.

Mark Loyd Jones
Sprint
Technology Planning & Integration
913-534-5247
mark.jones@mail.sprint.com


-----Original Message-----
From: clapp [mailto:clapp@research.telcordia.com]
Sent: Thursday, June 15, 2000 2:25 PM
To: tli
Cc: clapp; mpls
Subject: FW: RE: Information about optical routing in MPLS net.


I agree with the notion of optical equipment reusing IP control
protocols
to manage the network, but to what extent will routers that are clients
of
an optical network manage that network?  The ODSI is defining an
interface
(using MPLS signaling protocols) to enable a router to manage an
optical
channel, and they say that ATM switches and SONET ADMs can do the same.

Managing a channel isn't the same thing as managing a network, but it's
a
beginning.  How far do people think it will go?

George Clapp
voice     973-829-4610
email     clapp@research.telcordia.com

At 11:28 AM 6/15/00 -0700, you wrote:

>  | I would support the view that having the router control the
optical domain
>  | is not good.  This comes down to a simple desire to see an optical
layer
>  | which is open to ALL clients - not just IP.  Of course it is
possible to
>  | allow the router to control the optical layer ... however, this
idea
>  | overlooks the fact that an operator may wish to carry many other
clients
>  | across an optical network.
>
>
>The optical plane clearly needs a control plane that provides a
(lambda)
>routing and signaling infrastructure.  This infrastructure is
fundamentally
>similar to the routing and signaling technology that we're already
using
>for MPLS.  Now, we can choose to re-invent this technology, or we can
>leverage the technology that we have already have developed and have
>started to deploy.
>
>Note that this argument is completely independent of the nature of the
>optical client.  Nothing here precludes non-IP usage of the optical
core.
>It would simply use the IP network as the out-of-band control plane.
>
>Regards,
>Tony




From owner-mpls@UU.NET  Thu Jun 15 21:00:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18971
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 21:00:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQittk17895;
	Fri, 16 Jun 2000 01:00:00 GMT
Received: by mail-control.mail.uu.net 
	id QQittj08988
	for mpls-outgoing; Fri, 16 Jun 2000 00:59:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQittj08979
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 00:59:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQittj25063
	for <mpls@UU.NET>; Thu, 15 Jun 2000 20:59:19 -0400 (EDT)
Received: from ihemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQittj17300
	for <mpls@UU.NET>; Fri, 16 Jun 2000 00:59:18 GMT
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA11161
	for <mpls@UU.NET>; Thu, 15 Jun 2000 20:59:18 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA11147;
	Thu, 15 Jun 2000 20:59:17 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id UAA21572; Thu, 15 Jun 2000 20:59:15 -0400 (EDT)
Message-ID: <39497BE1.598542E3@lucent.com>
Date: Thu, 15 Jun 2000 20:59:13 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: alchiu@research.att.com
CC: "'Mark Jones'" <Mark.Jones@mail.sprint.com>, mpls@UU.NET,
        clapp@research.telcordia.com
Subject: Re: Information about optical routing in MPLS net.
References: <002f01bfd723$336b7210$5e83cf87@pcalchiu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


> On the other hand, a relatively new carrier who owns the
> transport network that provides only IP service may want a more integrated
> control by having IP clients provide limited control to the optical network
> besides signaling requests. In order to provide proper controls, certain
> information of the optical network (not the full information) may need to be
> propagated to the IP clients. So it would be desirable to design a set of
> protocols that are extendable to support both models.
> 

Instead of bothering IP clients directly, it can be an external gateway server
that gathers information and control the optical network for IP clients. By
doing this way, you don't need to modify existing routers.

Yangguang


From owner-mpls@UU.NET  Thu Jun 15 21:09:10 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19129
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 21:09:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQittk23135;
	Fri, 16 Jun 2000 01:08:42 GMT
Received: by mail-control.mail.uu.net 
	id QQittk19441
	for mpls-outgoing; Fri, 16 Jun 2000 01:08:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQittk19313
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 01:08:09 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQittk26358
	for <mpls@UU.NET>; Thu, 15 Jun 2000 21:08:02 -0400 (EDT)
Received: from ihemlsrv.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQittk22630
	for <mpls@UU.NET>; Fri, 16 Jun 2000 01:08:02 GMT
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA15070
	for <mpls@UU.NET>; Thu, 15 Jun 2000 21:08:01 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA15065;
	Thu, 15 Jun 2000 21:08:01 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id VAA22239; Thu, 15 Jun 2000 21:07:59 -0400 (EDT)
Message-ID: <39497DED.F4C91D2@lucent.com>
Date: Thu, 15 Jun 2000 21:07:57 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Grenville Armitage <gja@dnrc.bell-labs.com>
CC: neil.2.harrison@bt.com, mpls@UU.NET
Subject: Re: Information about optical routing in MPLS net.
References: <B9571FDEBD3DD21181E500606DD5EE0507B160B0@mbddmknt01.hc.bt.com> <394959A5.1083CD61@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Besides client/server relation, networks at different layers can also be viewed
as autonomous peers. In this case, having network in different layers using the
same address scheme and sharing same address space could actually benefit and
simplify network interworking. However, this doesn't mean client has to control
the server layer network.

Yangguang

Grenville Armitage wrote:
> 
> neil.2.harrison@bt.com wrote:
>         [..]
> > Addressing in
> > the L1, which is the 3rd major facet of the control plane, cannot be the
> > same as any of its clients.
> 
> I think that statement claims more than is necessary for clarity in
> this discussion. It may be explicitly observed that there's
> nothing stopping Layer N from using endpoint addressing that is
> syntactically similar to addresses from Layer N+1 (which some might
> believe is excluded by the wording above). I could in principle build
> a FOO transport network where all the nodes had 32 bit
> addresses looking remarkably like IPv4 addresses, and build a regular
> IPv4, IPv6, or ATM network on top of it. FOO would simply be a new link
> layer as far as my 'regular' network was concerned. FOO could quite
> easily also use IP-derived routing protocols to establish and maintain
> edge to edge FOO paths (part of its control plane) between clients of
> the FOO service (whether or not its data plane looked anything like
> 'conventional' packet-based IP)
> 
> cheers,
> gja (who thinks the 6bone is an educational example...)
> ________________________________________________________________________
> Grenville Armitage                    http://members.home.net/garmitage/
> Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Thu Jun 15 21:18:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19239
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 21:18:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQittl03245;
	Fri, 16 Jun 2000 01:17:53 GMT
Received: by mail-control.mail.uu.net 
	id QQittl20408
	for mpls-outgoing; Fri, 16 Jun 2000 01:17:21 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQittl20400
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 01:17:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQittl18668
	for <mpls@uu.net>; Thu, 15 Jun 2000 21:17:06 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQittl28151
	for <mpls@uu.net>; Fri, 16 Jun 2000 01:17:05 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA26794
	for mpls@uu.net; Thu, 15 Jun 2000 21:17:05 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQittl20353
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 01:16:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQittl18556
	for <mpls@UU.NET>; Thu, 15 Jun 2000 21:16:20 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQittl02222
	for <mpls@UU.NET>; Fri, 16 Jun 2000 01:16:19 GMT
Received: from dvlachos2-pc (ch2-dhcp135-185.cisco.com [161.44.135.185])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA26713;
	Thu, 15 Jun 2000 21:16:06 -0400 (EDT)
Message-Id: <4.2.0.58.20000615211010.03af0ee0@pilgrim.cisco.com>
X-Sender: dvlachos@pilgrim.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 15 Jun 2000 21:14:57 -0700
To: Yangguang Xu <xuyg@lucent.com>,
        Grenville Armitage <gja@dnrc.bell-labs.com>
From: Dimitri Stratton Vlachos <dvlachos@cisco.com>
Subject: Re: Information about optical routing in MPLS net.
Cc: neil.2.harrison@bt.com, mpls@UU.NET
In-Reply-To: <39497DED.F4C91D2@lucent.com>
References: <B9571FDEBD3DD21181E500606DD5EE0507B160B0@mbddmknt01.hc.bt.com>
 <394959A5.1083CD61@dnrc.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

On a somewhat different note, in optical networks today, how dynamic is the 
control plane.  I.E. if a optical cross-connect is to be configured through 
a series of optical switches what signalling protocols are available today 
and how proprietary are they??

------
"Give me allies to fight against."
	       -Napoleon
---------------------------------------------------------------------
Dimitri Stratton Vlachos                          dvlachos@cisco.com
Cisco Systems                                     Tel 978-244-8349
IOS Layer 3 Services                              Fax 978-244-8126
250 Apollo Drive
Chelmsford, Mass 01824




From owner-mpls@UU.NET  Thu Jun 15 22:05:19 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20811
	for <mpls-archive@lists.ietf.org>; Thu, 15 Jun 2000 22:05:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitto25477;
	Fri, 16 Jun 2000 02:04:51 GMT
Received: by mail-control.mail.uu.net 
	id QQitto03731
	for mpls-outgoing; Fri, 16 Jun 2000 02:04:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitto03619
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 02:04:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitto24071
	for <mpls@uu.net>; Thu, 15 Jun 2000 22:03:53 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQitto29184
	for <mpls@uu.net>; Fri, 16 Jun 2000 02:03:53 GMT
Received: from ra.pluris.com (ra.pluris.com [172.16.55.70])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA27382
	for <mpls@uu.net>; Thu, 15 Jun 2000 19:03:52 -0700 (PDT)
From: Puneet Agarwal <puneet@pluris.com>
Received: (from puneet@localhost)
	by ra.pluris.com (8.8.8+Sun/8.8.8) id TAA09207
	for mpls@uu.net; Thu, 15 Jun 2000 19:03:52 -0700 (PDT)
Date: Thu, 15 Jun 2000 19:03:52 -0700 (PDT)
Message-Id: <200006160203.TAA09207@ra.pluris.com>
To: mpls@UU.NET
Subject: ttl handling
Sender: owner-mpls@UU.NET
Precedence: bulk

   While reading the Uniform Model and Pipe Model section of 
   draft-ietf-mpls-diff-ext-05.txt, it struck me that for these models
   to be consistent for an LSP, one needs to also look at the TTL handling
   on the LSRs (and not just the diff-serv behavior). 

   section 2.4 of draft-ietf-mpls-label-encaps-07.txt seems to cover the
   Uniform model but does not cover the Pipe model.

   My model for TTL handling is described below. This can easily be
   extended for hierarchical operations.

   If these are already covered in an existing document, then I would 
   appreciate if someone can send me a pointer to the document.


   1. Operation of the Uniform Model is illustrated below
      (consistent with draft-ietf-mpls-label-encaps-07.txt):

             ========== LSP =============================>

                 +--Swap--(n-2)-...-swap--(n-i)-----+
                /        (outer header)              \
              (n-1)                                  (n-i)
              /                                         \
   >--(n)--Push...............(x).......................Pop--(n-i-1)->
            (I)           (inner header)                (E or P)

   (n) represents the TTL value in the corresponding header

   (x) represents non-meaningful TLL information


   2a) Operation of the Pipe Model without PHP is illustrated below (proposed):

             ========== LSP =============================>

                 +--Swap--(N-1)-...-swap--(N-i)-----+
                /        (outer header)              \
              (N)                                  (N-i)
              /                                         \
   >--(n)--Push...............(n-1).....................Pop--(n-2)->
            (I)           (inner header)                (E)

   (N) represents the TTL value (may have no relationship to n)
   (n) represents the tunneled TTL value in the encapsulated header

   2b) Operation of the Pipe Model with PHP is illustrated below (proposed):
             ========== LSP =====================================>
                 +--Swap--(N-1)-...-swap--(N-i)--+
                /        (outer header)           \
              (N)                                (N-i)
              /                                      \
   >--(n)--Push...............(n-1)..................Pop--(n-1)-(E)-(n-2)-->
            (I)           (inner header)                (P)

   (N) represents the TTL value (may have no relationship to n)
   (n) represents the tunneled TTL value in the encapsulated header

-Puneet


From owner-mpls@UU.NET  Fri Jun 16 02:47:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06954
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 02:47:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQituh27300;
	Fri, 16 Jun 2000 06:46:24 GMT
Received: by mail-control.mail.uu.net 
	id QQituh06740
	for mpls-outgoing; Fri, 16 Jun 2000 06:46:03 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQituh06700
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 06:45:55 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQituh24939
	for <mpls@uu.net>; Fri, 16 Jun 2000 02:45:41 -0400 (EDT)
Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQituh26796
	for <mpls@uu.net>; Fri, 16 Jun 2000 06:45:38 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000660421@fsnt.future.futusoft.com>;
 Fri, 16 Jun 2000 12:26:24 +0530
Received: from navneethk.future.futsoft.com ([172.16.1.28]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA22806; Fri, 16 Jun 2000 12:15:42 +0530
Received: by localhost with Microsoft MAPI; Fri, 16 Jun 2000 12:15:21 +0530
Message-Id: <01BFD78C.8B170C40.navaneethk@future.futsoft.com>
From: Navaneeth K <navaneethk@future.futsoft.com>
Reply-To: "navaneethk@future.futsoft.com" <navaneethk@future.futsoft.com>
To: "'Lyman Chapin'" <lyman@bbn.com>,
        "J. Noel Chiappa"
	 <jnc@ginger.lcs.mit.edu>
Cc: "mpls@uu.net" <mpls@UU.NET>
Subject: RE: MPLS and IS-IS
Date: Fri, 16 Jun 2000 12:15:20 +0530
Organization: Future Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Hi....
Any of you got any links to the papers mentioned below?
Any pointers in this regard, most welcome..

Regards
Navaneeth.

At 4:08 PM -0400 5/17/00, J. Noel Chiappa wrote:
>PS: Somwhere, covered by many layers of dust, I have at least two such
>documents, one by Radia and one by me, dating from around the period of the
>FSU IETF (whenever that was - probably '84 or so).

Noel,

Probably not '84, as the first IETF meeting took place in January 1986.

Radia's paper was published in IEEE Network (September 1991) - "A 
Comparison between Two Routing Protocols: OSPF and IS-IS."

The definitive comparison of OSPF and IS-IS, of course, is the 1991 
Interop debate between Radia and Milo Medin, which also featured Ross 
Callon and Dave Clark debating the merits, respectively, of 
"integrated" and "ships in the night" routing for the Internet.

Radia and Milo published their debate arguments in the October 1991 
number (5:10) of Ole Jacobsen's ConneXions - "The Great IGP Debate, 
Part I: IS-IS and Integrated Routing" by Radia, and "The Great IGP 
Debate, Part II: The Open Shortest Path First (OSPF) Routing 
Protocol" by Milo. I'm sure these are on the web somewhere.

- Lyman


From owner-mpls@UU.NET  Fri Jun 16 08:11:41 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10275
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 08:11:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitvc26754;
	Fri, 16 Jun 2000 12:10:59 GMT
Received: by mail-control.mail.uu.net 
	id QQitvc27685
	for mpls-outgoing; Fri, 16 Jun 2000 12:10:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitvc27437
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 12:10:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitvc01212
	for <mpls@uu.net>; Fri, 16 Jun 2000 08:09:53 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitvc25893
	for <mpls@uu.net>; Fri, 16 Jun 2000 12:09:52 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA28667
	for mpls@uu.net; Fri, 16 Jun 2000 08:09:51 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitvc26751
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 12:09:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitvc11117
	for <mpls@UU.NET>; Fri, 16 Jun 2000 08:09:15 -0400 (EDT)
Received: from qhars002.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19])
	id QQitvc20810
	for <mpls@UU.NET>; Fri, 16 Jun 2000 12:09:15 GMT
Received: from zhard00d.europe.nortel.com (actually zhard00d) 
          by qhars002.nortel.com; Fri, 16 Jun 2000 13:08:44 +0100
Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) 
          by zhard00d.europe.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id M8P9KC2P; Fri, 16 Jun 2000 13:08:45 +0100
Received: from nortelnetworks.com (LANDERSS [141.251.192.208]) 
          by zvb1c002.corpemea.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id L4PJHYCX; Fri, 16 Jun 2000 14:08:41 +0200
Message-ID: <394A18E2.119AAEC@nortelnetworks.com>
Date: Fri, 16 Jun 2000 14:09:06 +0200
X-Sybari-Space: 00000000 00000000 00000000
From: "Loa Andersson" <loa.andersson@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: curtis@avici.com
CC: "Abes, Andi" <aabes@quarrytech.com>,
        Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE
References: <200006141319.JAA23398@curtis-lt.avici.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis,

when first reading this I thought that it would introduce unnecessary
(maybe unwanted) restrictions to the use of per interface labels. Is 
your idea that when you set up hierarchial LSP the inner labels always
should from a per platform space?

The architecture says:
"In MPLS, there is no notion of having a different label space for 
different levels of the hierarchy; when interpreting a label, the 
level of the label is irrelevant."

If we require that the "outest label" should also be from a per
platform space?

....?

/Loa

Curtis Villamizar wrote:
> 

> 
> I makes sense for the inner labels to be per platform because the
> outer label can be rerouted and end up coming in on another interface.
> If that reroute occurs cleanly (make before break), it should not be
> nessecary to reroute the inner labels.
> 
> Curtis

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: loa.andersson@nortelnetworks.com



From owner-mpls@UU.NET  Fri Jun 16 09:32:16 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11430
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 09:32:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitvi11136;
	Fri, 16 Jun 2000 13:31:43 GMT
Received: by mail-control.mail.uu.net 
	id QQitvi13865
	for mpls-outgoing; Fri, 16 Jun 2000 13:31:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitvi13840
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 13:31:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitvi14106
	for <mpls@uu.net>; Fri, 16 Jun 2000 09:30:35 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitvi10223
	for <mpls@uu.net>; Fri, 16 Jun 2000 13:30:34 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA05878
	for mpls@uu.net; Fri, 16 Jun 2000 09:30:33 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitvi13788
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 13:30:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitvi24110
	for <mpls@UU.NET>; Fri, 16 Jun 2000 09:30:13 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQitvi16665
	for <mpls@UU.NET>; Fri, 16 Jun 2000 13:30:13 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 9A8DE168; Fri, 16 Jun 2000 15:30:12 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (flefauch-isdn-home.cisco.com [10.49.89.146])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA03337;
	Fri, 16 Jun 2000 15:30:03 +0200 (MET DST)
Message-Id: <200006161330.PAA03337@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Fri, 16 Jun 2000 15:28:03 +0200
To: curtis@avici.com
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
Cc: mpls@UU.NET, bsd@cisco.com, flefauch@cisco.com, liwwu@europe.cisco.com,
        pasi.vaananen@nokia.com, ram@nexabit.com ('Ram Krishnan'),
        Shahram_Davari@pmc-sierra.com (Shahram Davari),
        Pierrick.Cheval@alcatel.fr, jh@lohi.eng.telia.fi
In-Reply-To: <200006141535.LAA23728@curtis-lt.avici.com>
References: <Your message of "Wed, 14 Jun 2000 00:34:24 BST."             <B9571FDEBD3DD21181E500606DD5EE0507B16082@mbddmknt01.hc.bt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis,

At 11:35 14/06/2000 -0400, Curtis Villamizar wrote:
>
>> -	DS processing.......which is what draft-ietf-mpls-diff-ext-05.txt
>> discusses.
>> 
>> One final observation......in draft-ietf-mpls-diff-ext-05.txt it says that
>> the choice of the 'uniform' or 'pipe' model is done on a LSR basis.  I have
>> the concern that this may need to be done on a per LSP basis (and not on a
>> per LSR basis).  If true, this will get very messy on interworking and might
>> incur significant configuration problems.
>> 
>> Regards, Neil
>
>The draft does preclude setting uniform or pipe on a per LSP basis.
>This would need to be signalled.  The ingress should be able to
>request one or the other.  The egress can then reject a request for
>the model requested if it cannot support it (if the router is
>configured for the other and does not have per LSP capability or the
>router only supports one model).  The ingress can then decide whether
>to accept the alternate model or not bring up the LSP.
>
>I'm not sure that this flexibility is needed.  
>It may be better if the
>wording in draft-ietf-mpls-diff-ext-05.txt declared the signaling to
>set uniform or pipe on a per LSP basis as out of scope rather than
>precluding it so that a later document can define the signaling if
>there is a need.
>

This is a fine approach. We'll take this as a Last Call comment on draft-ietf-mpls-diff-ext-05.txt.
thanks
Francois

>Curtis
> 




From owner-mpls@UU.NET  Fri Jun 16 10:45:21 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13312
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 10:45:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitvm24697;
	Fri, 16 Jun 2000 14:34:55 GMT
Received: by mail-control.mail.uu.net 
	id QQitvm27336
	for mpls-outgoing; Fri, 16 Jun 2000 14:34:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitvm27324
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 14:34:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitvm27163
	for <mpls@uu.net>; Fri, 16 Jun 2000 10:33:51 -0400 (EDT)
Received: from web5103.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5103.mail.yahoo.com [216.115.106.73])
	id QQitvm23931
	for <mpls@uu.net>; Fri, 16 Jun 2000 14:33:51 GMT
Message-ID: <20000616143350.7334.qmail@web5103.mail.yahoo.com>
Received: from [169.144.16.187] by web5103.mail.yahoo.com; Fri, 16 Jun 2000 07:33:50 PDT
Date: Fri, 16 Jun 2000 07:33:50 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
Subject: Policing an LSP
To: mpls@UU.NET, diffserv@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I was wondering if it was ever necassary to look at
more than one label ( top label ) of a label stack to
do policing of an LSP. 

C.

=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/


From owner-mpls@UU.NET  Fri Jun 16 12:27:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16069
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 12:27:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitvt17141;
	Fri, 16 Jun 2000 16:26:01 GMT
Received: by mail-control.mail.uu.net 
	id QQitvt25291
	for mpls-outgoing; Fri, 16 Jun 2000 16:25:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitvt25256
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 16:25:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitvt00459
	for <mpls@uu.net>; Fri, 16 Jun 2000 12:25:06 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQitvt10855
	for <mpls@uu.net>; Fri, 16 Jun 2000 16:25:06 GMT
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Fri, 16 Jun 2000 11:24:02 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id M0V6RVBN; Fri, 16 Jun 2000 12:24:46 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id LQHBNP1Y; Fri, 16 Jun 2000 12:24:44 -0400
Message-ID: <394A54CD.D5C6E54A@americasm01.nt.com>
Date: Fri, 16 Jun 2000 12:24:45 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Bandwidth reservation per PSC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I have a question with regard to bandwidth availability per PSC and TE
extensions to OSPF/ISIS.

Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2
about constraint based routing being
performed separately for each PSC  where one of the constraints is
availability of bandwidth from the bandwidth
allocated to the relevant PSC.

My question is how TE extensions to OSPF/ISIS support advertizing
bandwidth availability per PSC. The only way I can
think this can be achieved is by assigning different colors/resource
classes to different PSCs thus advertizing bandwidth
availability per PSC simply as bandwidth availability per color/resource
class. Is this correct?.

If it is correct then how serious is the scaling/operational issue at
least within OSPF since N  TE LSAs are needed for  N
PSCs  for every link, implying lots of LSA traffic not to mention
storage within LSDB (which I gather can only store
65536 TE LSAs).

Thanks,

Darek Skalecki
Nortel Networks



From owner-mpls@UU.NET  Fri Jun 16 14:24:47 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19899
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 14:24:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitvx22787;
	Fri, 16 Jun 2000 17:26:30 GMT
Received: by mail-control.mail.uu.net 
	id QQitvx09984
	for mpls-outgoing; Fri, 16 Jun 2000 17:25:59 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQitvx09979
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 17:25:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitvx11772
	for <mpls@uu.net>; Fri, 16 Jun 2000 13:25:30 -0400 (EDT)
Received: from web5103.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5103.mail.yahoo.com [216.115.106.73])
	id QQitvx26602
	for <mpls@uu.net>; Fri, 16 Jun 2000 17:25:29 GMT
Message-ID: <20000616172529.13046.qmail@web5103.mail.yahoo.com>
Received: from [169.144.16.187] by web5103.mail.yahoo.com; Fri, 16 Jun 2000 10:25:29 PDT
Date: Fri, 16 Jun 2000 10:25:29 -0700 (PDT)
From: Chatur sharp <chatur_b@yahoo.com>
Subject: Re: [Diffserv] Policing an LSP
To: Venumadhav Josyula <vjosyula@osf1.gmu.edu>
Cc: mpls@UU.NET, differv@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

[please also read the mail - included in the message]

I specifically want to know about the case where two
labels are going to be popped by a LSR. Does he do 
policing on inner label after forwarding the packet to
itself.

C.

--- Venumadhav Josyula <vjosyula@osf1.gmu.edu> wrote:
> No it is not neccessary to at more than one label to
> do policing
> 
> venu
> 
> On Fri, 16
> Jun 2000, Chatur sharp wrote:
> 
> > Hi,
> > 
> > I was wondering if it was ever necassary to look
> at
> > more than one label ( top label ) of a label stack
> to
> > do policing of an LSP. 
> > 
> > C.
> > 
> > =====
> > I am willing to learn,  if you care to teach.
> > I am willing to teach, if you care to learn.
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Send instant messages with Yahoo! Messenger.
> > http://im.yahoo.com/
> > 
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > 
> > 
> 
> 
> 
> 
> 
> 
> 
> 
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Josyula Venumadhav
> 
> Residnce:
> 4303 Apt#L, Ramona Drive
> Fairfax, Virginia-22030
> 						
> Phone:
> Residence: (703)-359-5419
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> 


=====
I am willing to learn,  if you care to teach.
I am willing to teach, if you care to learn.

__________________________________________________
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/


From owner-mpls@UU.NET  Fri Jun 16 16:21:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23142
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 16:21:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitwj22972;
	Fri, 16 Jun 2000 20:20:37 GMT
Received: by mail-control.mail.uu.net 
	id QQitwj20814
	for mpls-outgoing; Fri, 16 Jun 2000 20:20:00 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitwj20788
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 20:19:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitwj14529
	for <mpls@uu.net>; Fri, 16 Jun 2000 16:18:06 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQitwj16639
	for <mpls@uu.net>; Fri, 16 Jun 2000 20:18:06 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA04037
	for mpls@uu.net; Fri, 16 Jun 2000 16:18:05 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQitwj20715
	for <mpls@mail-control.mail.uu.net>; Fri, 16 Jun 2000 20:17:45 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitwj29636
	for <mpls@UU.NET>; Fri, 16 Jun 2000 16:16:14 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQitwj19662
	for <mpls@UU.NET>; Fri, 16 Jun 2000 20:16:14 GMT
Received: from localhost (yakov@localhost)
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA01806;
	Fri, 16 Jun 2000 13:16:13 -0700 (PDT)
Message-Id: <200006162016.NAA01806@omega.cisco.com>
To: mpls@UU.NET
cc: kireeti@juniper.net
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1804.961186573.1@cisco.com>
Date: Fri, 16 Jun 2000 13:16:13 -0700
From: Yakov Rekhter <yakov@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Folks,

> Given the recent e-mail exchange on the topic of hierarchical
> tunnel establishment in RSVP-TE, and given that most (but probably
> not all) the relevant material is covered under the notion of
> Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
> I wonder whether there would be any objections agains extracting
> all the relevant material, filling the missing pieces (if any),
> and turning the result into a MPLS WG document.

Kireeti and myself just submitted an Internet Draft on this.
If you can't wait until the Draft will appear in the IETF
server, drop me an e-mail and I'll send you a copy.

Yakov.



From owner-mpls@UU.NET  Fri Jun 16 23:41:07 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02994
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 23:41:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitxm24875;
	Sat, 17 Jun 2000 03:39:50 GMT
Received: by mail-control.mail.uu.net 
	id QQitxm04141
	for mpls-outgoing; Sat, 17 Jun 2000 03:39:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitxm04136
	for <mpls@mail-control.mail.uu.net>; Sat, 17 Jun 2000 03:39:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQitxm22065
	for <mpls@UU.NET>; Fri, 16 Jun 2000 23:38:59 -0400 (EDT)
Received: from mail3.ntu.edu.sg by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [155.69.1.91])
	id QQitxm22331
	for <mpls@UU.NET>; Sat, 17 Jun 2000 03:38:58 GMT
Received: by mail3.ntu.edu.sg with Internet Mail Service (5.5.2650.21)
	id <NCL14DY5>; Sat, 17 Jun 2000 10:23:21 +0800
Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDCEA4@exchange4.ntu.edu.sg>
From: Shen Gangxiang <EGXShen@ntu.edu.sg>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Optical Domain Service Interconnect
Date: Fri, 16 Jun 2000 12:19:54 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Could anyone tell me the URL of Optical Domain Service Interconnect (ODSI)?
Thanks!

Gangxiang Shen


From owner-mpls@UU.NET  Fri Jun 16 23:44:49 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03044
	for <mpls-archive@lists.ietf.org>; Fri, 16 Jun 2000 23:44:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitxm25200;
	Sat, 17 Jun 2000 03:43:49 GMT
Received: by mail-control.mail.uu.net 
	id QQitxm04492
	for mpls-outgoing; Sat, 17 Jun 2000 03:43:25 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitxm04487
	for <mpls@mail-control.mail.uu.net>; Sat, 17 Jun 2000 03:43:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitxm10319
	for <mpls@UU.NET>; Fri, 16 Jun 2000 23:43:16 -0400 (EDT)
Received: from tcb.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tcb.net [205.168.100.1])
	id QQitxm26955
	for <mpls@UU.NET>; Sat, 17 Jun 2000 03:43:15 GMT
Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1])
	by tcb.net (8.9.3/8.9.3) with ESMTP id VAA32734;
	Fri, 16 Jun 2000 21:44:21 -0600
Message-Id: <200006170344.VAA32734@tcb.net>
X-Mailer: exmh version 2.0.3
To: Shen Gangxiang <EGXShen@ntu.edu.sg>
cc: "'mpls@UU.NET'" <mpls@UU.NET>
From: Danny McPherson <danny@tcb.net>
Reply-To: danny@tcb.net
Subject: Re: Optical Domain Service Interconnect 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 16 Jun 2000 21:44:21 -0600
Sender: owner-mpls@UU.NET
Precedence: bulk


As to avoid the flurry, I've cc'd the list...

www.odsi-coalition.com

-danny

> Could anyone tell me the URL of Optical Domain Service Interconnect (ODSI)?
> Thanks!




From owner-mpls@UU.NET  Sat Jun 17 01:02:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03813
	for <mpls-archive@lists.ietf.org>; Sat, 17 Jun 2000 01:02:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQitxs05374;
	Sat, 17 Jun 2000 05:01:28 GMT
Received: by mail-control.mail.uu.net 
	id QQitxs23183
	for mpls-outgoing; Sat, 17 Jun 2000 05:00:59 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQitxs22423
	for <mpls@mail-control.mail.uu.net>; Sat, 17 Jun 2000 05:00:45 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitxs01714
	for <mpls@UU.NET>; Sat, 17 Jun 2000 01:00:34 -0400 (EDT)
Received: from csa.iisc.ernet.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: csa.iisc.ernet.in [144.16.67.8])
	id QQitxs08438
	for <mpls@UU.NET>; Sat, 17 Jun 2000 05:00:31 GMT
Received: from emerald.csa.iisc.ernet.in (IDENT:root@emerald.csa.iisc.ernet.in [144.16.67.29])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id KAA10823
	for <mpls@UU.NET>; Sat, 17 Jun 2000 10:31:46 +0530
Received: from localhost (ytr@localhost)
	by emerald.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id KAA18132
	for <mpls@UU.NET>; Sat, 17 Jun 2000 10:35:11 +0530
X-Authentication-Warning: emerald.csa.iisc.ernet.in: ytr owned process doing -bs
Date: Sat, 17 Jun 2000 10:35:10 +0530 (IST)
From: Ramanjaneyulu Y T <ytr@csa.iisc.ernet.in>
To: mpls@UU.NET
Message-ID: <Pine.LNX.4.10.10006171015030.18113-100000@emerald.csa.iisc.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Respected all,

   At present  we are developing voice over IP router with MPLS and RSVP
protocols. I got one doubt in that. 

      At edge routers ( ingress , egress LSR ) many phones attached. When
ever a user wants  talk to other party he /she rings number, SIP will
verify other party is ready to accept call or not . If it ready to accept
RSVP will establish path.  This will same for if multiple party (
which phones are attached to same edge) want to communicate to same
destination edge. 

Once path is establishes when conversation starts , voice pakest starts
coming to ingress LSR . Now probelm is how to map IP addr. to  MPLS lable
on  destination IP because more than one destination RSVP paths
established. 



                                                                                                       
                                          With  Regards
                                        Ramanajaneyulu Y.T. 

 "Everyone hears what you say. Friends listen to what you say. Best
  friends listen to what you don't say."
  
------------------------------------------------------------------------------ 
Y.T.RAMANJANEYULU                        |   My other mail Ids:
E-70,INDIAN INSTITUTE OF SCIENCE         |         ytr@rediffmail.com
BANGALORE - 560012                       |         kingytr@excite.com
PH: 0091 - 080 - 3092622 ( HOSTEL )      |
    0091 - 080 - 3092906 ( LAB )         |
                   visit my home page:www2.csa.iisc.ernet.in/~ytr
--------------------------------------------------------------------------------




From owner-mpls@UU.NET  Sun Jun 18 07:15:13 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06912
	for <mpls-archive@lists.ietf.org>; Sun, 18 Jun 2000 07:15:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuci01797;
	Sun, 18 Jun 2000 11:13:58 GMT
Received: by mail-control.mail.uu.net 
	id QQiuci09964
	for mpls-outgoing; Sun, 18 Jun 2000 11:13:32 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuci09958
	for <mpls@mail-control.mail.uu.net>; Sun, 18 Jun 2000 11:13:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuci19930
	for <mpls@uu.net>; Sun, 18 Jun 2000 07:13:13 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuci01370
	for <mpls@uu.net>; Sun, 18 Jun 2000 11:13:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA05728
	for mpls@uu.net; Sun, 18 Jun 2000 07:13:11 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuci09932
	for <mpls@mail-control.mail.uu.net>; Sun, 18 Jun 2000 11:12:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuci19844
	for <mpls@uu.net>; Sun, 18 Jun 2000 07:12:27 -0400 (EDT)
Received: from malone.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: malone.cisco.com [171.68.225.99])
	id QQiuci13028
	for <mpls@uu.net>; Sun, 18 Jun 2000 11:12:26 GMT
Received: from OZT8000-pc.cisco.com (sj-vpdn-client-206.cisco.com [171.70.193.207]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id EAA00178 for <mpls@uu.net>; Sun, 18 Jun 2000 04:12:24 -0700 (PDT)
Message-Id: <4.1.20000618181107.00d0a7f0@malone.cisco.com>
X-Sender: ayappane@malone.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 18 Jun 2000 18:11:49 +1000
To: mpls@UU.NET
From: D Ayappane <ayappane@cisco.com>
Subject: subscribe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk


subscribe



From owner-mpls@UU.NET  Sun Jun 18 11:32:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08536
	for <mpls-archive@lists.ietf.org>; Sun, 18 Jun 2000 11:32:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuda27683;
	Sun, 18 Jun 2000 15:31:09 GMT
Received: by mail-control.mail.uu.net 
	id QQiuda03446
	for mpls-outgoing; Sun, 18 Jun 2000 15:30:52 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuda03441
	for <mpls@mail-control.mail.uu.net>; Sun, 18 Jun 2000 15:30:50 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuda19314
	for <mpls@uu.net>; Sun, 18 Jun 2000 11:30:47 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuda27357
	for <mpls@uu.net>; Sun, 18 Jun 2000 15:30:44 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA13672
	for mpls@uu.net; Sun, 18 Jun 2000 11:30:44 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuda03428
	for <mpls@mail-control.mail.uu.net>; Sun, 18 Jun 2000 15:30:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuda19213
	for <mpls@UU.NET>; Sun, 18 Jun 2000 11:30:26 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQiuda27168
	for <mpls@UU.NET>; Sun, 18 Jun 2000 15:30:25 GMT
Received: from cisco.com (rraszuk-dsl1.cisco.com [10.19.31.90])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA07702;
	Sun, 18 Jun 2000 08:30:24 -0700 (PDT)
Message-ID: <394CEB29.AFFD9604@cisco.com>
Date: Sun, 18 Jun 2000 08:30:49 -0700
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: D Ayappane <ayappane@cisco.com>
CC: mpls@UU.NET
Subject: Re: subscribe
References: <4.1.20000618181107.00d0a7f0@malone.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


> D Ayappane wrote:
> 
> subscribe

No

R.



From owner-mpls@UU.NET  Sun Jun 18 15:24:54 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09614
	for <mpls-archive@lists.ietf.org>; Sun, 18 Jun 2000 15:24:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiudp00574;
	Sun, 18 Jun 2000 19:24:17 GMT
Received: by mail-control.mail.uu.net 
	id QQiudp24762
	for mpls-outgoing; Sun, 18 Jun 2000 19:23:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiudp24749
	for <mpls@mail-control.mail.uu.net>; Sun, 18 Jun 2000 19:23:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiudp15844
	for <mpls@UU.NET>; Sun, 18 Jun 2000 15:23:37 -0400 (EDT)
Received: from csa.iisc.ernet.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: csa.iisc.ernet.in [144.16.67.8])
	id QQiudp00128
	for <mpls@UU.NET>; Sun, 18 Jun 2000 19:23:34 GMT
Received: from turing.csa.iisc.ernet.in (IDENT:ytr@turing.csa.iisc.ernet.in [144.16.67.4])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id AAA04169
	for <mpls@UU.NET>; Mon, 19 Jun 2000 00:54:48 +0530
Received: from localhost (ytr@localhost)
	by turing.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id AAA17376
	for <mpls@UU.NET>; Mon, 19 Jun 2000 00:53:30 +0530
X-Authentication-Warning: turing.csa.iisc.ernet.in: ytr owned process doing -bs
Date: Mon, 19 Jun 2000 00:53:29 +0530 (IST)
From: Ramanjaneyulu Y T <ytr@csa.iisc.ernet.in>
To: mpls@UU.NET
Subject: header 
Message-ID: <Pine.LNX.4.10.10006190049530.17366-100000@turing.csa.iisc.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

IP over MPLS

some packets may be normal IP packets(having only IP header), whereas some
may be MPLS packets(having MPLS header followed by IP header).

how does one distinguish whether it is an IP packet, or an MPLS packet.

                                                                                                       
                                          With  Regards
                                        Ramanajaneyulu Y.T. 




From owner-mpls@UU.NET  Sun Jun 18 19:10:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11003
	for <mpls-archive@lists.ietf.org>; Sun, 18 Jun 2000 19:10:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuee10916;
	Sun, 18 Jun 2000 23:10:05 GMT
Received: by mail-control.mail.uu.net 
	id QQiuee15506
	for mpls-outgoing; Sun, 18 Jun 2000 23:09:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuee15501
	for <mpls@mail-control.mail.uu.net>; Sun, 18 Jun 2000 23:09:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuee08262
	for <mpls@UU.NET>; Sun, 18 Jun 2000 19:09:06 -0400 (EDT)
Received: from mail01.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail01.gmu.edu [129.174.0.6])
	id QQiuee29118
	for <mpls@UU.NET>; Sun, 18 Jun 2000 23:09:06 GMT
Received: from thinkpad ([129.174.13.170]) by mail01.gmu.edu
          (Netscape Messaging Server 4.1) with ESMTP id FWDHN500.O2D; Sun,
          18 Jun 2000 19:09:05 -0400 
Message-ID: <002101bfd979$615e3f60$aa0dae81@gmu.edu>
From: "Lichung Chang" <lchang4@gmu.edu>
To: "Ramanjaneyulu Y T" <ytr@csa.iisc.ernet.in>
Cc: <mpls@UU.NET>
References: <Pine.LNX.4.10.10006190049530.17366-100000@turing.csa.iisc.ernet.in>
Subject: Re: header 
Date: Sun, 18 Jun 2000 19:03:12 -0400
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 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ramanjaneyulu,

    Please see Jim's answer at
http://cell.onecall.net/mhonarc/mpls/current/msg00038.html and read the
messages by thread "Ingress LER in LDP".  It will help.


Lichung

----- Original Message -----
From: Ramanjaneyulu Y T <ytr@csa.iisc.ernet.in>
To: <mpls@UU.NET>
Sent: Sunday, June 18, 2000 3:23 PM
Subject: header


> IP over MPLS
>
> some packets may be normal IP packets(having only IP header), whereas some
> may be MPLS packets(having MPLS header followed by IP header).
>
> how does one distinguish whether it is an IP packet, or an MPLS packet.
>
>
>                                           With  Regards
>                                         Ramanajaneyulu Y.T.
>
>
>



From owner-mpls@UU.NET  Mon Jun 19 04:33:30 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27767
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 04:33:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiufq00049;
	Mon, 19 Jun 2000 08:32:14 GMT
Received: by mail-control.mail.uu.net 
	id QQiufq13737
	for mpls-outgoing; Mon, 19 Jun 2000 08:31:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiufq13732
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 08:31:48 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiufq10452
	for <mpls@uu.net>; Mon, 19 Jun 2000 04:31:41 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiufq12521
	for <mpls@uu.net>; Mon, 19 Jun 2000 08:31:40 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA20931
	for mpls@uu.net; Mon, 19 Jun 2000 04:31:39 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiufq13670
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 08:31:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiufq10358
	for <mpls@UU.NET>; Mon, 19 Jun 2000 04:30:57 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQiufq29278
	for <mpls@UU.NET>; Mon, 19 Jun 2000 08:30:57 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id DB2EF16E; Mon, 19 Jun 2000 10:30:55 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp12.cisco.com [144.254.60.34])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id KAA11897;
	Mon, 19 Jun 2000 10:30:53 +0200 (MET DST)
Message-Id: <200006190830.KAA11897@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Mon, 19 Jun 2000 10:28:48 +0200
To: Bob Thomas <rhthomas@cisco.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: LDP Status Codes in <draft-ietf-diff-ext-05.txt>
Cc: "Loa Andersson" <loa.andersson@nortelnetworks.com>,
        Michelle Burns <Michelle.Burns@etx.ericsson.se>, flefauch@cisco.com,
        mpls@UU.NET
In-Reply-To: <200006161414.KAA15608@rhthomas-sun2.cisco.com>
References: <Your message of "Fri, 16 Jun 2000 15:13:59 +0200."             <394A2817.C9138902@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Bob and all,

Agreed: we will change the Status Code values specified in
<draft-ietf-diff-ext-05.txt>.

Looking at ldp-07, I noticed that 0x00000018 and 0x00000019 are now also
already used by LDP.

So, we will modify <draft-ietf-diff-ext-05.txt>, to the following:

Status Code                   E   Status Data   

     Unsupported PHB                0   0x0000001A
     Invalid EXP<-->PHB mapping     0   0x0000001B
     Unsupported PSC                0   0x0000001C
     Unexpected Diff-Serv TLV 0   0x0000001D

thanks

Francois

At 10:14 16/06/2000 -0400, Bob Thomas wrote:
>> All,
>> 
>> what do we want to do about this? 
>
>I think the codes in t the diff-ext draft need to be changed.
>
>For what it is worth, Section 4.4 of the ldp-07 addresses this
>issue (assignment of Status Codes).
>
>Bob
>
>
>> /Loa
>> 
>> Michelle Burns wrote:
>> > 
>> > Loa & Francois,
>> > 
>> > Two of the new status codes introduced by
>> > draft-ietf-mpls-ldp-07 are already used in
>> > draft-ietf-mpls-diff-ext-05.
>> > 
>> > STATUS CODE                   E   STATUS DATA
>> > draft-ietf-mpls-ldp-07:
>> > Missing Message Parameters    0   0x00000016
>> > Unsupported Address Family    0   0x00000017
>> > 
>> > draft-ietf-mpls-diff-ext-05:
>> > Unsupported PHB               0   0x00000016
>> > Invalid EXP<-->PHB mapping    0   0x00000017
>> > 
>> > It is probably easiest to change the status codes
>> > in the Diff Serv draft since the LDP last call
>> > has closed.
>> > 
>> > / Michelle
>> 
>> -- 
>  




From owner-mpls@UU.NET  Mon Jun 19 05:37:35 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28226
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 05:37:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiufu04519;
	Mon, 19 Jun 2000 09:36:12 GMT
Received: by mail-control.mail.uu.net 
	id QQiufu26688
	for mpls-outgoing; Mon, 19 Jun 2000 09:35:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiufu26683
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 09:35:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiufu12501
	for <mpls@uu.net>; Mon, 19 Jun 2000 05:35:25 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiufu14817
	for <mpls@uu.net>; Mon, 19 Jun 2000 09:35:24 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA23290
	for mpls@uu.net; Mon, 19 Jun 2000 05:35:24 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiufu26659
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 09:34:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiufu12467
	for <mpls@UU.NET>; Mon, 19 Jun 2000 05:34:49 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQiufu03690
	for <mpls@UU.NET>; Mon, 19 Jun 2000 09:34:48 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 35343246; Mon, 19 Jun 2000 11:34:48 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp12.cisco.com [144.254.60.34])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA03886;
	Mon, 19 Jun 2000 11:34:47 +0200 (MET DST)
Message-Id: <4.0.2.20000619104309.02157370@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Mon, 19 Jun 2000 11:31:03 +0200
To: "Darek Skalecki" <dareks@nortelnetworks.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: Bandwidth reservation per PSC
Cc: mpls@UU.NET, alchiu@att.com
In-Reply-To: <394A54CD.D5C6E54A@americasm01.nt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Darek,

At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
>Hi,
>
>I have a question with regard to bandwidth availability per PSC and TE
>extensions to OSPF/ISIS.
>
>Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2
>about constraint based routing being
>performed separately for each PSC  where one of the constraints is
>availability of bandwidth from the bandwidth
>allocated to the relevant PSC.
>
>My question is how TE extensions to OSPF/ISIS support advertizing
>bandwidth availability per PSC. The only way I can
>think this can be achieved is by assigning different colors/resource
>classes to different PSCs thus advertizing bandwidth
>availability per PSC simply as bandwidth availability per color/resource
>class. Is this correct?.
>
>If it is correct then how serious is the scaling/operational issue at
>least within OSPF since N  TE LSAs are needed for  N
>PSCs  for every link, implying lots of LSA traffic not to mention
>storage within LSDB (which I gather can only store
>65536 TE LSAs).
>

First, of course , in some environments, Constraint Based Routing may be performed "off-line"/"in a Centralised Manner". In these situations, per-PSC bandwidth availability can be determined by the centralised tool without relying on extensions to OSPF/ISIS.

Where Constraint Based Routing is performed "on-line"/"in a Distributed Manner", then yes, OSPF/ISIS are required to propagate all necessary bandwidth information. This could be achieved in a number of ways:
	- one approach would be to advertise bandwidth information for every PSC. As you are pointing out above, this may lead to scaling/operational issues earlier than desired.  
	- another approach would be to advertise bandwidth information only for each "family/class" of PSCs. A family/class of PSC would comprise all the PSCs which share the same bandwidth constraints. It is likely that multiple PSCs can share the same bandwidth constraints (eg "max-reservable-bandwidth"). For instance, multiple Premium/Non-real-time PSCs may share the same "max-reservable-bandwidth". In that case, you have traded a little bit of fine-grain control (you can't enforce bandwidth constraints which are different for absolutely every PSC), but you have significantly gained in scalability of OSPF/ISIS by "only" advertising 2/3 available bandwidth information. 

You will find some text on the second approach in section "6.7 Traffic Engineering in Diffserv Environments" of <draft-ietf-tewg-framework-01.txt>:

   "Instead of having per-class parameters being configured and
   propagated on each LSR interface, per-class parameters can be
   aggregated into per-class-type parameters. The main motivation for
   grouping a set of classes into a class-type is to improve the
   scalability of IGP link state advertisements by propagating
   information on a per-class-type basis instead of on a per-class
   basis, and also to allow better bandwidth sharing between  classes in
   the same class-type..."

Francois


>Thanks,
>
>Darek Skalecki
>Nortel Networks
> 

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Mon Jun 19 07:03:17 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29085
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 07:03:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuga20284;
	Mon, 19 Jun 2000 11:01:19 GMT
Received: by mail-control.mail.uu.net 
	id QQiuga13020
	for mpls-outgoing; Mon, 19 Jun 2000 11:00:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuga12663
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 11:00:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuga20995
	for <mpls@uu.net>; Mon, 19 Jun 2000 07:00:22 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuga19553
	for <mpls@uu.net>; Mon, 19 Jun 2000 11:00:21 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA26306
	for mpls@uu.net; Mon, 19 Jun 2000 07:00:20 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuga11288
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 11:00:05 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiufz20870
	for <mpls@uu.net>; Mon, 19 Jun 2000 06:59:54 -0400 (EDT)
Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQiufz00074
	for <mpls@uu.net>; Mon, 19 Jun 2000 10:59:53 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28943;
	Mon, 19 Jun 2000 06:59:53 -0400 (EDT)
Message-Id: <200006191059.GAA28943@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-atm-04.txt
Date: Mon, 19 Jun 2000 06:59:53 -0400
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		: MPLS using LDP and ATM VC Switching
	Author(s)	: B. Davie,  J. Lawrence,  K. McCloghrie, 
                          Y. Rekhter, E. Rosen, G. Swallow,  P. Doolan
	Filename	: draft-ietf-mpls-atm-04.txt
	Pages		: 21
	Date		: 16-Jun-00
	
The MPLS Architecture [1] discusses a way in which ATM switches may
be used as Label Switching Routers.  The ATM switches run network
layer routing algorithms (such as OSPF, IS-IS, etc.), and their data
forwarding is based on the results of these routing algorithms. No
ATM-specific routing or addressing is needed.  ATM switches used in
this way are known as ATM-LSRs.

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

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-atm-04.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-atm-04.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:	<20000616134453.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-atm-04.txt

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

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

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Mon Jun 19 09:02:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03641
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 09:02:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugi09817;
	Mon, 19 Jun 2000 13:00:52 GMT
Received: by mail-control.mail.uu.net 
	id QQiugi09765
	for mpls-outgoing; Mon, 19 Jun 2000 13:00:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiugi09675
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 13:00:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiugi05702
	for <mpls@uu.net>; Mon, 19 Jun 2000 09:00:08 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiugi09133
	for <mpls@uu.net>; Mon, 19 Jun 2000 13:00:06 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA03794
	for mpls@uu.net; Mon, 19 Jun 2000 09:00:05 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiugh08258
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 12:59:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiugh11339
	for <mpls@uu.net>; Mon, 19 Jun 2000 08:59:35 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiugh08647
	for <mpls@uu.net>; Mon, 19 Jun 2000 12:59:34 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA22897; Mon, 19 Jun 2000 08:59:25 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA04401;
	Mon, 19 Jun 2000 08:59:10 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000619085706.07854f00@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 19 Jun 2000 08:57:53 -0400
To: mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: MPLS TE MIB - Doubts
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_84191286==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_84191286==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi,

         Replies embedded in black text below.



At 09:22 PM 5/18/00 +0100, Adrian Farrel wrote:
>Thanks Cheenu, Arun and Tom.
>Good stuff.  Some responses (which appear to be in green for those 
>following the thread in html)
>
>Adrian,
>
>Please see our comments to the questions you sent some time back about
>the TE MIB. (Your questions are in black.) - blue?
>
>3. LSPId explicit hop type
>    Is there any reason to prevent configuration of an explicit hop
>    of type LSPId?  I suggested some ASN.1 for this in an email to
>    Tom on 7th Jan.
>
>         If ldp is chosen to route the tunnel then we'll add this as
>         a choice for the hop type.
>
>I'm not quite sure what your answer means.  I think you're saying you'll 
>add the hop type but only allow it if the signaling protocol is flagged as 
>[CR-]LDP.  This would be great.

         If any of the signaling protocols can handle such an option,
then we will extend the MIB to handle this. At present, none of
the MPLS signaling protocols officially support this.


>6. MPLS Tunnel Resource Table
>    This table is a welcome addition.
>    I believe you need to be very careful because of the differences
>    between forward and reverse resource reservation.  For example,
>    for an RSVP tunnel, what is configured here must be the TSpec.
>    Clearly, sharing TSpecs is useful from a configuration point of
>    view, but says nothing about sharing of resources which is
>    determined elsewhere in the network.  Is it your intention that
>    this table is updated on the reverse path?
>
>         - tunnels are unidirectional; so the issue of bidirectional
>                 resource reservation does not arise
>It wasn't my intention to talk about bi-directional LSPs at this point 
>(although that is an interesting topic of conversation in this 
>regard).  When I talk about forward and reverse reservation I am simply 
>distinguishing between CR-LDP where the resources are reserved as the 
>Label_Request traverses the network, and RSVP where the resources are 
>(strictly speaking) only reserved when the Resv travels back.  Thus the 
>information in the MIB row is far more likely to reflect the true 
>reservation in CR-LDP than in RSVP unless the table is updated by the 
>protocol code on completion of LSP setup to reflect the flowspec.

         The ARHopTable is captures the actual reservation, and is
applicable to both signaling protocols.

>15. mplsTunnelXCIndex
>    It would be good to expand on the Description.  Explain that this
>    object is only writeable in conjunction with pre-existing entries
>    in the LSR MIB.  Say that in normal signaled operation this object
>    will be set by the LSR.  Explain the meaning of zero.
>
>         We'll see how to improve the description.
>How about...
>        "This variable represents an index into the
>         mplsXCTable. This table identifies the segments
>         that compose this tunnel, their characteristics,
>         and relationships to each other.
>         In the case where a signaling protocol is used
>         to set up the tunnel, this field is set by the
>         MPLS code to reflect the row in the mplsXCTable
>         that has been set up to describe the cross-
>         connect for this LSP and SHOULD NOT be changed.
>         In the case where the tunnel has been statically
>         configured by writing to the tables in the LSR
>         MIB, this field MUST be set to indicate the
>         correct entry in the mplsXCTable."

         We would prefer the following:

        "This variable represents an index into the
         mplsXCTable. This table identifies the segments
         that compose this tunnel, their characteristics,
         and relationships to each other.
         In the case where a signaling protocol is used
         to set up the tunnel, this field is to reflect
         the row in the mplsXCTable
         that has been set up to describe the cross-
         connect for this LSP and SHOULD NOT be changed.
         In the case where the tunnel has been statically
         configured by writing to the tables in the LSR
         MIB, this field MUST be set to indicate the
         correct entry in the mplsXCTable."



>mplsTunnelResourceInMaxRate etc.
>MplsBitRate is defined in the LSR MIB in 1,000 bits per second.
>The descriptions for these fields need updating.  Additionally,
>the UNITS tag is ood.
>
>         What do you mean by this sentence ("ood")?
>Sorry.  ood = out of date.
>In other words, all of the UNITS definitions say "bits per second" and 
>should say "1,000s of bits per second".

         We will fix this in the next draft.

         --Tom

--=====================_84191286==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Replies
embedded in black text below.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<br>
At 09:22 PM 5/18/00 +0100, Adrian Farrel wrote:<br>
<blockquote type=cite cite><font size=2 color="#008000">Thanks Cheenu,
Arun and Tom.</font><br>
<font size=2 color="#008000">Good stuff.&nbsp; Some responses (which
appear to be in green for those following the thread in 
html)</font><br>
<font color="#0000FF"><br>
</font><font size=2 color="#FF0000">Adrian,</font><font size=2 color="#0000FF">
<br>
</font><font color="#0000FF"><br>
</font><font size=2 color="#FF0000">Please see our comments to the
questions you sent some time back
about</font><font size=2 color="#0000FF"> <br>
</font><font size=2 color="#FF0000">the TE MIB. (Your questions are
in</font><font size=2 color="#0000FF">
</font><font size=2>black</font><font size=2 color="#FF0000">.)</font><font size=2 color="#0000FF">
</font><font size=2 color="#FF0000">-
</font><font size=2 color="#008000">blue?<br>
</font><font color="#0000FF"><br>
</font><font size=2 color="#0000FF">3. LSPId explicit hop type <br>
&nbsp;&nbsp; Is there any reason to prevent configuration of an explicit
hop <br>
&nbsp;&nbsp; of type LSPId?&nbsp; I suggested some ASN.1 for this in an
email to <br>
&nbsp;&nbsp; Tom on 7th Jan. <br>
</font><font color="#0000FF"><br>
</font><font size=2 color="#0000FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><font size=2 color="#FF0000">If ldp is chosen to route the tunnel
then we'll add this as</font><font size=2 color="#0000FF"> <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><font size=2 color="#FF0000">a choice for the hop
type.</font><font size=2 color="#0000FF"> <br>
</font><font color="#0000FF"><br>
</font><font size=2 color="#008000">I'm not quite sure what your answer
means.&nbsp; I think you're saying you'll add the hop type but only allow
it if the signaling protocol is flagged as [CR-]LDP.&nbsp; This would be
great.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>If any of
the signaling protocols can handle such an option,<br>
then we will extend the MIB to handle this. At present, none of<br>
the MPLS signaling protocols officially support this.<br>
<br>
<br>
<blockquote type=cite cite><font size=2 color="#0000FF">6. MPLS Tunnel
Resource Table <br>
&nbsp;&nbsp; This table is a welcome addition. <br>
&nbsp;&nbsp; I believe you need to be very careful because of the
differences <br>
&nbsp;&nbsp; between forward and reverse resource reservation.&nbsp; For
example, <br>
&nbsp;&nbsp; for an RSVP tunnel, what is configured here must be the
TSpec.&nbsp; <br>
&nbsp;&nbsp; Clearly, sharing TSpecs is useful from a configuration point
of <br>
&nbsp;&nbsp; view, but says nothing about sharing of resources which is
<br>
&nbsp;&nbsp; determined elsewhere in the network.&nbsp; Is it your
intention that <br>
&nbsp;&nbsp; this table is updated on the reverse path? <br>
</font><font color="#0000FF"><br>
</font><font size=2 color="#0000FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><font size=2 color="#FF0000">- tunnels are unidirectional; so the
issue of bidirectional&nbsp;&nbsp;&nbsp;&nbsp;
</font><font size=2 color="#0000FF"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><font size=2 color="#FF0000">resource reservation does not
arise</font><font size=2 color="#0000FF"> <br>
</font><font size=2 color="#008000">It wasn't my intention to talk about
bi-directional LSPs at this point (although that is an interesting topic
of conversation in this regard).&nbsp; When I talk about forward and
reverse reservation I am simply distinguishing between CR-LDP where the
resources are reserved as the Label_Request traverses the network, and
RSVP where the resources are (strictly speaking) only reserved when the
Resv travels back.&nbsp; Thus the information in the MIB row is far more
likely to reflect the true reservation in CR-LDP than in RSVP unless the
table is updated by the protocol code on completion of LSP setup to
reflect the
flowspec</font><font size=2 color="#0000FF">.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
ARHopTable is captures the actual reservation, and is<br>
applicable to both signaling protocols.<br>
<br>
<blockquote type=cite cite><font size=2 color="#0000FF">15.
mplsTunnelXCIndex <br>
&nbsp;&nbsp; It would be good to expand on the Description.&nbsp; Explain
that this <br>
&nbsp;&nbsp; object is only writeable in conjunction with pre-existing
entries <br>
&nbsp;&nbsp; in the LSR MIB.&nbsp; Say that in normal signaled operation
this object <br>
&nbsp;&nbsp; will be set by the LSR.&nbsp; Explain the meaning of zero.
<br>
</font><font color="#0000FF"><br>
</font><font size=2 color="#0000FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><font size=2 color="#FF0000">We'll see how to improve the
description.</font><font size=2 color="#0000FF"> <br>
</font><font size=2 color="#008000">How about...<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This variable represents an
index into the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mplsXCTable. This table
identifies the segments<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that compose this tunnel,
their characteristics,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and relationships to each
other. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the case where a signaling
protocol is used</font><font size=2 color="#0000FF"><br>
</font><font size=2 color="#008000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to set up the tunnel, this field is set by the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPLS code to reflect the row
in the mplsXCTable<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that has been set up to
describe the cross-<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connect for this LSP and
SHOULD NOT be changed.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the case where the tunnel
has been statically<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configured by writing to the
tables in the LSR <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIB, this field MUST be set to
indicate the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; correct entry in the
mplsXCTable.&quot;</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>We would
prefer the following:<br>
<br>
<font size=2 color="#008000">&nbsp;</font><font size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;This variable represents an index into the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mplsXCTable. This table
identifies the segments<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that compose this tunnel,
their characteristics,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and relationships to each
other. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the case where a signaling
protocol is used<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to set up the tunnel, this
field is to reflect <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the row in the
mplsXCTable<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that has been set up to
describe the cross-<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connect for this LSP and
SHOULD NOT be changed.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the case where the tunnel
has been statically<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configured by writing to the
tables in the LSR <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIB, this field MUST be set to
indicate the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; correct entry in the
mplsXCTable.&quot;<br>
<br>
<br>
<br>
</font><blockquote type=cite cite><font size=2 color="#0000FF">mplsTunnelResourceInMaxRate
etc. <br>
MplsBitRate is defined in the LSR MIB in 1,000 bits per second. <br>
The descriptions for these fields need updating.&nbsp; Additionally,
<br>
the UNITS tag is ood. <br>
</font><font color="#0000FF"><br>
</font><font size=2 color="#0000FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
What do you mean by this sentence (&quot;ood&quot;)? <br>
Sorry.&nbsp; ood = out of date.<br>
In other words, all of the UNITS definitions say &quot;bits per
second&quot; and should say &quot;1,000s of bits per
second&quot;.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>We will
fix this in the next draft.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
</html>

--=====================_84191286==_.ALT--




From owner-mpls@UU.NET  Mon Jun 19 09:06:03 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03736
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 09:06:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugi28571;
	Mon, 19 Jun 2000 13:00:17 GMT
Received: by mail-control.mail.uu.net 
	id QQiugh08254
	for mpls-outgoing; Mon, 19 Jun 2000 12:59:42 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiugh08248
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 12:59:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiugh11325
	for <mpls@uu.net>; Mon, 19 Jun 2000 08:59:27 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiugh27838
	for <mpls@uu.net>; Mon, 19 Jun 2000 12:59:26 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA03707
	for mpls@uu.net; Mon, 19 Jun 2000 08:59:25 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiugh08230
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 12:58:56 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiugh05314
	for <mpls@uu.net>; Mon, 19 Jun 2000 08:58:42 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiugh27421
	for <mpls@uu.net>; Mon, 19 Jun 2000 12:58:41 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA22828; Mon, 19 Jun 2000 08:58:33 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA04400;
	Mon, 19 Jun 2000 08:58:16 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000619085626.045ecf00@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 19 Jun 2000 08:56:59 -0400
To: mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: MPLS TE MIB - Doubts
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_84137121==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_84137121==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi,

         Our responses are in blue.

>1) Local Cookie, Remote Cookie. - How do I get this value, Do I get this value
>by concatenating
>    a) Extended Tunnel Id and Tunnel ID field values in case of RSVP path 
> messages?
>    b) Ingress LSR Router ID and Local CRLS- Id in case of CRLDP Lbl Req 
> messages?

         By consensus of the WG mailing list, these objects are being removed
in the next version of the draft.

>2) What is the significant difference between the MIB objects 
>"mplsTunnelOwner"
>and "mplsTunnelSignallingProto"? and how are these fields to be used?
>
>   a) If the field "mplsTunnelOwner" is set to snmp(1) and the "mplsTunnel
>       SignallingProto" is set to "ldp" / "rsvp", does this mean once the row
>       status is made up, the tunnel must be established using CRLDP or
>       RSVP respectively?
>
>   b) If the filed "mplsTunnelOwner" indicates "ldp" or "rsvp" does it mean
>      that the tunnel is dynamically established using IGP (routing info)
>      information? If so will the "mplsTunnelSignallingProto" have value
>      "ldp" or "rsvp" respectively?

         If the tunnel is created my a management protocol operation and
is signaled, then the owner would be management, and the signaling protol
would be whatever signaling protocol was used. If the tunnel is manually
created, the owner would be set to management and the signaling protocol
would be set to none.

         --Tom


--=====================_84137121==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Our
responses are in blue.<br>
<br>
</font><blockquote type=cite cite>1) Local Cookie, Remote Cookie. - How
do I get this value, Do I get this value<br>
by concatenating <br>
&nbsp;&nbsp; a) Extended Tunnel Id and Tunnel ID field values in case of
RSVP path messages?<br>
&nbsp;&nbsp; b) Ingress LSR Router ID and Local CRLS- Id in case of CRLDP
Lbl Req messages?</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>By
consensus of the WG mailing list, these objects are being removed <br>
in the next version of the draft.<br>
<br>
</font><blockquote type=cite cite>2) What is the significant difference
between the MIB objects &quot;mplsTunnelOwner&quot; <br>
and &quot;mplsTunnelSignallingProto&quot;? and how are these fields to be
used?<br>
<br>
&nbsp; a) If the field &quot;mplsTunnelOwner&quot; is set to snmp(1) and
the &quot;mplsTunnel<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SignallingProto&quot; is set to
&quot;ldp&quot; / &quot;rsvp&quot;, does this mean once the row<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; status is made up, the tunnel must be
established using CRLDP or <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RSVP respectively?<br>
<br>
&nbsp; b) If the filed &quot;mplsTunnelOwner&quot; indicates
&quot;ldp&quot; or &quot;rsvp&quot; does it mean<br>
&nbsp;&nbsp;&nbsp;&nbsp; that the tunnel is dynamically established using
IGP (routing info)<br>
&nbsp;&nbsp;&nbsp;&nbsp; information? If so will the
&quot;mplsTunnelSignallingProto&quot; have value<br>
&nbsp;&nbsp;&nbsp;&nbsp; &quot;ldp&quot; or &quot;rsvp&quot;
respectively?</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>If
the tunnel is created my a management protocol operation and<br>
is signaled, then the owner would be management, and the signaling
protol<br>
would be whatever signaling protocol was used. If the tunnel is manually
<br>
created, the owner would be set to management and the signaling protocol
<br>
would be set to none.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
</font></html>

--=====================_84137121==_.ALT--




From owner-mpls@UU.NET  Mon Jun 19 09:06:38 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03793
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 09:06:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugi29697;
	Mon, 19 Jun 2000 13:01:24 GMT
Received: by mail-control.mail.uu.net 
	id QQiugi10688
	for mpls-outgoing; Mon, 19 Jun 2000 13:01:02 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiugi10533
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 13:00:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiugi06031
	for <mpls@uu.net>; Mon, 19 Jun 2000 09:00:54 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiugi29192
	for <mpls@uu.net>; Mon, 19 Jun 2000 13:00:53 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA03942
	for mpls@uu.net; Mon, 19 Jun 2000 09:00:52 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiugi09932
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 13:00:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiugi05782
	for <mpls@uu.net>; Mon, 19 Jun 2000 09:00:14 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiugi28473
	for <mpls@uu.net>; Mon, 19 Jun 2000 13:00:10 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA22950; Mon, 19 Jun 2000 09:00:02 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA04403;
	Mon, 19 Jun 2000 08:59:48 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000619085802.0784af00@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 19 Jun 2000 08:58:31 -0400
To: mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Additional Index for TE-MIB: mplsTunnelTable
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_84229216==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_84229216==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi,

         Responses are highlighted in blue.


>It is not clear to me how to represent a bi-directional tunnel with the MIB.
>Some of my confusion may come from the fact that I don't understand the
>mplsTunnelDirection object. For example, what does it mean to have this object
>set to "bi-directional"? Does it mean that this row refers to a bi-directional
>tunnel? Does the TunnelDirection (in, out) have any significance at the tunnel
>midpoint? What role does the cookie (or the lack of one!) play in
>bi-directional tunnels?

         We will remove this object since it is a vestage from the
time when we had bi-directional tunnels in mind (this will be
removed along with the cookie objects). This will instead be replaced
by an object which indicates whether the LSR is a tunnel src, dst, or
intermediate point.

         --Tom


--=====================_84229216==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font color="#0000FF"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Responses
are highlighted in blue.<br>
<br>
<br>
</font><blockquote type=cite cite>It is not clear to me how to represent
a bi-directional tunnel with the MIB.<br>
Some of my confusion may come from the fact that I don't understand
the<br>
mplsTunnelDirection object. For example, what does it mean to have this
object<br>
set to &quot;bi-directional&quot;? Does it mean that this row refers to a
bi-directional<br>
tunnel? Does the TunnelDirection (in, out) have any significance at the
tunnel<br>
midpoint? What role does the cookie (or the lack of one!) play in<br>
bi-directional tunnels?</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>We
will remove this object since it is a vestage from the<br>
time when we had bi-directional tunnels in mind (this will be<br>
removed along with the cookie objects). This will instead be
replaced<br>
by an object which indicates whether the LSR is a tunnel src, dst,
or<br>
intermediate point.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
</font></html>

--=====================_84229216==_.ALT--




From owner-mpls@UU.NET  Mon Jun 19 11:02:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09282
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 11:02:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugp19520;
	Mon, 19 Jun 2000 14:53:53 GMT
Received: by mail-control.mail.uu.net 
	id QQiugp08447
	for mpls-outgoing; Mon, 19 Jun 2000 14:53:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiugp08439
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 14:53:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiugp27398
	for <mpls@UU.net>; Mon, 19 Jun 2000 10:46:33 -0400 (EDT)
Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQiugp13990
	for <mpls@UU.net>; Mon, 19 Jun 2000 14:46:32 GMT
Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4)
	id KAA09070; Mon, 19 Jun 2000 10:39:57 -0400
Message-ID: <394E4097.D489B5C6@tellium.com>
Date: Mon, 19 Jun 2000 10:47:35 -0500
From: Debanjan Saha <dsaha@tellium.com>
Organization: Tellium Optical Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: "Yakov Rekhter (E-mail)" <yakov@cisco.com>,
        "Kireeti Kompella (E-mail)" <kireeti@juniper.net>,
        Lou Berger <lberger@labn.net>, mpls@UU.NET
Subject: draft-kompella-mpls-bundle-01.txt questiona..
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yakov, Kireeti and Lou,

First of all, is this the latest version of the draft. If yes,
I have the following questions.

Quoted from section 3.1 of the draft..

"Component links may either be unnumbered, or all components links
   must be numbered identically.  In the former case, the bundled link
   may be either unnumbered or numbered with IP addresses assigned to
   some "virtual" interfaces on an LSR (it is assumed that an LSR may
   have multiple virtual interfaces).  In the latter case, the bundled
   link is numbered the same as the component links."

In the first sentence, you say "all component links must be numbered 
identically". What does "identically" really mean?

In the last sentence, you say "the bundled link is numbered the same as 
the component links". Does it mean that the bundle can be numbered with
the IP address of any one of the component links?

Also, have you considered taking SRLG information into account for
bundling?

What about including resource information of the kind?
	4 OC-48 
        2 OC-192 etc...

Current mode of bandwidth accounting does not provide sufficient 
information on bandwidth granularity which is very important for
optical networks.

Regards,
Debanjan
        

Regards,

Debanjan


-- 
Debanjan Saha                         Phone: 732-923-4264
Senior Network Architect              Fax:   732-923-9804
Tellium Optical Systems               http://www.tellium.com


From owner-mpls@UU.NET  Mon Jun 19 11:03:51 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09352
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 11:03:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugn10432;
	Mon, 19 Jun 2000 14:23:54 GMT
Received: by mail-control.mail.uu.net 
	id QQiugn05797
	for mpls-outgoing; Mon, 19 Jun 2000 14:23:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiugn05768
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 14:23:06 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiugn22352
	for <mpls@UU.NET>; Mon, 19 Jun 2000 10:22:09 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQiugn26952
	for <mpls@UU.NET>; Mon, 19 Jun 2000 14:22:08 GMT
Received: from curtis-lt.avici.com (curtis-lt.avici.com [10.1.2.37])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id KAA05721; Mon, 19 Jun 2000 10:22:07 -0400 (EDT)
Received: from curtis-lt.avici.com (localhost [127.0.0.1])
	by curtis-lt.avici.com (8.9.2/8.9.2) with ESMTP id KAA26495;
	Wed, 31 May 2000 10:22:00 -0400 (EDT)
	(envelope-from curtis@curtis-lt.avici.com)
Message-Id: <200005311422.KAA26495@curtis-lt.avici.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'From MountIsland With Love'" <ahsanul@students.itb.ac.id>, mpls@UU.NET
Reply-To: curtis@avici.com
Subject: Re: parameter QoS in mpls network 
In-reply-to: Your message of "Thu, 15 Jun 2000 08:27:24 PDT."
             <336ECDAFDF7DD311B9E30090277AEE4101B40623@nt-exchange-bby.pmc-sierra.bc.ca> 
Date: Wed, 31 May 2000 10:22:00 -0400
From: Curtis Villamizar <curtis@avici.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <336ECDAFDF7DD311B9E30090277AEE4101B40623@nt-exchange-bby.pmc-sierra
.bc.ca>, Shahram Davari writes:
> If you are talking about per-LSP BW reservation, I don't consider that an
> MPLS QoS. This QoS is essentially either per-flow Intserv QoS, or
> per-flow-signaled aggregate Diffserv QoS.
> 
> In other words MPLS signaling (RSVP-TE, CR-LDP) gives you the ability to
> signal BW, but there are other protocol layers that provide the QoS, not
> MPLS. In other words MPLS in orthogonal to QoS but it facilitates providing
> QoS.
> 
> -Shahram


Shahram,

You are making very strong statements regarding features that you
claim that MPLS doesn't have.

MPLS TE, using draft-ietf-mpls-diff-ext-05.txt, provides a means to
signal traffic classifications that will later be applied on an MPLS
label and EXP basis to traffic.  The selection of PHB allows the
network operator to map aggregates of traffic identified by label and
EXP when classified as MPLS, into separate queues (for each BA, not
for each MPLS flow, unless a separate PSC value per flow is used).

At the ingress traffic can be classified by any means already defined
for IP (or whatever L3 is used, if not IP).  For IP this is expeced to
usually include DSCP, and may also include ingress interface or
ingress virtual interface.  In principle filters based on IP addresses
and port numbers or per microflow RSVP can be used on the ingress can
be used for classification, though classification at this fine a
granularity is expected to occur close to the edges of major networks
(if at all) and not in major backbones.

The traffic classification at ingress is used to select the tunnel
that provides the appropriate QoS.

The bandwidth reservation amounts allow such things as queue weights
to be set.  The aggregation of tunnels within tunnels allows the sum
of bandwidth within an outer tunnel to be reflected in the reservation
for the outer tunnel.

Although so far bandwidths on MPLS tunnels have been based on
configured values based on historic data, bandwidths could also be set
based on (filtered) measurements of traffic.

The statement that MPLS is orthogonal to QoS is simply not true.

Curtis


From owner-mpls@UU.NET  Mon Jun 19 11:15:59 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10005
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 11:15:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugq17989;
	Mon, 19 Jun 2000 15:14:49 GMT
Received: by mail-control.mail.uu.net 
	id QQiugq20526
	for mpls-outgoing; Mon, 19 Jun 2000 15:14:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiugq20509
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 15:14:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiugq11717
	for <mpls@UU.NET>; Mon, 19 Jun 2000 11:13:58 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQiugq17314
	for <mpls@UU.NET>; Mon, 19 Jun 2000 15:13:57 GMT
Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA29324;
	Mon, 19 Jun 2000 11:11:44 -0400 (EDT)
	(envelope-from bkumar@ennovatenetworks.com)
Reply-To: <bkumar@ennovatenetworks.com>
From: "Brijesh Kumar" <bkumar@ennovatenetworks.com>
To: <curtis@avici.com>, "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>
Cc: "'From MountIsland With Love'" <ahsanul@students.itb.ac.id>, <mpls@UU.NET>
Subject: RE: parameter QoS in mpls network 
Date: Mon, 19 Jun 2000 11:15:41 -0400
Message-ID: <008601bfda01$3c476e80$d001010a@tst.ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200005311422.KAA26495@curtis-lt.avici.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Curtis writes:

> -----Original Message-----
> > In other words MPLS signaling (RSVP-TE, CR-LDP) gives you
> the ability to
> > signal BW, but there are other protocol layers that provide
> the QoS, not
> > MPLS. In other words MPLS in orthogonal to QoS but it
> facilitates providing
> > QoS.
> >
> > -Shahram
>
> You are making very strong statements regarding features that you
> claim that MPLS doesn't have.
>
> <snip>
> Although so far bandwidths on MPLS tunnels have been based on
> configured values based on historic data, bandwidths could also be
set
> based on (filtered) measurements of traffic.
>
> The statement that MPLS is orthogonal to QoS is simply not true.

Curtis,

I can't understand why you have a problem with what Shahram says. As
you know, there are three distinct aspects relevant to QoS
provisioning:

1. Signaling for QoS (on per packet, or per traffic aggregate basis)
2. Packet queueing and Scheduling to Provide QoS (the services are
actually provided at the IS)
3. Provisioning paths capable of providing needed QoS ( a: Routing
with TE support + b: Path signaling)

MPLS only does part (b) of 3. Steps 1 and 2 are done by Diff-Serv
specs (though signaling of 1 is also re-mapped, and joined with 3(b)
in mpls diff-serv draft). I think that's what Shahram was saying.

Cheers,

--brijesh
Ennovate Networks Inc.





From owner-mpls@UU.NET  Mon Jun 19 11:54:19 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11874
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 11:54:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugt02016;
	Mon, 19 Jun 2000 15:52:43 GMT
Received: by mail-control.mail.uu.net 
	id QQiugt24877
	for mpls-outgoing; Mon, 19 Jun 2000 15:52:11 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiugt24863
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 15:52:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiugt10096
	for <mpls@UU.NET>; Mon, 19 Jun 2000 11:48:24 -0400 (EDT)
Received: from miles.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8])
	id QQiugt11874
	for <mpls@UU.NET>; Mon, 19 Jun 2000 15:48:24 GMT
Received: by MILES with Internet Mail Service (5.5.2650.21)
	id <M98R92P4>; Mon, 19 Jun 2000 16:48:08 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9A42@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>, mpls@UU.NET
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan
	 <csrinivasan@tachion.com>
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable
Date: Mon, 19 Jun 2000 16:48:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFDA05.C38FDC20"
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_01BFDA05.C38FDC20
Content-Type: text/plain;
	charset="iso-8859-1"

Sorry Tom.
 
I'd rather like to hang on to the direction field.  It proves very useful
for bi-directional tunnels!
 
What is more, when Lambda Switching extends its tentacles into the TE MIB
this field will definitely need to be re-instated.
 
Did you have a particular reason why you consider it no longer appropriate
to consider bi-directional tunnels?
 
Cheers,
Adrian

--
Adrian Farrel  mailto:af@datcon.co.uk <mailto:af@datcon.co.uk> 
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/ <http://www.datcon.co.uk/> 
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Monday, June 19, 2000 1:59 PM
To: mpls@UU.NET
Cc: arun Viswanathan; cheenu Srinivasan
Subject: Re: Additional Index for TE-MIB: mplsTunnelTable



        Hi,

        Responses are highlighted in blue.




It is not clear to me how to represent a bi-directional tunnel with the MIB.
Some of my confusion may come from the fact that I don't understand the
mplsTunnelDirection object. For example, what does it mean to have this
object
set to "bi-directional"? Does it mean that this row refers to a
bi-directional
tunnel? Does the TunnelDirection (in, out) have any significance at the
tunnel
midpoint? What role does the cookie (or the lack of one!) play in
bi-directional tunnels?


        We will remove this object since it is a vestage from the
time when we had bi-directional tunnels in mind (this will be
removed along with the cookie objects). This will instead be replaced
by an object which indicates whether the LSR is a tunnel src, dst, or
intermediate point.

        --Tom




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

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


<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D287524415-19062000>Sorry=20
Tom.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D287524415-19062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D287524415-19062000>I'd=20
rather like to hang on to the direction field.&nbsp; It proves very =
useful for=20
bi-directional tunnels!</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D287524415-19062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D287524415-19062000>What=20
is more, when Lambda Switching extends its tentacles into the TE MIB =
this field=20
will definitely need to be re-instated.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D287524415-19062000>Did=20
you have a particular reason why you consider it no longer appropriate =
to=20
consider bi-directional tunnels?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D287524415-19062000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D287524415-19062000>Cheers,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D287524415-19062000>Adrian</SPAN></FONT></DIV>
<P><FONT size=3D2>--<BR>Adrian Farrel&nbsp; <A=20
href=3D"mailto:af@datcon.co.uk">mailto:af@datcon.co.uk</A><BR>Network =
Convergence=20
Group<BR>Data Connection Ltd., Chester, UK<BR><A =
href=3D"http://www.datcon.co.uk/"=20
target=3D_blank>http://www.datcon.co.uk/</A><BR>Tel: +44 (0) 1244 =
313440&nbsp;=20
Fax: +44 (0) 1244 312422<BR></FONT></P>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Thomas D. Nadeau=20
  [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Monday, June 19, 2000 1:59 =

  PM<BR><B>To:</B> mpls@UU.NET<BR><B>Cc:</B> arun Viswanathan; cheenu=20
  Srinivasan<BR><B>Subject:</B> Re: Additional Index for TE-MIB:=20
  mplsTunnelTable<BR><BR></DIV></FONT><FONT=20
  =
color=3D#0000ff><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;</X-TAB>Hi,<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;</X-TAB>Responses=20
  are highlighted in blue.<BR><BR><BR></FONT>
  <BLOCKQUOTE cite type=3D"cite">It is not clear to me how to represent =
a=20
    bi-directional tunnel with the MIB.<BR>Some of my confusion may =
come from=20
    the fact that I don't understand the<BR>mplsTunnelDirection object. =
For=20
    example, what does it mean to have this object<BR>set to =
"bi-directional"?=20
    Does it mean that this row refers to a bi-directional<BR>tunnel? =
Does the=20
    TunnelDirection (in, out) have any significance at the =
tunnel<BR>midpoint?=20
    What role does the cookie (or the lack of one!) play =
in<BR>bi-directional=20
    tunnels?</BLOCKQUOTE><BR><FONT=20
  =
color=3D#0000ff><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
/X-TAB>We=20
  will remove this object since it is a vestage from the<BR>time when =
we had=20
  bi-directional tunnels in mind (this will be<BR>removed along with =
the cookie=20
  objects). This will instead be replaced<BR>by an object which =
indicates=20
  whether the LSR is a tunnel src, dst, or<BR>intermediate=20
  =
point.<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X=
-TAB>--Tom<BR><BR></BLOCKQUOTE></FONT></BODY></HTML>

------_=_NextPart_001_01BFDA05.C38FDC20--


From owner-mpls@UU.NET  Mon Jun 19 12:09:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12775
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 12:09:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugu12138;
	Mon, 19 Jun 2000 16:07:48 GMT
Received: by mail-control.mail.uu.net 
	id QQiugu05466
	for mpls-outgoing; Mon, 19 Jun 2000 16:07:12 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiugu05461
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 16:07:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiugt11481
	for <mpls@UU.NET>; Mon, 19 Jun 2000 11:55:58 -0400 (EDT)
Received: from mailhost.metro-optix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.metro-optix.com [63.91.47.254])
	id QQiugt04244
	for <mpls@UU.NET>; Mon, 19 Jun 2000 15:55:58 GMT
Received: by MAILHOST.metro-optix.com with Internet Mail Service (5.5.2650.21)
	id <NAL3WL4R>; Mon, 19 Jun 2000 10:56:21 -0500
Message-ID: <D7F6115661E9D311834F006008F5C83C0963FF@MAILHOST.metro-optix.com>
From: David Wang <david.wang@metro-optix.com>
To: mpls@UU.NET
Subject: RE: MPLS and IS-IS
Date: Mon, 19 Jun 2000 10:56:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi All,

I need to learn some basics of IS-IS. I checked amazon.com, cl.com (San Jose
Computer literature book store), bookpool.com and several other technology
bookstores. To my great surprise I couldn't find any book about IS-IS. I
couldn't find any tutorial or white paper about the IS-IS protocol on the
Internet either. All I can read is the 10 years old RFC 1142 and RFC 1195.

1. When IS-IS protocol is used to route IP packet only, what kind of lay 3
protocol the IS-IS routers use to communicate link state information (the
link state advertisements) and other protocol related information, IP or
CLNP? What is the encapsulation format of these packets. What the standard
specify and what people actually implement?  

2. Can someone recommend me a book, a white paper or some tutorials so I may
get started quicker.

Thanks for your help.
David

-----Original Message-----
From: HANSEN CHAN [mailto:hchan@newbridge.com]
Sent: Tuesday, May 16, 2000 7:22 AM
To: mpls@UU.NET
Subject: MPLS and IS-IS


Hi all,

I have been hearing IS-IS is a better protocol to be used than OSPF in a
MPLS
network for TE application. Is that a fair statement? What are the technical
reasons?

Appreciate if someone can shed some light on this subject.

Thanks,
Hansen


From owner-mpls@UU.NET  Mon Jun 19 12:23:04 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13354
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 12:23:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugv21316;
	Mon, 19 Jun 2000 16:21:24 GMT
Received: by mail-control.mail.uu.net 
	id QQiugv06504
	for mpls-outgoing; Mon, 19 Jun 2000 16:20:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiugv06499
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 16:20:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiugu23796
	for <mpls@uu.net>; Mon, 19 Jun 2000 12:09:46 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQiugu26510
	for <mpls@uu.net>; Mon, 19 Jun 2000 16:09:46 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCC6VZ>; Mon, 19 Jun 2000 09:16:00 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6626907AC@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Ramanjaneyulu Y T'" <ytr@csa.iisc.ernet.in>
Cc: "'MPLS Mailing List'" <mpls@UU.NET>
Subject: RE: 
Date: Mon, 19 Jun 2000 09:15:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk



> -----Original Message-----
> From: Ramanjaneyulu Y T [mailto:ytr@csa.iisc.ernet.in]
> Sent: Friday, June 16, 2000 10:05 PM
> To: mpls@UU.NET
> Subject: 
> 
> 
> Respected all,
> 
>    At present we are developing voice over IP router with 
> MPLS and RSVP protocols. I got one doubt in that. 
> 
>       At edge routers (ingress, egress LSR) many phones (are)
> attached. When ever a user wants (to) talk to other party he
> /she rings number, SIP will verify other party is ready to 
> accept call or not . If it ready to accept RSVP will establish 
> path. This will (be the) same ... if multiple party (which 
> phones are attached to same edge) want to communicate to (the) 
> same destination edge. 

Whether or not RSVP signaling will be used on a per call
basis is a topic still very much in the air.  Many people
speaking/writing on this subject pretty much assume that
RSVP-like signaling will be used to establish trunks over
which multiple services will be carried.

> 
> Once path is (established) when conversation starts, voice 
> (packets start) coming to ingress LSR. Now (the problem) is how 
> to map IP addr. to MPLS (label) on  destination IP because more 
> than one destination RSVP paths established. 

This depends on the types of conversations established.  If 
this is a multiparty call, then packets from different sources
will need to be reassembled to produce voice information at a
destination independent of similar packets from other sources.
The result of re-assembling packets from several speakers should 
be no worse than the experience of hearing multiple speakers 
talking at the same time in a "normal" conversation.

Because the application needs to sort out packets per source,
there should be no problem with merging packets toward the
destination.

On the other hand, if there are multiple individual calls for
a given destination (or source and destination), then whatever
signaling is used to establish the individual calls needs to
allow the application at each end to easily demux packets for
each of the individual calls - e.g. - via different source or
destination port numbers.

Does this help?

> 
> 
> 
>                                                               
>                                          
>                                           With  Regards
>                                         Ramanajaneyulu Y.T. 
> 
>  "Everyone hears what you say. Friends listen to what you say. Best
>   friends listen to what you don't say."

Can't figure out if this is incredibly optimistic or just
mildly so.  Everyone within earshot MAY notice that you
are making noise.  Some of them, perhaps sharing a common
language and being close enough MAY recognize your words.
People who listen MAY hear what you say.  People who think
MAY infer what you don't say.

If you expect that:

	(friends <==> listeners) 

		and 

	(best friends <==> thinkers)

then perhaps you set standards for friends too high and
standards for everyone else too low... :-)

>   
> --------------------------------------------------------------
> ---------------- 
> Y.T.RAMANJANEYULU                        |   My other mail Ids:
> E-70,INDIAN INSTITUTE OF SCIENCE         |         ytr@rediffmail.com
> BANGALORE - 560012                       |         kingytr@excite.com
> PH: 0091 - 080 - 3092622 ( HOSTEL )      |
>     0091 - 080 - 3092906 ( LAB )         |
>                    visit my home page:www2.csa.iisc.ernet.in/~ytr
> --------------------------------------------------------------
> ------------------
> 
> 

Eric Gray


From owner-mpls@UU.NET  Mon Jun 19 12:30:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13694
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 12:30:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugv09018;
	Mon, 19 Jun 2000 16:27:55 GMT
Received: by mail-control.mail.uu.net 
	id QQiugv07066
	for mpls-outgoing; Mon, 19 Jun 2000 16:27:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiugv07055
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 16:27:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiugv26278
	for <mpls@UU.NET>; Mon, 19 Jun 2000 12:23:01 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQiugv05570
	for <mpls@UU.NET>; Mon, 19 Jun 2000 16:23:01 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCC6X1>; Mon, 19 Jun 2000 09:29:11 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6626907AD@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Ramanjaneyulu Y T'" <ytr@csa.iisc.ernet.in>
Cc: "'MPLS Mailing List'" <mpls@UU.NET>
Subject: RE: header 
Date: Mon, 19 Jun 2000 09:29:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk



> -----Original Message-----
> From: Ramanjaneyulu Y T [mailto:ytr@csa.iisc.ernet.in]
> Sent: Sunday, June 18, 2000 12:23 PM
> To: mpls@UU.NET
> Subject: header 
> 
> 
> IP over MPLS
> 
> some packets may be normal IP packets (having only IP header), 
> whereas some may be MPLS packets(having MPLS header followed 
> by IP header).
> 
> how does one distinguish whether it is an IP packet, or an 
> MPLS packet.

If you check out the encapsulation draft, at:

http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt

you will find that there are protocol identifiers used at 
layer 2 to demux labeled and unlabeled packets for PPP and
Ethernet/802.3.

Both ATM and Frame Relay assume use of a separate VC to
carry unlabeled packets.

> 
>                                                               
>                                          
>                                           With  Regards
>                                         Ramanajaneyulu Y.T. 
> 
> 

--
Eric Gray


From owner-mpls@UU.NET  Mon Jun 19 12:38:47 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14049
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 12:38:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugw00998;
	Mon, 19 Jun 2000 16:35:14 GMT
Received: by mail-control.mail.uu.net 
	id QQiugw07481
	for mpls-outgoing; Mon, 19 Jun 2000 16:34:37 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiugw07441
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 16:34:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiugv15929
	for <mpls@UU.NET>; Mon, 19 Jun 2000 12:19:41 -0400 (EDT)
Received: from coltrane.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.datcon.co.uk [192.91.191.4])
	id QQiugv19979
	for <mpls@UU.NET>; Mon, 19 Jun 2000 16:19:41 GMT
Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21)
	id <M98TBWM9>; Mon, 19 Jun 2000 17:19:40 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9A43@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>, mpls@UU.NET
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan
	 <csrinivasan@tachion.com>
Subject: RE: MPLS TE MIB - Doubts
Date: Mon, 19 Jun 2000 17:19:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi again Tom.

I've given up with colours - too messy.

>>>>3. LSPId explicit hop type 
>>>>Is there any reason to prevent configuration of an explicit hop 
>>>>of type LSPId?  I suggested some ASN.1 for this in an email to 
>>>>Tom on 7th Jan. 

>>>If ldp is chosen to route the tunnel then we'll add this as 
>>>a choice for the hop type. 

>>I'm not quite sure what your answer means.  I think you're
>>saying you'll add the hop type but only allow it if the 
>>signaling protocol is flagged as [CR-]LDP.  This would be
>>great.

>If any of the signaling protocols can handle such an option,
>then we will extend the MIB to handle this. At present, none of
>the MPLS signaling protocols officially support this.

Ah but they do or have I missed a new version of the drafts?
Specifically, in draft-ietf-mpls-cr-ldp-03.txt CR-LDP allows this...

4.7.4. ER-Hop 4: LSPID

   The LSPID is used to identify the tunnel ingress point as the next
   hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an
   already established CR-LSP. It also allows for splicing the CR-LSP
   being established with an existing CR-LSP.

   If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may
   splice the CR-LSP of the incoming Label Request to the CR-LSP that
   currently exists with this LSPID.  This is useful, for example, at
   the point at which a Label Request used for local repair arrives at
   the next ER-Hop after the loosely specified CR-LSP segment.  Use of
   the LSPID Hop in this scenario eliminates the need for ER-Hops to
   keep the entire remaining ER-TLV at each LSR that is at either
   (upstream or downstream) end of a loosely specified CR-LSP segment
   as part of its state information. This is due to the fact that the
   upstream LSR needs only to keep the next ER-Hop and the LSPID and
   the downstream LSR needs only to keep the LSPID in order for each
   end to be able to recognize that the same LSP is being identified.

   If the LSPID Hop is not the last hop in an ER-TLV, the LSR must
   forward the remaining ER-TLV in a Label Request message, using the
   CR-LSP specified by the LSPID, to the LSR that is the CR-LSP's
   egress. That LSR will continue processing of the CR-LSP Label
   Request Message.  The result is a tunneled, or stacked, CR-LSP.

>>>>6. MPLS Tunnel Resource Table 
>>>>This table is a welcome addition. 
>>>>I believe you need to be very careful because of the differences 
>>>>between forward and reverse resource reservation.  For example, 
>>>>for an RSVP tunnel, what is configured here must be the TSpec.  
>>>>Clearly, sharing TSpecs is useful from a configuration point of 
>>>>view, but says nothing about sharing of resources which is 
>>>>determined elsewhere in the network.  Is it your intention that 
>>>>this table is updated on the reverse path? 

>>>tunnels are unidirectional; so the issue of bidirectional     
>>>resource reservation does not arise 

>>It wasn't my intention to talk about bi-directional LSPs at 
>>this point (although that is an interesting topic of 
>>conversation in this regard).  When I talk about forward and
>>reverse reservation I am simply distinguishing between CR-LDP
>>where the resources are reserved as the Label_Request traverses
>>the network, and RSVP where the resources are (strictly speaking)
>>only reserved when the Resv travels back.  Thus the information
>>in the MIB row is far more likely to reflect the true reservation
>>in CR-LDP than in RSVP unless the table is updated by the 
>>protocol code on completion of LSP setup to reflect the flowspec.

>The ARHopTable is captures the actual reservation, and is
>applicable to both signaling protocols.

I think I have missed something here.  We are still talking about version 03
of the draft aren't we?  In my copy the ARHopTable contains only the output
from the Recorded Route object.

So back to the question about recording the difference between requested
traffic parameters and actual reservations.

- Are you saying that the mplsTunnelResourceTable is updated
  to reflect the actual resources reserved?  This would
  intuitively be the job of mplsTrafficParamTable in the LSR
  MIB.
- If this is what you are saying then you will need to update
  most of the text which describes the movement of data from
  mplsTunnelResourceTable to mplsTrafficParamTable but not
  vice versa.
- Do you intend that sharing entries in mplsTunnelResourceTable 
  between rows in mplsTunnelTable reflects sharing TSpecs or 
  sharing real reservations?  These can be very different 
  matters in RSVP.

>>>>15. mplsTunnelXCIndex 
>We would prefer the following:
>       "This variable represents an index into the
>        mplsXCTable. This table identifies the segments
>        that compose this tunnel, their characteristics,
>        and relationships to each other. 
>        In the case where a signaling protocol is used
>        to set up the tunnel, this field is to reflect 
>        the row in the mplsXCTable
>        that has been set up to describe the cross-
>        connect for this LSP and SHOULD NOT be changed.
>        In the case where the tunnel has been statically
>        configured by writing to the tables in the LSR 
>        MIB, this field MUST be set to indicate the 
>        correct entry in the mplsXCTable."

Fine. You have only removed the bit about who sets the field in the signaled
case from my text, right?

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


From owner-mpls@UU.NET  Mon Jun 19 12:41:55 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14155
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 12:41:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugw16728;
	Mon, 19 Jun 2000 16:39:11 GMT
Received: by mail-control.mail.uu.net 
	id QQiugw07679
	for mpls-outgoing; Mon, 19 Jun 2000 16:38:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiugw07674
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 16:38:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiugv16823
	for <mpls@UU.NET>; Mon, 19 Jun 2000 12:24:20 -0400 (EDT)
Received: from node9.cwnet.frontiernet.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: node9.frontiernet.net [209.130.129.194])
	id QQiugv06472
	for <mpls@UU.NET>; Mon, 19 Jun 2000 16:24:20 GMT
Received: (from daemon@localhost)
	by node9.cwnet.frontiernet.net (8.9.3/8.9.3) id MAA18304;
	Mon, 19 Jun 2000 12:18:03 -0400
Received: from whip14.frontiernet.net(208.48.7.14), claiming to be "globalcenter.net"
 via SMTP by node9.frontiernet.net, id smtpdE.njUa; Mon Jun 19 12:17:54 2000
Message-ID: <394E4799.BC590269@globalcenter.net>
Date: Mon, 19 Jun 2000 12:17:29 -0400
From: "Larry G. Moore" <lmoore@globalcenter.net>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: David Wang <david.wang@metro-optix.com>
CC: mpls@UU.NET
Subject: Re: MPLS and IS-IS
References: <D7F6115661E9D311834F006008F5C83C0963FF@MAILHOST.metro-optix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

David Wang wrote:
> 
> Hi All,
> 
> I need to learn some basics of IS-IS. I checked amazon.com, cl.com (San Jose
> Computer literature book store), bookpool.com and several other technology
> bookstores. To my great surprise I couldn't find any book about IS-IS. I
> couldn't find any tutorial or white paper about the IS-IS protocol on the
> Internet either. All I can read is the 10 years old RFC 1142 and RFC 1195.

CCIE Professional Development: Routing TCP/IP Volume 1
Jeff Doyle 
ISBN 1-57870-041-8

http://www.amazon.com/exec/obidos/ASIN/1578700418/qid%3D961431340/002-4201853-0159269

> 
> 1. When IS-IS protocol is used to route IP packet only, what kind of lay 3
> protocol the IS-IS routers use to communicate link state information (the
> link state advertisements) and other protocol related information, IP or
> CLNP? What is the encapsulation format of these packets. What the standard
> specify and what people actually implement?
> 
> 2. Can someone recommend me a book, a white paper or some tutorials so I may
> get started quicker.
> 
> Thanks for your help.
> David
> 
> -----Original Message-----
> From: HANSEN CHAN [mailto:hchan@newbridge.com]
> Sent: Tuesday, May 16, 2000 7:22 AM
> To: mpls@UU.NET
> Subject: MPLS and IS-IS
> 
> Hi all,
> 
> I have been hearing IS-IS is a better protocol to be used than OSPF in a
> MPLS
> network for TE application. Is that a fair statement? What are the technical
> reasons?
> 
> Appreciate if someone can shed some light on this subject.
> 
> Thanks,
> Hansen

-- 
Larry G. Moore
Global Crossing NCC
800-414-5028
lmoore@globalcenter.net


From owner-mpls@UU.NET  Mon Jun 19 13:07:34 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15790
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 13:07:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiugy22240;
	Mon, 19 Jun 2000 17:06:52 GMT
Received: by mail-control.mail.uu.net 
	id QQiugy19159
	for mpls-outgoing; Mon, 19 Jun 2000 17:06:16 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiugy19120
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 17:06:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiugx21413
	for <mpls@uu.net>; Mon, 19 Jun 2000 12:51:36 -0400 (EDT)
Received: from bgslc02.TBG.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.99.125.2])
	id QQiugx25371
	for <mpls@uu.net>; Mon, 19 Jun 2000 16:51:36 GMT
Received: by BGSLC02 with Internet Mail Service (5.5.2448.0)
	id <M8ZD07YM>; Mon, 19 Jun 2000 10:44:38 -0600
Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE654@BGSLC02>
From: Irwin Lazar <ILazar@tbg.com>
To: "'David Wang'" <david.wang@metro-optix.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: RE: MPLS and IS-IS
Date: Mon, 19 Jun 2000 10:44:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

See: 
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/osi_rout.htm for an
OSI primer.

and

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/n
p1_c/1cisis.htm
for configuration information.

Also see my web site at http://www.itprc.com/ for more IP routing
information.

Irwin

-----Original Message-----
From: David Wang [mailto:david.wang@metro-optix.com]
Sent: Monday, June 19, 2000 11:56 AM
To: mpls@UU.NET
Subject: RE: MPLS and IS-IS



Hi All,

I need to learn some basics of IS-IS. I checked amazon.com, cl.com (San Jose
Computer literature book store), bookpool.com and several other technology
bookstores. To my great surprise I couldn't find any book about IS-IS. I
couldn't find any tutorial or white paper about the IS-IS protocol on the
Internet either. All I can read is the 10 years old RFC 1142 and RFC 1195.

1. When IS-IS protocol is used to route IP packet only, what kind of lay 3
protocol the IS-IS routers use to communicate link state information (the
link state advertisements) and other protocol related information, IP or
CLNP? What is the encapsulation format of these packets. What the standard
specify and what people actually implement?  

2. Can someone recommend me a book, a white paper or some tutorials so I may
get started quicker.

Thanks for your help.
David

-----Original Message-----
From: HANSEN CHAN [mailto:hchan@newbridge.com]
Sent: Tuesday, May 16, 2000 7:22 AM
To: mpls@UU.NET
Subject: MPLS and IS-IS


Hi all,

I have been hearing IS-IS is a better protocol to be used than OSPF in a
MPLS
network for TE application. Is that a fair statement? What are the technical
reasons?

Appreciate if someone can shed some light on this subject.

Thanks,
Hansen


From owner-mpls@UU.NET  Mon Jun 19 14:31:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19714
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 14:31:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuhd17941;
	Mon, 19 Jun 2000 18:28:44 GMT
Received: by mail-control.mail.uu.net 
	id QQiuhd05435
	for mpls-outgoing; Mon, 19 Jun 2000 18:28:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuhd05423
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 18:28:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuhd18729
	for <mpls@uu.net>; Mon, 19 Jun 2000 14:25:07 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuhd15218
	for <mpls@uu.net>; Mon, 19 Jun 2000 18:25:06 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA23370
	for mpls@uu.net; Mon, 19 Jun 2000 14:25:05 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuhd05186
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 18:24:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuhd05769
	for <mpls@UU.NET>; Mon, 19 Jun 2000 14:15:19 -0400 (EDT)
Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailman.cisco.com [171.68.225.9])
	id QQiuhd08284
	for <mpls@UU.NET>; Mon, 19 Jun 2000 18:15:18 GMT
Received: from chmetz-pc.cisco.com ([10.19.239.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA13061;
	Mon, 19 Jun 2000 11:06:52 -0700 (PDT)
Message-Id: <4.2.0.58.20000619135345.01398100@sj-email.cisco.com>
X-Sender: chmetz@sj-email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 19 Jun 2000 13:56:26 -0400
To: Irwin Lazar <ILazar@tbg.com>
From: Chris Metz <chmetz@cisco.com>
Subject: RE: MPLS and IS-IS
Cc: "'David Wang'" <david.wang@metro-optix.com>, "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <0C875DC28791D21192CD00104B95BFE7BAE654@BGSLC02>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi-
Check out:

Perlman, Radia, "Interconnections Second Edition", Addison-Wesley, 2000

Retana, et al, "Advanced IP Network Design", Cisco Press, 1999

Cheers ...


At 10:44 AM 6/19/2000 -0600, Irwin Lazar wrote:
>See:
>http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/osi_rout.htm for an
>OSI primer.
>
>and
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/n
>p1_c/1cisis.htm
>for configuration information.
>
>Also see my web site at http://www.itprc.com/ for more IP routing
>information.
>
>Irwin
>
>-----Original Message-----
>From: David Wang [mailto:david.wang@metro-optix.com]
>Sent: Monday, June 19, 2000 11:56 AM
>To: mpls@UU.NET
>Subject: RE: MPLS and IS-IS
>
>
>
>Hi All,
>
>I need to learn some basics of IS-IS. I checked amazon.com, cl.com (San Jose
>Computer literature book store), bookpool.com and several other technology
>bookstores. To my great surprise I couldn't find any book about IS-IS. I
>couldn't find any tutorial or white paper about the IS-IS protocol on the
>Internet either. All I can read is the 10 years old RFC 1142 and RFC 1195.
>
>1. When IS-IS protocol is used to route IP packet only, what kind of lay 3
>protocol the IS-IS routers use to communicate link state information (the
>link state advertisements) and other protocol related information, IP or
>CLNP? What is the encapsulation format of these packets. What the standard
>specify and what people actually implement?
>
>2. Can someone recommend me a book, a white paper or some tutorials so I may
>get started quicker.
>
>Thanks for your help.
>David
>
>-----Original Message-----
>From: HANSEN CHAN [mailto:hchan@newbridge.com]
>Sent: Tuesday, May 16, 2000 7:22 AM
>To: mpls@UU.NET
>Subject: MPLS and IS-IS
>
>
>Hi all,
>
>I have been hearing IS-IS is a better protocol to be used than OSPF in a
>MPLS
>network for TE application. Is that a fair statement? What are the technical
>reasons?
>
>Appreciate if someone can shed some light on this subject.
>
>Thanks,
>Hansen




Chris Metz
Lead IP Architect
Solutions Integration
Service Provider Line of Business
Cisco Systems
email: chmetz@cisco.com
offic phone: 408-525-3275
home office: 914-241-0423
pager: 800-365-4578
Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm  



From owner-mpls@UU.NET  Mon Jun 19 17:12:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23619
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 17:12:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuho24717;
	Mon, 19 Jun 2000 21:11:01 GMT
Received: by mail-control.mail.uu.net 
	id QQiuho17193
	for mpls-outgoing; Mon, 19 Jun 2000 21:10:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuho17183
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 21:10:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuho23669
	for <mpls@uu.net>; Mon, 19 Jun 2000 17:09:39 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQiuho25703
	for <mpls@uu.net>; Mon, 19 Jun 2000 21:09:38 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA24820
	for <mpls@uu.net>; Mon, 19 Jun 2000 14:09:48 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA19264 for mpls@uu.net; Mon, 19 Jun 2000 17:09:37 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQitzg21066
	for <mpls@mail-control.mail.uu.net>; Sat, 17 Jun 2000 15:08:00 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQitzg28308
	for <mpls@uu.net>; Sat, 17 Jun 2000 11:07:51 -0400 (EDT)
Received: from wisbech.cl.cam.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mta1.cl.cam.ac.uk [128.232.0.15])
	id QQitzg20569
	for <mpls@uu.net>; Sat, 17 Jun 2000 15:07:50 GMT
Received: from uridium.cl.cam.ac.uk
	([128.232.8.49] helo=cl.cam.ac.uk ident=kaf24)
	by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1)
	id 133KCM-0005AA-00; Sat, 17 Jun 2000 16:07:50 +0100
To: mpls@UU.NET
cc: Keir.Fraser@cl.cam.ac.uk
Subject: New MPLS implementation for Linux
Date: Sat, 17 Jun 2000 16:07:49 +0100
From: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Message-Id: <E133KCM-0005AA-00@wisbech.cl.cam.ac.uk>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is just to announce that I have released a new implementation of
MPLS for Linux 2.3. Note that this is NOT related to the existing
implementation by Jim Leu at University of Wisconsin.

It can be found at: 
http://www.cl.cam.ac.uk/Research/SRG/netos/netx/code/mpls-current.tar.gz


Advantages of the new implementation
------------------------------------
 * The Linux traffic classification architecture can be used to
   implement differentiated forwarding for different LSPs. This is
   documented further in the distribution.

 * We use the existing Linux routing code to map packets to LSPs. This
   can allow greater flexibility in specifying FECs than just destination
   subnet. 

 * The switching code is implemented quite efficiently and hooks
   cleanly into the Linux networking architecture. This was a _big_
   weakness in early versions of the Wisconsin implementation, which
   prompted me to write my own version in the first place. (However,
   new versions appear to have been massively reworked: this may not
   be a problem any more).

 * The whole thing is written cleanly and could be extended quite
   easily (I think! :-)


Disadvantages
-------------
 * This isn't an LDP implementation. All we needed for our own work
   was the switching plane.

 * No label pushing/popping. 

 * Only support for IPv4 tunnelling at present (more could be added
   quite easily).

 * I only supply a patch for linux 2.3.99-pre5. However, porting to
   other recent versions of the kernel shouldn't be a big task.


Feel free to contact me if you have any questions or problems!

 -- Keir Fraser 
    (Systems Research Group, University of Cambridge)



From owner-mpls@UU.NET  Mon Jun 19 19:07:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25301
	for <mpls-archive@lists.ietf.org>; Mon, 19 Jun 2000 19:07:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuhw18211;
	Mon, 19 Jun 2000 23:06:36 GMT
Received: by mail-control.mail.uu.net 
	id QQiuhw16192
	for mpls-outgoing; Mon, 19 Jun 2000 23:05:58 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuhw16184
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 23:05:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuhw12653
	for <mpls@UU.NET>; Mon, 19 Jun 2000 19:05:42 -0400 (EDT)
Received: from mail.krioukov.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cj114416-a.reston1.va.home.com [24.15.191.36])
	id QQiuhw17249
	for <mpls@UU.NET>; Mon, 19 Jun 2000 23:05:42 GMT
Received: from VA1ENG128 (fw-1.winstar.com [207.86.108.130])
	by mail.krioukov.net (8.9.3/8.9.3) with SMTP id SAA07229;
	Mon, 19 Jun 2000 18:49:36 -0400
From: "Dmitri Krioukov" <dima@krioukov.net>
To: "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>
Cc: <mpls@UU.NET>
Subject: RE: New MPLS implementation for Linux
Date: Mon, 19 Jun 2000 19:20:30 -0400
Message-ID: <NCBBIKACLKNMKDHKKKNFAEKCELAA.dima@krioukov.net>
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: <E133KCM-0005AA-00@wisbech.cl.cam.ac.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

have you tried to work with the zebra
group? they already have ldp in place.
i don't think they have hierarchical
tunnels.
--
dima.

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Keir
> Fraser
> Sent: Saturday, June 17, 2000 11:08 AM
> To: mpls@UU.NET
> Cc: Keir.Fraser@cl.cam.ac.uk
> Subject: New MPLS implementation for Linux
> 
> 
> This is just to announce that I have released a new implementation of
> MPLS for Linux 2.3. Note that this is NOT related to the existing
> implementation by Jim Leu at University of Wisconsin.
> 
> It can be found at: 
> http://www.cl.cam.ac.uk/Research/SRG/netos/netx/code/mpls-current.tar.gz
> 
> 
> Advantages of the new implementation
> ------------------------------------
>  * The Linux traffic classification architecture can be used to
>    implement differentiated forwarding for different LSPs. This is
>    documented further in the distribution.
> 
>  * We use the existing Linux routing code to map packets to LSPs. This
>    can allow greater flexibility in specifying FECs than just destination
>    subnet. 
> 
>  * The switching code is implemented quite efficiently and hooks
>    cleanly into the Linux networking architecture. This was a _big_
>    weakness in early versions of the Wisconsin implementation, which
>    prompted me to write my own version in the first place. (However,
>    new versions appear to have been massively reworked: this may not
>    be a problem any more).
> 
>  * The whole thing is written cleanly and could be extended quite
>    easily (I think! :-)
> 
> 
> Disadvantages
> -------------
>  * This isn't an LDP implementation. All we needed for our own work
>    was the switching plane.
> 
>  * No label pushing/popping. 
> 
>  * Only support for IPv4 tunnelling at present (more could be added
>    quite easily).
> 
>  * I only supply a patch for linux 2.3.99-pre5. However, porting to
>    other recent versions of the kernel shouldn't be a big task.
> 
> 
> Feel free to contact me if you have any questions or problems!
> 
>  -- Keir Fraser 
>     (Systems Research Group, University of Cambridge)


From owner-mpls@UU.NET  Tue Jun 20 01:39:50 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06952
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 01:39:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuiw19880;
	Tue, 20 Jun 2000 05:38:29 GMT
Received: by mail-control.mail.uu.net 
	id QQiuiw10834
	for mpls-outgoing; Tue, 20 Jun 2000 05:37:41 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuiw10826
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 05:37:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuiw01067
	for <mpls@UU.NET>; Tue, 20 Jun 2000 01:37:25 -0400 (EDT)
Received: from mail-out.globalone.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-out.globalone.net [199.184.38.11])
	id QQiuiw19171
	for <mpls@UU.NET>; Tue, 20 Jun 2000 05:37:25 GMT
Received: from master.res.globalone.net (master.res.globalone.net [192.168.75.50])
	by mail-out.globalone.net (8.8.7/8.8.5) with ESMTP id BAA22956
	for <mpls@UU.NET>; Tue, 20 Jun 2000 01:39:10 -0400
Received: from master.hok.globalone.net (root@master.hok.globalone.net [160.81.187.23])
	by master.res.globalone.net (8.8.7/8.8.5) with ESMTP id BAA13594
	for <mpls@UU.NET>; Tue, 20 Jun 2000 01:36:50 -0400
Received: from mail.tok.globalone.net (mail.tok.globalone.net [160.81.176.100])
	by master.hok.globalone.net (8.8.7/8.8.5) with ESMTP id NAA12970
	for <mpls@UU.NET>; Tue, 20 Jun 2000 13:37:05 +0800
Received: from hishii ([160.81.177.100]) by mail.tok.globalone.net
          (Netscape Messaging Server 3.62)  with ESMTP id 151;
          Tue, 20 Jun 2000 14:39:38 +0900
Message-Id: <4.2.0.58.J.20000620143459.03bbd450@160.81.176.100>
X-Sender: hideo.ishii@160.81.176.100
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Tue, 20 Jun 2000 14:35:33 +0900
To: "Dmitri Krioukov" <dima@krioukov.net>
From: "Hideo Ishii" <Hideo.Ishii@globalone.net>
Subject: RE: New MPLS implementation for Linux
Cc: <mpls@UU.NET>
In-Reply-To: <NCBBIKACLKNMKDHKKKNFAEKCELAA.dima@krioukov.net>
References: <E133KCM-0005AA-00@wisbech.cl.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Zebra doesn't have LDP function yet, as far as I know.
But zebra will be implemented LDP, I guess.:-)

--
Hideo Ishii
Global One Japan

At $B8a8e(B 07:20 00/06/19 -0400, Dmitri Krioukov wrote:
>have you tried to work with the zebra
>group? they already have ldp in place.
>i don't think they have hierarchical
>tunnels.
>--
>dima.
>
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Keir
> > Fraser
> > Sent: Saturday, June 17, 2000 11:08 AM
> > To: mpls@UU.NET
> > Cc: Keir.Fraser@cl.cam.ac.uk
> > Subject: New MPLS implementation for Linux
> >
> >
> > This is just to announce that I have released a new implementation of
> > MPLS for Linux 2.3. Note that this is NOT related to the existing
> > implementation by Jim Leu at University of Wisconsin.
> >
> > It can be found at:
> > http://www.cl.cam.ac.uk/Research/SRG/netos/netx/code/mpls-current.tar.gz
> >
> >
> > Advantages of the new implementation
> > ------------------------------------
> >  * The Linux traffic classification architecture can be used to
> >    implement differentiated forwarding for different LSPs. This is
> >    documented further in the distribution.
> >
> >  * We use the existing Linux routing code to map packets to LSPs. This
> >    can allow greater flexibility in specifying FECs than just destination
> >    subnet.
> >
> >  * The switching code is implemented quite efficiently and hooks
> >    cleanly into the Linux networking architecture. This was a _big_
> >    weakness in early versions of the Wisconsin implementation, which
> >    prompted me to write my own version in the first place. (However,
> >    new versions appear to have been massively reworked: this may not
> >    be a problem any more).
> >
> >  * The whole thing is written cleanly and could be extended quite
> >    easily (I think! :-)
> >
> >
> > Disadvantages
> > -------------
> >  * This isn't an LDP implementation. All we needed for our own work
> >    was the switching plane.
> >
> >  * No label pushing/popping.
> >
> >  * Only support for IPv4 tunnelling at present (more could be added
> >    quite easily).
> >
> >  * I only supply a patch for linux 2.3.99-pre5. However, porting to
> >    other recent versions of the kernel shouldn't be a big task.
> >
> >
> > Feel free to contact me if you have any questions or problems!
> >
> >  -- Keir Fraser
> >     (Systems Research Group, University of Cambridge)




From owner-mpls@UU.NET  Tue Jun 20 03:31:00 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14775
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 03:31:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiujd06999;
	Tue, 20 Jun 2000 07:29:53 GMT
Received: by mail-control.mail.uu.net 
	id QQiujd07777
	for mpls-outgoing; Tue, 20 Jun 2000 07:29:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiujd07769
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 07:29:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiujd15097
	for <mpls@UU.NET>; Tue, 20 Jun 2000 03:29:05 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQiujd06020
	for <mpls@UU.NET>; Tue, 20 Jun 2000 07:28:52 GMT
Received: from santosh (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id MAA17091
	for <mpls@UU.NET>; Tue, 20 Jun 2000 12:45:18 -0600 (GMT)
Message-ID: <002101bfda88$38062f00$100d85a5@dti.daewoo.co.kr>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: LDP + COPS
Date: Tue, 20 Jun 2000 12:50:36 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0019_01BFDAB6.21215980"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01BFDAB6.21215980
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello
    I am integrating LDP working with COPS in MPLS domain. Is there any =
draft/references specially for LDP+COPS something like =
cops-usage-with-ldp.=20
Thanx.

santosh

------=_NextPart_000_0019_01BFDAB6.21215980
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I am integrating LDP =
working=20
with COPS in MPLS domain. Is there any draft/references specially for =
LDP+COPS=20
something like cops-usage-with-ldp. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanx.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>santosh</FONT></DIV></BODY></HTML>

------=_NextPart_000_0019_01BFDAB6.21215980--



From owner-mpls@UU.NET  Tue Jun 20 07:30:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17336
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 07:30:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiujt06212;
	Tue, 20 Jun 2000 11:20:56 GMT
Received: by mail-control.mail.uu.net 
	id QQiujt00306
	for mpls-outgoing; Tue, 20 Jun 2000 11:20:25 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiujt00288
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 11:20:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiujt18434
	for <mpls@uu.net>; Tue, 20 Jun 2000 07:20:05 -0400 (EDT)
From: kong.yong@mail.zte.com.cn
Received: from mail.zhongxing.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.103.147.133])
	id QQiujt08645
	for <mpls@uu.net>; Tue, 20 Jun 2000 11:18:14 GMT
Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 48256904.003E25A4 ; Tue, 20 Jun 2000 19:18:48 +0800
X-Lotus-FromDomain: ZTE_LTD
To: mpls@UU.NET
Message-ID: <48256904.003D8A61.00@mail.zhongxing.com>
Date: Tue, 20 Jun 2000 19:12:11 +0800
Sender: owner-mpls@UU.NET
Precedence: bulk




 FILE /internet-drafts/draft-ietf-mpls-diff-ext-04.txt




From owner-mpls@UU.NET  Tue Jun 20 07:38:09 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17549
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 07:38:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuju24434;
	Tue, 20 Jun 2000 11:36:38 GMT
Received: by mail-control.mail.uu.net 
	id QQiuju01202
	for mpls-outgoing; Tue, 20 Jun 2000 11:36:21 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuju01197
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 11:36:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuju13192
	for <mpls@uu.net>; Tue, 20 Jun 2000 07:36:04 -0400 (EDT)
From: kong.yong@mail.zte.com.cn
Received: from mail.zhongxing.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.103.147.133])
	id QQiuju14353
	for <mpls@uu.net>; Tue, 20 Jun 2000 11:35:49 GMT
Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2  (600.1 3-26-1998))  id 48256904.003E2BD7 ; Tue, 20 Jun 2000 19:19:04 +0800
X-Lotus-FromDomain: ZTE_LTD
To: mpls@UU.NET
Message-ID: <48256904.003D920A.00@mail.zhongxing.com>
Date: Tue, 20 Jun 2000 19:12:30 +0800
Sender: owner-mpls@UU.NET
Precedence: bulk




 FILE /internet-drafts/draft-ietf-mpls-diff-ext-05.txt




From owner-mpls@UU.NET  Tue Jun 20 08:02:00 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18353
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 08:02:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiujw28528;
	Tue, 20 Jun 2000 12:00:18 GMT
Received: by mail-control.mail.uu.net 
	id QQiujv02411
	for mpls-outgoing; Tue, 20 Jun 2000 11:59:42 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiujv02405
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 11:59:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiujv22451
	for <mpls@UU.NET>; Tue, 20 Jun 2000 07:58:55 -0400 (EDT)
Received: from mantrafive.mantranets.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mantra62.erols.com [209.122.107.62])
	id QQiujv27498
	for <mpls@UU.NET>; Tue, 20 Jun 2000 11:58:55 GMT
Received: from vjosyula ([209.122.107.2]) by mantrafive.mantranets.com
          (Post.Office MTA v3.1 release PO205e ID# 572-47850U100L2S100)
          with SMTP id AAA147; Tue, 20 Jun 2000 07:59:49 -0400
Message-ID: <001701bfdaae$b8e14940$4400a8c0@mantranet.com>
From: vjosyula@mantranet.com (Venu Josyula)
To: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>, <mpls@UU.NET>
References: <002101bfda88$38062f00$100d85a5@dti.daewoo.co.kr>
Subject: Re: LDP + COPS
Date: Tue, 20 Jun 2000 07:57:34 -0400
Organization: Mantra
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0014_01BFDA8D.31B73F40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01BFDA8D.31B73F40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As per my knowledge, there is no documentations for LDP+COPS but you can =
refer the internet daraft on LDP for implementation details.

venu

  ----- Original Message -----=20
  From: Santosh Gupta=20
  To: mpls@UU.NET=20
  Sent: Tuesday, June 20, 2000 3:20 AM
  Subject: LDP + COPS


  Hello
      I am integrating LDP working with COPS in MPLS domain. Is there =
any draft/references specially for LDP+COPS something like =
cops-usage-with-ldp.=20
  Thanx.

  santosh

------=_NextPart_000_0014_01BFDA8D.31B73F40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>As per my knowledge, there is no =
documentations for=20
LDP+COPS but you can refer the internet daraft on LDP for implementation =

details.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>venu</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:santoshg@daewoo.dti.daewoo.co.kr"=20
  title=3Dsantoshg@daewoo.dti.daewoo.co.kr>Santosh Gupta</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:mpls@UU.NET"=20
  title=3Dmpls@UU.NET>mpls@UU.NET</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, June 20, 2000 =
3:20=20
AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> LDP + COPS</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>Hello</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I am integrating =
LDP working=20
  with COPS in MPLS domain. Is there any draft/references specially for =
LDP+COPS=20
  something like cops-usage-with-ldp. </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Thanx.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial =
size=3D2>santosh</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0014_01BFDA8D.31B73F40--



From owner-mpls@UU.NET  Tue Jun 20 09:17:52 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20981
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 09:17:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiukb00825;
	Tue, 20 Jun 2000 13:16:06 GMT
Received: by mail-control.mail.uu.net 
	id QQiukb28954
	for mpls-outgoing; Tue, 20 Jun 2000 13:15:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiukb28945
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 13:15:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiukb28448
	for <mpls@UU.NET>; Tue, 20 Jun 2000 09:15:20 -0400 (EDT)
Received: from bmailnj.iphighway.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.89.157.130])
	id QQiukb00212
	for <mpls@UU.NET>; Tue, 20 Jun 2000 13:15:19 GMT
Received: by BMAILNJ with Internet Mail Service (5.5.2650.21)
	id <L1GT54D0>; Tue, 20 Jun 2000 09:10:24 -0400
Message-ID: <6399122981E1D211AB490090271E0AA33C9EC1@BMAILNJ>
From: "Francis Reichmeyer (IPHighway MA)" <FranR@iphighway.com>
To: "'Santosh Gupta '" <santoshg@daewoo.dti.daewoo.co.kr>,
        "'mpls@UU.NET '"
	 <mpls@UU.NET>
Subject: RE: LDP + COPS
Date: Tue, 20 Jun 2000 09:10:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

There is some interest in cops-mpls for use with traffic
engineering. A couple initial I-Ds on this are:

draft- wright-policy-mpls-00.txt
draft-wright-mpls-te-policy-00.txt

Soon (i.e. before the Pittsburgh meeting) there will be a 
cops usage with mpls/traffic engineering draft available as well.

Thanks,
-Fran

-----Original Message-----
From: Santosh Gupta
To: mpls@UU.NET
Sent: 06/20/2000 3:20 AM
Subject: LDP + COPS

Hello
    I am integrating LDP working with COPS in MPLS domain. Is there any
draft/references specially for LDP+COPS something like
cops-usage-with-ldp. 
Thanx.
 
santosh


From owner-mpls@UU.NET  Tue Jun 20 11:14:23 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25591
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 11:14:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuki23950;
	Tue, 20 Jun 2000 15:12:39 GMT
Received: by mail-control.mail.uu.net 
	id QQiuki01420
	for mpls-outgoing; Tue, 20 Jun 2000 15:12:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuki01415
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 15:12:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuki26829
	for <mpls@UU.NET>; Tue, 20 Jun 2000 11:11:52 -0400 (EDT)
Received: from mailhost.metro-optix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.metro-optix.com [63.91.47.254])
	id QQiuki19711
	for <mpls@UU.NET>; Tue, 20 Jun 2000 15:11:52 GMT
Received: by MAILHOST with Internet Mail Service (5.5.2650.21)
	id <N2XMHQM7>; Tue, 20 Jun 2000 10:12:36 -0500
Message-ID: <D7F6115661E9D311834F006008F5C83C096403@MAILHOST>
From: David Wang <david.wang@metro-optix.com>
To: mpls@UU.NET
Subject: IS-IS TE extension document
Date: Tue, 20 Jun 2000 10:12:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


The "ISIS Extensions for Traffic Engineering",
draft-ietf-isis-traffic-02.txt has expired and has been deleted from the
IETF draft-directory. But I still need to find some information from that
document. Can somebody send me a copy or point me a place where I can
download the document.

Thanks
David



From owner-mpls@UU.NET  Tue Jun 20 11:42:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26689
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 11:42:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiukk20024;
	Tue, 20 Jun 2000 15:41:23 GMT
Received: by mail-control.mail.uu.net 
	id QQiukk03886
	for mpls-outgoing; Tue, 20 Jun 2000 15:40:48 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiukk03877
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 15:40:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiukk02655
	for <mpls@uu.net>; Tue, 20 Jun 2000 11:39:56 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiukk13896
	for <mpls@uu.net>; Tue, 20 Jun 2000 15:39:55 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA05541
	for mpls@uu.net; Tue, 20 Jun 2000 11:39:54 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiukk03837
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 15:39:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiukk00047;
	Tue, 20 Jun 2000 11:38:59 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQiukk13101;
	Tue, 20 Jun 2000 15:38:59 GMT
Received: from localhost (yakov@localhost)
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA07685;
	Tue, 20 Jun 2000 08:38:58 -0700 (PDT)
Message-Id: <200006201538.IAA07685@omega.cisco.com>
To: Daniel Awduche <awduche@UU.NET>
cc: mpls@UU.NET
Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
In-reply-to: Your message of "Tue, 13 Jun 2000 15:54:14 EDT."
             <20000613155414.B1317@uu.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7683.961515538.1@cisco.com>
Date: Tue, 20 Jun 2000 08:38:58 -0700
From: Yakov Rekhter <yakov@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Dan,

> The FA concept clearly has independent interest, besides the 
> original optical application. In fact, it is needed in certain
> operational contexts today. Therefore, it's a good idea to
> document it separately, and include additional relevant details 
> not shown in draft-kompella-optical-mpls-00.txt, so that, 
> hopefully, interoperable implementations can be derived

Kireeti and myself did as we promised. The Internet Draft is
draft-kompella-lsp-hierarchy-00.txt. Kireeti and myself would like the
MPLS WG to accept this Internet Draft as an MPLS WG document.

Yakov.
> 
> Cheers,
> /Dan
> 
> On Tue, Jun 13, 2000 at 12:29:24PM -0700, Yakov Rekhter wrote:
> > Folks,
> > 
> > Given the recent e-mail exchange on the topic of hierarchical
> > tunnel establishment in RSVP-TE, and given that most (but probably
> > not all) the relevant material is covered under the notion of
> > Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
> > I wonder whether there would be any objections agains extracting
> > all the relevant material, filling the missing pieces (if any),
> > and turning the result into a MPLS WG document. 
> > 
> > Yakov.
> 



From owner-mpls@UU.NET  Tue Jun 20 12:06:14 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27466
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 12:06:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiukm00876;
	Tue, 20 Jun 2000 16:01:58 GMT
Received: by mail-control.mail.uu.net 
	id QQiukm08243
	for mpls-outgoing; Tue, 20 Jun 2000 16:01:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiukm08093
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 16:01:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiukm06813
	for <mpls@UU.NET>; Tue, 20 Jun 2000 12:00:30 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQiukm29381
	for <mpls@UU.NET>; Tue, 20 Jun 2000 16:00:29 GMT
Received: from ganeshpc (ganesh-pc.laurelnetworks.com [192.168.0.30])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id MAA10516;
	Tue, 20 Jun 2000 12:00:24 -0400
From: "Ganesh Murugesan" <ganesh@laurelnetworks.com>
To: "Yakov Rekhter" <yakov@cisco.com>, <mpls@UU.NET>
Cc: <kireeti@juniper.net>
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Tue, 20 Jun 2000 11:59:53 -0400
Message-ID: <004b01bfdad0$92604a60$8ac6fea9@laurelnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <200006162016.NAA01806@omega.cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Can you forward me a copy of this draft.

thanks
ganesh


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yakov
> Rekhter
> Sent: Friday, June 16, 2000 4:16 PM
> To: mpls@UU.NET
> Cc: kireeti@juniper.net
> Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
> 
> 
> Folks,
> 
> > Given the recent e-mail exchange on the topic of hierarchical
> > tunnel establishment in RSVP-TE, and given that most (but probably
> > not all) the relevant material is covered under the notion of
> > Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
> > I wonder whether there would be any objections agains extracting
> > all the relevant material, filling the missing pieces (if any),
> > and turning the result into a MPLS WG document.
> 
> Kireeti and myself just submitted an Internet Draft on this.
> If you can't wait until the Draft will appear in the IETF
> server, drop me an e-mail and I'll send you a copy.
> 
> Yakov.
> 


From owner-mpls@UU.NET  Tue Jun 20 12:47:07 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28515
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 12:47:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuko14909;
	Tue, 20 Jun 2000 16:41:27 GMT
Received: by mail-control.mail.uu.net 
	id QQiuko19925
	for mpls-outgoing; Tue, 20 Jun 2000 16:41:04 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuko19912
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 16:41:02 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuko13353
	for <mpls@UU.NET>; Tue, 20 Jun 2000 12:40:59 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQiuko00288
	for <mpls@UU.NET>; Tue, 20 Jun 2000 16:40:58 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCC0NH>; Tue, 20 Jun 2000 09:47:14 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6626907C2@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Ganesh Murugesan'" <ganesh@laurelnetworks.com>,
        Yakov Rekhter
	 <yakov@cisco.com>, mpls@UU.NET
Cc: kireeti@juniper.net
Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
Date: Tue, 20 Jun 2000 09:47:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Ganesh,

	It's at

http://www.ietf.org/internet-drafts/draft-kompella-lsp-hierarchy-00.txt

--
Eric Gray

> -----Original Message-----
> From: Ganesh Murugesan [mailto:ganesh@laurelnetworks.com]
> Sent: Tuesday, June 20, 2000 9:00 AM
> To: Yakov Rekhter; mpls@UU.NET
> Cc: kireeti@juniper.net
> Subject: RE: Hierarchical Tunnel Establishment in RSVP-TE 
> 
> 
> Hi,
> 
> Can you forward me a copy of this draft.
> 
> thanks
> ganesh
> 
> 
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yakov
> > Rekhter
> > Sent: Friday, June 16, 2000 4:16 PM
> > To: mpls@UU.NET
> > Cc: kireeti@juniper.net
> > Subject: Re: Hierarchical Tunnel Establishment in RSVP-TE 
> > 
> > 
> > Folks,
> > 
> > > Given the recent e-mail exchange on the topic of hierarchical
> > > tunnel establishment in RSVP-TE, and given that most (but probably
> > > not all) the relevant material is covered under the notion of
> > > Forwarding Adjacencies in draft-kompella-optical-mpls-00.txt,
> > > I wonder whether there would be any objections agains extracting
> > > all the relevant material, filling the missing pieces (if any),
> > > and turning the result into a MPLS WG document.
> > 
> > Kireeti and myself just submitted an Internet Draft on this.
> > If you can't wait until the Draft will appear in the IETF
> > server, drop me an e-mail and I'll send you a copy.
> > 
> > Yakov.
> > 
> 


From owner-mpls@UU.NET  Tue Jun 20 13:02:47 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29385
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 13:02:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiukq18186;
	Tue, 20 Jun 2000 17:00:48 GMT
Received: by mail-control.mail.uu.net 
	id QQiukq23775
	for mpls-outgoing; Tue, 20 Jun 2000 17:00:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiukq23291
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 17:00:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiukq17061
	for <mpls@UU.NET>; Tue, 20 Jun 2000 13:00:02 -0400 (EDT)
Received: from mail.krioukov.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cj114416-a.reston1.va.home.com [24.15.191.36])
	id QQiukq28645
	for <mpls@UU.NET>; Tue, 20 Jun 2000 17:00:02 GMT
Received: from VA1ENG128 (fw-1.winstar.com [207.86.108.130])
	by mail.krioukov.net (8.9.3/8.9.3) with SMTP id MAA07420;
	Tue, 20 Jun 2000 12:43:54 -0400
From: "Dmitri Krioukov" <dima@krioukov.net>
To: "Hideo Ishii" <Hideo.Ishii@globalone.net>
Cc: <mpls@UU.NET>
Subject: RE: New MPLS implementation for Linux
Date: Tue, 20 Jun 2000 13:14:46 -0400
Message-ID: <NCBBIKACLKNMKDHKKKNFMEKJELAA.dima@krioukov.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-2022-JP"
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <4.2.0.58.J.20000620143459.03bbd450@160.81.176.100>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

i based my statement on phrase "we have the ldp that works"
in http://tania.be.linux.org/zebra/msg00835.html, but
now i know that they were looking at the wisconsin code
reuse and later on the decision was made to implement
ldp independently (which is not done yet).

thanks,
--
dima.

> -----Original Message-----
> From: Hideo Ishii [mailto:Hideo.Ishii@globalone.net]
> Sent: Tuesday, June 20, 2000 1:36 AM
> To: Dmitri Krioukov
> Cc: mpls@UU.NET
> Subject: RE: New MPLS implementation for Linux
>
>
> Zebra doesn't have LDP function yet, as far as I know.
> But zebra will be implemented LDP, I guess.:-)
>
> --
> Hideo Ishii
> Global One Japan
>
> At $B8a8e(B 07:20 00/06/19 -0400, Dmitri Krioukov wrote:
> >have you tried to work with the zebra
> >group? they already have ldp in place.
> >i don't think they have hierarchical
> >tunnels.
> >--
> >dima.
> >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Keir
> > > Fraser
> > > Sent: Saturday, June 17, 2000 11:08 AM
> > > To: mpls@UU.NET
> > > Cc: Keir.Fraser@cl.cam.ac.uk
> > > Subject: New MPLS implementation for Linux
> > >
> > >
> > > This is just to announce that I have released a new implementation of
> > > MPLS for Linux 2.3. Note that this is NOT related to the existing
> > > implementation by Jim Leu at University of Wisconsin.
> > >
> > > It can be found at:
> > >
http://www.cl.cam.ac.uk/Research/SRG/netos/netx/code/mpls-current.tar.gz
> >
> >
> > Advantages of the new implementation
> > ------------------------------------
> >  * The Linux traffic classification architecture can be used to
> >    implement differentiated forwarding for different LSPs. This is
> >    documented further in the distribution.
> >
> >  * We use the existing Linux routing code to map packets to LSPs. This
> >    can allow greater flexibility in specifying FECs than just
destination
> >    subnet.
> >
> >  * The switching code is implemented quite efficiently and hooks
> >    cleanly into the Linux networking architecture. This was a _big_
> >    weakness in early versions of the Wisconsin implementation, which
> >    prompted me to write my own version in the first place. (However,
> >    new versions appear to have been massively reworked: this may not
> >    be a problem any more).
> >
> >  * The whole thing is written cleanly and could be extended quite
> >    easily (I think! :-)
> >
> >
> > Disadvantages
> > -------------
> >  * This isn't an LDP implementation. All we needed for our own work
> >    was the switching plane.
> >
> >  * No label pushing/popping.
> >
> >  * Only support for IPv4 tunnelling at present (more could be added
> >    quite easily).
> >
> >  * I only supply a patch for linux 2.3.99-pre5. However, porting to
> >    other recent versions of the kernel shouldn't be a big task.
> >
> >
> > Feel free to contact me if you have any questions or problems!
> >
> >  -- Keir Fraser
> >     (Systems Research Group, University of Cambridge)



From owner-mpls@UU.NET  Tue Jun 20 14:58:56 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01644
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 14:58:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiukx11295;
	Tue, 20 Jun 2000 18:52:55 GMT
Received: by mail-control.mail.uu.net 
	id QQiukx25001
	for mpls-outgoing; Tue, 20 Jun 2000 18:52:25 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiukx24996
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 18:52:10 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiukx14734
	for <mpls@UU.NET>; Tue, 20 Jun 2000 14:51:56 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQiukx00274
	for <mpls@UU.NET>; Tue, 20 Jun 2000 18:51:56 GMT
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Tue, 20 Jun 2000 13:50:27 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2WJ09H7; Tue, 20 Jun 2000 14:51:29 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2LHFQ0Z; Tue, 20 Jun 2000 14:51:27 -0400
Message-ID: <394FBD2F.E4370F2F@americasm01.nt.com>
Date: Tue, 20 Jun 2000 14:51:27 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Francois Le Faucheur <flefauch@cisco.com>
CC: mpls@UU.NET, alchiu@att.com
Subject: Re: Bandwidth reservation per PSC
References: <4.0.2.20000619104309.02157370@europe.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks Francois,

My question was indeed related to the distributed model. What I am still not sure about is how bandwidth availability within OSPF/ISIS is advertized  per PSC or per family  of TE related PSCs when the TE extensions only imply advertizement per priority. Are colors assigned to different PSCs or families of TE related PSCs and bandwidth availability advertized per color?.

Thanks,

Darek


Francois Le Faucheur wrote:

> Darek,
>
> At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
> >Hi,
> >
> >I have a question with regard to bandwidth availability per PSC and TE
> >extensions to OSPF/ISIS.
> >
> >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2
> >about constraint based routing being
> >performed separately for each PSC  where one of the constraints is
> >availability of bandwidth from the bandwidth
> >allocated to the relevant PSC.
> >
> >My question is how TE extensions to OSPF/ISIS support advertizing
> >bandwidth availability per PSC. The only way I can
> >think this can be achieved is by assigning different colors/resource
> >classes to different PSCs thus advertizing bandwidth
> >availability per PSC simply as bandwidth availability per color/resource
> >class. Is this correct?.
> >
> >If it is correct then how serious is the scaling/operational issue at
> >least within OSPF since N  TE LSAs are needed for  N
> >PSCs  for every link, implying lots of LSA traffic not to mention
> >storage within LSDB (which I gather can only store
> >65536 TE LSAs).
> >
>
> First, of course , in some environments, Constraint Based Routing may be performed "off-line"/"in a Centralised Manner". In these situations, per-PSC bandwidth availability can be determined by the centralised tool without relying on extensions to OSPF/ISIS.
>
> Where Constraint Based Routing is performed "on-line"/"in a Distributed Manner", then yes, OSPF/ISIS are required to propagate all necessary bandwidth information. This could be achieved in a number of ways:
>         - one approach would be to advertise bandwidth information for every PSC. As you are pointing out above, this may lead to scaling/operational issues earlier than desired.
>         - another approach would be to advertise bandwidth information only for each "family/class" of PSCs. A family/class of PSC would comprise all the PSCs which share the same bandwidth constraints. It is likely that multiple PSCs can share the same bandwidth constraints (eg "max-reservable-bandwidth"). For instance, multiple Premium/Non-real-time PSCs may share the same "max-reservable-bandwidth". In that case, you have traded a little bit of fine-grain control (you can't enforce bandwidth constraints which are different for absolutely every PSC), but you have significantly gained in scalability of OSPF/ISIS by "only" advertising 2/3 available bandwidth information.
>
> You will find some text on the second approach in section "6.7 Traffic Engineering in Diffserv Environments" of <draft-ietf-tewg-framework-01.txt>:
>
>    "Instead of having per-class parameters being configured and
>    propagated on each LSR interface, per-class parameters can be
>    aggregated into per-class-type parameters. The main motivation for
>    grouping a set of classes into a class-type is to improve the
>    scalability of IGP link state advertisements by propagating
>    information on a per-class-type basis instead of on a per-class
>    basis, and also to allow better bandwidth sharing between  classes in
>    the same class-type..."
>
> Francois
>
> >Thanks,
> >
> >Darek Skalecki
> >Nortel Networks
> >
>
> _________________________________________________________________
> Francois Le Faucheur
> Development Engineer, IOS Layer 3 Services
> Cisco Systems
> Office Phone:           +33 4 92 96 75 64
> Home Office Phone:     +33 4 92 94 00 78
> Mobile :               +33 6 89 108 159
> Vmail:                 +33 1 58 04 62 66
> Fax:                   +33 4 92 96 79 08
> Email:                  flefauch@cisco.com
> _________________________________________________________________
> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
> _________________________________________________________________



From owner-mpls@UU.NET  Tue Jun 20 15:09:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01826
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 15:09:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuky13161;
	Tue, 20 Jun 2000 19:07:35 GMT
Received: by mail-control.mail.uu.net 
	id QQiuky06660
	for mpls-outgoing; Tue, 20 Jun 2000 19:07:10 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuky06640
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 19:07:03 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuky16215
	for <mpls@UU.NET>; Tue, 20 Jun 2000 15:06:39 -0400 (EDT)
Received: from mail-green.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103])
	id QQiuky12401
	for <mpls@UU.NET>; Tue, 20 Jun 2000 19:06:39 GMT
Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 623861E00F; Tue, 20 Jun 2000 15:06:35 -0400 (EDT)
Received: from pcalchiu (pclopez [135.207.131.94])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA13239;
	Tue, 20 Jun 2000 15:05:29 -0400 (EDT)
Reply-To: <alchiu@research.att.com>
From: "Angela Chiu" <alchiu@research.att.com>
To: "'Darek Skalecki'" <dareks@nortelnetworks.com>
Cc: <mpls@UU.NET>, "'Francois Le Faucheur'" <flefauch@cisco.com>
Subject: RE: Bandwidth reservation per PSC
Date: Tue, 20 Jun 2000 15:06:41 -0400
Message-ID: <007d01bfdaea$ac1f5440$5e83cf87@pcalchiu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <394FBD2F.E4370F2F@americasm01.nt.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Darek,

These are additional requirements for IGP extensions, as stated in TE
Framework draft
http://www.ietf.org/internet-drafts/draft-ietf-tewg-framework-01.txt
"In order to perform constraint-based routing on a per-class basis for LSPs,
the conventional IGPs (e.g., IS-IS and OSPF) should provide extensions to
propagate per-class resource information."
Then the draft states that "per-class parameters can be aggregated into
per-class-type parameters" for scalability improvements.

Regards,

Angela

-----Original Message-----
From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
Sent: Tuesday, June 20, 2000 2:51 PM
To: Francois Le Faucheur
Cc: mpls@UU.NET; alchiu@att.com
Subject: Re: Bandwidth reservation per PSC


Thanks Francois,

My question was indeed related to the distributed model. What I am still not
sure about is how bandwidth availability within OSPF/ISIS is advertized  per
PSC or per family  of TE related PSCs when the TE extensions only imply
advertizement per priority. Are colors assigned to different PSCs or
families of TE related PSCs and bandwidth availability advertized per
color?.

Thanks,

Darek


Francois Le Faucheur wrote:

> Darek,
>
> At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
> >Hi,
> >
> >I have a question with regard to bandwidth availability per PSC and TE
> >extensions to OSPF/ISIS.
> >
> >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2
> >about constraint based routing being
> >performed separately for each PSC  where one of the constraints is
> >availability of bandwidth from the bandwidth
> >allocated to the relevant PSC.
> >
> >My question is how TE extensions to OSPF/ISIS support advertizing
> >bandwidth availability per PSC. The only way I can
> >think this can be achieved is by assigning different colors/resource
> >classes to different PSCs thus advertizing bandwidth
> >availability per PSC simply as bandwidth availability per color/resource
> >class. Is this correct?.
> >
> >If it is correct then how serious is the scaling/operational issue at
> >least within OSPF since N  TE LSAs are needed for  N
> >PSCs  for every link, implying lots of LSA traffic not to mention
> >storage within LSDB (which I gather can only store
> >65536 TE LSAs).
> >
>
> First, of course , in some environments, Constraint Based Routing may be
performed "off-line"/"in a Centralised Manner". In these situations, per-PSC
bandwidth availability can be determined by the centralised tool without
relying on extensions to OSPF/ISIS.
>
> Where Constraint Based Routing is performed "on-line"/"in a Distributed
Manner", then yes, OSPF/ISIS are required to propagate all necessary
bandwidth information. This could be achieved in a number of ways:
>         - one approach would be to advertise bandwidth information for
every PSC. As you are pointing out above, this may lead to
scaling/operational issues earlier than desired.
>         - another approach would be to advertise bandwidth information
only for each "family/class" of PSCs. A family/class of PSC would comprise
all the PSCs which share the same bandwidth constraints. It is likely that
multiple PSCs can share the same bandwidth constraints (eg
"max-reservable-bandwidth"). For instance, multiple Premium/Non-real-time
PSCs may share the same "max-reservable-bandwidth". In that case, you have
traded a little bit of fine-grain control (you can't enforce bandwidth
constraints which are different for absolutely every PSC), but you have
significantly gained in scalability of OSPF/ISIS by "only" advertising 2/3
available bandwidth information.
>
> You will find some text on the second approach in section "6.7 Traffic
Engineering in Diffserv Environments" of <draft-ietf-tewg-framework-01.txt>:
>
>    "Instead of having per-class parameters being configured and
>    propagated on each LSR interface, per-class parameters can be
>    aggregated into per-class-type parameters. The main motivation for
>    grouping a set of classes into a class-type is to improve the
>    scalability of IGP link state advertisements by propagating
>    information on a per-class-type basis instead of on a per-class
>    basis, and also to allow better bandwidth sharing between  classes in
>    the same class-type..."
>
> Francois
>
> >Thanks,
> >
> >Darek Skalecki
> >Nortel Networks
> >
>
> _________________________________________________________________
> Francois Le Faucheur
> Development Engineer, IOS Layer 3 Services
> Cisco Systems
> Office Phone:           +33 4 92 96 75 64
> Home Office Phone:     +33 4 92 94 00 78
> Mobile :               +33 6 89 108 159
> Vmail:                 +33 1 58 04 62 66
> Fax:                   +33 4 92 96 79 08
> Email:                  flefauch@cisco.com
> _________________________________________________________________
> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
> _________________________________________________________________




From owner-mpls@UU.NET  Tue Jun 20 16:15:30 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03171
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 16:15:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiulc09105;
	Tue, 20 Jun 2000 20:12:51 GMT
Received: by mail-control.mail.uu.net 
	id QQiulc24243
	for mpls-outgoing; Tue, 20 Jun 2000 20:12:29 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiulc24238
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 20:12:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiulc03240
	for <mpls@UU.NET>; Tue, 20 Jun 2000 16:10:55 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQiulc06859
	for <mpls@UU.NET>; Tue, 20 Jun 2000 20:10:54 GMT
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by ertpg14e1.nortelnetworks.com; Tue, 20 Jun 2000 16:07:50 -0400
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2WKAKSM; Tue, 20 Jun 2000 16:06:06 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2LHFSA0; Tue, 20 Jun 2000 16:06:04 -0400
Message-ID: <394FCEAC.49196180@americasm01.nt.com>
Date: Tue, 20 Jun 2000 16:06:05 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: alchiu <alchiu@research.att.com>
CC: mpls <mpls@UU.NET>, "'Francois Le Faucheur'" <flefauch@cisco.com>
Subject: Re: Bandwidth reservation per PSC
References: <007d01bfdaea$ac1f5440$5e83cf87@pcalchiu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks Angela,

Are these extensions currently defined for OSPF and ISIS?. If yes then please
provide me with a reference, and if not then is anyone working on them ?. I can
only find extensions related to advertizing bandwidth availability per priority
not resource class.

Thanks,

Darek


Angela Chiu wrote:

> Darek,
>
> These are additional requirements for IGP extensions, as stated in TE
> Framework draft
> http://www.ietf.org/internet-drafts/draft-ietf-tewg-framework-01.txt
> "In order to perform constraint-based routing on a per-class basis for LSPs,
> the conventional IGPs (e.g., IS-IS and OSPF) should provide extensions to
> propagate per-class resource information."
> Then the draft states that "per-class parameters can be aggregated into
> per-class-type parameters" for scalability improvements.
>
> Regards,
>
> Angela
>
> -----Original Message-----
> From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
> Sent: Tuesday, June 20, 2000 2:51 PM
> To: Francois Le Faucheur
> Cc: mpls@UU.NET; alchiu@att.com
> Subject: Re: Bandwidth reservation per PSC
>
> Thanks Francois,
>
> My question was indeed related to the distributed model. What I am still not
> sure about is how bandwidth availability within OSPF/ISIS is advertized  per
> PSC or per family  of TE related PSCs when the TE extensions only imply
> advertizement per priority. Are colors assigned to different PSCs or
> families of TE related PSCs and bandwidth availability advertized per
> color?.
>
> Thanks,
>
> Darek
>
> Francois Le Faucheur wrote:
>
> > Darek,
> >
> > At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
> > >Hi,
> > >
> > >I have a question with regard to bandwidth availability per PSC and TE
> > >extensions to OSPF/ISIS.
> > >
> > >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2
> > >about constraint based routing being
> > >performed separately for each PSC  where one of the constraints is
> > >availability of bandwidth from the bandwidth
> > >allocated to the relevant PSC.
> > >
> > >My question is how TE extensions to OSPF/ISIS support advertizing
> > >bandwidth availability per PSC. The only way I can
> > >think this can be achieved is by assigning different colors/resource
> > >classes to different PSCs thus advertizing bandwidth
> > >availability per PSC simply as bandwidth availability per color/resource
> > >class. Is this correct?.
> > >
> > >If it is correct then how serious is the scaling/operational issue at
> > >least within OSPF since N  TE LSAs are needed for  N
> > >PSCs  for every link, implying lots of LSA traffic not to mention
> > >storage within LSDB (which I gather can only store
> > >65536 TE LSAs).
> > >
> >
> > First, of course , in some environments, Constraint Based Routing may be
> performed "off-line"/"in a Centralised Manner". In these situations, per-PSC
> bandwidth availability can be determined by the centralised tool without
> relying on extensions to OSPF/ISIS.
> >
> > Where Constraint Based Routing is performed "on-line"/"in a Distributed
> Manner", then yes, OSPF/ISIS are required to propagate all necessary
> bandwidth information. This could be achieved in a number of ways:
> >         - one approach would be to advertise bandwidth information for
> every PSC. As you are pointing out above, this may lead to
> scaling/operational issues earlier than desired.
> >         - another approach would be to advertise bandwidth information
> only for each "family/class" of PSCs. A family/class of PSC would comprise
> all the PSCs which share the same bandwidth constraints. It is likely that
> multiple PSCs can share the same bandwidth constraints (eg
> "max-reservable-bandwidth"). For instance, multiple Premium/Non-real-time
> PSCs may share the same "max-reservable-bandwidth". In that case, you have
> traded a little bit of fine-grain control (you can't enforce bandwidth
> constraints which are different for absolutely every PSC), but you have
> significantly gained in scalability of OSPF/ISIS by "only" advertising 2/3
> available bandwidth information.
> >
> > You will find some text on the second approach in section "6.7 Traffic
> Engineering in Diffserv Environments" of <draft-ietf-tewg-framework-01.txt>:
> >
> >    "Instead of having per-class parameters being configured and
> >    propagated on each LSR interface, per-class parameters can be
> >    aggregated into per-class-type parameters. The main motivation for
> >    grouping a set of classes into a class-type is to improve the
> >    scalability of IGP link state advertisements by propagating
> >    information on a per-class-type basis instead of on a per-class
> >    basis, and also to allow better bandwidth sharing between  classes in
> >    the same class-type..."
> >
> > Francois
> >
> > >Thanks,
> > >
> > >Darek Skalecki
> > >Nortel Networks
> > >
> >
> > _________________________________________________________________
> > Francois Le Faucheur
> > Development Engineer, IOS Layer 3 Services
> > Cisco Systems
> > Office Phone:           +33 4 92 96 75 64
> > Home Office Phone:     +33 4 92 94 00 78
> > Mobile :               +33 6 89 108 159
> > Vmail:                 +33 1 58 04 62 66
> > Fax:                   +33 4 92 96 79 08
> > Email:                  flefauch@cisco.com
> > _________________________________________________________________
> > Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
> > _________________________________________________________________



From owner-mpls@UU.NET  Tue Jun 20 17:44:00 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05088
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 17:44:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuli26693;
	Tue, 20 Jun 2000 21:42:32 GMT
Received: by mail-control.mail.uu.net 
	id QQiuli14023
	for mpls-outgoing; Tue, 20 Jun 2000 21:41:56 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuli14018
	for <mpls@mail-control.mail.uu.net>; Tue, 20 Jun 2000 21:41:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuli25174
	for <mpls@UU.NET>; Tue, 20 Jun 2000 17:41:36 -0400 (EDT)
Received: from mail-green.research.att.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103])
	id QQiuli25935
	for <mpls@UU.NET>; Tue, 20 Jun 2000 21:41:35 GMT
Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 85A851E01F; Tue, 20 Jun 2000 17:41:35 -0400 (EDT)
Received: from pcalchiu (pclopez [135.207.131.94])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id RAA20085;
	Tue, 20 Jun 2000 17:40:29 -0400 (EDT)
Reply-To: <alchiu@research.att.com>
From: "Angela Chiu" <alchiu@research.att.com>
To: "'Darek Skalecki'" <dareks@nortelnetworks.com>
Cc: "'mpls'" <mpls@UU.NET>, "'Francois Le Faucheur'" <flefauch@cisco.com>
Subject: RE: Bandwidth reservation per PSC
Date: Tue, 20 Jun 2000 17:41:43 -0400
Message-ID: <008601bfdb00$5454a6a0$5e83cf87@pcalchiu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <394FCEAC.49196180@americasm01.nt.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Darek,

I don't think it is currently included in the OSPF and ISIS TE extensions. I
am not aware of anyone who is working on it. But I could be wrong since
there are so many activities around MPLS, hard to keep track of all of them.

Angela

-----Original Message-----
From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
Sent: Tuesday, June 20, 2000 4:06 PM
To: alchiu
Cc: mpls; 'Francois Le Faucheur'
Subject: Re: Bandwidth reservation per PSC


Thanks Angela,

Are these extensions currently defined for OSPF and ISIS?. If yes then
please
provide me with a reference, and if not then is anyone working on them ?. I
can
only find extensions related to advertizing bandwidth availability per
priority
not resource class.

Thanks,

Darek


Angela Chiu wrote:

> Darek,
>
> These are additional requirements for IGP extensions, as stated in TE
> Framework draft
> http://www.ietf.org/internet-drafts/draft-ietf-tewg-framework-01.txt
> "In order to perform constraint-based routing on a per-class basis for
LSPs,
> the conventional IGPs (e.g., IS-IS and OSPF) should provide extensions to
> propagate per-class resource information."
> Then the draft states that "per-class parameters can be aggregated into
> per-class-type parameters" for scalability improvements.
>
> Regards,
>
> Angela
>
> -----Original Message-----
> From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
> Sent: Tuesday, June 20, 2000 2:51 PM
> To: Francois Le Faucheur
> Cc: mpls@UU.NET; alchiu@att.com
> Subject: Re: Bandwidth reservation per PSC
>
> Thanks Francois,
>
> My question was indeed related to the distributed model. What I am still
not
> sure about is how bandwidth availability within OSPF/ISIS is advertized
per
> PSC or per family  of TE related PSCs when the TE extensions only imply
> advertizement per priority. Are colors assigned to different PSCs or
> families of TE related PSCs and bandwidth availability advertized per
> color?.
>
> Thanks,
>
> Darek
>
> Francois Le Faucheur wrote:
>
> > Darek,
> >
> > At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
> > >Hi,
> > >
> > >I have a question with regard to bandwidth availability per PSC and TE
> > >extensions to OSPF/ISIS.
> > >
> > >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2
> > >about constraint based routing being
> > >performed separately for each PSC  where one of the constraints is
> > >availability of bandwidth from the bandwidth
> > >allocated to the relevant PSC.
> > >
> > >My question is how TE extensions to OSPF/ISIS support advertizing
> > >bandwidth availability per PSC. The only way I can
> > >think this can be achieved is by assigning different colors/resource
> > >classes to different PSCs thus advertizing bandwidth
> > >availability per PSC simply as bandwidth availability per
color/resource
> > >class. Is this correct?.
> > >
> > >If it is correct then how serious is the scaling/operational issue at
> > >least within OSPF since N  TE LSAs are needed for  N
> > >PSCs  for every link, implying lots of LSA traffic not to mention
> > >storage within LSDB (which I gather can only store
> > >65536 TE LSAs).
> > >
> >
> > First, of course , in some environments, Constraint Based Routing may be
> performed "off-line"/"in a Centralised Manner". In these situations,
per-PSC
> bandwidth availability can be determined by the centralised tool without
> relying on extensions to OSPF/ISIS.
> >
> > Where Constraint Based Routing is performed "on-line"/"in a Distributed
> Manner", then yes, OSPF/ISIS are required to propagate all necessary
> bandwidth information. This could be achieved in a number of ways:
> >         - one approach would be to advertise bandwidth information for
> every PSC. As you are pointing out above, this may lead to
> scaling/operational issues earlier than desired.
> >         - another approach would be to advertise bandwidth information
> only for each "family/class" of PSCs. A family/class of PSC would comprise
> all the PSCs which share the same bandwidth constraints. It is likely that
> multiple PSCs can share the same bandwidth constraints (eg
> "max-reservable-bandwidth"). For instance, multiple Premium/Non-real-time
> PSCs may share the same "max-reservable-bandwidth". In that case, you have
> traded a little bit of fine-grain control (you can't enforce bandwidth
> constraints which are different for absolutely every PSC), but you have
> significantly gained in scalability of OSPF/ISIS by "only" advertising 2/3
> available bandwidth information.
> >
> > You will find some text on the second approach in section "6.7 Traffic
> Engineering in Diffserv Environments" of
<draft-ietf-tewg-framework-01.txt>:
> >
> >    "Instead of having per-class parameters being configured and
> >    propagated on each LSR interface, per-class parameters can be
> >    aggregated into per-class-type parameters. The main motivation for
> >    grouping a set of classes into a class-type is to improve the
> >    scalability of IGP link state advertisements by propagating
> >    information on a per-class-type basis instead of on a per-class
> >    basis, and also to allow better bandwidth sharing between  classes in
> >    the same class-type..."
> >
> > Francois
> >
> > >Thanks,
> > >
> > >Darek Skalecki
> > >Nortel Networks
> > >
> >
> > _________________________________________________________________
> > Francois Le Faucheur
> > Development Engineer, IOS Layer 3 Services
> > Cisco Systems
> > Office Phone:           +33 4 92 96 75 64
> > Home Office Phone:     +33 4 92 94 00 78
> > Mobile :               +33 6 89 108 159
> > Vmail:                 +33 1 58 04 62 66
> > Fax:                   +33 4 92 96 79 08
> > Email:                  flefauch@cisco.com
> > _________________________________________________________________
> > Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne -
France
> > _________________________________________________________________




From owner-mpls@UU.NET  Tue Jun 20 20:24:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06706
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 20:24:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiult21720;
	Wed, 21 Jun 2000 00:23:46 GMT
Received: by mail-control.mail.uu.net 
	id QQiult01604
	for mpls-outgoing; Wed, 21 Jun 2000 00:23:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiult01595
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 00:23:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiult13994
	for <mpls@UU.NET>; Tue, 20 Jun 2000 20:21:43 -0400 (EDT)
Received: from hotmail.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: f285.law9.hotmail.com [64.4.8.160])
	id QQiult16527
	for <mpls@UU.NET>; Wed, 21 Jun 2000 00:21:43 GMT
Received: (qmail 39818 invoked by uid 0); 21 Jun 2000 00:21:38 -0000
Message-ID: <20000621002138.39817.qmail@hotmail.com>
Received: from 24.161.114.141 by www.hotmail.com with HTTP;
	Tue, 20 Jun 2000 17:21:38 PDT
X-Originating-IP: [24.161.114.141]
From: "Mike Badil" <hasko10@hotmail.com>
To: mpls@UU.NET
Subject: TE
Date: Tue, 20 Jun 2000 20:21:38 EDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all

I just reading MPLS document, I have a question which I am not really clear 
to understand, if someone helps I will be happy.

The Question is:

What makes MPLS to support constraint based routing?
If it just adding contsraint metrics to conventional routing in order to 
support TE.
Why it is not possible without MPLS.

In other word, in conventional IP routing, if we add constraint metrics, can 
conventional IP routing support it also?

Thanks.


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From owner-mpls@UU.NET  Tue Jun 20 22:42:23 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10037
	for <mpls-archive@lists.ietf.org>; Tue, 20 Jun 2000 22:42:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiumc09528;
	Wed, 21 Jun 2000 02:41:19 GMT
Received: by mail-control.mail.uu.net 
	id QQiumc02629
	for mpls-outgoing; Wed, 21 Jun 2000 02:41:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiumc02592
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 02:40:55 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiumc00236
	for <mpls@UU.NET>; Tue, 20 Jun 2000 22:40:47 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQiumc08972
	for <mpls@UU.NET>; Wed, 21 Jun 2000 02:40:46 GMT
Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA23007
	for <mpls@UU.NET>; Tue, 20 Jun 2000 22:40:45 -0400 (EDT)
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA22997;
	Tue, 20 Jun 2000 22:40:44 -0400 (EDT)
Received: from lucent.com by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id WAA25733; Tue, 20 Jun 2000 22:40:39 -0400 (EDT)
Message-ID: <39502B24.A419C796@lucent.com>
Date: Tue, 20 Jun 2000 22:40:36 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Venu Josyula <vjosyula@mantranet.com>
CC: Santosh Gupta <santoshg@daewoo.dti.daewoo.co.kr>, mpls@UU.NET
Subject: Re: LDP + COPS
References: <002101bfda88$38062f00$100d85a5@dti.daewoo.co.kr> <001701bfdaae$b8e14940$4400a8c0@mantranet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Instead of LDP + COPS, CR-LDP + COPS makes more sense.

Yangguang


From owner-mpls@UU.NET  Wed Jun 21 01:01:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11521
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 01:01:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiumm10215;
	Wed, 21 Jun 2000 05:00:01 GMT
Received: by mail-control.mail.uu.net 
	id QQiuml01824
	for mpls-outgoing; Wed, 21 Jun 2000 04:59:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuml01819
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 04:59:26 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuml24342
	for <mpls@UU.NET>; Wed, 21 Jun 2000 00:59:17 -0400 (EDT)
Received: from mail-out.globalone.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-out.globalone.net [199.184.38.11])
	id QQiuml15520
	for <mpls@UU.NET>; Wed, 21 Jun 2000 04:59:16 GMT
Received: from master.res.globalone.net (master.res.globalone.net [192.168.75.50])
	by mail-out.globalone.net (8.8.7/8.8.5) with ESMTP id BAA23454
	for <mpls@UU.NET>; Wed, 21 Jun 2000 01:00:59 -0400
Received: from master.hok.globalone.net (root@master.hok.globalone.net [160.81.187.23])
	by master.res.globalone.net (8.8.7/8.8.5) with ESMTP id AAA28764
	for <mpls@UU.NET>; Wed, 21 Jun 2000 00:58:42 -0400
Received: from mail.tok.globalone.net (mail.tok.globalone.net [160.81.176.100])
	by master.hok.globalone.net (8.8.7/8.8.5) with ESMTP id MAA23915
	for <mpls@UU.NET>; Wed, 21 Jun 2000 12:58:58 +0800
Received: from hishii ([160.81.177.100]) by mail.tok.globalone.net
          (Netscape Messaging Server 3.62)  with ESMTP id 190;
          Wed, 21 Jun 2000 14:01:31 +0900
Message-Id: <4.2.0.58.J.20000621134351.02f6ada0@160.81.176.100>
X-Sender: hideo.ishii@160.81.176.100
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Wed, 21 Jun 2000 13:57:28 +0900
To: "Dmitri Krioukov" <dima@krioukov.net>
From: "Hideo Ishii" <Hideo.Ishii@globalone.net>
Subject: RE: New MPLS implementation for Linux
Cc: mpls@UU.NET
In-Reply-To: <NCBBIKACLKNMKDHKKKNFMEKJELAA.dima@krioukov.net>
References: <4.2.0.58.J.20000620143459.03bbd450@160.81.176.100>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I talked with zebra's developer about LDP implementation before.
but I am not sure about what's going on now.
Anyway, a start,our requirement for zebra is MPLS BGP-RR, in terms of zebra
will be able to handle the Huge Routing table with RD by many CE-PE routing 
instance.

Regards,
Hideo

---
Hideo Ishii
IP Engineering , GlobalOne Japan
---



At $B8a8e(B 01:14 00/06/20 -0400, you wrote:
>i based my statement on phrase "we have the ldp that works"
>in http://tania.be.linux.org/zebra/msg00835.html, but
>now i know that they were looking at the wisconsin code
>reuse and later on the decision was made to implement
>ldp independently (which is not done yet).
>
>thanks,
>--
>dima.
>
> > -----Original Message-----
> > From: Hideo Ishii [mailto:Hideo.Ishii@globalone.net]
> > Sent: Tuesday, June 20, 2000 1:36 AM
> > To: Dmitri Krioukov
> > Cc: mpls@UU.NET
> > Subject: RE: New MPLS implementation for Linux
> >
> >
> > Zebra doesn't have LDP function yet, as far as I know.
> > But zebra will be implemented LDP, I guess.:-)
> >
> > --
> > Hideo Ishii
> > Global One Japan
> >
> > At $B8a8e(B 07:20 00/06/19 -0400, Dmitri Krioukov wrote:
> > >have you tried to work with the zebra
> > >group? they already have ldp in place.
> > >i don't think they have hierarchical
> > >tunnels.
> > >--
> > >dima.
> > >
> > > > -----Original Message-----
> > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Keir
> > > > Fraser
> > > > Sent: Saturday, June 17, 2000 11:08 AM
> > > > To: mpls@UU.NET
> > > > Cc: Keir.Fraser@cl.cam.ac.uk
> > > > Subject: New MPLS implementation for Linux
> > > >
> > > >
> > > > This is just to announce that I have released a new implementation of
> > > > MPLS for Linux 2.3. Note that this is NOT related to the existing
> > > > implementation by Jim Leu at University of Wisconsin.
> > > >
> > > > It can be found at:
> > > >
>http://www.cl.cam.ac.uk/Research/SRG/netos/netx/code/mpls-current.tar.gz
> > >
> > >
> > > Advantages of the new implementation
> > > ------------------------------------
> > >  * The Linux traffic classification architecture can be used to
> > >    implement differentiated forwarding for different LSPs. This is
> > >    documented further in the distribution.
> > >
> > >  * We use the existing Linux routing code to map packets to LSPs. This
> > >    can allow greater flexibility in specifying FECs than just
>destination
> > >    subnet.
> > >
> > >  * The switching code is implemented quite efficiently and hooks
> > >    cleanly into the Linux networking architecture. This was a _big_
> > >    weakness in early versions of the Wisconsin implementation, which
> > >    prompted me to write my own version in the first place. (However,
> > >    new versions appear to have been massively reworked: this may not
> > >    be a problem any more).
> > >
> > >  * The whole thing is written cleanly and could be extended quite
> > >    easily (I think! :-)
> > >
> > >
> > > Disadvantages
> > > -------------
> > >  * This isn't an LDP implementation. All we needed for our own work
> > >    was the switching plane.
> > >
> > >  * No label pushing/popping.
> > >
> > >  * Only support for IPv4 tunnelling at present (more could be added
> > >    quite easily).
> > >
> > >  * I only supply a patch for linux 2.3.99-pre5. However, porting to
> > >    other recent versions of the kernel shouldn't be a big task.
> > >
> > >
> > > Feel free to contact me if you have any questions or problems!
> > >
> > >  -- Keir Fraser
> > >     (Systems Research Group, University of Cambridge)




From owner-mpls@UU.NET  Wed Jun 21 01:47:58 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16992
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 01:47:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiump16136;
	Wed, 21 Jun 2000 05:46:34 GMT
Received: by mail-control.mail.uu.net 
	id QQiump15650
	for mpls-outgoing; Wed, 21 Jun 2000 05:46:10 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiump15570
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 05:45:59 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiump29562
	for <mpls@UU.NET>; Wed, 21 Jun 2000 01:45:50 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQiumo14963
	for <mpls@UU.NET>; Wed, 21 Jun 2000 05:44:56 GMT
Received: from santosh (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id LAA28748
	for <mpls@UU.NET>; Wed, 21 Jun 2000 11:06:24 -0600 (GMT)
Message-ID: <010001bfdb43$618410c0$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshgupta@poboxes.com>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: LDP MIB
Date: Wed, 21 Jun 2000 11:11:41 +0530
Organization: Daewoo Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00FD_01BFDB71.7ABDA6E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00FD_01BFDB71.7ABDA6E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello=20
    I have  a few doubts regarding draft-ietf-mpls-ldp-mib-05. Could =
someone clarify these.

1. mplsLdpEntityOperStatus
What is the use of this field in mplsLdpEntityTable ?

2. mplsLdpEntityHopCount
The draft says this value specifies the "Initial Hop Count for this =
Entity". What could be the use of such assignment when we know that Hop =
Count is decided online depending  on the path on which the LSP is setup =
?

3. mplsLdpEntityStorageType=20
Not clear what it means and what is  it's use.

4. mplsLdpEntityRowStatus=20
What is the need for this field when mplsLdpEntityAdminStatus field  is =
serving the same purpose?

santosh

------=_NextPart_000_00FD_01BFDB71.7ABDA6E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I have&nbsp; a few =
doubts=20
regarding draft-ietf-mpls-ldp-mib-05. Could someone clarify =
these.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. <FONT face=3D"Courier New"=20
size=3D2>mplsLdpEntityOperStatus</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>What is the use of this field =
in=20
mplsLdpEntityTable ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>2. <FONT face=3D"Courier New"=20
size=3D2>mplsLdpEntityHopCount</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The draft says this value specifies the =
"Initial=20
Hop Count for this Entity". What could be the use of such assignment =
when we=20
know that Hop Count is decided&nbsp;online depending&nbsp; on the path =
on which=20
the LSP is setup ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3. <FONT face=3D"Courier New"=20
size=3D2>mplsLdpEntityStorageType </FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Not clear what it means and =
what is&nbsp;=20
it's use.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>4. <FONT face=3D"Courier New"=20
size=3D2>mplsLdpEntityRowStatus </FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>What is the need for this field =
when <FONT=20
face=3D"Courier New" size=3D2>mplsLdpEntityAdminStatus field&nbsp; is =
serving the=20
same purpose?</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT=20
face=3D"Courier New">&nbsp;</DIV></FONT></FONT>
<DIV><FONT face=3DArial size=3D2>santosh</FONT></DIV></BODY></HTML>

------=_NextPart_000_00FD_01BFDB71.7ABDA6E0--



From owner-mpls@UU.NET  Wed Jun 21 06:49:07 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25833
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 06:49:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiunj27886;
	Wed, 21 Jun 2000 10:47:55 GMT
Received: by mail-control.mail.uu.net 
	id QQiunj26992
	for mpls-outgoing; Wed, 21 Jun 2000 10:47:30 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiunj26987
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 10:47:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiunj23033
	for <mpls@uu.net>; Wed, 21 Jun 2000 06:47:14 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiunj25737
	for <mpls@uu.net>; Wed, 21 Jun 2000 10:47:14 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA16806
	for mpls@uu.net; Wed, 21 Jun 2000 06:47:13 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiunj26974
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 10:46:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiunj22942
	for <mpls@uu.net>; Wed, 21 Jun 2000 06:46:25 -0400 (EDT)
Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQiunj25195
	for <mpls@uu.net>; Wed, 21 Jun 2000 10:46:25 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25758;
	Wed, 21 Jun 2000 06:46:24 -0400 (EDT)
Message-Id: <200006211046.GAA25758@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-fr-06.txt
Date: Wed, 21 Jun 2000 06:46:24 -0400
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		: Use of Label Switching on Frame Relay Networks 
                          Specification
	Author(s)	: A. Conta, P. Doolan, A. Malis
	Filename	: draft-ietf-mpls-fr-06.txt
	Pages		: 24
	Date		: 20-Jun-00
	
This  document  defines  the  model  and   generic   mechanisms   for
Multiprotocol  Label  Switching on Frame Relay networks. Furthermore,
it  extends  and  clarifies  portions  of  the  Multiprotocol   Label
Switching Architecture described in [ARCH] and the Label Distribution
Protocol (LDP) described in [LDP] relative to Frame  Relay  Networks.
MPLS  enables  the  use  of  Frame  Relay Switches as Label Switching
Routers (LSRs).

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

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-fr-06.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Wed Jun 21 09:31:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00936
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 09:31:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiunt20108;
	Wed, 21 Jun 2000 13:28:41 GMT
Received: by mail-control.mail.uu.net 
	id QQiunt10972
	for mpls-outgoing; Wed, 21 Jun 2000 13:28:12 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiunt10890
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 13:27:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiunt14829
	for <mpls@uu.net>; Wed, 21 Jun 2000 09:27:36 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiunt06413
	for <mpls@uu.net>; Wed, 21 Jun 2000 13:27:35 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA27767
	for mpls@uu.net; Wed, 21 Jun 2000 09:27:34 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiunt10680
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 13:27:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiunt14662
	for <mpls@UU.NET>; Wed, 21 Jun 2000 09:26:39 -0400 (EDT)
Received: from brixcorp2.brixnet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5])
	id QQiunt17705
	for <mpls@UU.NET>; Wed, 21 Jun 2000 13:26:39 GMT
Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21)
	id <M68WS4HY>; Wed, 21 Jun 2000 09:26:38 -0400
Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEBEF@brixcorp2.brixnet.com>
From: "Cucchiara, Joan" <JCucchiara@Brixnet.com>
To: "'Santosh Gupta'" <santoshgupta@poboxes.com>, mpls@UU.NET
Subject: RE: LDP MIB
Date: Wed, 21 Jun 2000 09:26:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


-----Original Message-----
> From: Santosh Gupta [mailto:santoshg@daewoo.dti.daewoo.co.kr]
> Sent: Wednesday, June 21, 2000 1:42 AM
> To: mpls@UU.NET
> Subject: LDP MIB
>

Hi Santosh,

All of the issues below (except the question on StorageType) were
raised during the LDP MIB last call.  I'll recap where we are
going with these for the next rev.

>
> Hello 
>     I have  a few doubts regarding draft-ietf-mpls-ldp-mib-05. Could
someone > clarify these.
> 
> 1. mplsLdpEntityOperStatus
> What is the use of this field in mplsLdpEntityTable ?

The idea is to represent the Actual state of the entry.
For example, you can set a state to up in the admin status
object, but that doesn't mean that the actual entity is 
working, the operstatus gives an indication of what the
actual state is.   The circumstances under which an OperStatus
is down and an AdminStatus is up is left to specific implementations
but for example, if there isn't enough system resources to support
another entity then operStatus may be down.  

> 
> 2. mplsLdpEntityHopCount
> The draft says this value specifies the "Initial Hop Count for this
Entity". > What could be the use of such assignment when we know that Hop
Count is
> decided online depending  on the path on which the LSP is setup ?

This will be reworked similarly to what Piers Finlayson suggested in
email c. 3/11/00.

Essentially combine both the HopCountLoopDetection and
HopCount objects into an object similar to:   

      "mplsLdpEntityHopCounterLimit OBJECT-TYPE 
          SYNTAX       Integer32 (0..255)
          MAX-ACCESS   read-create 
          STATUS       current 
          DESCRIPTION 
              "If the value of this object is 0 (zero),
              then Loop Detection using Hop Counters is
              disabled.
              If the value of this object is greater than
              0 (zero) then Loop Detection using Hop
              Counters is enabled, and this object
              specifies this Entity's maximum allowable
              value for the Hop Count.
              Also, the value of the object
              mplsLdpLsrLoopDetectionCapable must be set
              to either 'hopCount(3)' or
              'hopCountAndPathVector(5)' if this object
              has a value greater than 0 (zero)."
          ::= { mplsLdpEntityEntry 15 }" 

> 
> 3. mplsLdpEntityStorageType 
> Not clear what it means and what is  it's use.

This is used as described in RFC2579.  It is an
SMIv2 Textual Convention which is used to indicate
if/how the configured information is stored in 
nonvolatile storage.  It was thought appropriate that
LDP entity configuration include this as a way to
indicate if the configuration was stored in non-volatile
memory or not.

> 
> 4. mplsLdpEntityRowStatus 
> What is the need for this field when mplsLdpEntityAdminStatus field  is 
> serving the same purpose?

Granted these objects do overlap in function somewhat (not completely).
The idea is that some users may be allowed to manipulate admin status, 
but NOT rowStatus. For example, deleting a row may only be granted to 
a specific user, whereas admin status capabilities (which are less
drastic than deleting a row, may be granted to more users.)

   -Joan

>  
> santosh
>



From owner-mpls@UU.NET  Wed Jun 21 09:47:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01626
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 09:47:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiunv10755;
	Wed, 21 Jun 2000 13:46:05 GMT
Received: by mail-control.mail.uu.net 
	id QQiunv12614
	for mpls-outgoing; Wed, 21 Jun 2000 13:45:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiunv12538
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 13:45:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiunu17874
	for <mpls@UU.NET>; Wed, 21 Jun 2000 09:44:45 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQiunu09305
	for <mpls@UU.NET>; Wed, 21 Jun 2000 13:44:45 GMT
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Wed, 21 Jun 2000 08:42:36 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2WKDBAW; Wed, 21 Jun 2000 09:43:40 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2LHF4Z2; Wed, 21 Jun 2000 09:43:38 -0400
Message-ID: <3950C68B.A1492FA8@americasm01.nt.com>
Date: Wed, 21 Jun 2000 09:43:39 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Mike Badil <hasko10@hotmail.com>
CC: mpls@UU.NET
Subject: Re: TE
References: <20000621002138.39817.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mike Badil wrote:

> Hi all
>
> I just reading MPLS document, I have a question which I am not really clear
> to understand, if someone helps I will be happy.
>
> The Question is:
>
> What makes MPLS to support constraint based routing?
> If it just adding contsraint metrics to conventional routing in order to
> support TE.
> Why it is not possible without MPLS.
>
> In other word, in conventional IP routing, if we add constraint metrics, can
> conventional IP routing support it also?
>
> Thanks.
>
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Constraint based routing is not only about metrics but also bandwidth such as
maximum reservable and how much is actually available.

Darek



From owner-mpls@UU.NET  Wed Jun 21 09:58:49 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02035
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 09:58:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiunv22707;
	Wed, 21 Jun 2000 13:57:12 GMT
Received: by mail-control.mail.uu.net 
	id QQiunv13648
	for mpls-outgoing; Wed, 21 Jun 2000 13:56:34 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiunv13636
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 13:56:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiunv20103
	for <mpls@uu.net>; Wed, 21 Jun 2000 09:55:57 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQiunv25961
	for <mpls@uu.net>; Wed, 21 Jun 2000 13:55:57 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA02175
	for <mpls@uu.net>; Wed, 21 Jun 2000 06:56:07 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA25194 for mpls@uu.net; Wed, 21 Jun 2000 09:55:55 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuhx18105
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 23:27:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuhx00015
	for <mpls@UU.NET>; Mon, 19 Jun 2000 19:26:51 -0400 (EDT)
Received: from tahoe.allegronetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tahoe.allegronetworks.com [206.14.65.10])
	id QQiuhx02504
	for <mpls@UU.NET>; Mon, 19 Jun 2000 23:26:51 GMT
Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21)
	id <N2BS9665>; Mon, 19 Jun 2000 16:26:47 -0700
Message-ID: <B4DFCB7CDE2DD4118F690008C7869416179002@tahoe.allegronetworks.com>
From: Neal Castagnoli <cast@allegronetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: MPLS and IS-IS
Date: Mon, 19 Jun 2000 16:26:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFDA45.D65614EC"
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_01BFDA45.D65614EC
Content-Type: text/plain;
	charset="iso-8859-1"



> From: 	David Wang [mailto:david.wang@metro-optix.com] 
> 
> Hi All,
> 
> I need to learn some basics of IS-IS. I checked amazon.com, 
> cl.com (San Jose Computer literature book store), 
> bookpool.com and several other technology bookstores. To my 
> great surprise I couldn't find any book about IS-IS. I 
> couldn't find any tutorial or white paper about the IS-IS 
> protocol on the Internet either. All I can read is the 10 
> years old RFC 1142 and RFC 1195.

You can download the protocol specification for IS - IS (ISO/IEC 10589) from
ANSI (www.ansi.org) for a fee.  This is the base upon which RFC 1195 is
built.  You also might want to check out the ietf is-is working group.

> 1.	When IS-IS protocol is used to route IP packet only, 
> what kind of lay 3 protocol the IS-IS routers use to 
> communicate link state information (the link state 
> advertisements) and other protocol related information, IP or 
> CLNP? What is the encapsulation format of these packets. What 
> the standard specify and what people actually implement?  

IS - IS runs directly on top of the data-link using the CLNP protocol ID
(SAP in Ethernet 802 terms).  IS - IS packets are not encapsulated in CLNP.
You don't need to forward or process CLNP packets. To be compliant with RFC
1195, you run the IS portion of ES - IS (ISO 9542) over WAN links.

There is also a draft standard describing the encapsulation of IS - IS in
IP, draft-ietf-isis-wg-over-ip-02.txt.


> 2.	Can someone recommend me a book, a white paper or some 
> tutorials so I may get started quicker.


There is some discussion of IS - IS in Radia Perlman's book
"Interconnections, Second Edition," ISBN 0-201-63448-1.

> 
> Thanks for your help.
> David

  --Neal Castagnoli
    allegro networks




> 
> -----Original Message-----
> From:	HANSEN CHAN [mailto:hchan@newbridge.com]
> Sent:	Tuesday, May 16, 2000 7:22 AM
> To:	mpls@UU.NET
> Subject:	MPLS and IS-IS
> 
> 
> Hi all,
> 
> I have been hearing IS-IS is a better protocol to be used 
> than OSPF in a MPLS network for TE application. Is that a 
> fair statement? What are the technical reasons?
> Appreciate if someone can shed some light on this subject.
> Thanks,
> Hansen
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: MPLS and IS-IS</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; From: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
David Wang [<A =
HREF=3D"mailto:david.wang@metro-optix.com">mailto:david.wang@metro-optix=
.com</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi All,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I need to learn some basics of IS-IS. I checked =
amazon.com, </FONT>
<BR><FONT SIZE=3D2>&gt; cl.com (San Jose Computer literature book =
store), </FONT>
<BR><FONT SIZE=3D2>&gt; bookpool.com and several other technology =
bookstores. To my </FONT>
<BR><FONT SIZE=3D2>&gt; great surprise I couldn't find any book about =
IS-IS. I </FONT>
<BR><FONT SIZE=3D2>&gt; couldn't find any tutorial or white paper about =
the IS-IS </FONT>
<BR><FONT SIZE=3D2>&gt; protocol on the Internet either. All I can read =
is the 10 </FONT>
<BR><FONT SIZE=3D2>&gt; years old RFC 1142 and RFC 1195.</FONT>
</P>

<P><FONT SIZE=3D2>You can download the protocol specification for IS - =
IS (ISO/IEC 10589) from ANSI (www.ansi.org) for a fee.&nbsp; This is =
the base upon which RFC 1195 is built.&nbsp; You also might want to =
check out the ietf is-is working group.</FONT></P>

<P><FONT SIZE=3D2>&gt; 1.&nbsp;&nbsp;&nbsp; When IS-IS protocol is used =
to route IP packet only, </FONT>
<BR><FONT SIZE=3D2>&gt; what kind of lay 3 protocol the IS-IS routers =
use to </FONT>
<BR><FONT SIZE=3D2>&gt; communicate link state information (the link =
state </FONT>
<BR><FONT SIZE=3D2>&gt; advertisements) and other protocol related =
information, IP or </FONT>
<BR><FONT SIZE=3D2>&gt; CLNP? What is the encapsulation format of these =
packets. What </FONT>
<BR><FONT SIZE=3D2>&gt; the standard specify and what people actually =
implement?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>IS - IS runs directly on top of the data-link using =
the CLNP protocol ID (SAP in Ethernet 802 terms).&nbsp; IS - IS packets =
are not encapsulated in CLNP.&nbsp; You don't need to forward or =
process CLNP packets. To be compliant with RFC 1195, you run the IS =
portion of ES - IS (ISO 9542) over WAN links.</FONT></P>

<P><FONT SIZE=3D2>There is also a draft standard describing the =
encapsulation of IS - IS in IP, =
draft-ietf-isis-wg-over-ip-02.txt.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; 2.&nbsp;&nbsp;&nbsp; Can someone recommend me a =
book, a white paper or some </FONT>
<BR><FONT SIZE=3D2>&gt; tutorials so I may get started quicker.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>There is some discussion of IS - IS in Radia =
Perlman's book &quot;Interconnections, Second Edition,&quot; ISBN =
0-201-63448-1.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks for your help.</FONT>
<BR><FONT SIZE=3D2>&gt; David</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; --Neal Castagnoli</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; allegro networks</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: HANSEN CHAN [<A =
HREF=3D"mailto:hchan@newbridge.com">mailto:hchan@newbridge.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, May 16, 2000 7:22 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp; mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MPLS and =
IS-IS</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi all,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I have been hearing IS-IS is a better protocol =
to be used </FONT>
<BR><FONT SIZE=3D2>&gt; than OSPF in a MPLS network for TE application. =
Is that a </FONT>
<BR><FONT SIZE=3D2>&gt; fair statement? What are the technical reasons?<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Appreciate if someone can shed some light on =
this subject.</FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; Hansen</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFDA45.D65614EC--



From owner-mpls@UU.NET  Wed Jun 21 10:02:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02320
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 10:02:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiunv26783;
	Wed, 21 Jun 2000 13:57:02 GMT
Received: by mail-control.mail.uu.net 
	id QQiunv13643
	for mpls-outgoing; Wed, 21 Jun 2000 13:56:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiunv13638
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 13:56:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiunv02052
	for <mpls@uu.net>; Wed, 21 Jun 2000 09:56:11 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQiunv26138
	for <mpls@uu.net>; Wed, 21 Jun 2000 13:56:11 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA02330
	for <mpls@uu.net>; Wed, 21 Jun 2000 06:56:21 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA25198 for mpls@uu.net; Wed, 21 Jun 2000 09:56:09 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuhy19148
	for <mpls@mail-control.mail.uu.net>; Mon, 19 Jun 2000 23:42:52 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuhy17672
	for <mpls@UU.NET>; Mon, 19 Jun 2000 19:42:34 -0400 (EDT)
Received: from mail.erlangtech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: www.erlangtech.com [209.145.148.2])
	id QQiuhy01049
	for <mpls@UU.NET>; Mon, 19 Jun 2000 23:42:34 GMT
Received: from rgit.wustl.edu (stl-cust-13-ip130.gabrielcom.net [64.19.16.130] (may be forged))
	by mail.erlangtech.com (8.9.3/8.9.3) with ESMTP id SAA20387;
	Mon, 19 Jun 2000 18:45:36 -0500
Message-ID: <394EAFDA.D0C57675@rgit.wustl.edu>
Date: Mon, 19 Jun 2000 18:42:18 -0500
From: Nasser Yazdani <nasser@rgit.wustl.edu>
Reply-To: nasser@rgit.wustl.edu
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: A question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I was wondering how we can distinguish between frames with shim headers
and without shim headers in Ethernet frames. I appreciate if anybody
can give me a solid answer, I mean with reference.

Regards,

-- Nasser




From owner-mpls@UU.NET  Wed Jun 21 10:21:16 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02778
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 10:21:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiunx13296;
	Wed, 21 Jun 2000 14:17:56 GMT
Received: by mail-control.mail.uu.net 
	id QQiunx26104
	for mpls-outgoing; Wed, 21 Jun 2000 14:17:34 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiunx26076
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 14:17:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiunx06566
	for <mpls@UU.NET>; Wed, 21 Jun 2000 10:16:51 -0400 (EDT)
Received: from alpha.dtix.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.dtix.com [198.62.174.1])
	id QQiunx12387
	for <mpls@UU.NET>; Wed, 21 Jun 2000 14:16:50 GMT
Received: from localhost (renuka@localhost)
	by alpha.dtix.com (8.9.3/8.8.7) with ESMTP id JAA22192;
	Wed, 21 Jun 2000 09:30:57 -0400
Date: Wed, 21 Jun 2000 09:30:57 -0400 (EDT)
From: Renuka Arunachalam <renuka@alpha.dtix.com>
To: Nasser Yazdani <nasser@rgit.wustl.edu>
cc: mpls@UU.NET, Renuka Arunachalam <renuka@alpha.dtix.com>
Subject: Re: A question
In-Reply-To: <394EAFDA.D0C57675@rgit.wustl.edu>
Message-ID: <Pine.LNX.4.10.10006210923540.22089-100000@alpha.dtix.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

From the etherType. It is 0x8847 for labeled unicast packets and 0x8848
for multicast packets.
Reference: MPLS Label Stack Encoding. Can be found at
www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt

renuka

On Mon, 19 Jun 2000, Nasser Yazdani wrote:

> Hi,
> 
> I was wondering how we can distinguish between frames with shim headers
> and without shim headers in Ethernet frames. I appreciate if anybody
> can give me a solid answer, I mean with reference.
> 
> Regards,
> 
> -- Nasser
> 
> 



From owner-mpls@UU.NET  Wed Jun 21 10:22:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02809
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 10:22:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiunx11833;
	Wed, 21 Jun 2000 14:17:14 GMT
Received: by mail-control.mail.uu.net 
	id QQiunx26023
	for mpls-outgoing; Wed, 21 Jun 2000 14:16:41 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiunx26002
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 14:16:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiunx06351
	for <mpls@UU.NET>; Wed, 21 Jun 2000 10:16:02 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQiunx11837
	for <mpls@UU.NET>; Wed, 21 Jun 2000 14:16: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 KAA13431
	for <mpls@UU.NET>; Wed, 21 Jun 2000 10:16:00 -0400 (EDT)
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 KAA28286
	for <mpls@UU.NET>; Wed, 21 Jun 2000 10:16:00 -0400 (EDT)
Message-ID: <3950CE31.FD81C36@marconi.com>
Date: Wed, 21 Jun 2000 10:16:17 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: TE
References: <20000621002138.39817.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mike Badil wrote:
> 
> I just reading MPLS document, I have a question which I am not really
> clear to understand, if someone helps I will be happy.
> 
> The Question is:
> 
> What makes MPLS to support constraint based routing?

The existance of LSPs makes traffic engineering easier to implement.  It
does not make it impossible, however.

> If it just adding contsraint metrics to conventional routing in order
> to support TE.
> Why it is not possible without MPLS.

Sure, it's possible.  Who said it wasn't?

> In other word, in conventional IP routing, if we add constraint
> metrics, can conventional IP routing support it also?

I think you're missing the point of MPLS.

MPLS's purpose is not to create the ability to perform constraint-based
routing and traffic engineering where it was previously impossible.

MPLS's purpose is to create a connection-oriented link layer (COLL). 
Where forwarding decisions are made solely on the basis of a packet's
label, and not on any other content in the packet.

The use of a COLL is not a requirement for traffic engineering.  It
simply makes it easier to implement.  With a COLL, the hard work of
determining the path that data packets must take can be done once, when
the LSP is set up.  Without a COLL, this work must be done by every
switch, for every data packet.

Connection oriented link layers are not new.  ATM and Frame Relay also
use them.  The big thing that makes MPLS special is that it can run over
nearly any transport medium (ATM, FR, POS, Ethernet, etc) instead of
being tied to a specific layer-2 encapsulation.  Also, because it uses
IP for its addressing, it can work with many common routing and
signalling protocols (like OSPF, IS-IS, and RSVP).

-- David


From owner-mpls@UU.NET  Wed Jun 21 10:25:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02856
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 10:25:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiunx16861;
	Wed, 21 Jun 2000 14:22:22 GMT
Received: by mail-control.mail.uu.net 
	id QQiunx26515
	for mpls-outgoing; Wed, 21 Jun 2000 14:21:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiunx26494
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 14:21:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiunx07908
	for <mpls@UU.NET>; Wed, 21 Jun 2000 10:21:18 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQiunx16037
	for <mpls@UU.NET>; Wed, 21 Jun 2000 14:21: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 KAA14152
	for <mpls@UU.NET>; Wed, 21 Jun 2000 10:21:15 -0400 (EDT)
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 KAA29732
	for <mpls@UU.NET>; Wed, 21 Jun 2000 10:21:15 -0400 (EDT)
Message-ID: <3950CF6B.B825C69F@marconi.com>
Date: Wed, 21 Jun 2000 10:21:31 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: TE
References: <20000621002138.39817.qmail@hotmail.com> <3950CE31.FD81C36@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

David Charlap wrote:
> 
> The existance of LSPs makes traffic engineering easier to implement.
> It does not make it impossible, however.

Correction:

	The absence of LSPs does not make traffic engineering 	impossible.

-- David


From owner-mpls@UU.NET  Wed Jun 21 11:32:26 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04226
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 11:32:26 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuob24744;
	Wed, 21 Jun 2000 15:29:38 GMT
Received: by mail-control.mail.uu.net 
	id QQiuob12992
	for mpls-outgoing; Wed, 21 Jun 2000 15:29:13 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuob12983
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 15:29:05 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuob09414
	for <mpls@uu.net>; Wed, 21 Jun 2000 11:28:49 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuob07775
	for <mpls@uu.net>; Wed, 21 Jun 2000 15:28:49 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA16305
	for mpls@uu.net; Wed, 21 Jun 2000 11:28:48 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuob12958
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 15:28:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuob23067
	for <mpls@UU.NET>; Wed, 21 Jun 2000 11:28:12 -0400 (EDT)
Received: from drawbridge.ascend.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: drawbridge.ascend.com [198.4.92.1])
	id QQiuob23020
	for <mpls@UU.NET>; Wed, 21 Jun 2000 15:28:11 GMT
Received: from fw-ext.ascend.com (fw-ext [198.4.92.5])
	by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id IAA27178
	for <mpls@UU.NET>; Wed, 21 Jun 2000 08:21:00 -0700 (PDT)
Received: from russet.ascend.com by fw-ext.ascend.com
          via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 21 Jun 2000 15:28:11 UT
Received: from porky (porky.ascend.com [192.207.23.83])
	by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id IAA12060;
	Wed, 21 Jun 2000 08:28:09 -0700 (PDT)
Received: from ascend.com by ascend.com
Message-Id: <4.3.2.7.2.20000621112009.029bbdc0@alpo.casc.com>
X-Sender: amalis@alpo.casc.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 21 Jun 2000 11:23:56 -0400
To: mpls@UU.NET
From: "Andrew G. Malis" <amalis@lucent.com>
Subject: Fwd: I-D ACTION:draft-ietf-mpls-fr-06.txt
Cc: amalis@lucent.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

The difference from -05 to -06 was changing the coding for 23-bit DLCIs 
back to 2 (I mistakenly changed it to 1 in -05) to be fully consistent with 
the LDP draft.

Cheers,
Andy

------- Begin of Forwarded Message -------
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-fr-06.txt
Date: Wed, 21 Jun 2000 06:46:24 -0400
Sender: nsyracus@cnri.reston.va.us

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		: Use of Label Switching on Frame Relay Networks
                           Specification
	Author(s)	: A. Conta, P. Doolan, A. Malis
	Filename	: draft-ietf-mpls-fr-06.txt
	Pages		: 24
	Date		: 20-Jun-00
	
This  document  defines  the  model  and   generic   mechanisms   for
Multiprotocol  Label  Switching on Frame Relay networks. Furthermore,
it  extends  and  clarifies  portions  of  the  Multiprotocol   Label
Switching Architecture described in [ARCH] and the Label Distribution
Protocol (LDP) described in [LDP] relative to Frame  Relay  Networks.
MPLS  enables  the  use  of  Frame  Relay Switches as Label Switching
Routers (LSRs).

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

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-fr-06.txt".

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


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

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

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

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-fr-06.txt>

------- End of Forwarded Message ------- 




From owner-mpls@UU.NET  Wed Jun 21 11:47:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04532
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 11:47:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuod08400;
	Wed, 21 Jun 2000 15:45:42 GMT
Received: by mail-control.mail.uu.net 
	id QQiuoc14247
	for mpls-outgoing; Wed, 21 Jun 2000 15:44:58 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuoc14242
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 15:44:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuoc26674
	for <mpls@uu.net>; Wed, 21 Jun 2000 11:44:11 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQiuoc07444
	for <mpls@uu.net>; Wed, 21 Jun 2000 15:44:10 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA27519
	for <mpls@uu.net>; Wed, 21 Jun 2000 08:44:21 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA25725 for mpls@uu.net; Wed, 21 Jun 2000 11:44:09 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuoc13654
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 15:34:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuoc24555
	for <mpls@UU.NET>; Wed, 21 Jun 2000 11:34:04 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49])
	id QQiuoc12022
	for <mpls@UU.NET>; Wed, 21 Jun 2000 15:34:03 GMT
Received: from nslocum.cs.bell-labs.com ([135.104.8.38]) by crufty; Wed Jun 21 11:33:55 EDT 2000
Received: from research.bell-labs.com (wang-pc.research.bell-labs.com [135.104.54.50])
	by nslocum.cs.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA7246705;
	Wed, 21 Jun 2000 11:33:32 -0400 (EDT)
Message-ID: <3950DFE0.E201AD97@research.bell-labs.com>
Date: Wed, 21 Jun 2000 11:31:44 -0400
From: Jay Wang <wang@research.bell-labs.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hasko10@hotmail.com
CC: mpls@UU.NET
Subject: Re: TE
References: <20000621002138.39817.qmail@hotmail.com> <3950CE31.FD81C36@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mike,

    MPLS is not created to support constraint based routing
    and it doesn't.  It let you set up layer two tunnels using
    label switching.  An IP network can benefit from the
    existence of MPLS with at least the following:

    1. Faster data forwarding at the transient (core) routers -
        This is because there is only label (index) lookup and
        no IP header processing.  This however became much
        weaker an argument lately since lots of work that used
        to be done by software (e.g., header processing,
        classification) now are typically done in ASIC in vendor's
        box.

    2. Traffic Engineering - MPLS allows you to set up tunnels
        with explicit routing so that you can design your routes
        off-line in order to achieve best traffic distribution to
        minimize network hot spots (which often occur in OSPF
        type routing) and improve network capacity efficiency.
        Load balancing (parallel MPLS tunnels running between
        a source-dest pair) and trunk protection also become easy.

    3. QoS/VPN  - MPLS interworking with Diffserv gives you traffic
        isolation (and hence some performance protection). Also,
        MPLS with proper support of resource
        reservation signaling mechanism (e.g., RSVP), you can specify
        thE size of each MPLS 'pipe'.  With a careful traffic trunk
analysis,
        you may set up a set of corresponding pipes (using constraint based
        or explicit routing) such that you can place some application
specific
        (e.g., voice,  video) flows on the trunks while meeting some
        stringent real-time specs (e.g., loss, jitters, latency).

- Jay

David Charlap wrote:

> Mike Badil wrote:
> >
> > I just reading MPLS document, I have a question which I am not really
> > clear to understand, if someone helps I will be happy.
> >
> > The Question is:
> >
> > What makes MPLS to support constraint based routing?
>
> The existance of LSPs makes traffic engineering easier to implement.  It
> does not make it impossible, however.
>
> > If it just adding contsraint metrics to conventional routing in order
> > to support TE.
> > Why it is not possible without MPLS.
>
> Sure, it's possible.  Who said it wasn't?
>
> > In other word, in conventional IP routing, if we add constraint
> > metrics, can conventional IP routing support it also?
>
> I think you're missing the point of MPLS.
>
> MPLS's purpose is not to create the ability to perform constraint-based
> routing and traffic engineering where it was previously impossible.
>
> MPLS's purpose is to create a connection-oriented link layer (COLL).
> Where forwarding decisions are made solely on the basis of a packet's
> label, and not on any other content in the packet.
>
> The use of a COLL is not a requirement for traffic engineering.  It
> simply makes it easier to implement.  With a COLL, the hard work of
> determining the path that data packets must take can be done once, when
> the LSP is set up.  Without a COLL, this work must be done by every
> switch, for every data packet.
>
> Connection oriented link layers are not new.  ATM and Frame Relay also
> use them.  The big thing that makes MPLS special is that it can run over
> nearly any transport medium (ATM, FR, POS, Ethernet, etc) instead of
> being tied to a specific layer-2 encapsulation.  Also, because it uses
> IP for its addressing, it can work with many common routing and
> signalling protocols (like OSPF, IS-IS, and RSVP).
>
> -- David

--
Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
600 Mountain Avenue, Room 2C-308,          wang@research.bell-labs.com
Murray Hill, NJ 07974-2070





From owner-mpls@UU.NET  Wed Jun 21 13:02:15 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08550
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 13:02:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuoh01081;
	Wed, 21 Jun 2000 16:58:55 GMT
Received: by mail-control.mail.uu.net 
	id QQiuoh02414
	for mpls-outgoing; Wed, 21 Jun 2000 16:58:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuoh02404
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 16:58:13 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuoh25521
	for <mpls@UU.NET>; Wed, 21 Jun 2000 12:57:15 -0400 (EDT)
Received: from baynet.baynetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20])
	id QQiuoh29861
	for <mpls@UU.NET>; Wed, 21 Jun 2000 16:57:14 GMT
Received: from mailhost.BayNetworks.COM (hcc0c.s84f5.BayNetworks.COM [132.245.204.12])
	by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id JAA25195;
	Wed, 21 Jun 2000 09:55:43 -0700 (PDT)
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6])
	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id NAA26268;
	Wed, 21 Jun 2000 13:01:13 -0400 (EDT)
Received: from bubba.engeast (bubba [192.168.136.194])
	by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP
	id MAA24867; Wed, 21 Jun 2000 12:01:57 -0400
	for 
Received: by bubba.engeast (SMI-8.6/SMI-SVR4)
	id MAA15971; Wed, 21 Jun 2000 12:01:57 -0400
From: dwilder@baynetworks.com (David Wilder)
Message-Id: <200006211601.MAA15971@bubba.engeast>
Subject: Re: TE
In-Reply-To: <3950DFE0.E201AD97@research.bell-labs.com> from Jay Wang at "Jun
 21, 2000 11:31:44 am"
To: Jay Wang <wang@research.bell-labs.com>
Date: Wed, 21 Jun 2000 12:01:56 -0400 (EDT)
CC: hasko10@hotmail.com, mpls@UU.NET
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
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

Very well put Jay.

- Dave


> Mike,
> 
>     MPLS is not created to support constraint based routing
>     and it doesn't.  It let you set up layer two tunnels using
>     label switching.  An IP network can benefit from the
>     existence of MPLS with at least the following:
> 
>     1. Faster data forwarding at the transient (core) routers -
>         This is because there is only label (index) lookup and
>         no IP header processing.  This however became much
>         weaker an argument lately since lots of work that used
>         to be done by software (e.g., header processing,
>         classification) now are typically done in ASIC in vendor's
>         box.
> 
>     2. Traffic Engineering - MPLS allows you to set up tunnels
>         with explicit routing so that you can design your routes
>         off-line in order to achieve best traffic distribution to
>         minimize network hot spots (which often occur in OSPF
>         type routing) and improve network capacity efficiency.
>         Load balancing (parallel MPLS tunnels running between
>         a source-dest pair) and trunk protection also become easy.
> 
>     3. QoS/VPN  - MPLS interworking with Diffserv gives you traffic
>         isolation (and hence some performance protection). Also,
>         MPLS with proper support of resource
>         reservation signaling mechanism (e.g., RSVP), you can specify
>         thE size of each MPLS 'pipe'.  With a careful traffic trunk
> analysis,
>         you may set up a set of corresponding pipes (using constraint based
>         or explicit routing) such that you can place some application
> specific
>         (e.g., voice,  video) flows on the trunks while meeting some
>         stringent real-time specs (e.g., loss, jitters, latency).
> 
> - Jay
> 
> David Charlap wrote:
> 
> > Mike Badil wrote:
> > >
> > > I just reading MPLS document, I have a question which I am not really
> > > clear to understand, if someone helps I will be happy.
> > >
> > > The Question is:
> > >
> > > What makes MPLS to support constraint based routing?
> >
> > The existance of LSPs makes traffic engineering easier to implement.  It
> > does not make it impossible, however.
> >
> > > If it just adding contsraint metrics to conventional routing in order
> > > to support TE.
> > > Why it is not possible without MPLS.
> >
> > Sure, it's possible.  Who said it wasn't?
> >
> > > In other word, in conventional IP routing, if we add constraint
> > > metrics, can conventional IP routing support it also?
> >
> > I think you're missing the point of MPLS.
> >
> > MPLS's purpose is not to create the ability to perform constraint-based
> > routing and traffic engineering where it was previously impossible.
> >
> > MPLS's purpose is to create a connection-oriented link layer (COLL).
> > Where forwarding decisions are made solely on the basis of a packet's
> > label, and not on any other content in the packet.
> >
> > The use of a COLL is not a requirement for traffic engineering.  It
> > simply makes it easier to implement.  With a COLL, the hard work of
> > determining the path that data packets must take can be done once, when
> > the LSP is set up.  Without a COLL, this work must be done by every
> > switch, for every data packet.
> >
> > Connection oriented link layers are not new.  ATM and Frame Relay also
> > use them.  The big thing that makes MPLS special is that it can run over
> > nearly any transport medium (ATM, FR, POS, Ethernet, etc) instead of
> > being tied to a specific layer-2 encapsulation.  Also, because it uses
> > IP for its addressing, it can work with many common routing and
> > signalling protocols (like OSPF, IS-IS, and RSVP).
> >
> > -- David
> 
> --
> Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
> Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
> 600 Mountain Avenue, Room 2C-308,          wang@research.bell-labs.com
> Murray Hill, NJ 07974-2070
> 
> 
> 



From owner-mpls@UU.NET  Wed Jun 21 13:43:58 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09631
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 13:43:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuok12757;
	Wed, 21 Jun 2000 17:40:21 GMT
Received: by mail-control.mail.uu.net 
	id QQiuok17208
	for mpls-outgoing; Wed, 21 Jun 2000 17:39:58 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuok17196
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 17:39:45 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuok19171
	for <mpls@UU.NET>; Wed, 21 Jun 2000 13:39:36 -0400 (EDT)
Received: from c000.snv.cp.net by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: c000-h000.c000.snv.cp.net [209.228.32.64])
	id QQiuok29175
	for <mpls@UU.NET>; Wed, 21 Jun 2000 17:39:35 GMT
Received: (cpmta 22749 invoked from network); 21 Jun 2000 10:39:34 -0700
Received: from dhcp196.altasoft.com (HELO am) (204.242.142.196)
  by smtp.ipoptical.com (209.228.32.64) with SMTP; 21 Jun 2000 10:39:34 -0700
X-Sent: 21 Jun 2000 17:39:34 GMT
From: "alex.mondrus" <alex.mondrus@ipoptical.com>
To: "David Wilder" <dwilder@baynetworks.com>,
        "Jay Wang" <wang@research.bell-labs.com>
Cc: <hasko10@hotmail.com>, <mpls@UU.NET>
Subject: RE: TE
Date: Wed, 21 Jun 2000 13:47:44 -0400
Message-ID: <NEBBLJNJKMBINGNCIHNKMELDCAAA.alex.mondrus@ipoptical.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200006211601.MAA15971@bubba.engeast>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

In general to do an explicit path set up you do not need to use MPLS.

Alex Mondrus

http://www.ipoptical.com


Traffic Engineering - MPLS allows you to set up tunnels
>         with explicit routing so that you can design your routes
>         off-line in order to achieve best traffic distribution to
>         minimize network hot spots (which often occur in OSPF
>         type routing) and improve network capacity efficiency.
>         Load balancing (parallel MPLS tunnels running between
>         a source-dest pair) and trunk protection also become easy.

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
Wilder
Sent: Wednesday, June 21, 2000 12:02 PM
To: Jay Wang
Cc: hasko10@hotmail.com; mpls@UU.NET
Subject: Re: TE


Very well put Jay.

- Dave


> Mike,
>
>     MPLS is not created to support constraint based routing
>     and it doesn't.  It let you set up layer two tunnels using
>     label switching.  An IP network can benefit from the
>     existence of MPLS with at least the following:
>
>     1. Faster data forwarding at the transient (core) routers -
>         This is because there is only label (index) lookup and
>         no IP header processing.  This however became much
>         weaker an argument lately since lots of work that used
>         to be done by software (e.g., header processing,
>         classification) now are typically done in ASIC in vendor's
>         box.
>
>     2. Traffic Engineering - MPLS allows you to set up tunnels
>         with explicit routing so that you can design your routes
>         off-line in order to achieve best traffic distribution to
>         minimize network hot spots (which often occur in OSPF
>         type routing) and improve network capacity efficiency.
>         Load balancing (parallel MPLS tunnels running between
>         a source-dest pair) and trunk protection also become easy.
>
>     3. QoS/VPN  - MPLS interworking with Diffserv gives you traffic
>         isolation (and hence some performance protection). Also,
>         MPLS with proper support of resource
>         reservation signaling mechanism (e.g., RSVP), you can specify
>         thE size of each MPLS 'pipe'.  With a careful traffic trunk
> analysis,
>         you may set up a set of corresponding pipes (using constraint
based
>         or explicit routing) such that you can place some application
> specific
>         (e.g., voice,  video) flows on the trunks while meeting some
>         stringent real-time specs (e.g., loss, jitters, latency).
>
> - Jay
>
> David Charlap wrote:
>
> > Mike Badil wrote:
> > >
> > > I just reading MPLS document, I have a question which I am not really
> > > clear to understand, if someone helps I will be happy.
> > >
> > > The Question is:
> > >
> > > What makes MPLS to support constraint based routing?
> >
> > The existance of LSPs makes traffic engineering easier to implement.  It
> > does not make it impossible, however.
> >
> > > If it just adding contsraint metrics to conventional routing in order
> > > to support TE.
> > > Why it is not possible without MPLS.
> >
> > Sure, it's possible.  Who said it wasn't?
> >
> > > In other word, in conventional IP routing, if we add constraint
> > > metrics, can conventional IP routing support it also?
> >
> > I think you're missing the point of MPLS.
> >
> > MPLS's purpose is not to create the ability to perform constraint-based
> > routing and traffic engineering where it was previously impossible.
> >
> > MPLS's purpose is to create a connection-oriented link layer (COLL).
> > Where forwarding decisions are made solely on the basis of a packet's
> > label, and not on any other content in the packet.
> >
> > The use of a COLL is not a requirement for traffic engineering.  It
> > simply makes it easier to implement.  With a COLL, the hard work of
> > determining the path that data packets must take can be done once, when
> > the LSP is set up.  Without a COLL, this work must be done by every
> > switch, for every data packet.
> >
> > Connection oriented link layers are not new.  ATM and Frame Relay also
> > use them.  The big thing that makes MPLS special is that it can run over
> > nearly any transport medium (ATM, FR, POS, Ethernet, etc) instead of
> > being tied to a specific layer-2 encapsulation.  Also, because it uses
> > IP for its addressing, it can work with many common routing and
> > signalling protocols (like OSPF, IS-IS, and RSVP).
> >
> > -- David
>
> --
> Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
> Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
> 600 Mountain Avenue, Room 2C-308,          wang@research.bell-labs.com
> Murray Hill, NJ 07974-2070
>
>
>




From owner-mpls@UU.NET  Wed Jun 21 15:19:26 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11446
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 15:19:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuoq12422;
	Wed, 21 Jun 2000 19:14:57 GMT
Received: by mail-control.mail.uu.net 
	id QQiuoq16772
	for mpls-outgoing; Wed, 21 Jun 2000 19:14:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuoq16765
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 19:14:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuoq21754
	for <mpls@UU.NET>; Wed, 21 Jun 2000 15:12:50 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQiuoq10166
	for <mpls@UU.NET>; Wed, 21 Jun 2000 19:12:50 GMT
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by ertpg14e1.nortelnetworks.com; Wed, 21 Jun 2000 14:01:04 -0400
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id NKGZLJRP; Wed, 21 Jun 2000 14:01:00 -0400
Received: from americasm01.nt.com (wcars0ua.ca.nortel.com [47.14.98.155]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2LHFX94; Wed, 21 Jun 2000 14:00:59 -0400
Message-ID: <395102DC.39188BD7@americasm01.nt.com>
Date: Wed, 21 Jun 2000 14:01:00 -0400
From: "Arup Das" <arupdas@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "alex.mondrus" <alex.mondrus@ipoptical.com>
CC: dwilder@baynetworks.com, Jay Wang <wang@research.bell-labs.com>,
        hasko10 <hasko10@hotmail.com>, mpls <mpls@UU.NET>
Subject: Re: TE
References: <NEBBLJNJKMBINGNCIHNKMELDCAAA.alex.mondrus@ipoptical.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

True - you can do that in IP too.

However, in IP if you want to do explicit routing, you need to include the full
path information in each IP packet header. Now, that will dramatically increase
the IP packet header size and consequently, the processing time will increase.
The explicit path used in MPLS has much less overhead compared to that in IP.
"alex.mondrus" wrote:

> In general to do an explicit path set up you do not need to use MPLS.
>
> Alex Mondrus
>
> http://www.ipoptical.com
>
> Traffic Engineering - MPLS allows you to set up tunnels
> >         with explicit routing so that you can design your routes
> >         off-line in order to achieve best traffic distribution to
> >         minimize network hot spots (which often occur in OSPF
> >         type routing) and improve network capacity efficiency.
> >         Load balancing (parallel MPLS tunnels running between
> >         a source-dest pair) and trunk protection also become easy.
>
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
> Wilder
> Sent: Wednesday, June 21, 2000 12:02 PM
> To: Jay Wang
> Cc: hasko10@hotmail.com; mpls@UU.NET
> Subject: Re: TE
>
> Very well put Jay.
>
> - Dave
>
> > Mike,
> >
> >     MPLS is not created to support constraint based routing
> >     and it doesn't.  It let you set up layer two tunnels using
> >     label switching.  An IP network can benefit from the
> >     existence of MPLS with at least the following:
> >
> >     1. Faster data forwarding at the transient (core) routers -
> >         This is because there is only label (index) lookup and
> >         no IP header processing.  This however became much
> >         weaker an argument lately since lots of work that used
> >         to be done by software (e.g., header processing,
> >         classification) now are typically done in ASIC in vendor's
> >         box.
> >
> >     2. Traffic Engineering - MPLS allows you to set up tunnels
> >         with explicit routing so that you can design your routes
> >         off-line in order to achieve best traffic distribution to
> >         minimize network hot spots (which often occur in OSPF
> >         type routing) and improve network capacity efficiency.
> >         Load balancing (parallel MPLS tunnels running between
> >         a source-dest pair) and trunk protection also become easy.
> >
> >     3. QoS/VPN  - MPLS interworking with Diffserv gives you traffic
> >         isolation (and hence some performance protection). Also,
> >         MPLS with proper support of resource
> >         reservation signaling mechanism (e.g., RSVP), you can specify
> >         thE size of each MPLS 'pipe'.  With a careful traffic trunk
> > analysis,
> >         you may set up a set of corresponding pipes (using constraint
> based
> >         or explicit routing) such that you can place some application
> > specific
> >         (e.g., voice,  video) flows on the trunks while meeting some
> >         stringent real-time specs (e.g., loss, jitters, latency).
> >
> > - Jay
> >
> > David Charlap wrote:
> >
> > > Mike Badil wrote:
> > > >
> > > > I just reading MPLS document, I have a question which I am not really
> > > > clear to understand, if someone helps I will be happy.
> > > >
> > > > The Question is:
> > > >
> > > > What makes MPLS to support constraint based routing?
> > >
> > > The existance of LSPs makes traffic engineering easier to implement.  It
> > > does not make it impossible, however.
> > >
> > > > If it just adding contsraint metrics to conventional routing in order
> > > > to support TE.
> > > > Why it is not possible without MPLS.
> > >
> > > Sure, it's possible.  Who said it wasn't?
> > >
> > > > In other word, in conventional IP routing, if we add constraint
> > > > metrics, can conventional IP routing support it also?
> > >
> > > I think you're missing the point of MPLS.
> > >
> > > MPLS's purpose is not to create the ability to perform constraint-based
> > > routing and traffic engineering where it was previously impossible.
> > >
> > > MPLS's purpose is to create a connection-oriented link layer (COLL).
> > > Where forwarding decisions are made solely on the basis of a packet's
> > > label, and not on any other content in the packet.
> > >
> > > The use of a COLL is not a requirement for traffic engineering.  It
> > > simply makes it easier to implement.  With a COLL, the hard work of
> > > determining the path that data packets must take can be done once, when
> > > the LSP is set up.  Without a COLL, this work must be done by every
> > > switch, for every data packet.
> > >
> > > Connection oriented link layers are not new.  ATM and Frame Relay also
> > > use them.  The big thing that makes MPLS special is that it can run over
> > > nearly any transport medium (ATM, FR, POS, Ethernet, etc) instead of
> > > being tied to a specific layer-2 encapsulation.  Also, because it uses
> > > IP for its addressing, it can work with many common routing and
> > > signalling protocols (like OSPF, IS-IS, and RSVP).
> > >
> > > -- David
> >
> > --
> > Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
> > Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
> > 600 Mountain Avenue, Room 2C-308,          wang@research.bell-labs.com
> > Murray Hill, NJ 07974-2070
> >
> >
> >

--
Regards,
Arup Das
(763-1863)





From owner-mpls@UU.NET  Wed Jun 21 16:35:57 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12406
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 16:35:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuow01121;
	Wed, 21 Jun 2000 20:33:18 GMT
Received: by mail-control.mail.uu.net 
	id QQiuow15187
	for mpls-outgoing; Wed, 21 Jun 2000 20:32:57 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuow15182
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 20:32:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuow26490
	for <mpls@uu.net>; Wed, 21 Jun 2000 16:32:39 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQiuow00496
	for <mpls@uu.net>; Wed, 21 Jun 2000 20:32:39 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA27202
	for <mpls@uu.net>; Wed, 21 Jun 2000 13:32:49 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA26634 for mpls@uu.net; Wed, 21 Jun 2000 16:32:37 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuov14586
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 20:24:13 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuov05279
	for <mpls@UU.NET>; Wed, 21 Jun 2000 16:24:03 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49])
	id QQiuov02540
	for <mpls@UU.NET>; Wed, 21 Jun 2000 20:24:02 GMT
Received: from nslocum.cs.bell-labs.com ([135.104.8.38]) by crufty; Wed Jun 21 16:23:18 EDT 2000
Received: from research.bell-labs.com (wang-pc.research.bell-labs.com [135.104.54.50])
	by nslocum.cs.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA6769167;
	Wed, 21 Jun 2000 16:23:15 -0400 (EDT)
Message-ID: <395123CE.61F41A2D@research.bell-labs.com>
Date: Wed, 21 Jun 2000 16:21:34 -0400
From: Jay Wang <wang@research.bell-labs.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "alex.mondrus" <alex.mondrus@ipoptical.com>
CC: mpls <mpls@UU.NET>
Subject: Re: TE
References: <NEBBLJNJKMBINGNCIHNKMELDCAAA.alex.mondrus@ipoptical.com> <395102DC.39188BD7@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Alex,

    Yes, you can statically set up an explicit route for a set of
    flows without MPLS.  But the focus really is in traffic
    engineering. Static routing will not be a proper solution to deal
    with TE for any sizable ISP.  In addition to the salability
    concern as Arup pointed out, there is also a management issue.
    With MPLS, in ISP's management system pertaining to TE each
    tunnel can be handled as a single unit. The signaling and control
    is all done "in the network".  On the other hand, without MPLS the
    ISP's external management system most likely has to provide a
    wrapping (to create a view of a "logical tunnel") that signals and
    coordinates all the participating routers externally.  This raises the
    issue of complexity (as if managing thousands of MPLS-LSPs is not
    complex enough) and perhaps reliability.

- Jay


Arup Das wrote:

> True - you can do that in IP too.
>
> However, in IP if you want to do explicit routing, you need to include the full
> path information in each IP packet header. Now, that will dramatically increase
> the IP packet header size and consequently, the processing time will increase.
> The explicit path used in MPLS has much less overhead compared to that in IP.
> "alex.mondrus" wrote:
>
> > In general to do an explicit path set up you do not need to use MPLS.
> >
> > Alex Mondrus
> >
> > http://www.ipoptical.com
> >
> > Traffic Engineering - MPLS allows you to set up tunnels
> > >         with explicit routing so that you can design your routes
> > >         off-line in order to achieve best traffic distribution to
> > >         minimize network hot spots (which often occur in OSPF
> > >         type routing) and improve network capacity efficiency.
> > >         Load balancing (parallel MPLS tunnels running between
> > >         a source-dest pair) and trunk protection also become easy.
> >
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
> > Wilder
> > Sent: Wednesday, June 21, 2000 12:02 PM
> > To: Jay Wang
> > Cc: hasko10@hotmail.com; mpls@UU.NET
> > Subject: Re: TE
> >
> > Very well put Jay.
> >
> > - Dave
> >
> > > Mike,
> > >
> > >     MPLS is not created to support constraint based routing
> > >     and it doesn't.  It let you set up layer two tunnels using
> > >     label switching.  An IP network can benefit from the
> > >     existence of MPLS with at least the following:
> > >
> > >     1. Faster data forwarding at the transient (core) routers -
> > >         This is because there is only label (index) lookup and
> > >         no IP header processing.  This however became much
> > >         weaker an argument lately since lots of work that used
> > >         to be done by software (e.g., header processing,
> > >         classification) now are typically done in ASIC in vendor's
> > >         box.
> > >
> > >     2. Traffic Engineering - MPLS allows you to set up tunnels
> > >         with explicit routing so that you can design your routes
> > >         off-line in order to achieve best traffic distribution to
> > >         minimize network hot spots (which often occur in OSPF
> > >         type routing) and improve network capacity efficiency.
> > >         Load balancing (parallel MPLS tunnels running between
> > >         a source-dest pair) and trunk protection also become easy.
> > >
> > >     3. QoS/VPN  - MPLS interworking with Diffserv gives you traffic
> > >         isolation (and hence some performance protection). Also,
> > >         MPLS with proper support of resource
> > >         reservation signaling mechanism (e.g., RSVP), you can specify
> > >         thE size of each MPLS 'pipe'.  With a careful traffic trunk
> > > analysis,
> > >         you may set up a set of corresponding pipes (using constraint
> > based
> > >         or explicit routing) such that you can place some application
> > > specific
> > >         (e.g., voice,  video) flows on the trunks while meeting some
> > >         stringent real-time specs (e.g., loss, jitters, latency).
> > >
> > > - Jay
> > >
> > > David Charlap wrote:
> > >
> > > > Mike Badil wrote:
> > > > >
> > > > > I just reading MPLS document, I have a question which I am not really
> > > > > clear to understand, if someone helps I will be happy.
> > > > >
> > > > > The Question is:
> > > > >
> > > > > What makes MPLS to support constraint based routing?
> > > >
> > > > The existance of LSPs makes traffic engineering easier to implement.  It
> > > > does not make it impossible, however.
> > > >
> > > > > If it just adding contsraint metrics to conventional routing in order
> > > > > to support TE.
> > > > > Why it is not possible without MPLS.
> > > >
> > > > Sure, it's possible.  Who said it wasn't?
> > > >
> > > > > In other word, in conventional IP routing, if we add constraint
> > > > > metrics, can conventional IP routing support it also?
> > > >
> > > > I think you're missing the point of MPLS.
> > > >
> > > > MPLS's purpose is not to create the ability to perform constraint-based
> > > > routing and traffic engineering where it was previously impossible.
> > > >
> > > > MPLS's purpose is to create a connection-oriented link layer (COLL).
> > > > Where forwarding decisions are made solely on the basis of a packet's
> > > > label, and not on any other content in the packet.
> > > >
> > > > The use of a COLL is not a requirement for traffic engineering.  It
> > > > simply makes it easier to implement.  With a COLL, the hard work of
> > > > determining the path that data packets must take can be done once, when
> > > > the LSP is set up.  Without a COLL, this work must be done by every
> > > > switch, for every data packet.
> > > >
> > > > Connection oriented link layers are not new.  ATM and Frame Relay also
> > > > use them.  The big thing that makes MPLS special is that it can run over
> > > > nearly any transport medium (ATM, FR, POS, Ethernet, etc) instead of
> > > > being tied to a specific layer-2 encapsulation.  Also, because it uses
> > > > IP for its addressing, it can work with many common routing and
> > > > signalling protocols (like OSPF, IS-IS, and RSVP).
> > > >
> > > > -- David
> > >
> > > --
> > > Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
> > > Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
> > > 600 Mountain Avenue, Room 2C-308,          wang@research.bell-labs.com
> > > Murray Hill, NJ 07974-2070
> > >
> > >
> > >
>
> --
> Regards,
> Arup Das
> (763-1863)




From owner-mpls@UU.NET  Wed Jun 21 17:59:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13759
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 17:59:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiupb16435;
	Wed, 21 Jun 2000 21:57:52 GMT
Received: by mail-control.mail.uu.net 
	id QQiupb02446
	for mpls-outgoing; Wed, 21 Jun 2000 21:57:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiupb02438
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 21:57:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiupb21549
	for <mpls@uu.net>; Wed, 21 Jun 2000 17:57:05 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiupb15865
	for <mpls@uu.net>; Wed, 21 Jun 2000 21:57:04 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA13019
	for mpls@uu.net; Wed, 21 Jun 2000 17:57:04 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiupb02320
	for <mpls@mail-control.mail.uu.net>; Wed, 21 Jun 2000 21:56:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiupb21420
	for <mpls@UU.NET>; Wed, 21 Jun 2000 17:56:11 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQiupb29755
	for <mpls@UU.NET>; Wed, 21 Jun 2000 21:56:10 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 013DCB5; Wed, 21 Jun 2000 23:56:09 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (ch2-dhcp134-171.cisco.com [161.44.134.171])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id XAA24053;
	Wed, 21 Jun 2000 23:56:07 +0200 (MET DST)
Message-Id: <200006212156.XAA24053@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Wed, 21 Jun 2000 17:48:27 +0200
To: <alchiu@research.att.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: RE: Bandwidth reservation per PSC
Cc: "'Darek Skalecki'" <dareks@nortelnetworks.com>, "'mpls'" <mpls@UU.NET>,
        "'Francois Le Faucheur'" <flefauch@cisco.com>
In-Reply-To: <008601bfdb00$5454a6a0$5e83cf87@pcalchiu>
References: <394FCEAC.49196180@americasm01.nt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Darek, 
I am hoping to submit something on extensions to IGPs for support of "Class-types". Let me know if you're interested in working on this.
Francois

At 17:41 20/06/2000 -0400, Angela Chiu wrote:
>Darek,
>
>I don't think it is currently included in the OSPF and ISIS TE extensions. I
>am not aware of anyone who is working on it. But I could be wrong since
>there are so many activities around MPLS, hard to keep track of all of them.
>
>Angela
>
>-----Original Message-----
>From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
>Sent: Tuesday, June 20, 2000 4:06 PM
>To: alchiu
>Cc: mpls; 'Francois Le Faucheur'
>Subject: Re: Bandwidth reservation per PSC
>
>
>Thanks Angela,
>
>Are these extensions currently defined for OSPF and ISIS?. If yes then
>please
>provide me with a reference, and if not then is anyone working on them ?. I
>can
>only find extensions related to advertizing bandwidth availability per
>priority
>not resource class.
>
>Thanks,
>
>Darek
>
>
>Angela Chiu wrote:
>
>> Darek,
>>
>> These are additional requirements for IGP extensions, as stated in TE
>> Framework draft
>> http://www.ietf.org/internet-drafts/draft-ietf-tewg-framework-01.txt
>> "In order to perform constraint-based routing on a per-class basis for
>LSPs,
>> the conventional IGPs (e.g., IS-IS and OSPF) should provide extensions to
>> propagate per-class resource information."
>> Then the draft states that "per-class parameters can be aggregated into
>> per-class-type parameters" for scalability improvements.
>>
>> Regards,
>>
>> Angela
>>
>> -----Original Message-----
>> From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
>> Sent: Tuesday, June 20, 2000 2:51 PM
>> To: Francois Le Faucheur
>> Cc: mpls@UU.NET; alchiu@att.com
>> Subject: Re: Bandwidth reservation per PSC
>>
>> Thanks Francois,
>>
>> My question was indeed related to the distributed model. What I am still
>not
>> sure about is how bandwidth availability within OSPF/ISIS is advertized
>per
>> PSC or per family  of TE related PSCs when the TE extensions only imply
>> advertizement per priority. Are colors assigned to different PSCs or
>> families of TE related PSCs and bandwidth availability advertized per
>> color?.
>>
>> Thanks,
>>
>> Darek
>>
>> Francois Le Faucheur wrote:
>>
>> > Darek,
>> >
>> > At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
>> > >Hi,
>> > >
>> > >I have a question with regard to bandwidth availability per PSC and TE
>> > >extensions to OSPF/ISIS.
>> > >
>> > >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2
>> > >about constraint based routing being
>> > >performed separately for each PSC  where one of the constraints is
>> > >availability of bandwidth from the bandwidth
>> > >allocated to the relevant PSC.
>> > >
>> > >My question is how TE extensions to OSPF/ISIS support advertizing
>> > >bandwidth availability per PSC. The only way I can
>> > >think this can be achieved is by assigning different colors/resource
>> > >classes to different PSCs thus advertizing bandwidth
>> > >availability per PSC simply as bandwidth availability per
>color/resource
>> > >class. Is this correct?.
>> > >
>> > >If it is correct then how serious is the scaling/operational issue at
>> > >least within OSPF since N  TE LSAs are needed for  N
>> > >PSCs  for every link, implying lots of LSA traffic not to mention
>> > >storage within LSDB (which I gather can only store
>> > >65536 TE LSAs).
>> > >
>> >
>> > First, of course , in some environments, Constraint Based Routing may be
>> performed "off-line"/"in a Centralised Manner". In these situations,
>per-PSC
>> bandwidth availability can be determined by the centralised tool without
>> relying on extensions to OSPF/ISIS.
>> >
>> > Where Constraint Based Routing is performed "on-line"/"in a Distributed
>> Manner", then yes, OSPF/ISIS are required to propagate all necessary
>> bandwidth information. This could be achieved in a number of ways:
>> >         - one approach would be to advertise bandwidth information for
>> every PSC. As you are pointing out above, this may lead to
>> scaling/operational issues earlier than desired.
>> >         - another approach would be to advertise bandwidth information
>> only for each "family/class" of PSCs. A family/class of PSC would comprise
>> all the PSCs which share the same bandwidth constraints. It is likely that
>> multiple PSCs can share the same bandwidth constraints (eg
>> "max-reservable-bandwidth"). For instance, multiple Premium/Non-real-time
>> PSCs may share the same "max-reservable-bandwidth". In that case, you have
>> traded a little bit of fine-grain control (you can't enforce bandwidth
>> constraints which are different for absolutely every PSC), but you have
>> significantly gained in scalability of OSPF/ISIS by "only" advertising 2/3
>> available bandwidth information.
>> >
>> > You will find some text on the second approach in section "6.7 Traffic
>> Engineering in Diffserv Environments" of
><draft-ietf-tewg-framework-01.txt>:
>> >
>> >    "Instead of having per-class parameters being configured and
>> >    propagated on each LSR interface, per-class parameters can be
>> >    aggregated into per-class-type parameters. The main motivation for
>> >    grouping a set of classes into a class-type is to improve the
>> >    scalability of IGP link state advertisements by propagating
>> >    information on a per-class-type basis instead of on a per-class
>> >    basis, and also to allow better bandwidth sharing between  classes in
>> >    the same class-type..."
>> >
>> > Francois
>> >
>> > >Thanks,
>> > >
>> > >Darek Skalecki
>> > >Nortel Networks
>> > >
>> >
>> > _________________________________________________________________
>> > Francois Le Faucheur
>> > Development Engineer, IOS Layer 3 Services
>> > Cisco Systems
>> > Office Phone:           +33 4 92 96 75 64
>> > Home Office Phone:     +33 4 92 94 00 78
>> > Mobile :               +33 6 89 108 159
>> > Vmail:                 +33 1 58 04 62 66
>> > Fax:                   +33 4 92 96 79 08
>> > Email:                  flefauch@cisco.com
>> > _________________________________________________________________
>> > Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne -
>France
>> > _________________________________________________________________
> 
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Wed Jun 21 20:51:00 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15730
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 20:50:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiupn08809;
	Thu, 22 Jun 2000 00:48:46 GMT
Received: by mail-control.mail.uu.net 
	id QQiupn16576
	for mpls-outgoing; Thu, 22 Jun 2000 00:48:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiupn16571
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 00:48:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiupn14297
	for <mpls@UU.NET>; Wed, 21 Jun 2000 20:48:09 -0400 (EDT)
Received: from hotmail.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: f245.law9.hotmail.com [64.4.9.245])
	id QQiupn07263
	for <mpls@UU.NET>; Thu, 22 Jun 2000 00:48:08 GMT
Received: (qmail 78209 invoked by uid 0); 22 Jun 2000 00:48:08 -0000
Message-ID: <20000622004808.78208.qmail@hotmail.com>
Received: from 128.230.209.233 by www.hotmail.com with HTTP;
	Wed, 21 Jun 2000 17:48:08 PDT
X-Originating-IP: [128.230.209.233]
From: "Mike Badil" <hasko10@hotmail.com>
To: arupdas@nortelnetworks.com, alex.mondrus@ipoptical.com
Cc: dwilder@baynetworks.com, wang@research.bell-labs.com, hasko10@hotmail.com,
        mpls@UU.NET
Subject: Re: TE
Date: Wed, 21 Jun 2000 20:48:08 EDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi

>True - you can do that in IP too.
>
>However, in IP if you want to do explicit routing, you need to include the 
>full
>path information in each IP packet header. Now, that will dramatically 
>increase
>the IP packet header size and consequently, the processing time will 
>increase.
>The explicit path used in MPLS has much less overhead compared to that in 
>IP.
>"alex.mondrus" wrote:

Yes, you are right, explicit routing is clear. I agree with what you 
said,but My question was about Constraint Based Routing. How to choose 
explicit path(best path according to TE)?, that explicit path is not 
shortest path which calculated by OSPF.




Thanks


>
> > In general to do an explicit path set up you do not need to use MPLS.
> >
> > Alex Mondrus
> >
> > http://www.ipoptical.com
> >
> > Traffic Engineering - MPLS allows you to set up tunnels
> > >         with explicit routing so that you can design your routes
> > >         off-line in order to achieve best traffic distribution to
> > >         minimize network hot spots (which often occur in OSPF
> > >         type routing) and improve network capacity efficiency.
> > >         Load balancing (parallel MPLS tunnels running between
> > >         a source-dest pair) and trunk protection also become easy.
> >
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
> > Wilder
> > Sent: Wednesday, June 21, 2000 12:02 PM
> > To: Jay Wang
> > Cc: hasko10@hotmail.com; mpls@UU.NET
> > Subject: Re: TE
> >
> > Very well put Jay.
> >
> > - Dave
> >
> > > Mike,
> > >
> > >     MPLS is not created to support constraint based routing
> > >     and it doesn't.  It let you set up layer two tunnels using
> > >     label switching.  An IP network can benefit from the
> > >     existence of MPLS with at least the following:
> > >
> > >     1. Faster data forwarding at the transient (core) routers -
> > >         This is because there is only label (index) lookup and
> > >         no IP header processing.  This however became much
> > >         weaker an argument lately since lots of work that used
> > >         to be done by software (e.g., header processing,
> > >         classification) now are typically done in ASIC in vendor's
> > >         box.
> > >
> > >     2. Traffic Engineering - MPLS allows you to set up tunnels
> > >         with explicit routing so that you can design your routes
> > >         off-line in order to achieve best traffic distribution to
> > >         minimize network hot spots (which often occur in OSPF
> > >         type routing) and improve network capacity efficiency.
> > >         Load balancing (parallel MPLS tunnels running between
> > >         a source-dest pair) and trunk protection also become easy.
> > >
> > >     3. QoS/VPN  - MPLS interworking with Diffserv gives you traffic
> > >         isolation (and hence some performance protection). Also,
> > >         MPLS with proper support of resource
> > >         reservation signaling mechanism (e.g., RSVP), you can specify
> > >         thE size of each MPLS 'pipe'.  With a careful traffic trunk
> > > analysis,
> > >         you may set up a set of corresponding pipes (using constraint
> > based
> > >         or explicit routing) such that you can place some application
> > > specific
> > >         (e.g., voice,  video) flows on the trunks while meeting some
> > >         stringent real-time specs (e.g., loss, jitters, latency).
> > >
> > > - Jay
> > >
> > > David Charlap wrote:
> > >
> > > > Mike Badil wrote:
> > > > >
> > > > > I just reading MPLS document, I have a question which I am not 
>really
> > > > > clear to understand, if someone helps I will be happy.
> > > > >
> > > > > The Question is:
> > > > >
> > > > > What makes MPLS to support constraint based routing?
> > > >
> > > > The existance of LSPs makes traffic engineering easier to implement. 
>  It
> > > > does not make it impossible, however.
> > > >
> > > > > If it just adding contsraint metrics to conventional routing in 
>order
> > > > > to support TE.
> > > > > Why it is not possible without MPLS.
> > > >
> > > > Sure, it's possible.  Who said it wasn't?
> > > >
> > > > > In other word, in conventional IP routing, if we add constraint
> > > > > metrics, can conventional IP routing support it also?
> > > >
> > > > I think you're missing the point of MPLS.
> > > >
> > > > MPLS's purpose is not to create the ability to perform 
>constraint-based
> > > > routing and traffic engineering where it was previously impossible.
> > > >
> > > > MPLS's purpose is to create a connection-oriented link layer (COLL).
> > > > Where forwarding decisions are made solely on the basis of a 
>packet's
> > > > label, and not on any other content in the packet.
> > > >
> > > > The use of a COLL is not a requirement for traffic engineering.  It
> > > > simply makes it easier to implement.  With a COLL, the hard work of
> > > > determining the path that data packets must take can be done once, 
>when
> > > > the LSP is set up.  Without a COLL, this work must be done by every
> > > > switch, for every data packet.
> > > >
> > > > Connection oriented link layers are not new.  ATM and Frame Relay 
>also
> > > > use them.  The big thing that makes MPLS special is that it can run 
>over
> > > > nearly any transport medium (ATM, FR, POS, Ethernet, etc) instead of
> > > > being tied to a specific layer-2 encapsulation.  Also, because it 
>uses
> > > > IP for its addressing, it can work with many common routing and
> > > > signalling protocols (like OSPF, IS-IS, and RSVP).
> > > >
> > > > -- David
> > >
> > > --
> > > Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
> > > Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
> > > 600 Mountain Avenue, Room 2C-308,          wang@research.bell-labs.com
> > > Murray Hill, NJ 07974-2070
> > >
> > >
> > >
>
>--
>Regards,
>Arup Das
>(763-1863)
>
>
>

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From owner-mpls@UU.NET  Wed Jun 21 20:52:38 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15758
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 20:52:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiupn09452;
	Thu, 22 Jun 2000 00:50:17 GMT
Received: by mail-control.mail.uu.net 
	id QQiupn16620
	for mpls-outgoing; Thu, 22 Jun 2000 00:49:49 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiupn16615
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 00:49:46 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiupn14424
	for <mpls@UU.NET>; Wed, 21 Jun 2000 20:49:12 -0400 (EDT)
Received: from hotmail.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: f213.law9.hotmail.com [64.4.9.213])
	id QQiupn08253
	for <mpls@UU.NET>; Thu, 22 Jun 2000 00:49:12 GMT
Received: (qmail 20324 invoked by uid 0); 22 Jun 2000 00:49:11 -0000
Message-ID: <20000622004911.20323.qmail@hotmail.com>
Received: from 128.230.209.233 by www.hotmail.com with HTTP;
	Wed, 21 Jun 2000 17:49:11 PDT
X-Originating-IP: [128.230.209.233]
From: "Mike Badil" <hasko10@hotmail.com>
To: mpls@UU.NET
Subject: Re: TE
Date: Wed, 21 Jun 2000 20:49:11 EDT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi

>True - you can do that in IP too.
>
>However, in IP if you want to do explicit routing, you need to include the 
>full
>path information in each IP packet header. Now, that will dramatically 
>increase
>the IP packet header size and consequently, the processing time will 
>increase.
>The explicit path used in MPLS has much less overhead compared to that in 
>IP.
>"alex.mondrus" wrote:

Yes, you are right, explicit routing is clear. I agree with what you 
said,but My question was about Constraint Based Routing. How to choose 
explicit path(best path according to TE)?, that explicit path is not 
shortest path which calculated by OSPF.




Thanks


>
> > In general to do an explicit path set up you do not need to use MPLS.
> >
> > Alex Mondrus
> >
> > http://www.ipoptical.com
> >
> > Traffic Engineering - MPLS allows you to set up tunnels
> > >         with explicit routing so that you can design your routes
> > >         off-line in order to achieve best traffic distribution to
> > >         minimize network hot spots (which often occur in OSPF
> > >         type routing) and improve network capacity efficiency.
> > >         Load balancing (parallel MPLS tunnels running between
> > >         a source-dest pair) and trunk protection also become easy.
> >
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
> > Wilder
> > Sent: Wednesday, June 21, 2000 12:02 PM
> > To: Jay Wang
> > Cc: hasko10@hotmail.com; mpls@UU.NET
> > Subject: Re: TE
> >
> > Very well put Jay.
> >
> > - Dave
> >
> > > Mike,
> > >
> > >     MPLS is not created to support constraint based routing
> > >     and it doesn't.  It let you set up layer two tunnels using
> > >     label switching.  An IP network can benefit from the
> > >     existence of MPLS with at least the following:
> > >
> > >     1. Faster data forwarding at the transient (core) routers -
> > >         This is because there is only label (index) lookup and
> > >         no IP header processing.  This however became much
> > >         weaker an argument lately since lots of work that used
> > >         to be done by software (e.g., header processing,
> > >         classification) now are typically done in ASIC in vendor's
> > >         box.
> > >
> > >     2. Traffic Engineering - MPLS allows you to set up tunnels
> > >         with explicit routing so that you can design your routes
> > >         off-line in order to achieve best traffic distribution to
> > >         minimize network hot spots (which often occur in OSPF
> > >         type routing) and improve network capacity efficiency.
> > >         Load balancing (parallel MPLS tunnels running between
> > >         a source-dest pair) and trunk protection also become easy.
> > >
> > >     3. QoS/VPN  - MPLS interworking with Diffserv gives you traffic
> > >         isolation (and hence some performance protection). Also,
> > >         MPLS with proper support of resource
> > >         reservation signaling mechanism (e.g., RSVP), you can specify
> > >         thE size of each MPLS 'pipe'.  With a careful traffic trunk
> > > analysis,
> > >         you may set up a set of corresponding pipes (using constraint
> > based
> > >         or explicit routing) such that you can place some application
> > > specific
> > >         (e.g., voice,  video) flows on the trunks while meeting some
> > >         stringent real-time specs (e.g., loss, jitters, latency).
> > >
> > > - Jay
> > >
> > > David Charlap wrote:
> > >
> > > > Mike Badil wrote:
> > > > >
> > > > > I just reading MPLS document, I have a question which I am not 
>really
> > > > > clear to understand, if someone helps I will be happy.
> > > > >
> > > > > The Question is:
> > > > >
> > > > > What makes MPLS to support constraint based routing?
> > > >
> > > > The existance of LSPs makes traffic engineering easier to implement. 
>  It
> > > > does not make it impossible, however.
> > > >
> > > > > If it just adding contsraint metrics to conventional routing in 
>order
> > > > > to support TE.
> > > > > Why it is not possible without MPLS.
> > > >
> > > > Sure, it's possible.  Who said it wasn't?
> > > >
> > > > > In other word, in conventional IP routing, if we add constraint
> > > > > metrics, can conventional IP routing support it also?
> > > >
> > > > I think you're missing the point of MPLS.
> > > >
> > > > MPLS's purpose is not to create the ability to perform 
>constraint-based
> > > > routing and traffic engineering where it was previously impossible.
> > > >
> > > > MPLS's purpose is to create a connection-oriented link layer (COLL).
> > > > Where forwarding decisions are made solely on the basis of a 
>packet's
> > > > label, and not on any other content in the packet.
> > > >
> > > > The use of a COLL is not a requirement for traffic engineering.  It
> > > > simply makes it easier to implement.  With a COLL, the hard work of
> > > > determining the path that data packets must take can be done once, 
>when
> > > > the LSP is set up.  Without a COLL, this work must be done by every
> > > > switch, for every data packet.
> > > >
> > > > Connection oriented link layers are not new.  ATM and Frame Relay 
>also
> > > > use them.  The big thing that makes MPLS special is that it can run 
>over
> > > > nearly any transport medium (ATM, FR, POS, Ethernet, etc) instead of
> > > > being tied to a specific layer-2 encapsulation.  Also, because it 
>uses
> > > > IP for its addressing, it can work with many common routing and
> > > > signalling protocols (like OSPF, IS-IS, and RSVP).
> > > >
> > > > -- David
> > >
> > > --
> > > Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
> > > Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
> > > 600 Mountain Avenue, Room 2C-308,          wang@research.bell-labs.com
> > > Murray Hill, NJ 07974-2070
> > >
> > >
> > >
>
>--
>Regards,
>Arup Das
>(763-1863)
>
>
>

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From owner-mpls@UU.NET  Wed Jun 21 23:42:33 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19462
	for <mpls-archive@lists.ietf.org>; Wed, 21 Jun 2000 23:42:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiupy16572;
	Thu, 22 Jun 2000 03:30:32 GMT
Received: by mail-control.mail.uu.net 
	id QQiupy28127
	for mpls-outgoing; Thu, 22 Jun 2000 03:30:09 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiupy28118
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 03:30:01 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiupx27262
	for <mpls@UU.NET>; Wed, 21 Jun 2000 23:29:47 -0400 (EDT)
Received: from baynet.baynetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20])
	id QQiupx14886
	for <mpls@UU.NET>; Thu, 22 Jun 2000 03:29:46 GMT
Received: from mailhost.BayNetworks.COM (hcc0c.s84f5.BayNetworks.COM [132.245.204.12])
	by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id UAA16966
	for <mpls@UU.NET>; Wed, 21 Jun 2000 20:28:12 -0700 (PDT)
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6])
	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id XAA21452
	for <mpls@UU.NET>; Wed, 21 Jun 2000 23:33:41 -0400 (EDT)
Received: from bubba.engeast (bubba [192.168.136.194])
	by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP
	id XAA08732; Wed, 21 Jun 2000 23:29:40 -0400
	for <mpls@UU.NET>
Received: by bubba.engeast (SMI-8.6/SMI-SVR4)
	id XAA16806; Wed, 21 Jun 2000 23:29:40 -0400
From: dwilder@baynetworks.com (David Wilder)
Message-Id: <200006220329.XAA16806@bubba.engeast>
Subject: RSVP Refresh Reduction
To: mpls@UU.NET
Date: Wed, 21 Jun 2000 23:29:39 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
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

Hi,

Where can I find the RSVP Refresh Reduction draft?  I believe it was named
something like "draft-ietf-rsvp-refresh-reduct".

Thanks,

Dave Wilder



From owner-mpls@UU.NET  Thu Jun 22 05:42:21 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24305
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 05:41:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuqs05161;
	Thu, 22 Jun 2000 08:41:24 GMT
Received: by mail-control.mail.uu.net 
	id QQiuqs09209
	for mpls-outgoing; Thu, 22 Jun 2000 08:40:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuqs09204
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 08:40:38 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuqs09094
	for <mpls@UU.NET>; Thu, 22 Jun 2000 04:40:20 -0400 (EDT)
Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8])
	id QQiuqs02068
	for <mpls@UU.NET>; Thu, 22 Jun 2000 08:40:20 GMT
Received: by MILES with Internet Mail Service (5.5.2650.21)
	id <M98R9MY0>; Thu, 22 Jun 2000 09:40:13 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9A8D@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: dwilder@baynetworks.com, mpls@UU.NET
Subject: RE: RSVP Refresh Reduction
Date: Thu, 22 Jun 2000 09:40:04 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Dave,

Go to
http://www.ietf.org/internet-drafts/draft-ietf-rsvp-refresh-reduct-05.txt

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


>-----Original Message-----
>From: dwilder@baynetworks.com [mailto:dwilder@baynetworks.com]
>Sent: Thursday, June 22, 2000 4:30 AM
>To: mpls@UU.NET
>Subject: RSVP Refresh Reduction
>
>
>Hi,
>
>Where can I find the RSVP Refresh Reduction draft?  I believe 
>it was named
>something like "draft-ietf-rsvp-refresh-reduct".
>
>Thanks,
>
>Dave Wilder
>


From owner-mpls@UU.NET  Thu Jun 22 07:43:49 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26169
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 07:43:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuqm01056;
	Thu, 22 Jun 2000 07:01:59 GMT
Received: by mail-control.mail.uu.net 
	id QQiuqm17887
	for mpls-outgoing; Thu, 22 Jun 2000 07:01:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuqm17843
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 07:01:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuqm23353
	for <mpls@UU.NET>; Thu, 22 Jun 2000 03:01:19 -0400 (EDT)
Received: from hermes.research.kpn.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hermes.research.kpn.com [139.63.192.8])
	id QQiuqm29974
	for <mpls@UU.NET>; Thu, 22 Jun 2000 07:01:18 GMT
Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204])
 by research.kpn.com (PMDF V5.2-31 #42699)
 with ESMTP id <01JQWC7S5Y9400060F@research.kpn.com> for mpls@UU.NET; Thu,
 22 Jun 2000 09:01:16 +0200
Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21)
	id <MPLNZ2DL>; Thu, 22 Jun 2000 09:01:09 +0100
Content-return: allowed
Date: Thu, 22 Jun 2000 09:01:05 +0100
From: "Metz, E.T." <E.T.Metz@kpn.com>
Subject: RE: Bandwidth reservation per PSC
To: "'Francois Le Faucheur'" <flefauch@cisco.com>, alchiu@research.att.com
Cc: "'Darek Skalecki'" <dareks@nortelnetworks.com>, "'mpls'" <mpls@UU.NET>
Message-id: <59063B5B4D98D311BC0D0001FA7E4522014437B3@l04.research.kpn.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

isn't this already included in the current drafts? I thought there were
resource classes defined. This may not match with the PSC though.

In general, when (if) some form of classes are available, wouldn't it be
more efficient to map new types of classes to these? Instead of defining
extensions for new types of classes.

Just some thoughts.

cheers,
	Eduard

> -----Original Message-----
> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> Sent: woensdag 21 juni 2000 16:48
> To: alchiu@research.att.com
> Cc: 'Darek Skalecki'; 'mpls'; 'Francois Le Faucheur'
> Subject: RE: Bandwidth reservation per PSC
> 
> 
> Darek, 
> I am hoping to submit something on extensions to IGPs for 
> support of "Class-types". Let me know if you're interested in 
> working on this.
> Francois
> 
> At 17:41 20/06/2000 -0400, Angela Chiu wrote:
> >Darek,
> >
> >I don't think it is currently included in the OSPF and ISIS 
> TE extensions. I
> >am not aware of anyone who is working on it. But I could be 
> wrong since
> >there are so many activities around MPLS, hard to keep track 
> of all of them.
> >
> >Angela
> >
> >-----Original Message-----
> >From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
> >Sent: Tuesday, June 20, 2000 4:06 PM
> >To: alchiu
> >Cc: mpls; 'Francois Le Faucheur'
> >Subject: Re: Bandwidth reservation per PSC
> >
> >
> >Thanks Angela,
> >
> >Are these extensions currently defined for OSPF and ISIS?. 
> If yes then
> >please
> >provide me with a reference, and if not then is anyone 
> working on them ?. I
> >can
> >only find extensions related to advertizing bandwidth 
> availability per
> >priority
> >not resource class.
> >
> >Thanks,
> >
> >Darek
> >
> >
> >Angela Chiu wrote:
> >
> >> Darek,
> >>
> >> These are additional requirements for IGP extensions, as 
> stated in TE
> >> Framework draft
> >> 
> http://www.ietf.org/internet-drafts/draft-ietf-tewg-framework-01.txt
> >> "In order to perform constraint-based routing on a 
> per-class basis for
> >LSPs,
> >> the conventional IGPs (e.g., IS-IS and OSPF) should 
> provide extensions to
> >> propagate per-class resource information."
> >> Then the draft states that "per-class parameters can be 
> aggregated into
> >> per-class-type parameters" for scalability improvements.
> >>
> >> Regards,
> >>
> >> Angela
> >>
> >> -----Original Message-----
> >> From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
> >> Sent: Tuesday, June 20, 2000 2:51 PM
> >> To: Francois Le Faucheur
> >> Cc: mpls@UU.NET; alchiu@att.com
> >> Subject: Re: Bandwidth reservation per PSC
> >>
> >> Thanks Francois,
> >>
> >> My question was indeed related to the distributed model. 
> What I am still
> >not
> >> sure about is how bandwidth availability within OSPF/ISIS 
> is advertized
> >per
> >> PSC or per family  of TE related PSCs when the TE 
> extensions only imply
> >> advertizement per priority. Are colors assigned to 
> different PSCs or
> >> families of TE related PSCs and bandwidth availability 
> advertized per
> >> color?.
> >>
> >> Thanks,
> >>
> >> Darek
> >>
> >> Francois Le Faucheur wrote:
> >>
> >> > Darek,
> >> >
> >> > At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
> >> > >Hi,
> >> > >
> >> > >I have a question with regard to bandwidth availability 
> per PSC and TE
> >> > >extensions to OSPF/ISIS.
> >> > >
> >> > >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in 
> APPENDIX B Scenario 2
> >> > >about constraint based routing being
> >> > >performed separately for each PSC  where one of the 
> constraints is
> >> > >availability of bandwidth from the bandwidth
> >> > >allocated to the relevant PSC.
> >> > >
> >> > >My question is how TE extensions to OSPF/ISIS support 
> advertizing
> >> > >bandwidth availability per PSC. The only way I can
> >> > >think this can be achieved is by assigning different 
> colors/resource
> >> > >classes to different PSCs thus advertizing bandwidth
> >> > >availability per PSC simply as bandwidth availability per
> >color/resource
> >> > >class. Is this correct?.
> >> > >
> >> > >If it is correct then how serious is the 
> scaling/operational issue at
> >> > >least within OSPF since N  TE LSAs are needed for  N
> >> > >PSCs  for every link, implying lots of LSA traffic not 
> to mention
> >> > >storage within LSDB (which I gather can only store
> >> > >65536 TE LSAs).
> >> > >
> >> >
> >> > First, of course , in some environments, Constraint 
> Based Routing may be
> >> performed "off-line"/"in a Centralised Manner". In these 
> situations,
> >per-PSC
> >> bandwidth availability can be determined by the 
> centralised tool without
> >> relying on extensions to OSPF/ISIS.
> >> >
> >> > Where Constraint Based Routing is performed 
> "on-line"/"in a Distributed
> >> Manner", then yes, OSPF/ISIS are required to propagate all 
> necessary
> >> bandwidth information. This could be achieved in a number of ways:
> >> >         - one approach would be to advertise bandwidth 
> information for
> >> every PSC. As you are pointing out above, this may lead to
> >> scaling/operational issues earlier than desired.
> >> >         - another approach would be to advertise 
> bandwidth information
> >> only for each "family/class" of PSCs. A family/class of 
> PSC would comprise
> >> all the PSCs which share the same bandwidth constraints. 
> It is likely that
> >> multiple PSCs can share the same bandwidth constraints (eg
> >> "max-reservable-bandwidth"). For instance, multiple 
> Premium/Non-real-time
> >> PSCs may share the same "max-reservable-bandwidth". In 
> that case, you have
> >> traded a little bit of fine-grain control (you can't 
> enforce bandwidth
> >> constraints which are different for absolutely every PSC), 
> but you have
> >> significantly gained in scalability of OSPF/ISIS by "only" 
> advertising 2/3
> >> available bandwidth information.
> >> >
> >> > You will find some text on the second approach in 
> section "6.7 Traffic
> >> Engineering in Diffserv Environments" of
> ><draft-ietf-tewg-framework-01.txt>:
> >> >
> >> >    "Instead of having per-class parameters being configured and
> >> >    propagated on each LSR interface, per-class parameters can be
> >> >    aggregated into per-class-type parameters. The main 
> motivation for
> >> >    grouping a set of classes into a class-type is to improve the
> >> >    scalability of IGP link state advertisements by propagating
> >> >    information on a per-class-type basis instead of on a 
> per-class
> >> >    basis, and also to allow better bandwidth sharing 
> between  classes in
> >> >    the same class-type..."
> >> >
> >> > Francois
> >> >
> >> > >Thanks,
> >> > >
> >> > >Darek Skalecki
> >> > >Nortel Networks
> >> > >
> >> >
> >> > _________________________________________________________________
> >> > Francois Le Faucheur
> >> > Development Engineer, IOS Layer 3 Services
> >> > Cisco Systems
> >> > Office Phone:           +33 4 92 96 75 64
> >> > Home Office Phone:     +33 4 92 94 00 78
> >> > Mobile :               +33 6 89 108 159
> >> > Vmail:                 +33 1 58 04 62 66
> >> > Fax:                   +33 4 92 96 79 08
> >> > Email:                  flefauch@cisco.com
> >> > _________________________________________________________________
> >> > Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 
> Valbonne -
> >France
> >> > _________________________________________________________________
> > 
> _________________________________________________________________
> Francois Le Faucheur   
> Development Engineer, IOS Layer 3 Services 
> Cisco Systems 
> Office Phone:   	+33 4 92 96 75 64
> Home Office Phone:     +33 4 92 94 00 78
> Mobile :               +33 6 89 108 159
> Vmail:                 +33 1 58 04 62 66
> Fax:                   +33 4 92 96 79 08
> Email:          	flefauch@cisco.com
> _________________________________________________________________
> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 
> Valbonne - France
> _________________________________________________________________ 
> 


From owner-mpls@UU.NET  Thu Jun 22 09:29:16 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05380
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 09:29:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiurl21205;
	Thu, 22 Jun 2000 13:27:42 GMT
Received: by mail-control.mail.uu.net 
	id QQiurl21158
	for mpls-outgoing; Thu, 22 Jun 2000 13:27:19 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiurl21149
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 13:27:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiurl12407
	for <mpls@UU.NET>; Thu, 22 Jun 2000 09:26:45 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQiurl24887
	for <mpls@UU.NET>; Thu, 22 Jun 2000 13:26:44 GMT
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by ertpg14e1.nortelnetworks.com; Thu, 22 Jun 2000 09:15:07 -0400
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id NKGZ3T5B; Thu, 22 Jun 2000 09:15:05 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2LHF69X; Thu, 22 Jun 2000 09:15:05 -0400
Message-ID: <39521158.149F7B2C@americasm01.nt.com>
Date: Thu, 22 Jun 2000 09:15:05 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: "Metz, E.T." <E.T.Metz@kpn.com>
CC: "'Francois Le Faucheur'" <flefauch@cisco.com>, alchiu@research.att.com,
        "'mpls'" <mpls@UU.NET>
Subject: Re: Bandwidth reservation per PSC
References: <59063B5B4D98D311BC0D0001FA7E4522014437B3@l04.research.kpn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Actually what is currently defined for advertizement is bandwidth
availability by priority not resource/color/class/class-type.

Francois: I would be interested in working on class-type extensions to
IGPs. Let me know how I can contribute, maybe I can review what you are
going to propose.

Thanks,

Darek

Metz, E.T. wrote:

> Hi,
>
> isn't this already included in the current drafts? I thought there were
> resource classes defined. This may not match with the PSC though.
>
> In general, when (if) some form of classes are available, wouldn't it be
> more efficient to map new types of classes to these? Instead of defining
> extensions for new types of classes.
>
> Just some thoughts.
>
> cheers,
>         Eduard
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> > Sent: woensdag 21 juni 2000 16:48
> > To: alchiu@research.att.com
> > Cc: 'Darek Skalecki'; 'mpls'; 'Francois Le Faucheur'
> > Subject: RE: Bandwidth reservation per PSC
> >
> >
> > Darek,
> > I am hoping to submit something on extensions to IGPs for
> > support of "Class-types". Let me know if you're interested in
> > working on this.
> > Francois
> >
> >



From owner-mpls@UU.NET  Thu Jun 22 09:49:41 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05834
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 09:49:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiurn18192;
	Thu, 22 Jun 2000 13:48:30 GMT
Received: by mail-control.mail.uu.net 
	id QQiurn22698
	for mpls-outgoing; Thu, 22 Jun 2000 13:47:59 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiurn22691
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 13:47:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiurn16080
	for <mpls@UU.NET>; Thu, 22 Jun 2000 09:47:18 -0400 (EDT)
Received: from apollo.mctr.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89])
	id QQiurn18337
	for <mpls@UU.NET>; Thu, 22 Jun 2000 13:47:18 GMT
Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142])
	by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id JAA01358
	for <mpls@UU.NET>; Thu, 22 Jun 2000 09:47:17 -0400 (EDT)
Received: from localhost (mpls@localhost)
	by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id JAA01742
	for <mpls@UU.NET>; Thu, 22 Jun 2000 09:50:29 -0400 (EDT)
X-Authentication-Warning: mercury.mctr.umbc.edu: mpls owned process doing -bs
Date: Thu, 22 Jun 2000 09:50:28 -0400 (EDT)
From: MPLS <mpls@apollo.mctr.umbc.edu>
X-Sender: mpls@mercury.mctr.umbc.edu
To: mpls@UU.NET
Subject: TE conversions from Reserved to unreserved bandwidth
Message-ID: <Pine.GSO.3.95.1000622094220.28746A-100000@mercury.mctr.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

This is in reference to implementation of IGP extensions to support TE.

If the IGP advertises the Reserved bandwidth per priority, then what are
the mechanism/equations to deduce the Unreserved bandwidth per priority?
Also how about the reverse mapping (i.e from Reserved bandwidth per
priority how do we et the Unreserved b/w per priority).

Thanks in advance,
gargi



From owner-mpls@UU.NET  Thu Jun 22 10:36:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06890
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 10:36:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiurq09325;
	Thu, 22 Jun 2000 14:35:18 GMT
Received: by mail-control.mail.uu.net 
	id QQiurq07398
	for mpls-outgoing; Thu, 22 Jun 2000 14:34:43 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiurq07395
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 14:34:42 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiurq25546
	for <mpls@uu.net>; Thu, 22 Jun 2000 10:33:43 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQiurq07656
	for <mpls@uu.net>; Thu, 22 Jun 2000 14:33:42 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA28123
	for <mpls@uu.net>; Thu, 22 Jun 2000 07:33:52 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA29228 for mpls@uu.net; Thu, 22 Jun 2000 10:33:40 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiupk13356
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 00:03:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiupk09309
	for <mpls@UU.NET>; Wed, 21 Jun 2000 20:02:54 -0400 (EDT)
Received: from scexch.rampnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.240.45.25])
	id QQiupk28081
	for <mpls@UU.NET>; Thu, 22 Jun 2000 00:02:54 GMT
Received: by scexch.rampnet.com with Internet Mail Service (5.5.2650.10)
	id <NMAFM0A0>; Wed, 21 Jun 2000 17:03:00 -0700
Message-ID: <D101AF7CF027D211A00A00805FBB32A4EB2B0E@scexch.rampnet.com>
From: Ashok Ramchandra <ARamchandra@RampNet.com>
To: "'Jay Wang '" <wang@research.bell-labs.com>,
        "'alex.mondrus '"
	 <alex.mondrus@ipoptical.com>
Cc: "'mpls '" <mpls@UU.NET>
Subject: RE: TE
Date: Wed, 21 Jun 2000 17:02:49 -0700
X-Mailer: Internet Mail Service (5.5.2650.10)
Sender: owner-mpls@UU.NET
Precedence: bulk

I have a small confusion here. It might be the case that I am missing
something. 

I can completely understand the second part of the argument that an external
mechanism should be present in absence of MPLS to signal the participating
routers in an explicit route, but not the first one. Even in case of MPLS
aware domain, if one is to create a ER-LSP, the originator of an LSP should
have a static route configured. If that is not neccessary for an originator
of a LSP and can be done using the routing protocols present, then what is
stopping the non-mpls N/W to do it?

Thanks,
R.Ashok
-----Original Message-----
From: Jay Wang
To: alex.mondrus
Cc: mpls
Sent: 6/21/00 1:21 PM
Subject: Re: TE

Alex,

    Yes, you can statically set up an explicit route for a set of
    flows without MPLS.  But the focus really is in traffic
    engineering. Static routing will not be a proper solution to deal
    with TE for any sizable ISP.  In addition to the salability
    concern as Arup pointed out, there is also a management issue.
    With MPLS, in ISP's management system pertaining to TE each
    tunnel can be handled as a single unit. The signaling and control
    is all done "in the network".  On the other hand, without MPLS the
    ISP's external management system most likely has to provide a
    wrapping (to create a view of a "logical tunnel") that signals and
    coordinates all the participating routers externally.  This raises
the
    issue of complexity (as if managing thousands of MPLS-LSPs is not
    complex enough) and perhaps reliability.

- Jay


Arup Das wrote:

> True - you can do that in IP too.
>
> However, in IP if you want to do explicit routing, you need to include
the full
> path information in each IP packet header. Now, that will dramatically
increase
> the IP packet header size and consequently, the processing time will
increase.
> The explicit path used in MPLS has much less overhead compared to that
in IP.
> "alex.mondrus" wrote:
>
> > In general to do an explicit path set up you do not need to use
MPLS.
> >
> > Alex Mondrus
> >
> > http://www.ipoptical.com
> >
> > Traffic Engineering - MPLS allows you to set up tunnels
> > >         with explicit routing so that you can design your routes
> > >         off-line in order to achieve best traffic distribution to
> > >         minimize network hot spots (which often occur in OSPF
> > >         type routing) and improve network capacity efficiency.
> > >         Load balancing (parallel MPLS tunnels running between
> > >         a source-dest pair) and trunk protection also become easy.
> >
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
> > Wilder
> > Sent: Wednesday, June 21, 2000 12:02 PM
> > To: Jay Wang
> > Cc: hasko10@hotmail.com; mpls@UU.NET
> > Subject: Re: TE
> >
> > Very well put Jay.
> >
> > - Dave
> >
> > > Mike,
> > >
> > >     MPLS is not created to support constraint based routing
> > >     and it doesn't.  It let you set up layer two tunnels using
> > >     label switching.  An IP network can benefit from the
> > >     existence of MPLS with at least the following:
> > >
> > >     1. Faster data forwarding at the transient (core) routers -
> > >         This is because there is only label (index) lookup and
> > >         no IP header processing.  This however became much
> > >         weaker an argument lately since lots of work that used
> > >         to be done by software (e.g., header processing,
> > >         classification) now are typically done in ASIC in vendor's
> > >         box.
> > >
> > >     2. Traffic Engineering - MPLS allows you to set up tunnels
> > >         with explicit routing so that you can design your routes
> > >         off-line in order to achieve best traffic distribution to
> > >         minimize network hot spots (which often occur in OSPF
> > >         type routing) and improve network capacity efficiency.
> > >         Load balancing (parallel MPLS tunnels running between
> > >         a source-dest pair) and trunk protection also become easy.
> > >
> > >     3. QoS/VPN  - MPLS interworking with Diffserv gives you
traffic
> > >         isolation (and hence some performance protection). Also,
> > >         MPLS with proper support of resource
> > >         reservation signaling mechanism (e.g., RSVP), you can
specify
> > >         thE size of each MPLS 'pipe'.  With a careful traffic
trunk
> > > analysis,
> > >         you may set up a set of corresponding pipes (using
constraint
> > based
> > >         or explicit routing) such that you can place some
application
> > > specific
> > >         (e.g., voice,  video) flows on the trunks while meeting
some
> > >         stringent real-time specs (e.g., loss, jitters, latency).
> > >
> > > - Jay
> > >
> > > David Charlap wrote:
> > >
> > > > Mike Badil wrote:
> > > > >
> > > > > I just reading MPLS document, I have a question which I am not
really
> > > > > clear to understand, if someone helps I will be happy.
> > > > >
> > > > > The Question is:
> > > > >
> > > > > What makes MPLS to support constraint based routing?
> > > >
> > > > The existance of LSPs makes traffic engineering easier to
implement.  It
> > > > does not make it impossible, however.
> > > >
> > > > > If it just adding contsraint metrics to conventional routing
in order
> > > > > to support TE.
> > > > > Why it is not possible without MPLS.
> > > >
> > > > Sure, it's possible.  Who said it wasn't?
> > > >
> > > > > In other word, in conventional IP routing, if we add
constraint
> > > > > metrics, can conventional IP routing support it also?
> > > >
> > > > I think you're missing the point of MPLS.
> > > >
> > > > MPLS's purpose is not to create the ability to perform
constraint-based
> > > > routing and traffic engineering where it was previously
impossible.
> > > >
> > > > MPLS's purpose is to create a connection-oriented link layer
(COLL).
> > > > Where forwarding decisions are made solely on the basis of a
packet's
> > > > label, and not on any other content in the packet.
> > > >
> > > > The use of a COLL is not a requirement for traffic engineering.
It
> > > > simply makes it easier to implement.  With a COLL, the hard work
of
> > > > determining the path that data packets must take can be done
once, when
> > > > the LSP is set up.  Without a COLL, this work must be done by
every
> > > > switch, for every data packet.
> > > >
> > > > Connection oriented link layers are not new.  ATM and Frame
Relay also
> > > > use them.  The big thing that makes MPLS special is that it can
run over
> > > > nearly any transport medium (ATM, FR, POS, Ethernet, etc)
instead of
> > > > being tied to a specific layer-2 encapsulation.  Also, because
it uses
> > > > IP for its addressing, it can work with many common routing and
> > > > signalling protocols (like OSPF, IS-IS, and RSVP).
> > > >
> > > > -- David
> > >
> > > --
> > > Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
> > > Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
> > > 600 Mountain Avenue, Room 2C-308,
wang@research.bell-labs.com
> > > Murray Hill, NJ 07974-2070
> > >
> > >
> > >
>
> --
> Regards,
> Arup Das
> (763-1863)




From owner-mpls@UU.NET  Thu Jun 22 11:08:06 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07739
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 11:08:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiurs11732;
	Thu, 22 Jun 2000 15:07:01 GMT
Received: by mail-control.mail.uu.net 
	id QQiurs16043
	for mpls-outgoing; Thu, 22 Jun 2000 15:06:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiurs15972
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 15:06:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiurs01834
	for <mpls@uu.net>; Thu, 22 Jun 2000 11:06:15 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiurs10053
	for <mpls@uu.net>; Thu, 22 Jun 2000 15:06:14 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA22062
	for mpls@uu.net; Thu, 22 Jun 2000 11:06:13 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiurs15672
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 15:05:53 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiurs01708
	for <mpls@uu.net>; Thu, 22 Jun 2000 11:05:45 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiurs10187
	for <mpls@uu.net>; Thu, 22 Jun 2000 15:05:44 GMT
Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA21989;
	Thu, 22 Jun 2000 11:05:43 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA07660; Thu, 22 Jun 2000 11:05:43 -0400 (EDT)
Message-Id: <200006221505.LAA07660@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Cc: swallow@cisco.com
Subject: LSP hierarchy with MPLS TE
Date: Thu, 22 Jun 2000 11:05:43 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Folks,

Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt
be accepted as a work group document.  So far I've only seen support.
If there are no objects by 6/27, we'll declare it so.

...George

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






From owner-mpls@UU.NET  Thu Jun 22 14:24:08 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12326
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 14:24:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiusf28592;
	Thu, 22 Jun 2000 18:23:24 GMT
Received: by mail-control.mail.uu.net 
	id QQiusf11513
	for mpls-outgoing; Thu, 22 Jun 2000 18:22:42 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiusf11489
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 18:22:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiusf14056
	for <mpls@uu.net>; Thu, 22 Jun 2000 14:22:12 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiusf12054
	for <mpls@uu.net>; Thu, 22 Jun 2000 18:22:07 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA20250
	for mpls@uu.net; Thu, 22 Jun 2000 14:22:06 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiusf11350
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 18:21:37 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiusf08720
	for <mpls@uu.net>; Thu, 22 Jun 2000 14:21:14 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiusf11123
	for <mpls@uu.net>; Thu, 22 Jun 2000 18:21:13 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA20398; Thu, 22 Jun 2000 14:21:13 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-196.cisco.com [161.44.134.196])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA16286;
	Thu, 22 Jun 2000 14:21:37 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000622141338.04dd6480@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 22 Jun 2000 14:17:57 -0400
To: "Friedeborn, William" <wfriedeb@netplane.com>,
        "Friedeborn, William" <wfriedeb@netplane.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <7BF58A904536D411ADD400508BC97B8501BE68@xover1.hjinc.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_14220241==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_14220241==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi,

>I took this to mean that the Tunnel objects can be brought into existence 
>by either an SNMP request or by a signaling entity at the ingress/egress 
>nodes. In the case of an SNMP request, the creation of the tunnel 
>(MPLS_TE_MIB) objects in the head end node would be the trigger that 
>caused the creation of the LSR-MIB objects in the head end, and kick off 
>the protocols to signal the lsp to the other nodes (assuming the 
>SignalingProto object is LDP or RSVP). In the intermediate nodes, the 
>LSR-MIB objects are created till the egress node is reached, at which 
>point the Tunnel objects are created here (as this is the egress end). 
>(Actually, the sig proto reaches egress node, Tunnel objects/LSR-MIB 
>created and intermediate nodes filled in on return trip). In the case 
>where it is a signaling entity that is creating the Tunnel objects, I 
>could see that the ingress/egress node knows that the LSP is an 
>Originating/Terminating LSP and could create the Tunnel objects.

         Yes, your understanding of the MIB seems correct. Initially the intent
of the TE MIB was for its information to be available at the ingress and
egress. However, some implementations may choose to make intermediate
tunnel hop information available at midpoints along the tunnel's path. There
is nothing in the standards which precludes this. However, since this is
an optional behavior, we did not make it mandatory in the MIB.

>What is it in the signaling protocol (RSVP or LDP) that would tell the 
>intermediate node that the LSP being created should have objects other 
>than LSR-MIB objects created?

         I think that this is an implementation issue. For example, if
one's device supports RSVP, then one may obtain this information
at intermediate nodes by capturing the recorded route.

         --Tom


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

<html>
<font face=3D"arial"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
</font><blockquote type=3Dcite cite><font face=3D"arial" size=3D2 color=3D"#=
0000FF">I
took this to mean that the Tunnel objects can be brought into existence
by either an SNMP request or by a signaling entity at the ingress/egress
nodes. In the case of an SNMP request, the creation of the tunnel
(MPLS_TE_MIB) objects in the head end node would be the trigger that
caused the creation of the LSR-MIB objects in the head end, and kick off
the protocols to signal the lsp to the other nodes (assuming the
SignalingProto object is LDP or RSVP). In the intermediate nodes, the
LSR-MIB objects are created till the egress node is reached, at which
point the Tunnel objects are created here (as this is the egress end).
(Actually, the sig proto reaches egress node, Tunnel objects/LSR-MIB
created and intermediate nodes filled in on return trip). In the case
where it is a signaling entity that is creating the Tunnel objects, I
could see that the ingress/egress node knows that the LSP is an
Originating/Terminating LSP and could create the Tunnel
objects.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes, your
understanding of the MIB seems correct. Initially the intent<br>
of the TE MIB was for its information to be available at the ingress
and<br>
egress. However, some implementations may choose to make intermediate
<br>
tunnel hop information available at midpoints along the tunnel's path.
There<br>
is nothing in the standards which precludes this. However, since this
is<br>
an optional behavior, we did not make it mandatory in the MIB.<br>
<br>
<blockquote type=3Dcite cite><font face=3D"arial" size=3D2 color=3D"#0000FF"=
>What
is it in the signaling protocol (RSVP or LDP) that would tell the
intermediate node that the LSP being created should have objects other
than LSR-MIB objects created?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I think
that this is an implementation issue. For example, if<br>
one's device supports RSVP, then one may obtain this information<br>
at intermediate nodes by capturing the recorded route.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
</html>

--=====================_14220241==_.ALT--




From owner-mpls@UU.NET  Thu Jun 22 14:26:29 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12363
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 14:26:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiusf15276;
	Thu, 22 Jun 2000 18:25:40 GMT
Received: by mail-control.mail.uu.net 
	id QQiusf11876
	for mpls-outgoing; Thu, 22 Jun 2000 18:25:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiusf11868
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 18:25:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiusf14538
	for <mpls@uu.net>; Thu, 22 Jun 2000 14:24:51 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiusf00127
	for <mpls@uu.net>; Thu, 22 Jun 2000 18:24:50 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA20788
	for mpls@uu.net; Thu, 22 Jun 2000 14:24:50 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiusf11744
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 18:24:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiusf14409
	for <mpls@UU.NET>; Thu, 22 Jun 2000 14:24:11 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiusf29440
	for <mpls@UU.NET>; Thu, 22 Jun 2000 18:24:10 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA20819; Thu, 22 Jun 2000 14:24:00 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-196.cisco.com [161.44.134.196])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA16296;
	Thu, 22 Jun 2000 14:24:26 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000622141816.04428250@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 22 Jun 2000 14:20:46 -0400
To: Adrian Farrel <AF@datcon.co.uk>, mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>
In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2C9A42@monk.datcon.co.uk>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_14388771==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_14388771==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi,

>I'd rather like to hang on to the direction field.  It proves very useful 
>for bi-directional tunnels!
>Did you have a particular reason why you consider it no longer appropriate 
>to consider bi-directional tunnels?

         There is nothing in the standard documents which
defines what bidirectional tunnels are. The standard MIB cannot
model non-standard objects.

         --Tom



>
>Cheers,
>Adrian
>
>--
>Adrian Farrel  <mailto:af@datcon.co.uk>mailto:af@datcon.co.uk
>Network Convergence Group
>Data Connection Ltd., Chester, UK
><http://www.datcon.co.uk/>http://www.datcon.co.uk/
>Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
>>-----Original Message-----
>>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
>>Sent: Monday, June 19, 2000 1:59 PM
>>To: mpls@UU.NET
>>Cc: arun Viswanathan; cheenu Srinivasan
>>Subject: Re: Additional Index for TE-MIB: mplsTunnelTable
>>
>>
>>         Hi,
>>
>>         Responses are highlighted in blue.
>>
>>
>>>It is not clear to me how to represent a bi-directional tunnel with the MIB.
>>>Some of my confusion may come from the fact that I don't understand the
>>>mplsTunnelDirection object. For example, what does it mean to have this 
>>>object
>>>set to "bi-directional"? Does it mean that this row refers to a 
>>>bi-directional
>>>tunnel? Does the TunnelDirection (in, out) have any significance at the 
>>>tunnel
>>>midpoint? What role does the cookie (or the lack of one!) play in
>>>bi-directional tunnels?
>>
>>         We will remove this object since it is a vestage from the
>>time when we had bi-directional tunnels in mind (this will be
>>removed along with the cookie objects). This will instead be replaced
>>by an object which indicates whether the LSR is a tunnel src, dst, or
>>intermediate point.
>>
>>         --Tom

--=====================_14388771==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="arial"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">I'd
rather like to hang on to the direction field.&nbsp; It proves very
useful for bi-directional tunnels!<br>
Did you have a particular reason why you consider it no longer
appropriate to consider bi-directional tunnels?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>There is
nothing in the standard documents which<br>
defines what bidirectional tunnels are. The standard MIB cannot <br>
model non-standard objects.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Cheers,</font><br>
<font face="arial" size=2 color="#0000FF">Adrian</font><br>
<br>
<font size=2>--<br>
Adrian Farrel&nbsp;
<a href="mailto:af@datcon.co.uk">mailto:af@datcon.co.uk</a><br>
Network Convergence Group<br>
Data Connection Ltd., Chester, UK<br>
<a href="http://www.datcon.co.uk/">http://www.datcon.co.uk/</a><br>
Tel: +44 (0) 1244 313440&nbsp; Fax: +44 (0) 1244 312422<br>
</font><blockquote type=cite cite><font face="tahoma" size=2>-----Original
Message-----<br>
<b>From:</b> Thomas D. Nadeau
[<a href="mailto:tnadeau@cisco.com" eudora="autourl">mailto:tnadeau@cisco.com</a>]<br>
<b>Sent:</b> Monday, June 19, 2000 1:59 PM<br>
<b>To:</b> mpls@UU.NET<br>
<b>Cc:</b> arun Viswanathan; cheenu Srinivasan<br>
<b>Subject:</b> Re: Additional Index for TE-MIB: mplsTunnelTable<br>
<br>
</font><font color="#0000FF"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Responses
are highlighted in blue.<br>
<br>
<br>
</font><blockquote type=cite cite>It is not clear to me how to represent
a bi-directional tunnel with the MIB.<br>
Some of my confusion may come from the fact that I don't understand
the<br>
mplsTunnelDirection object. For example, what does it mean to have this
object<br>
set to &quot;bi-directional&quot;? Does it mean that this row refers to a
bi-directional<br>
tunnel? Does the TunnelDirection (in, out) have any significance at the
tunnel<br>
midpoint? What role does the cookie (or the lack of one!) play in<br>
bi-directional tunnels?</blockquote><br>
<font color="#0000FF"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>We
will remove this object since it is a vestage from the<br>
time when we had bi-directional tunnels in mind (this will be<br>
removed along with the cookie objects). This will instead be
replaced<br>
by an object which indicates whether the LSR is a tunnel src, dst,
or<br>
intermediate point.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
</font></blockquote></blockquote></html>

--=====================_14388771==_.ALT--




From owner-mpls@UU.NET  Thu Jun 22 14:44:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12803
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 14:44:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiusg21887;
	Thu, 22 Jun 2000 18:43:38 GMT
Received: by mail-control.mail.uu.net 
	id QQiusg14810
	for mpls-outgoing; Thu, 22 Jun 2000 18:43:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiusg14776
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 18:42:47 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiusg18510
	for <mpls@uu.net>; Thu, 22 Jun 2000 14:41:52 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiusg29677
	for <mpls@uu.net>; Thu, 22 Jun 2000 18:41:51 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA23898
	for mpls@uu.net; Thu, 22 Jun 2000 14:41:51 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiusg14592
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 18:41:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiusg12797
	for <mpls@UU.NET>; Thu, 22 Jun 2000 14:40:59 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiusg29010
	for <mpls@UU.NET>; Thu, 22 Jun 2000 18:40:59 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA23053; Thu, 22 Jun 2000 14:40:47 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-196.cisco.com [161.44.134.196])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA16365;
	Thu, 22 Jun 2000 14:41:10 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000622142059.0442ee30@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 22 Jun 2000 14:37:29 -0400
To: Adrian Farrel <AF@datcon.co.uk>, mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: MPLS TE MIB - Doubts
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>
In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2C9A43@monk.datcon.co.uk>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_15391541==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_15391541==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         Hi,

> >>>>3. LSPId explicit hop type
> >>>>Is there any reason to prevent configuration of an explicit hop
> >>>>of type LSPId?  I suggested some ASN.1 for this in an email to
> >>>>Tom on 7th Jan.
>
> >>>If ldp is chosen to route the tunnel then we'll add this as
> >>>a choice for the hop type.
>
> >>I'm not quite sure what your answer means.  I think you're
> >>saying you'll add the hop type but only allow it if the
> >>signaling protocol is flagged as [CR-]LDP.  This would be
> >>great.

         Perhaps I was confused about this. Now that Arun and I
have discussed this, we now recall that we agreed to add this.
Here is a description of the object type. We have also added the
LSP ID to the hop entry as well.

mplsTunnelHopAddrType OBJECT-TYPE
SYNTAX        INTEGER { ipV4(1),
ipV6(2),
asNumber(3),
lspid(4)
}

> >>>>6. MPLS Tunnel Resource Table
> >>>>This table is a welcome addition.
> >>>>I believe you need to be very careful because of the differences
> >>>>between forward and reverse resource reservation.  For example,
> >>>>for an RSVP tunnel, what is configured here must be the TSpec.
> >>>>Clearly, sharing TSpecs is useful from a configuration point of
> >>>>view, but says nothing about sharing of resources which is
> >>>>determined elsewhere in the network.  Is it your intention that
> >>>>this table is updated on the reverse path?
>
> >>>tunnels are unidirectional; so the issue of bidirectional
> >>>resource reservation does not arise
>
> >>It wasn't my intention to talk about bi-directional LSPs at
> >>this point (although that is an interesting topic of
> >>conversation in this regard).  When I talk about forward and
> >>reverse reservation I am simply distinguishing between CR-LDP
> >>where the resources are reserved as the Label_Request traverses
> >>the network, and RSVP where the resources are (strictly speaking)
> >>only reserved when the Resv travels back.  Thus the information
> >>in the MIB row is far more likely to reflect the true reservation
> >>in CR-LDP than in RSVP unless the table is updated by the
> >>protocol code on completion of LSP setup to reflect the flowspec.
>
> >The ARHopTable is captures the actual reservation, and is
> >applicable to both signaling protocols.
>
>I think I have missed something here.  We are still talking about version 03
>of the draft aren't we?  In my copy the ARHopTable contains only the output
>from the Recorded Route object.
>
>So back to the question about recording the difference between requested
>traffic parameters and actual reservations.
>
>- Are you saying that the mplsTunnelResourceTable is updated
>   to reflect the actual resources reserved?  This would
>   intuitively be the job of mplsTrafficParamTable in the LSR
>   MIB.

         Yes, the parameters configured in the mplsTunnelResourceTable
are configured or desired values only. One should look to the
LSR MIB for the actual values. When a tunnel is signaled,
it will point at an LSP in the LSR MIB.

>- If this is what you are saying then you will need to update
>   most of the text which describes the movement of data from
>   mplsTunnelResourceTable to mplsTrafficParamTable but not
>   vice versa.

         Yes, this should be the case. When a tunnel is specified
(i.e.: configured), and it is successfully signalled with those
parameters, then those parameters should be reflected in the underlying
LSP (i.e.: in the LSR MIB). If they aren't, then an appropriate LSP
could not be found to satisfy the desired tunnel configuration,
and hence, the tunnel should not have been signalled.

>- Do you intend that sharing entries in mplsTunnelResourceTable
>   between rows in mplsTunnelTable reflects sharing TSpecs or
>   sharing real reservations?

         Yes, it was our intent that when more than one tunnel
points at the same mplsTunnelResourceTable entry, that they
indeed share the same RSVP reservation/session. Furthermore,
because they share the same reservation, they should also
share the same traffic specification.

>These can be very different matters in RSVP.

         Can you please be more specific?


         --Tom



> >>>>15. mplsTunnelXCIndex
> >We would prefer the following:
> >       "This variable represents an index into the
> >        mplsXCTable. This table identifies the segments
> >        that compose this tunnel, their characteristics,
> >        and relationships to each other.
> >        In the case where a signaling protocol is used
> >        to set up the tunnel, this field is to reflect
> >        the row in the mplsXCTable
> >        that has been set up to describe the cross-
> >        connect for this LSP and SHOULD NOT be changed.
> >        In the case where the tunnel has been statically
> >        configured by writing to the tables in the LSR
> >        MIB, this field MUST be set to indicate the
> >        correct entry in the mplsXCTable."
>
>Fine. You have only removed the bit about who sets the field in the signaled
>case from my text, right?
>
>Regards,
>Adrian
>--
>Adrian Farrel  mailto:af@datcon.co.uk
>Network Convergence Group
>Data Connection Ltd., Chester, UK
>http://www.datcon.co.uk/
>Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

--=====================_15391541==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
<blockquote type=cite cite>&gt;&gt;&gt;&gt;3. LSPId explicit hop type
<br>
&gt;&gt;&gt;&gt;Is there any reason to prevent configuration of an
explicit hop <br>
&gt;&gt;&gt;&gt;of type LSPId?&nbsp; I suggested some ASN.1 for this in
an email to <br>
&gt;&gt;&gt;&gt;Tom on 7th Jan. <br>
<br>
&gt;&gt;&gt;If ldp is chosen to route the tunnel then we'll add this as
<br>
&gt;&gt;&gt;a choice for the hop type. <br>
<br>
&gt;&gt;I'm not quite sure what your answer means.&nbsp; I think
you're<br>
&gt;&gt;saying you'll add the hop type but only allow it if the <br>
&gt;&gt;signaling protocol is flagged as [CR-]LDP.&nbsp; This would
be<br>
&gt;&gt;great.</blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Perhaps I
was confused about this. Now that Arun and I <br>
have discussed this, we now recall that we agreed to add this.<br>
Here is a description of the object type. We have also added the<br>
LSP ID to the hop entry as well.<br>
<br>
mplsTunnelHopAddrType OBJECT-TYPE<br>
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER { ipV4(1),
<dl>
<dl>
<dl>
<dl>
<dl>
<dl>
<dd>ipV6(2),
<dd>asNumber(3),
<dd>lspid(4) 
</dl>
</dl>
</dl>
</dl>
</dl>
</dl>}<br>
<br>
<blockquote type=cite cite>&gt;&gt;&gt;&gt;6. MPLS Tunnel Resource Table
<br>
&gt;&gt;&gt;&gt;This table is a welcome addition. <br>
&gt;&gt;&gt;&gt;I believe you need to be very careful because of the
differences <br>
&gt;&gt;&gt;&gt;between forward and reverse resource reservation.&nbsp;
For example, <br>
&gt;&gt;&gt;&gt;for an RSVP tunnel, what is configured here must be the
TSpec.&nbsp; <br>
&gt;&gt;&gt;&gt;Clearly, sharing TSpecs is useful from a configuration
point of <br>
&gt;&gt;&gt;&gt;view, but says nothing about sharing of resources which
is <br>
&gt;&gt;&gt;&gt;determined elsewhere in the network.&nbsp; Is it your
intention that <br>
&gt;&gt;&gt;&gt;this table is updated on the reverse path? <br>
<br>
&gt;&gt;&gt;tunnels are unidirectional; so the issue of
bidirectional&nbsp;&nbsp;&nbsp;&nbsp; <br>
&gt;&gt;&gt;resource reservation does not arise <br>
<br>
&gt;&gt;It wasn't my intention to talk about bi-directional LSPs at 
<br>
&gt;&gt;this point (although that is an interesting topic of <br>
&gt;&gt;conversation in this regard).&nbsp; When I talk about forward
and<br>
&gt;&gt;reverse reservation I am simply distinguishing between
CR-LDP<br>
&gt;&gt;where the resources are reserved as the Label_Request
traverses<br>
&gt;&gt;the network, and RSVP where the resources are (strictly
speaking)<br>
&gt;&gt;only reserved when the Resv travels back.&nbsp; Thus the
information<br>
&gt;&gt;in the MIB row is far more likely to reflect the true
reservation<br>
&gt;&gt;in CR-LDP than in RSVP unless the table is updated by the <br>
&gt;&gt;protocol code on completion of LSP setup to reflect the
flowspec.<br>
<br>
&gt;The ARHopTable is captures the actual reservation, and is<br>
&gt;applicable to both signaling protocols.<br>
<br>
I think I have missed something here.&nbsp; We are still talking about
version 03<br>
of the draft aren't we?&nbsp; In my copy the ARHopTable contains only the
output<br>
from the Recorded Route object.<br>
<br>
So back to the question about recording the difference between
requested<br>
traffic parameters and actual reservations.<br>
<br>
- Are you saying that the mplsTunnelResourceTable is updated<br>
&nbsp; to reflect the actual resources reserved?&nbsp; This would<br>
&nbsp; intuitively be the job of mplsTrafficParamTable in the LSR<br>
&nbsp; MIB.</blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes, the
parameters configured in the mplsTunnelResourceTable<br>
are configured or desired values only. One should look to the<br>
LSR MIB for the actual values. When a tunnel is signaled,<br>
it will point at an LSP in the LSR MIB.<br>
<br>
<blockquote type=cite cite>- If this is what you are saying then you will
need to update<br>
&nbsp; most of the text which describes the movement of data from<br>
&nbsp; mplsTunnelResourceTable to mplsTrafficParamTable but not<br>
&nbsp; vice versa.</blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes, this
should be the case. When a tunnel is specified<br>
(i.e.: configured), and it is successfully signalled with those<br>
parameters, then those parameters should be reflected in the
underlying<br>
LSP (i.e.: in the LSR MIB). If they aren't, then an appropriate LSP 
<br>
could not be found to satisfy the desired tunnel configuration,<br>
and hence, the tunnel should not have been signalled.<br>
<br>
<blockquote type=cite cite>- Do you intend that sharing entries in
mplsTunnelResourceTable <br>
&nbsp; between rows in mplsTunnelTable reflects sharing TSpecs or <br>
&nbsp; sharing real reservations?&nbsp; </blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes, it
was our intent that when more than one tunnel <br>
points at the same mplsTunnelResourceTable entry, that they <br>
indeed share the same RSVP reservation/session. Furthermore,<br>
because they share the same reservation, they should also <br>
share the same traffic specification.<br>
<br>
<blockquote type=cite cite>These can be very different matters in
RSVP.</blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Can you
please be more
specific?<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite>&gt;&gt;&gt;&gt;15. mplsTunnelXCIndex <br>
&gt;We would prefer the following:<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This variable represents
an index into the<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mplsXCTable. This table
identifies the segments<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that compose this tunnel,
their characteristics,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and relationships to each
other. <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the case where a
signaling protocol is used<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to set up the tunnel, this
field is to reflect <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the row in the
mplsXCTable<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that has been set up to
describe the cross-<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connect for this LSP and
SHOULD NOT be changed.<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the case where the
tunnel has been statically<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configured by writing to
the tables in the LSR <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIB, this field MUST be
set to indicate the <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; correct entry in the
mplsXCTable.&quot;<br>
<br>
Fine. You have only removed the bit about who sets the field in the
signaled<br>
case from my text, right?<br>
<br>
Regards,<br>
Adrian<br>
--<br>
Adrian Farrel&nbsp;
<a href="mailto:af@datcon.co.uk" eudora="autourl">mailto:af@datcon.co.uk</a><br>
Network Convergence Group<br>
Data Connection Ltd., Chester, UK<br>
<a href="http://www.datcon.co.uk/" eudora="autourl">http://www.datcon.co.uk/</a><br>
Tel: +44 (0) 1244 313440&nbsp; Fax: +44 (0) 1244
312422</blockquote></html>

--=====================_15391541==_.ALT--




From owner-mpls@UU.NET  Thu Jun 22 14:59:02 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13093
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 14:59:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiush14334;
	Thu, 22 Jun 2000 18:57:37 GMT
Received: by mail-control.mail.uu.net 
	id QQiush17094
	for mpls-outgoing; Thu, 22 Jun 2000 18:57:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiush17086
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 18:57:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiush21545
	for <mpls@uu.net>; Thu, 22 Jun 2000 14:56:35 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiush04297
	for <mpls@uu.net>; Thu, 22 Jun 2000 18:56:34 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA26388
	for mpls@uu.net; Thu, 22 Jun 2000 14:56:33 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiush16918
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 18:56:05 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiush15735
	for <mpls@UU.NET>; Thu, 22 Jun 2000 14:55:30 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiush03289
	for <mpls@UU.NET>; Thu, 22 Jun 2000 18:55:30 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24877; Thu, 22 Jun 2000 14:55:19 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-196.cisco.com [161.44.134.196])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA16424;
	Thu, 22 Jun 2000 14:55:44 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000622145045.0442a0e0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 22 Jun 2000 14:52:00 -0400
To: Paul Langille <langille@crescentnets.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Additional Index for TE-MIB: mplsTunnelTable
Cc: mpls@UU.NET, Cheenu Srinivasan <cheenu_s@yahoo.com>,
        arun Viswanathan <arun@force10networks.com>
In-Reply-To: <393CF0B0.86897FD1@crescentnets.com>
References: <4.3.2.7.2.20000602142324.0467f5d0@bucket.cisco.com>
 <4.3.2.7.2.20000605173329.0753b0d0@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


> > >Could you also give some brief examples as to how this would work with
> > >bi-directional tunnels. (I may be a bit confused by the
> > >mplsTunnelDirection object.)
> >
> >          Do you still need the example now that you know that the
> > cookie is deleted, or were you referring to the addition of the
> > srcAddr to the index?
>
>It is not clear to me how to represent a bi-directional tunnel with the MIB.

         See my last email to Adrian.

         --Tom





From owner-mpls@UU.NET  Thu Jun 22 15:22:56 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13535
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 15:22:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiusj28833;
	Thu, 22 Jun 2000 19:21:50 GMT
Received: by mail-control.mail.uu.net 
	id QQiusj01890
	for mpls-outgoing; Thu, 22 Jun 2000 19:21:27 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiusj01863
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 19:21:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiusj21529
	for <mpls@uu.net>; Thu, 22 Jun 2000 15:20:46 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiusj15693
	for <mpls@uu.net>; Thu, 22 Jun 2000 19:20:45 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA00096
	for mpls@uu.net; Thu, 22 Jun 2000 15:20:45 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiusj01547
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 19:20:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiusj21101
	for <mpls@uu.net>; Thu, 22 Jun 2000 15:19:32 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiusj14091
	for <mpls@uu.net>; Thu, 22 Jun 2000 19:19:32 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA27940; Thu, 22 Jun 2000 15:19:23 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-196.cisco.com [161.44.134.196])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA16508;
	Thu, 22 Jun 2000 15:19:48 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000622151536.04dcd460@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 22 Jun 2000 15:16:01 -0400
To: mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Additional Index for mplsTunnelEntry 
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


	Hi,

	Instead of calling the new index mplsTunnelSrcIpv4Addr,
we have decided that it would be more inline with the
current MPLS draft specifications for RSVP and CR-LDP to
use a 4-byte OCTET STRING called mplsTunnelIngressRouterId

	References to both drafts and their associated
text are listed below.

	--Tom


From:

http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-05.txt


          Extended Tunnel ID

          A 32-bit identifier used in the SESSION that  remains  constant
          over  the  life  of  the  tunnel.   Normally  set to all zeros.
          Ingress nodes that wish to narrow the scope of a SESSION to the
          ingress-egress  pair  may  place  their  IPv4 address here as a
          globally unique identifier.

	From:

http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-03.txt

    Ingress LSR Router ID
         An LSR may use any of its own IPv4 addresses in this field. 




From owner-mpls@UU.NET  Thu Jun 22 16:41:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15253
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 16:41:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuso23669;
	Thu, 22 Jun 2000 20:40:22 GMT
Received: by mail-control.mail.uu.net 
	id QQiuso24781
	for mpls-outgoing; Thu, 22 Jun 2000 20:39:52 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuso24767
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 20:39:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuso17686
	for <mpls@uu.net>; Thu, 22 Jun 2000 16:39:18 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQiuso22478
	for <mpls@uu.net>; Thu, 22 Jun 2000 20:39:18 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDDXH>; Thu, 22 Jun 2000 13:45:37 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6626907E8@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "Ross Callon (E-mail)" <rcallon@juniper.com>,
        "Arun Viswanathan (E-mail)" <arun@force10networks.com>,
        "'Eric Rosen'"
	 <erosen@cisco.com>
Cc: Eric Gray <EGray@zaffire.com>,
        "Thomas D. Nadeau (E-mail)"
	 <tnadeau@cisco.com>,
        "'MPLS Mailing List'" <mpls@UU.NET>
Subject: MPLS Architecture Issue
Date: Thu, 22 Jun 2000 13:45:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric (et al),

    Tom earlier made the point that none of the
MPLS drafts appear to introduce - let alone 
discuss or specify - the notion of bi-directional
association of LSPs.  There is the notion of use
of Labels under circumstances in which specific
hardware uses "labels" (VPI/VCI, and possibly
DLCI, values) in both directions, but this is not
the same thing.

    In an off-line discussion, we talked about the
fact that the TE Requirements RFC (RFC2702) talks 
about the idea of bi-directional traffic trunks.  
It describes behaviors which might be hard for an 
NMS to model without being able to determine that 
an LSP-pair is used as a bidirectional LSP tunnel.
But it is "only" an informational RFC.

	The Framework draft briefly mentions use of
bi-directional LSPs as a possible solution to error
reporting problems, but - as far as I know - none
of the current set of "standards track" MPLS drafts
addresses the concept of pairing of LSPs to form a
bi-directional tunnel or trunk.

	Is it possible to add this to the Architecture
at this point, do we need to create a standards track
draft specifically for this purpose or is it enough 
to simply add appropriate "stuff" to the TE-MIB based
on the informational RFC?

--
Eric Gray


From owner-mpls@UU.NET  Thu Jun 22 16:50:21 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15361
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 16:50:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiusp08773;
	Thu, 22 Jun 2000 20:49:25 GMT
Received: by mail-control.mail.uu.net 
	id QQiusp26252
	for mpls-outgoing; Thu, 22 Jun 2000 20:49:03 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiusp26238
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 20:48:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiusp11270
	for <mpls@UU.NET>; Thu, 22 Jun 2000 16:48:25 -0400 (EDT)
Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p1.globespan.net [209.191.59.250])
	id QQiusp00648
	for <mpls@UU.NET>; Thu, 22 Jun 2000 20:48:25 GMT
Received: from globespan.net (ROHIT [192.168.25.21]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id NN041QH4; Thu, 22 Jun 2000 16:47:39 -0400
Message-ID: <39527B87.B0A4FAA6@globespan.net>
Date: Thu, 22 Jun 2000 16:48:07 -0400
From: Rohit Chhapolia <rohit@globespan.net>
Organization: Globespan, Inc.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yakov Rekhter <yakov@cisco.com>, Kireeti Kompella <kireeti@juniper.net>
CC: mpls@UU.NET
Subject: Question on draft-kompella-lsp-hierarchy-00.txt
References: <200006201538.IAA07685@omega.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

In the section 5.1, it is suggested that Path/Resv message
should be encapsulated in another IP header if sent
as unicast over the control plane. Can you please
clarify why is this required?

It should be possible to send the Resv message as it is.
Path message can be sent without router alert to the
next hop IP address. In this case, IP address of the tail
end of the FA-LSP.

thanks,
Rohit

-- 
Rohit Chhapolia
Globespan, Inc.
mailto:rohit@globespan.net
http://www.globespan.net


From owner-mpls@UU.NET  Thu Jun 22 18:01:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16514
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 18:01:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiust06278;
	Thu, 22 Jun 2000 21:59:54 GMT
Received: by mail-control.mail.uu.net 
	id QQiust18018
	for mpls-outgoing; Thu, 22 Jun 2000 21:59:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiust17992
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 21:59:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiust04135
	for <mpls@uu.net>; Thu, 22 Jun 2000 17:58:48 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiust27517
	for <mpls@uu.net>; Thu, 22 Jun 2000 21:58:47 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA21006
	for mpls@uu.net; Thu, 22 Jun 2000 17:58:46 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiust17884
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 21:58:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiust03990
	for <mpls@UU.NET>; Thu, 22 Jun 2000 17:58:02 -0400 (EDT)
Received: from omega.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omega.cisco.com [171.69.63.141])
	id QQiust04122
	for <mpls@UU.NET>; Thu, 22 Jun 2000 21:58:01 GMT
Received: from localhost (yakov@localhost)
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA19312;
	Thu, 22 Jun 2000 14:58:00 -0700 (PDT)
Message-Id: <200006222158.OAA19312@omega.cisco.com>
To: Rohit Chhapolia <rohit@globespan.net>
cc: mpls@UU.NET
Subject: Re: Question on draft-kompella-lsp-hierarchy-00.txt 
In-reply-to: Your message of "Thu, 22 Jun 2000 16:48:07 EDT."
             <39527B87.B0A4FAA6@globespan.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19309.961711079.1@cisco.com>
Date: Thu, 22 Jun 2000 14:57:59 -0700
From: Yakov Rekhter <yakov@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Rohit,

> In the section 5.1, it is suggested that Path/Resv message
> should be encapsulated in another IP header if sent
> as unicast over the control plane. Can you please
> clarify why is this required?

See below....
  
> It should be possible to send the Resv message as it is.

Agreed.

> Path message can be sent without router alert to the
> next hop IP address. In this case, IP address of the tail
> end of the FA-LSP.

Agreed.

We'll correct the text in the next iteration of this document.

Yakov.



From owner-mpls@UU.NET  Thu Jun 22 18:08:13 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16571
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 18:08:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiusu13921;
	Thu, 22 Jun 2000 22:07:18 GMT
Received: by mail-control.mail.uu.net 
	id QQiusu29608
	for mpls-outgoing; Thu, 22 Jun 2000 22:06:54 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiusu29589
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 22:06:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiusu05921
	for <mpls@UU.NET>; Thu, 22 Jun 2000 18:06:44 -0400 (EDT)
Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [207.71.195.18])
	id QQiusu04739
	for <mpls@UU.NET>; Thu, 22 Jun 2000 22:06:43 GMT
Received: by LUX with Internet Mail Service (5.5.2448.0)
	id <NCB9DWBL>; Thu, 22 Jun 2000 15:06:43 -0700
Message-ID: <51DA0AB3D747D311832F005004827CC013E79F@LUX>
From: Jonathan Lang <jplang@calient.net>
To: "'Eric Gray'" <EGray@zaffire.com>,
        "Ross Callon (E-mail)"
	 <rcallon@juniper.com>,
        "Arun Viswanathan (E-mail)"
	 <arun@force10networks.com>,
        "'Eric Rosen'" <erosen@cisco.com>
Cc: "Thomas D. Nadeau (E-mail)" <tnadeau@cisco.com>,
        "'MPLS Mailing List'"
	 <mpls@UU.NET>
Subject: RE: MPLS Architecture Issue
Date: Thu, 22 Jun 2000 15:06:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

There were two drafts presented at the last meeting in Adelaide that
proposed bi-directional LSPs (draft-lang-mpls-rsvp-oxc-00.txt and
draft-saha-rsvp-optical-signaling-00.txt).  These were primarily a result of
optical constraints, but there is no reason they couldn't be used for
regular LSPs.

Jonathan

Calient Networks                     

> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Thursday, June 22, 2000 1:46 PM
> To: Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric Rosen'
> Cc: Eric Gray; Thomas D. Nadeau (E-mail); 'MPLS Mailing List'
> Subject: MPLS Architecture Issue
> 
> 
> Eric (et al),
> 
>     Tom earlier made the point that none of the
> MPLS drafts appear to introduce - let alone 
> discuss or specify - the notion of bi-directional
> association of LSPs.  There is the notion of use
> of Labels under circumstances in which specific
> hardware uses "labels" (VPI/VCI, and possibly
> DLCI, values) in both directions, but this is not
> the same thing.
> 
>     In an off-line discussion, we talked about the
> fact that the TE Requirements RFC (RFC2702) talks 
> about the idea of bi-directional traffic trunks.  
> It describes behaviors which might be hard for an 
> NMS to model without being able to determine that 
> an LSP-pair is used as a bidirectional LSP tunnel.
> But it is "only" an informational RFC.
> 
> 	The Framework draft briefly mentions use of
> bi-directional LSPs as a possible solution to error
> reporting problems, but - as far as I know - none
> of the current set of "standards track" MPLS drafts
> addresses the concept of pairing of LSPs to form a
> bi-directional tunnel or trunk.
> 
> 	Is it possible to add this to the Architecture
> at this point, do we need to create a standards track
> draft specifically for this purpose or is it enough 
> to simply add appropriate "stuff" to the TE-MIB based
> on the informational RFC?
> 
> --
> Eric Gray
> 


From owner-mpls@UU.NET  Thu Jun 22 18:28:16 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16717
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 18:28:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiusv22964;
	Thu, 22 Jun 2000 22:27:09 GMT
Received: by mail-control.mail.uu.net 
	id QQiusv03172
	for mpls-outgoing; Thu, 22 Jun 2000 22:26:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiusv03152
	for <mpls@mail-control.mail.uu.net>; Thu, 22 Jun 2000 22:26:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiusv29382
	for <mpls@UU.net>; Thu, 22 Jun 2000 18:26:31 -0400 (EDT)
Received: from dnsmx1rrc.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41])
	id QQiusv01658
	for <mpls@UU.net>; Thu, 22 Jun 2000 22:26:30 GMT
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1])
	by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id SAA26082
	for <mpls@UU.net>; Thu, 22 Jun 2000 18:21:16 -0400 (EDT)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256906.007ACBAF ; Thu, 22 Jun 2000 18:21:15 -0400
X-Lotus-FromDomain: TELCORDIA
From: "Robert Streijl" <rstreijl@telcordia.com>
To: mpls@UU.NET
Message-ID: <85256906.007ACA05.00@notes950.cc.telcordia.com>
Date: Thu, 22 Jun 2000 18:19:37 -0400
Subject: Question on TLVs
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



Hi,

I am fairly new to MPLS and I am currently reading through the produced drafts.
I bumped into Type Length Values used for encoding.
I started with the architecture and then started reading the LDP spec, but I
still don't get it.

I understand that LDP PDUs can contain multiple messages. I also understand that
there are different message types, but I don't understand the role of TLVs.
The TLVs show byte allocations, so I am wondering if it goes in the LDP PDU or
LDP messages. First I thought it is appended to the LDP PDU header, then I
thought it is one of the fields in each of the messages. However, the TLV
messages are bigger than the reserved space in the LDP messages.

Is this encoding information somehow stored in a different way, not in the LDP
messages/PDUs?

Can somebody please help me understand this?

Thanks very much in advance.

Regards,
Robert




From owner-mpls@UU.NET  Thu Jun 22 21:12:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18187
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 21:12:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiutg28695;
	Fri, 23 Jun 2000 01:10:15 GMT
Received: by mail-control.mail.uu.net 
	id QQiutg22177
	for mpls-outgoing; Fri, 23 Jun 2000 01:09:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiutg22162
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 01:09:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiutg20958
	for <mpls@UU.NET>; Thu, 22 Jun 2000 21:09:07 -0400 (EDT)
Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8])
	id QQiutg27797
	for <mpls@UU.NET>; Fri, 23 Jun 2000 01:09:07 GMT
Received: by MILES with Internet Mail Service (5.5.2650.21)
	id <M98R9313>; Fri, 23 Jun 2000 02:08:57 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2A31C7@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>, mpls@UU.NET
Cc: arun Viswanathan <arun@force10networks.com>,
        cheenu Srinivasan
	 <csrinivasan@tachion.com>
Subject: RE: MPLS TE MIB - Doubts
Date: Fri, 23 Jun 2000 02:08:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom, Thanks.

>>>>3. LSPId explicit hop type 
>>>>Is there any reason to prevent configuration of an explicit hop 
>>>>of type LSPId?  I suggested some ASN.1 for this in an email to 
>>>>Tom on 7th Jan. 

>>>If ldp is chosen to route the tunnel then we'll add this as 
>>>a choice for the hop type. 

>>I'm not quite sure what your answer means.  I think you're
>>saying you'll add the hop type but only allow it if the 
>>signaling protocol is flagged as [CR-]LDP.  This would be
>>great.

>        Perhaps I was confused about this. Now that Arun and I 
>have discussed this, we now recall that we agreed to add this.
>Here is a description of the object type. We have also added the
>LSP ID to the hop entry as well.
>
>mplsTunnelHopAddrType OBJECT-TYPE
>SYNTAX        INTEGER {ipV4(1), 
>                       ipV6(2), 
>                       asNumber(3), 
>                       lspid(4) 
>                      }

Great.  Thanks, that's just what I wanted.  You'll also need to add another
object to express a hop of this type as I suggested in January, viz.

MplsTunnelHopEntry ::= SEQUENCE {
      mplsTunnelHopIndex              Integer32,
      mplsTunnelHopAddrType           INTEGER,
      mplsTunnelHopIpv4Addr           IpAddress,
      mplsTunnelHopIpv4PrefixLen      INTEGER,
      mplsTunnelHopIpv6Addr           Ipv6Address,
      mplsTunnelHopIpv6PrefixLen      INTEGER,
      mplsTunnelHopAsNumber           INTEGER,
      mplsTunnelHopLspId              INTEGER,
      mplsTunnelHopStrictOrLoose      INTEGER,
      mplsTunnelHopRowStatus          RowStatus
   }

mplsTunnelHopLspId OBJECT-TYPE
   SYNTAX        OCTET STRING (SIZE(6))
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "If mplsTunnelHopAddrType is lspId(4), the LSPID
        over which to route this hop.  This is encoded as
        two bytes of Local LSPID followed by four bytes of
        Ingress LSR Router ID.
        This object is not significant otherwise and should
        return a value of 0."
   ::= { mplsTunnelHopEntry 8 }


>>>>6. MPLS Tunnel Resource Table 
[Lots of pruning!]

OK.  I think we now have the same understanding on most of this.
We have...
- mplsTunnelResourceTable is configured and not updated by 
  the protocol code
- mplsTrafficParamTable reflects the actual reservations made
- if two rows in the mplsTunnelTable reference the same row in
  the mplsTunnelResourceTable and the protocol is RSVP then
  the LSPs have the same TSpec
- if two rows in the mplsIn/OutSegmentTable reference the same
  row in the mplsTrafficParamTable then the segments share the 
  same reserved resources

Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


From owner-mpls@UU.NET  Thu Jun 22 23:52:51 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21552
	for <mpls-archive@lists.ietf.org>; Thu, 22 Jun 2000 23:52:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiutr28200;
	Fri, 23 Jun 2000 03:50:42 GMT
Received: by mail-control.mail.uu.net 
	id QQiutr05527
	for mpls-outgoing; Fri, 23 Jun 2000 03:50:27 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiutr05511
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 03:50:18 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiutr11195
	for <mpls@UU.NET>; Thu, 22 Jun 2000 23:50:03 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49])
	id QQiutr27465
	for <mpls@UU.NET>; Fri, 23 Jun 2000 03:50:02 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jun 22 23:49:08 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn64.pa.bell-labs.com [135.250.1.64])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id XAA12620;
	Thu, 22 Jun 2000 23:49:40 -0400 (EDT)
Message-ID: <3952DF29.3D614438@dnrc.bell-labs.com>
Date: Thu, 22 Jun 2000 20:53:13 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: George Swallow <swallow@cisco.com>
CC: mpls@UU.NET
Subject: Re: LSP hierarchy with MPLS TE
References: <200006221505.LAA07660@lir.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


I wouldn't call this an objection, but how about we decide
its disposition at the upcoming IETF after hearing a presentation?
Its not like the meeting is that far away.

cheers,
gja

George Swallow wrote:
> 
> Folks,
> 
> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt
> be accepted as a work group document.  So far I've only seen support.
> If there are no objects by 6/27, we'll declare it so.
> 
> ...George

________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Fri Jun 23 00:45:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21970
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 00:45:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiutg29914;
	Fri, 23 Jun 2000 01:10:24 GMT
Received: by mail-control.mail.uu.net 
	id QQiutg22210
	for mpls-outgoing; Fri, 23 Jun 2000 01:09:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiutg22168
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 01:09:21 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiutg20950
	for <mpls@UU.NET>; Thu, 22 Jun 2000 21:09:02 -0400 (EDT)
Received: from miles.datcon.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8])
	id QQiutg27755
	for <mpls@UU.NET>; Fri, 23 Jun 2000 01:09:02 GMT
Received: by MILES with Internet Mail Service (5.5.2650.21)
	id <M98R931N>; Fri, 23 Jun 2000 02:08:52 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2A31C6@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: Jonathan Lang <jplang@calient.net>, "'Eric Gray'" <EGray@zaffire.com>,
        "Ross Callon (E-mail)" <rcallon@juniper.com>,
        "Arun Viswanathan (E-mail)"
	 <arun@force10networks.com>,
        "'Eric Rosen'" <erosen@cisco.com>
Cc: "Thomas D. Nadeau (E-mail)" <tnadeau@cisco.com>,
        "'MPLS Mailing List'"
	 <mpls@UU.NET>
Subject: RE: MPLS Architecture Issue
Date: Fri, 23 Jun 2000 02:08:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Sorry,

Playing catch-up and my previous mail on this subject lags behind the
discussion...

The bi-directionality in draft-lang-mpls-rsvp-oxc provides a good model for
bi-directional LSPs in optical and non-optical networks.

In a network built on ATM hardware it is also necessary to know whether the
full bi-directionality of the switching will be used since it is often
possible to reserve resources in such hardware in a uni-directional sense.
Such function will also require an extension to the signaling protocol (or
carnal knowledge amongst the switches) and draft-lang-mpls-rsvp-oxc could
provide such a mechanism (although is perhaps heavy handed for this use).

Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


>-----Original Message-----
>From: Jonathan Lang [mailto:jplang@calient.net]
>Sent: Thursday, June 22, 2000 11:07 PM
>To: 'Eric Gray'; Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric
>Rosen'
>Cc: Thomas D. Nadeau (E-mail); 'MPLS Mailing List'
>Subject: RE: MPLS Architecture Issue
>
>
>Eric,
>
>There were two drafts presented at the last meeting in Adelaide that
>proposed bi-directional LSPs (draft-lang-mpls-rsvp-oxc-00.txt and
>draft-saha-rsvp-optical-signaling-00.txt).  These were 
>primarily a result of
>optical constraints, but there is no reason they couldn't be used for
>regular LSPs.
>
>Jonathan
>
>Calient Networks                     
>
>> -----Original Message-----
>> From: Eric Gray [mailto:EGray@zaffire.com]
>> Sent: Thursday, June 22, 2000 1:46 PM
>> To: Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric Rosen'
>> Cc: Eric Gray; Thomas D. Nadeau (E-mail); 'MPLS Mailing List'
>> Subject: MPLS Architecture Issue
>> 
>> 
>> Eric (et al),
>> 
>>     Tom earlier made the point that none of the
>> MPLS drafts appear to introduce - let alone 
>> discuss or specify - the notion of bi-directional
>> association of LSPs.  There is the notion of use
>> of Labels under circumstances in which specific
>> hardware uses "labels" (VPI/VCI, and possibly
>> DLCI, values) in both directions, but this is not
>> the same thing.
>> 
>>     In an off-line discussion, we talked about the
>> fact that the TE Requirements RFC (RFC2702) talks 
>> about the idea of bi-directional traffic trunks.  
>> It describes behaviors which might be hard for an 
>> NMS to model without being able to determine that 
>> an LSP-pair is used as a bidirectional LSP tunnel.
>> But it is "only" an informational RFC.
>> 
>> 	The Framework draft briefly mentions use of
>> bi-directional LSPs as a possible solution to error
>> reporting problems, but - as far as I know - none
>> of the current set of "standards track" MPLS drafts
>> addresses the concept of pairing of LSPs to form a
>> bi-directional tunnel or trunk.
>> 
>> 	Is it possible to add this to the Architecture
>> at this point, do we need to create a standards track
>> draft specifically for this purpose or is it enough 
>> to simply add appropriate "stuff" to the TE-MIB based
>> on the informational RFC?
>> 
>> --
>> Eric Gray
>> 
>


From owner-mpls@UU.NET  Fri Jun 23 02:08:25 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04506
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 02:08:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuua29587;
	Fri, 23 Jun 2000 06:05:37 GMT
Received: by mail-control.mail.uu.net 
	id QQiuua24912
	for mpls-outgoing; Fri, 23 Jun 2000 06:05:22 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuua24844
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 06:05:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuua25607
	for <mpls@UU.NET>; Fri, 23 Jun 2000 02:04:58 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nat-01.juniper.net [208.197.169.49])
	id QQiuua28971
	for <mpls@UU.NET>; Fri, 23 Jun 2000 06:04:58 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id XAA15078;
	Thu, 22 Jun 2000 23:04:51 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id XAA04307; Thu, 22 Jun 2000 23:04:47 -0700 (PDT)
Date: Thu, 22 Jun 2000 23:04:47 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006230604.XAA04307@kummer.juniper.net>
To: gja@dnrc.bell-labs.com, swallow@cisco.com
Subject: Re: LSP hierarchy with MPLS TE
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

> I wouldn't call this an objection, but how about we decide
> its disposition at the upcoming IETF after hearing a presentation?

I guess you missed my presentation of draft-kompella-mpls-optical-00.txt,
the focus of which was Forwarding Adjacencies, the basis of the LSP
hierarchy draft.

From the minutes of the IETF 47 MPLS WG:

  Kireeti Kompella started off his presentation by discussing network
  design considerations, but mentioned that the focus of the talk was on
  forwarding adjacencies.

  ...

  He went on to discuss forwarding adjacencies, which were a key part of
  this draft. (etc)

Of course, if enough people ask for an encore, Yakov or I will be
glad to do it.

Kireeti.


From owner-mpls@UU.NET  Fri Jun 23 02:31:20 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04649
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 02:31:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuub02319;
	Fri, 23 Jun 2000 06:26:52 GMT
Received: by mail-control.mail.uu.net 
	id QQiuub29004
	for mpls-outgoing; Fri, 23 Jun 2000 06:26:36 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuub28996
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 06:26:35 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuub27999
	for <mpls@UU.NET>; Fri, 23 Jun 2000 02:26:05 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6])
	id QQiuub16818
	for <mpls@UU.NET>; Fri, 23 Jun 2000 06:26:05 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jun 23 02:25:39 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn64.pa.bell-labs.com [135.250.1.64])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id CAA13395;
	Fri, 23 Jun 2000 02:26:10 -0400 (EDT)
Message-ID: <395303D8.71CADCC7@dnrc.bell-labs.com>
Date: Thu, 22 Jun 2000 23:29:44 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Labs Research Silicon Valley
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: mpls@UU.NET
Subject: Re: LSP hierarchy with MPLS TE
References: <200006230604.XAA04307@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


if your new draft is no more than some contents extracted
from a draft already accepted to be a working group document,
then yes i did miss that point.

cheers,
gja

Kireeti Kompella wrote:
> 
> > I wouldn't call this an objection, but how about we decide
> > its disposition at the upcoming IETF after hearing a presentation?
> 
> I guess you missed my presentation of draft-kompella-mpls-optical-00.txt,
> the focus of which was Forwarding Adjacencies, the basis of the LSP
> hierarchy draft.
> 
> >From the minutes of the IETF 47 MPLS WG:
> 
>   Kireeti Kompella started off his presentation by discussing network
>   design considerations, but mentioned that the focus of the talk was on
>   forwarding adjacencies.
> 
>   ...
> 
>   He went on to discuss forwarding adjacencies, which were a key part of
>   this draft. (etc)
> 
> Of course, if enough people ask for an encore, Yakov or I will be
> glad to do it.
> 
> Kireeti.

-- 
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Fri Jun 23 03:05:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04882
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 03:05:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuue22868;
	Fri, 23 Jun 2000 07:02:32 GMT
Received: by mail-control.mail.uu.net 
	id QQiuue07619
	for mpls-outgoing; Fri, 23 Jun 2000 07:01:53 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuue07257
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 07:01:44 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuue02429
	for <mpls@uu.net>; Fri, 23 Jun 2000 03:01:29 -0400 (EDT)
Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQiuue16494
	for <mpls@uu.net>; Fri, 23 Jun 2000 07:01:27 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000690337@fsnt.future.futusoft.com>;
 Fri, 23 Jun 2000 12:42:42 +0530
Received: from manis.future.futsoft.com (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA09228; Fri, 23 Jun 2000 12:31:05 +0530
Received: by localhost with Microsoft MAPI; Fri, 23 Jun 2000 12:36:03 +0530
Message-Id: <01BFDD0F.98100D60.manis@future.futsoft.com>
From: manikantan <manis@future.futsoft.com>
To: "'Robert Streijl'" <rstreijl@telcordia.com>, "mpls@uu.net" <mpls@UU.NET>
Subject: RE: Question on TLVs
Date: Fri, 23 Jun 2000 12:36:02 +0530
Importance: high
X-Priority: 1 (Highest)
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Hello Robert

(Reference Section 3.1 LDP PDUs in draft-ietf-mpls-ldp-07.txt)
A LDP PDU transmitted by an LSR/LER will have in its start the
three information fields Version, PDU Length and the LDP Identifier.

After the first 10 bytes, the PDU will contain one or more
LDP Messages. 

(Reference Section 3.5 LDP Messages in draft-ietf-mpls-ldp-07.txt)
A message is uniquely identified with the three information fields
Message type, Message Length and Message ID.

Following the Message information the message related TLVs will
be available.

I have placed below set of PDU dumps and its interpretations.
In my example all the PDUs has only one message.


******************************************************************
LDP PDU with  INIT Message 

0x00 0x01 0x00 0x20 0x0a 0x01 0x05 0x01 0x00 0x00 
0x02 0x00 0x00 0x16 0x00 0x00 0x00 0x0c 0x05 0x00 
0x00 0x0e 0x00 0x01 0x00 0x3c 0xc0 0x20 0x10 0x00 
0x0a 0x05 0x04 0x05 0x00 0x00 

LDP: ---------------------------------------------
LDP: LDP PDU HDR CONTENTS : 
LDP: LDP Version      : 1 
LDP: LDP PduLen       : 32 
LDP: LDP Id           : 0xa:1:5:1:0:0 
LDP: LDP MSG HDR CONTENTS : 
LDP: LDP Msg Type     : 0x200 - Ldp Init Msg.
LDP: LDP Msg Len      : 22 
LDP: LDP Msg Id       : 12 
LDP: TLV Type         : 0x500  - CmnSsnParmsTlv.
LDP: TLV Length       : 14 
LDP: LDP Version      : 1
LDP: Keep Alive Time  : 60
LDP: Advt_Loop Inf    : 0xc0
LDP: Advt Type        : DOD.
LDP: Loop Detection   : Enabled. 
LDP: Path Vect Limit  : 32
LDP: Max PDU Length   : 4096
LDP: Rcvr LDP Id      : 0xa:0x5:0x4:0x5:0:0 
LDP: ---------------------------------------------
******************************************************************
LDP PDU with Keep Alive Message 

0x00 0x01 0x00 0x0e 0x0a 0x01 0x05 0x01 0x00 0x00 
0x02 0x01 0x00 0x04 0x00 0x00 0x00 0x10 

LDP: ---------------------------------------------
LDP: LDP PDU HDR CONTENTS : 
LDP: LDP Version      : 1 
LDP: LDP PduLen       : 14 
LDP: LDP Id           : 0xa:1:5:1:0:0 
LDP: LDP MSG HDR CONTENTS : 
LDP: LDP Msg Type     : 0x201 - Keep Alive Msg.
LDP: LDP Msg Len      : 4 
LDP: LDP Msg Id       : 16 
LDP: ---------------------------------------------
******************************************************************
LDP PDU with Address message

0x00 0x01 0x00 0x18 0x0a 0x01 0x05 0x01 0x00 0x00 
0x03 0x00 0x00 0x0e 0x00 0x00 0x00 0x14 0x01 0x01 
0x00 0x06 0x00 0x01 0x0a 0x01 0x05 0x01 

LDP: ---------------------------------------------
LDP: LDP PDU HDR CONTENTS : 
LDP: LDP Version      : 1 
LDP: LDP PduLen       : 24 
LDP: LDP Id           : 0xa:1:5:1:0:0 
LDP: LDP MSG HDR CONTENTS : 
LDP: LDP Msg Type     : 0x300 - Addr Msg 
LDP: LDP Msg Len      : 14 
LDP: LDP Msg Id       : 20 
LDP: LDP TLV Type     : 0x101 - AddrList TLV.
LDP: LDP TLV Len      : 6  
LDP: Addr Family      : 1 - IPv4 
LDP: Addr - 1        : 0xa010501  
LDP: ---------------------------------------------
******************************************************************
LDP PDU with Label Request Message

0x00 0x01 0x00 0x26 0x0a 0x01 0x05 0x01 0x00 0x00 
0x04 0x01 0x00 0x1c 0x00 0x00 0x00 0x15 0x01 0x00 
0x00 0x07 0x02 0x00 0x01 0x18 0x0a 0x03 0x04 0x01 
0x03 0x00 0x01 0x01 0x01 0x04 0x00 0x04 0x0a 0x01 
0x05 0x01 

LDP: ---------------------------------------------
LDP: LDP PDU HDR CONTENTS : 
LDP: LDP Version      : 1 
LDP: LDP PduLen       : 38 
LDP: LDP Id           : 0xa:1:5:1:0:0 
LDP: LDP MSG HDR CONTENTS : 
LDP: LDP Msg Type     : 0x401 - Lbl Req Msg 
LDP: LDP Msg Len      : 28 
LDP: LDP Msg Id       : 21 
LDP: TLV Type         : 0x100 - FEC Tlv  
LDP: TLV Len          : 7 
LDP: FEC Type         : 0x2  - Prefix Type.
LDP: Addr Fmly        : 0x1  - IPv4.
LDP: Prefix Len       : 0x18
LDP: Prefix           : 0xa0304
LDP: TLV Type         : 0x103  - HopCount TLV.
LDP: Tlv Length       : 1
LDP: Hop Count val    : 1
LDP: TLV Type         : 0x104  - Path Vector TLV.
LDP: Tlv Length       : 4
LDP: LSR ID - 64      : 0xa010501
LDP: ---------------------------------------------

******************************************************************
LDP PDU with Label Map message.

0x00 0x01 0x00 0x36 0x0a 0x01 0x05 0x01 0x00 0x00 
0x04 0x00 0x00 0x2c 0x00 0x00 0x00 0x1a 0x01 0x00 
0x00 0x07 0x02 0x00 0x01 0x18 0x14 0x00 0x06 0x02 
0x00 0x00 0x04 0x00 0x00 0x00 0x10 0x06 0x00 0x00 
0x04 0x00 0x00 0x00 0x1d 0x01 0x03 0x00 0x01 0x01 
0x01 0x04 0x00 0x04 0x0a 0x01 0x05 0x01 

LDP: ---------------------------------------------
LDP: LDP PDU HDR CONTENTS : 
LDP: LDP Version      : 1 
LDP: LDP PduLen       : 54 
LDP: LDP Id           : 0xa:1:5:1:0:0 
LDP: LDP MSG HDR CONTENTS : 
LDP: LDP Msg Type     : 0x400 - Lbl Map Msg 
LDP: LDP Msg Len      : 44 
LDP: LDP Msg Id       : 26 
LDP: TLV Type         : 0x100 - FEC Tlv  
LDP: TLV Len          : 7 
LDP: FEC Type         : 0x2  - Prefix Type.
LDP: Addr Fmly        : 0x1  - IPv4.
LDP: Prefix Len       : 0x18
LDP: Prefix           : 0x140006
LDP: TLV Type         : 0x200  - Gen Lbl TLV.
LDP: Tlv Length       : 4 
LDP: Label Value      : 0x10
LDP: TLV Type         : 0x600  - LblReqMsgId TLV.
LDP: Tlv Length       : 4
LDP: LblReqMsgId val  : 29
LDP: TLV Type         : 0x103  - HopCount TLV.
LDP: Tlv Length       : 1
LDP: Hop Count val    : 1
LDP: TLV Type         : 0x104  - Path Vector TLV.
LDP: Tlv Length       : 4
LDP: LSR ID - 1      : 0xa010501
LDP: ---------------------------------------------
******************************************************************

Hope this helps

with best regards
mani
 
/*-------------------------------------------------------------------*/
S.Manikantan
Future Software Private Limited
480-481, Anna salai, Nandanam,
Chennai, Tamil Nadu, 600 035,
India.
Phone	: +91-44-4330550
Fax	: +91-44-4344157.
Email	: manis@future.futsoft.com
http://www.futsoft.com
/*--------------------------------------------------------------------*/

-----Original Message-----
From:	Robert Streijl [SMTP:rstreijl@telcordia.com]
Sent:	Friday, June 23, 2000 3:50 AM
To:	mpls@uu.net
Subject:	Question on TLVs



Hi,

I am fairly new to MPLS and I am currently reading through the produced drafts.
I bumped into Type Length Values used for encoding.
I started with the architecture and then started reading the LDP spec, but I
still don't get it.

I understand that LDP PDUs can contain multiple messages. I also understand that
there are different message types, but I don't understand the role of TLVs.
The TLVs show byte allocations, so I am wondering if it goes in the LDP PDU or
LDP messages. First I thought it is appended to the LDP PDU header, then I
thought it is one of the fields in each of the messages. However, the TLV
messages are bigger than the reserved space in the LDP messages.

Is this encoding information somehow stored in a different way, not in the LDP
messages/PDUs?

Can somebody please help me understand this?

Thanks very much in advance.

Regards,
Robert



From owner-mpls@UU.NET  Fri Jun 23 08:32:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08372
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 08:32:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuva20660;
	Fri, 23 Jun 2000 12:30:07 GMT
Received: by mail-control.mail.uu.net 
	id QQiuuz19247
	for mpls-outgoing; Fri, 23 Jun 2000 12:29:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuuz19237
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 12:29:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuuz08094
	for <mpls@uu.net>; Fri, 23 Jun 2000 08:29:13 -0400 (EDT)
Received: from flower.comeng.chungnam.ac.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [168.188.44.2])
	id QQiuuz21466
	for <mpls@uu.net>; Fri, 23 Jun 2000 12:29:12 GMT
Received: (from hyskim@localhost)
	by flower.comeng.chungnam.ac.kr (8.9.1/8.9.1) id VAA02991
	for mpls@uu.net; Fri, 23 Jun 2000 21:24:37 +0900 (KST)
From: ±èÇö¼® <hyskim@ce.cnu.ac.kr>
Message-Id: <200006231224.VAA02991@flower.comeng.chungnam.ac.kr>
Subject: mpls_encdec.c code by Nortel
To: mpls@UU.NET
Date: Fri, 23 Jun 100 21:24:37 +0900 (KST)
X-Mailer: ELM [version 2.4 PL21-h4]
MIME-Version: 1.0
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

I think it is a good idea to ask many people in the world
about some problem.
I saw the encoding and decoding routine in mpls_encdec.c coded by Nortel
In the way of testing the Nortel code, 
I found something strange in the code.
Label Request encoding routine has below code.

--------------------------------------------
	MEM_COPY( tempBuf,
		   (u_char*)&(fecAdrEl->addressEl.address),
		  fecAdrEl->addressEl.preLen);
--------------------------------------------
"fecAdrEl->addressEl.preLen" is a variable that is filled 
with the prefix length in bits.
Is it a correct code?
I need a advice.

In addition, I ask you about some code related "Label Request".

--------------------------------------------
	preLen = fecAdrEl->addressEl.preLen;
	if (fecAdrEl->addressEl.preLen > sizeof(u_int))
	{
	  /* error - the length cannot exeed 32 bits */
		/* skip the FEC and return error code */
		/* fill in the preLen field to the number of bytes for this
	   	   fec; we need it to know how much to skip from the buffer
		   when we do the decoding for the following fec element 
		*/
		   fecAdrEl->addressEl.preLen = preLen + decodedSize;
		   return MPLS_FECERROR;
																					 }
--------------------------------------------

Draft says that preLen contains a length of prefix in bits.
Except the case of zero length of prefix, 
this condition could be satisfied?


Hope your good answer.

----------- from Korea.


From owner-mpls@UU.NET  Fri Jun 23 09:17:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09455
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 09:17:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvd27788;
	Fri, 23 Jun 2000 13:16:05 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvd05343
	for mpls-outgoing; Fri, 23 Jun 2000 13:15:40 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuvd05317
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 13:15:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvd03274
	for <mpls@UU.NET>; Fri, 23 Jun 2000 09:15:00 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQiuvd26795
	for <mpls@UU.NET>; Fri, 23 Jun 2000 13:15:00 GMT
Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id JAA04632;
	Fri, 23 Jun 2000 09:14:59 -0400
Received: (from jleu@localhost)
	by localhost.laurelnetworks.com (8.9.3/8.9.3) id JAA00847;
	Fri, 23 Jun 2000 09:14:59 -0400
Date: Fri, 23 Jun 2000 09:14:59 -0400
From: "James R. Leu" <jleu@laurelnetworks.com>
To: Robert Streijl <rstreijl@telcordia.com>
Cc: mpls@UU.NET
Subject: Re: Question on TLVs
Message-ID: <20000623091459.A767@laurelnetworks.com>
Reply-To: jleu@laurelnetworks.com
References: <85256906.007ACA05.00@notes950.cc.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <85256906.007ACA05.00@notes950.cc.telcordia.com>; from rstreijl@telcordia.com on Thu, Jun 22, 2000 at 06:19:37PM -0400
Organization: Laurel Networks
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, Jun 22, 2000 at 06:19:37PM -0400, Robert Streijl wrote:
> 
> 
> Hi,
> 
> I am fairly new to MPLS and I am currently reading through the produced drafts.
> I bumped into Type Length Values used for encoding.
> I started with the architecture and then started reading the LDP spec, but I
> still don't get it.
> 
> I understand that LDP PDUs can contain multiple messages. I also understand that
> there are different message types, but I don't understand the role of TLVs.
> The TLVs show byte allocations, so I am wondering if it goes in the LDP PDU or
> LDP messages. First I thought it is appended to the LDP PDU header, then I
> thought it is one of the fields in each of the messages. However, the TLV
> messages are bigger than the reserved space in the LDP messages.
> 
> Is this encoding information somehow stored in a different way, not in the LDP
> messages/PDUs?
> 
> Can somebody please help me understand this?

Each PDU contains an LDP Message.  Each LDP Message contains an LDP Message
header and some LDP TLVs.  The LDP Message header dictats which type of LDP
Message it is, and that determins which LDP TLVs will follow.

If your looking for a sample implementation look at MPLS for Linux at

http://nero.doit.wisc.edu/mpls-linux/

It utilizes LDP PDU encode and decode functions from Nortel Networks.

Jim
-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com


From owner-mpls@UU.NET  Fri Jun 23 10:08:44 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11091
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 10:08:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvg08843;
	Fri, 23 Jun 2000 14:06:43 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvg17566
	for mpls-outgoing; Fri, 23 Jun 2000 14:06:20 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuvg17525
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 14:06:17 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuvg13721
	for <mpls@UU.NET>; Fri, 23 Jun 2000 10:06:08 -0400 (EDT)
Received: from redbaron.nexabit.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: d28.nexabit.com [209.6.34.253])
	id QQiuvg08156
	for <mpls@UU.NET>; Fri, 23 Jun 2000 14:06:08 GMT
Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4])
	by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id KAA17693;
	Fri, 23 Jun 2000 10:08:07 -0400
Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21)
	id <L9T5JB0V>; Fri, 23 Jun 2000 10:06:00 -0400
Message-ID: <BAC9CCF04FEED311BD1D00062950ABB157D751@bandito.nexabit.com>
From: Jeff Parker <jparker@nexabit.com>
To: Kireeti Kompella <kireeti@juniper.net>, swallow@cisco.com
Cc: mpls@UU.NET, isis-wg@juniper.net
Subject: RE: LSP hierarchy with MPLS TE
Date: Fri, 23 Jun 2000 10:05:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

> Folks,
> 
> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt
> be accepted as a work group document.  So far I've only seen support.
> If there are no objects by 6/27, we'll declare it so.
> 
> ...George

I find this draft a useful addition to the discussion of TE, and would
support it's adoption as an MPLS group document.

However, I am a bit puzzled by the last paragraph before
section 4.3 (bottom of page 5).

	"Route computation procedures should not perform two-way
	 connectivity check on the links used by the procedures.
	 That is, the two way check should not be performed on
	 one-way pipes, as they will fail."

I agree that relaxing this test for one-way links is a Good Thing.  But 
looking at the aged out draft "IS-IS extensions for Traffic Engineering"
<draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish 
"forward adjacencies" that are unidirectional LSPs from point-to-point 
adjacencies, where we should retain the test.  

Perhaps this will be addressed in the next rev of the IS-IS TE doc.  

- jeff parker
- Lucent Technologies



From owner-mpls@UU.NET  Fri Jun 23 12:03:55 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13801
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 12:03:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvo15099;
	Fri, 23 Jun 2000 16:01:44 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvo17039
	for mpls-outgoing; Fri, 23 Jun 2000 16:01:11 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuvo16903
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 16:01:03 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvo16720
	for <mpls@uu.net>; Fri, 23 Jun 2000 12:00:14 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuvo16624
	for <mpls@uu.net>; Fri, 23 Jun 2000 16:00:13 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA02358
	for mpls@uu.net; Fri, 23 Jun 2000 12:00:13 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuvl12772
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 15:28:39 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvl01880
	for <mpls@UU.NET>; Fri, 23 Jun 2000 11:28:32 -0400 (EDT)
Received: from postal.redback.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postal.redback.com [155.53.12.9])
	id QQiuvl23420
	for <mpls@UU.NET>; Fri, 23 Jun 2000 15:28:31 GMT
Received: from redback.com (malt.redback.com [155.53.12.41])
	by postal.redback.com (Postfix) with ESMTP
	id 526552AA04; Fri, 23 Jun 2000 08:28:30 -0700 (PDT)
To: Jeff Parker <jparker@nexabit.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, swallow@cisco.com, mpls@UU.NET,
        isis-wg@juniper.net
Subject: Re: [Isis-wg] RE: LSP hierarchy with MPLS TE 
In-reply-to: Mail from Jeff Parker <jparker@nexabit.com> 
 dated Fri, 23 Jun 2000 10:05:59 EDT
 <BAC9CCF04FEED311BD1D00062950ABB157D751@bandito.nexabit.com> 
Date: Fri, 23 Jun 2000 08:27:43 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20000623152830.526552AA04@postal.redback.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


I think you can use the cue which normal IS-IS ignores this type of
links, which is the links are having the default metric of (2^24 - 1).


 ]> Folks,
 ]> 
 ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt
 ]> be accepted as a work group document.  So far I've only seen support.
 ]> If there are no objects by 6/27, we'll declare it so.
 ]> 
 ]> ...George
 ]
 ]I find this draft a useful addition to the discussion of TE, and would
 ]support it's adoption as an MPLS group document.
 ]
 ]However, I am a bit puzzled by the last paragraph before
 ]section 4.3 (bottom of page 5).
 ]
 ]	"Route computation procedures should not perform two-way
 ]	 connectivity check on the links used by the procedures.
 ]	 That is, the two way check should not be performed on
 ]	 one-way pipes, as they will fail."
 ]
 ]I agree that relaxing this test for one-way links is a Good Thing.  But 
 ]looking at the aged out draft "IS-IS extensions for Traffic Engineering"
 ]<draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish 
 ]"forward adjacencies" that are unidirectional LSPs from point-to-point 
 ]adjacencies, where we should retain the test.  
 ]
 ]Perhaps this will be addressed in the next rev of the IS-IS TE doc.  
 ]
 ]- jeff parker
 ]- Lucent Technologies
 ]
 ]
 ]_______________________________________________
 ]Isis-wg mailing list  -  Isis-wg@external.juniper.net
 ]http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming



From owner-mpls@UU.NET  Fri Jun 23 12:05:36 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13836
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 12:05:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvo18571;
	Fri, 23 Jun 2000 16:02:30 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvo17541
	for mpls-outgoing; Fri, 23 Jun 2000 16:01:59 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuvo17511
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 16:01:56 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvo09243
	for <mpls@uu.net>; Fri, 23 Jun 2000 12:01:47 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuvo17851
	for <mpls@uu.net>; Fri, 23 Jun 2000 16:01:47 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA02829
	for mpls@uu.net; Fri, 23 Jun 2000 12:01:46 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuvm13123
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 15:33:33 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvm11305
	for <mpls@UU.NET>; Fri, 23 Jun 2000 11:32:20 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQiuvm26326
	for <mpls@UU.NET>; Fri, 23 Jun 2000 15:32:20 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA14189;
	Fri, 23 Jun 2000 08:31:13 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <NCL20JYC>; Fri, 23 Jun 2000 08:32:12 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4063D@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Mike Badil'" <hasko10@hotmail.com>, mpls@UU.NET
Subject: RE: TE
Date: Fri, 23 Jun 2000 08:31:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Mike,

In theory it is possible to do some sort of limited constraint-based routing
without Explicit-Routing (with or without MPLS). In order to do that you
need to define a new routing protocol (let's call it QoS-OSPF), which can be
run on all routers and which can compute the best path according to some
predefined constraint. Drawbacks are:

1) All nodes need to do CR computation.
2) You can only support one set of CR rules.

Cheers,
-Shahram

>-----Original Message-----
>From: Mike Badil [mailto:hasko10@hotmail.com]
>Sent: Wednesday, June 21, 2000 8:49 PM
>To: mpls@UU.NET
>Subject: Re: TE
>
>
>
>Hi
>
>>True - you can do that in IP too.
>>
>>However, in IP if you want to do explicit routing, you need 
>to include the 
>>full
>>path information in each IP packet header. Now, that will 
>dramatically 
>>increase
>>the IP packet header size and consequently, the processing time will 
>>increase.
>>The explicit path used in MPLS has much less overhead 
>compared to that in 
>>IP.
>>"alex.mondrus" wrote:
>
>Yes, you are right, explicit routing is clear. I agree with what you 
>said,but My question was about Constraint Based Routing. How to choose 
>explicit path(best path according to TE)?, that explicit path is not 
>shortest path which calculated by OSPF.
>
>
>
>
>Thanks
>
>
>>
>> > In general to do an explicit path set up you do not need 
>to use MPLS.
>> >
>> > Alex Mondrus
>> >
>> > http://www.ipoptical.com
>> >
>> > Traffic Engineering - MPLS allows you to set up tunnels
>> > >         with explicit routing so that you can design your routes
>> > >         off-line in order to achieve best traffic distribution to
>> > >         minimize network hot spots (which often occur in OSPF
>> > >         type routing) and improve network capacity efficiency.
>> > >         Load balancing (parallel MPLS tunnels running between
>> > >         a source-dest pair) and trunk protection also 
>become easy.
>> >
>> > -----Original Message-----
>> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On 
>Behalf Of David
>> > Wilder
>> > Sent: Wednesday, June 21, 2000 12:02 PM
>> > To: Jay Wang
>> > Cc: hasko10@hotmail.com; mpls@UU.NET
>> > Subject: Re: TE
>> >
>> > Very well put Jay.
>> >
>> > - Dave
>> >
>> > > Mike,
>> > >
>> > >     MPLS is not created to support constraint based routing
>> > >     and it doesn't.  It let you set up layer two tunnels using
>> > >     label switching.  An IP network can benefit from the
>> > >     existence of MPLS with at least the following:
>> > >
>> > >     1. Faster data forwarding at the transient (core) routers -
>> > >         This is because there is only label (index) lookup and
>> > >         no IP header processing.  This however became much
>> > >         weaker an argument lately since lots of work that used
>> > >         to be done by software (e.g., header processing,
>> > >         classification) now are typically done in ASIC 
>in vendor's
>> > >         box.
>> > >
>> > >     2. Traffic Engineering - MPLS allows you to set up tunnels
>> > >         with explicit routing so that you can design your routes
>> > >         off-line in order to achieve best traffic distribution to
>> > >         minimize network hot spots (which often occur in OSPF
>> > >         type routing) and improve network capacity efficiency.
>> > >         Load balancing (parallel MPLS tunnels running between
>> > >         a source-dest pair) and trunk protection also 
>become easy.
>> > >
>> > >     3. QoS/VPN  - MPLS interworking with Diffserv gives 
>you traffic
>> > >         isolation (and hence some performance protection). Also,
>> > >         MPLS with proper support of resource
>> > >         reservation signaling mechanism (e.g., RSVP), 
>you can specify
>> > >         thE size of each MPLS 'pipe'.  With a careful 
>traffic trunk
>> > > analysis,
>> > >         you may set up a set of corresponding pipes 
>(using constraint
>> > based
>> > >         or explicit routing) such that you can place 
>some application
>> > > specific
>> > >         (e.g., voice,  video) flows on the trunks while 
>meeting some
>> > >         stringent real-time specs (e.g., loss, jitters, latency).
>> > >
>> > > - Jay
>> > >
>> > > David Charlap wrote:
>> > >
>> > > > Mike Badil wrote:
>> > > > >
>> > > > > I just reading MPLS document, I have a question 
>which I am not 
>>really
>> > > > > clear to understand, if someone helps I will be happy.
>> > > > >
>> > > > > The Question is:
>> > > > >
>> > > > > What makes MPLS to support constraint based routing?
>> > > >
>> > > > The existance of LSPs makes traffic engineering easier 
>to implement. 
>>  It
>> > > > does not make it impossible, however.
>> > > >
>> > > > > If it just adding contsraint metrics to conventional 
>routing in 
>>order
>> > > > > to support TE.
>> > > > > Why it is not possible without MPLS.
>> > > >
>> > > > Sure, it's possible.  Who said it wasn't?
>> > > >
>> > > > > In other word, in conventional IP routing, if we add 
>constraint
>> > > > > metrics, can conventional IP routing support it also?
>> > > >
>> > > > I think you're missing the point of MPLS.
>> > > >
>> > > > MPLS's purpose is not to create the ability to perform 
>>constraint-based
>> > > > routing and traffic engineering where it was 
>previously impossible.
>> > > >
>> > > > MPLS's purpose is to create a connection-oriented link 
>layer (COLL).
>> > > > Where forwarding decisions are made solely on the basis of a 
>>packet's
>> > > > label, and not on any other content in the packet.
>> > > >
>> > > > The use of a COLL is not a requirement for traffic 
>engineering.  It
>> > > > simply makes it easier to implement.  With a COLL, the 
>hard work of
>> > > > determining the path that data packets must take can 
>be done once, 
>>when
>> > > > the LSP is set up.  Without a COLL, this work must be 
>done by every
>> > > > switch, for every data packet.
>> > > >
>> > > > Connection oriented link layers are not new.  ATM and 
>Frame Relay 
>>also
>> > > > use them.  The big thing that makes MPLS special is 
>that it can run 
>>over
>> > > > nearly any transport medium (ATM, FR, POS, Ethernet, 
>etc) instead of
>> > > > being tied to a specific layer-2 encapsulation.  Also, 
>because it 
>>uses
>> > > > IP for its addressing, it can work with many common routing and
>> > > > signalling protocols (like OSPF, IS-IS, and RSVP).
>> > > >
>> > > > -- David
>> > >
>> > > --
>> > > Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
>> > > Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
>> > > 600 Mountain Avenue, Room 2C-308,          
>wang@research.bell-labs.com
>> > > Murray Hill, NJ 07974-2070
>> > >
>> > >
>> > >
>>
>>--
>>Regards,
>>Arup Das
>>(763-1863)
>>
>>
>>
>
>_______________________________________________________________
>_________
>Get Your Private, Free E-mail from MSN Hotmail at 
>http://www.hotmail.com
>



From owner-mpls@UU.NET  Fri Jun 23 12:24:37 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14241
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 12:24:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvp01999;
	Fri, 23 Jun 2000 16:19:36 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvp27816
	for mpls-outgoing; Fri, 23 Jun 2000 16:18:53 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuvp27691
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 16:18:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvp19974
	for <mpls@UU.NET>; Fri, 23 Jun 2000 12:18:19 -0400 (EDT)
Received: from c000.snv.cp.net by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: c000-h000.c000.snv.cp.net [209.228.32.64])
	id QQiuvp00794
	for <mpls@UU.NET>; Fri, 23 Jun 2000 16:18:18 GMT
Received: (cpmta 28796 invoked from network); 23 Jun 2000 09:18:17 -0700
Received: from dhcp196.altasoft.com (HELO am) (204.242.142.196)
  by smtp.ipoptical.com (209.228.32.64) with SMTP; 23 Jun 2000 09:18:17 -0700
X-Sent: 23 Jun 2000 16:18:17 GMT
From: "alex.mondrus" <alex.mondrus@ipoptical.com>
To: "Shahram Davari" <Shahram_Davari@pmc-sierra.com>,
        "'Mike Badil'" <hasko10@hotmail.com>, <mpls@UU.NET>
Subject: RE: TE
Date: Fri, 23 Jun 2000 12:26:30 -0400
Message-ID: <NEBBLJNJKMBINGNCIHNKGELOCAAA.alex.mondrus@ipoptical.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B4063D@nt-exchange-bby.pmc-sierra.bc.ca>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mike:

Please review the following document

http://www.seas.upenn.edu/~guerin/publications/qos_ospf_rfc.txt

Alex Mondrus

http://www.ipoptical.com




-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram
Davari
Sent: Friday, June 23, 2000 11:31 AM
To: 'Mike Badil'; mpls@UU.NET
Subject: RE: TE


Hi Mike,

In theory it is possible to do some sort of limited constraint-based routing
without Explicit-Routing (with or without MPLS). In order to do that you
need to define a new routing protocol (let's call it QoS-OSPF), which can be
run on all routers and which can compute the best path according to some
predefined constraint. Drawbacks are:

1) All nodes need to do CR computation.
2) You can only support one set of CR rules.

Cheers,
-Shahram

>-----Original Message-----
>From: Mike Badil [mailto:hasko10@hotmail.com]
>Sent: Wednesday, June 21, 2000 8:49 PM
>To: mpls@UU.NET
>Subject: Re: TE
>
>
>
>Hi
>
>>True - you can do that in IP too.
>>
>>However, in IP if you want to do explicit routing, you need
>to include the
>>full
>>path information in each IP packet header. Now, that will
>dramatically
>>increase
>>the IP packet header size and consequently, the processing time will
>>increase.
>>The explicit path used in MPLS has much less overhead
>compared to that in
>>IP.
>>"alex.mondrus" wrote:
>
>Yes, you are right, explicit routing is clear. I agree with what you
>said,but My question was about Constraint Based Routing. How to choose
>explicit path(best path according to TE)?, that explicit path is not
>shortest path which calculated by OSPF.
>
>
>
>
>Thanks
>
>
>>
>> > In general to do an explicit path set up you do not need
>to use MPLS.
>> >
>> > Alex Mondrus
>> >
>> > http://www.ipoptical.com
>> >
>> > Traffic Engineering - MPLS allows you to set up tunnels
>> > >         with explicit routing so that you can design your routes
>> > >         off-line in order to achieve best traffic distribution to
>> > >         minimize network hot spots (which often occur in OSPF
>> > >         type routing) and improve network capacity efficiency.
>> > >         Load balancing (parallel MPLS tunnels running between
>> > >         a source-dest pair) and trunk protection also
>become easy.
>> >
>> > -----Original Message-----
>> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On
>Behalf Of David
>> > Wilder
>> > Sent: Wednesday, June 21, 2000 12:02 PM
>> > To: Jay Wang
>> > Cc: hasko10@hotmail.com; mpls@UU.NET
>> > Subject: Re: TE
>> >
>> > Very well put Jay.
>> >
>> > - Dave
>> >
>> > > Mike,
>> > >
>> > >     MPLS is not created to support constraint based routing
>> > >     and it doesn't.  It let you set up layer two tunnels using
>> > >     label switching.  An IP network can benefit from the
>> > >     existence of MPLS with at least the following:
>> > >
>> > >     1. Faster data forwarding at the transient (core) routers -
>> > >         This is because there is only label (index) lookup and
>> > >         no IP header processing.  This however became much
>> > >         weaker an argument lately since lots of work that used
>> > >         to be done by software (e.g., header processing,
>> > >         classification) now are typically done in ASIC
>in vendor's
>> > >         box.
>> > >
>> > >     2. Traffic Engineering - MPLS allows you to set up tunnels
>> > >         with explicit routing so that you can design your routes
>> > >         off-line in order to achieve best traffic distribution to
>> > >         minimize network hot spots (which often occur in OSPF
>> > >         type routing) and improve network capacity efficiency.
>> > >         Load balancing (parallel MPLS tunnels running between
>> > >         a source-dest pair) and trunk protection also
>become easy.
>> > >
>> > >     3. QoS/VPN  - MPLS interworking with Diffserv gives
>you traffic
>> > >         isolation (and hence some performance protection). Also,
>> > >         MPLS with proper support of resource
>> > >         reservation signaling mechanism (e.g., RSVP),
>you can specify
>> > >         thE size of each MPLS 'pipe'.  With a careful
>traffic trunk
>> > > analysis,
>> > >         you may set up a set of corresponding pipes
>(using constraint
>> > based
>> > >         or explicit routing) such that you can place
>some application
>> > > specific
>> > >         (e.g., voice,  video) flows on the trunks while
>meeting some
>> > >         stringent real-time specs (e.g., loss, jitters, latency).
>> > >
>> > > - Jay
>> > >
>> > > David Charlap wrote:
>> > >
>> > > > Mike Badil wrote:
>> > > > >
>> > > > > I just reading MPLS document, I have a question
>which I am not
>>really
>> > > > > clear to understand, if someone helps I will be happy.
>> > > > >
>> > > > > The Question is:
>> > > > >
>> > > > > What makes MPLS to support constraint based routing?
>> > > >
>> > > > The existance of LSPs makes traffic engineering easier
>to implement.
>>  It
>> > > > does not make it impossible, however.
>> > > >
>> > > > > If it just adding contsraint metrics to conventional
>routing in
>>order
>> > > > > to support TE.
>> > > > > Why it is not possible without MPLS.
>> > > >
>> > > > Sure, it's possible.  Who said it wasn't?
>> > > >
>> > > > > In other word, in conventional IP routing, if we add
>constraint
>> > > > > metrics, can conventional IP routing support it also?
>> > > >
>> > > > I think you're missing the point of MPLS.
>> > > >
>> > > > MPLS's purpose is not to create the ability to perform
>>constraint-based
>> > > > routing and traffic engineering where it was
>previously impossible.
>> > > >
>> > > > MPLS's purpose is to create a connection-oriented link
>layer (COLL).
>> > > > Where forwarding decisions are made solely on the basis of a
>>packet's
>> > > > label, and not on any other content in the packet.
>> > > >
>> > > > The use of a COLL is not a requirement for traffic
>engineering.  It
>> > > > simply makes it easier to implement.  With a COLL, the
>hard work of
>> > > > determining the path that data packets must take can
>be done once,
>>when
>> > > > the LSP is set up.  Without a COLL, this work must be
>done by every
>> > > > switch, for every data packet.
>> > > >
>> > > > Connection oriented link layers are not new.  ATM and
>Frame Relay
>>also
>> > > > use them.  The big thing that makes MPLS special is
>that it can run
>>over
>> > > > nearly any transport medium (ATM, FR, POS, Ethernet,
>etc) instead of
>> > > > being tied to a specific layer-2 encapsulation.  Also,
>because it
>>uses
>> > > > IP for its addressing, it can work with many common routing and
>> > > > signalling protocols (like OSPF, IS-IS, and RSVP).
>> > > >
>> > > > -- David
>> > >
>> > > --
>> > > Jay Wang - http://math.research.bell-labs.com/~wang/wang.htm
>> > > Bell Laboratories, Lucent Technologies     Tel: (908) 582-7223
>> > > 600 Mountain Avenue, Room 2C-308,
>wang@research.bell-labs.com
>> > > Murray Hill, NJ 07974-2070
>> > >
>> > >
>> > >
>>
>>--
>>Regards,
>>Arup Das
>>(763-1863)
>>
>>
>>
>
>_______________________________________________________________
>_________
>Get Your Private, Free E-mail from MSN Hotmail at
>http://www.hotmail.com
>




From owner-mpls@UU.NET  Fri Jun 23 12:47:21 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14764
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 12:47:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvr27898;
	Fri, 23 Jun 2000 16:45:18 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvq00800
	for mpls-outgoing; Fri, 23 Jun 2000 16:44:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuvq00792
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 16:44:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvq18561
	for <mpls@UU.NET>; Fri, 23 Jun 2000 12:44:32 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQiuvq27096
	for <mpls@UU.NET>; Fri, 23 Jun 2000 16:44:31 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDFAN>; Fri, 23 Jun 2000 09:50:52 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A6626907FF@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Grenville Armitage'" <gja@dnrc.bell-labs.com>,
        Kireeti Kompella
	 <kireeti@juniper.net>
Cc: mpls@UU.NET
Subject: RE: LSP hierarchy with MPLS TE
Date: Fri, 23 Jun 2000 09:50:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Folks,

	Based on this mail message (in which Yakov replied to
Daniel Awduche):

Yakov Rekhter wrote:
> > The FA concept clearly has independent interest, besides the 
> > original optical application. In fact, it is needed in certain
> > operational contexts today. Therefore, it's a good idea to
> > document it separately, and include additional relevant details 
> > not shown in draft-kompella-optical-mpls-00.txt, so that, 
> > hopefully, interoperable implementations can be derived
> 
> Kireeti and myself did as we promised. The Internet Draft is
> draft-kompella-lsp-hierarchy-00.txt. Kireeti and myself would like the
> MPLS WG to accept this Internet Draft as an MPLS WG document.
>
> Yakov.

I asked Yakov if there was any reason why he couldn't just
ask George Swallow and the working group to adopt this draft
as a working group document.  Since Yakov had already asked
the working group if it was a good idea to generate this 
draft, I thought it should go forward as such.

	I doubt that I was the only one to make this suggestion
but - if I was - I apologize for any precedent setting trend
it might have established.  There is nothing going on behind
the curtains on this one...

--
Eric Gray


Grenville Armitage wrote:
> -----Original Message-----
> From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com]
> Sent: Thursday, June 22, 2000 11:30 PM
> To: Kireeti Kompella
> Cc: mpls@UU.NET
> Subject: Re: LSP hierarchy with MPLS TE
> 
> 
> 
> if your new draft is no more than some contents extracted
> from a draft already accepted to be a working group document,
> then yes i did miss that point.
> 
> cheers,
> gja
> 
> Kireeti Kompella wrote:
> > 
> > > I wouldn't call this an objection, but how about we decide
> > > its disposition at the upcoming IETF after hearing a presentation?
> > 
> > I guess you missed my presentation of 
> draft-kompella-mpls-optical-00.txt,
> > the focus of which was Forwarding Adjacencies, the basis of the LSP
> > hierarchy draft.
> > 
> > >From the minutes of the IETF 47 MPLS WG:
> > 
> >   Kireeti Kompella started off his presentation by 
> discussing network
> >   design considerations, but mentioned that the focus of 
> the talk was on
> >   forwarding adjacencies.
> > 
> >   ...
> > 
> >   He went on to discuss forwarding adjacencies, which were 
> a key part of
> >   this draft. (etc)
> > 
> > Of course, if enough people ask for an encore, Yakov or I will be
> > glad to do it.
> > 
> > Kireeti.
> 
> -- 
> ______________________________________________________________
> __________
> Grenville Armitage                    
> http://members.home.net/garmitage/
> Bell Labs Research Silicon Valley
> 


From owner-mpls@UU.NET  Fri Jun 23 13:13:41 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15542
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 13:13:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvs23264;
	Fri, 23 Jun 2000 17:11:54 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvs14238
	for mpls-outgoing; Fri, 23 Jun 2000 17:11:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuvs14228
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 17:11:21 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuvs00231
	for <mpls@UU.NET>; Fri, 23 Jun 2000 13:10:49 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nat-01.juniper.net [208.197.169.49])
	id QQiuvs05082
	for <mpls@UU.NET>; Fri, 23 Jun 2000 17:10:48 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA00739;
	Fri, 23 Jun 2000 10:10:42 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA05765; Fri, 23 Jun 2000 10:10:36 -0700 (PDT)
Date: Fri, 23 Jun 2000 10:10:36 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006231710.KAA05765@kummer.juniper.net>
To: jparker@nexabit.com, kireeti@juniper.net, swallow@cisco.com
Subject: RE: LSP hierarchy with MPLS TE
Cc: isis-wg@juniper.net, mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Jeff,

> I find this draft a useful addition to the discussion of TE, and would
> support it's adoption as an MPLS group document.

Thanks!

> However, I am a bit puzzled by the last paragraph before
> section 4.3 (bottom of page 5).

> 	"Route computation procedures should not perform two-way
> 	 connectivity check on the links used by the procedures.
> 	 That is, the two way check should not be performed on
> 	 one-way pipes, as they will fail."

Here's the deal: if you have a unidirectional FA-LSP from A to B,
but no LSP from B to A, and you want to compute a _TE_ path for
another LSP to tunnel over the FA-LSP, the two-way check will not
allow the FA-LSP to be used.  Hence the above statement.

> I agree that relaxing this test for one-way links is a Good Thing.

Note that for CSPF (i.e., TE path) computation, discarding the two-way
check will not cause routing loops.  However, it's trivial to come up
with an example where if a router doesn't do the two-way check for
'regular' SPF but other routers do, you will get permanent routing
loops.  Yes, it might be a Good Thing to eventually relax the two-way
check for regular SPF as well, but that would take much more work.

> looking at the aged out draft "IS-IS extensions for Traffic Engineering"
> <draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish 
> "forward adjacencies" that are unidirectional LSPs from point-to-point 
> adjacencies, where we should retain the test.  

Forwarding adjacencies are (almost) indistinguishable from point-to-point
links.  However, the distinction we're making is CSPF vs. regular
SPF, not FAs vs. p2p links.  For *all* CSPF computations, we recommend
not doing the two-way check.  For all SPF computations, we _highly_
recommend doing the two-way check (for fear of routing loops) until
such time that there is means to achieve consensus among *all* the
routers in an ISIS level/OSPF area not to do the two-way check.

Kireeti.


From owner-mpls@UU.NET  Fri Jun 23 13:20:36 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15705
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 13:20:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvt12980;
	Fri, 23 Jun 2000 17:18:51 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvt15735
	for mpls-outgoing; Fri, 23 Jun 2000 17:18:23 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuvt15727
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 17:18:19 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuvt25520
	for <mpls@UU.NET>; Fri, 23 Jun 2000 13:18:03 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6])
	id QQiuvt12223
	for <mpls@UU.NET>; Fri, 23 Jun 2000 17:18:03 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jun 23 13:17:04 EDT 2000
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA18527;
	Fri, 23 Jun 2000 13:17:35 -0400 (EDT)
Message-ID: <39539C70.181A18BD@dnrc.bell-labs.com>
Date: Fri, 23 Jun 2000 10:20:48 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <EGray@zaffire.com>
CC: Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: LSP hierarchy with MPLS TE
References: <9A564CC874B5D3118FB9009027B0A6626907FF@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Eric Gray wrote:
	[..]
>         I doubt that I was the only one to make this suggestion
> but - if I was - I apologize for any precedent setting trend
> it might have established.  There is nothing going on behind
> the curtains on this one...

Well, just to clear up any confusion, my suggestion was procedural
not a comment on the contents. My brain glitched insofar as
I thought it was new material.

cheers,
gja


From owner-mpls@UU.NET  Fri Jun 23 13:36:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15996
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 13:36:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvu27066;
	Fri, 23 Jun 2000 17:34:24 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvu17474
	for mpls-outgoing; Fri, 23 Jun 2000 17:34:04 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuvu17464
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 17:33:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvu28466
	for <mpls@UU.NET>; Fri, 23 Jun 2000 13:33:43 -0400 (EDT)
Received: from alpo.casc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpo.casc.com [152.148.10.6])
	id QQiuvu11187
	for <mpls@UU.NET>; Fri, 23 Jun 2000 17:33:43 GMT
Received: from athletic.casc.com (athletic [152.148.12.133])
	by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id NAA07869;
	Fri, 23 Jun 2000 13:33:43 -0400 (EDT)
Received: by athletic.casc.com (8.8.8+Sun/SMI-SVR4)
	id NAA18557; Fri, 23 Jun 2000 13:33:42 -0400 (EDT)
From: Ravi Sastry <rsastry@lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14675.40822.557469.84707@gargle.gargle.HOWL>
Date: Fri, 23 Jun 2000 13:33:42 -0400 (EDT)
To: kireeti@juniper.net
Cc: mpls@UU.NET, Ravi Sastry <rsastry@lucent.com>
Subject: RE: LSP hierarchy with MPLS TE
References: <BAC9CCF04FEED311BD1D00062950ABB157D751@bandito.nexabit.com>
X-Mailer: VM 6.75 under 19.14 XEmacs Lucid
Reply-To: Ravi Sastry <rsastry@casc.com>
X-Organization: Lucent Technologies, Internetworking Systems, Westford, MA.
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



 Kireeti:
 
   I have a couple of questions on the LSP hierarchy draft
   These may be nitty gritty details. I thought I would ask them
   anyway. 

   1) Do FA-LSPs span across multiple OSPF areas?  If the answer is
      yes, 
       a) the OSPF-TE draft need to be extended to support
          summarization of TE-LSAs across areas.    
       b) I am not sure how forwarding adjacencies can be represented
          as unnumbered links.

   2) Suppose, the metric on the path to FA-LSP tail-end changes such a
      way that, there is a better TE path between head-end and the
      tail-end. Then all the LSPs that follow FA-LSP path may need to
      be rerouted (assuming they are not pinned).  This calls for
      considerable reroute processing at the head-end of the FA-LSP.

    
  Overall I think it is a good draft and, should be adopted as IETF
  draft. 

 thanks

 ravi/




From owner-mpls@UU.NET  Fri Jun 23 13:46:47 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16160
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 13:46:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvv07352;
	Fri, 23 Jun 2000 17:45:00 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvu18474
	for mpls-outgoing; Fri, 23 Jun 2000 17:44:23 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuvu18455
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 17:44:04 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuvu06416
	for <mpls@uu.net>; Fri, 23 Jun 2000 13:43:48 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuvu05944
	for <mpls@uu.net>; Fri, 23 Jun 2000 17:43:47 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA19414
	for mpls@uu.net; Fri, 23 Jun 2000 13:43:47 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuvu18386
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 17:43:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuvu00129
	for <mpls@UU.NET>; Fri, 23 Jun 2000 13:42:56 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQiuvu05247
	for <mpls@UU.NET>; Fri, 23 Jun 2000 17:42:55 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA05586; Fri, 23 Jun 2000 13:42:54 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com ([161.44.204.102])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA19447;
	Fri, 23 Jun 2000 13:43:25 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000623133059.075b3cb0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 23 Jun 2000 13:39:21 -0400
To: Adrian Farrel <AF@datcon.co.uk>, Jonathan Lang <jplang@calient.net>,
        "'Eric Gray'" <EGray@zaffire.com>,
        "Ross Callon (E-mail)" <rcallon@juniper.com>,
        "Arun Viswanathan (E-mail)" <arun@force10networks.com>,
        "'Eric Rosen'" <erosen@cisco.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: MPLS Architecture Issue
Cc: "'MPLS Mailing List'" <mpls@UU.NET>
In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2A31C6@monk.datcon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi,

         Whenever a standards track document is available
which thoroughly outlines (not just alludes to) how
bi-directional tunnels are defined for MPLS, we will
add support for such a mechanism at that time. Our
mandate from the MPLS working group is to produce
a MIB which reflects the currently defined standards
for MPLS Traffic Engineering.

         --Tom


>The bi-directionality in draft-lang-mpls-rsvp-oxc provides a good model for
>bi-directional LSPs in optical and non-optical networks.
>In a network built on ATM hardware it is also necessary to know whether the
>full bi-directionality of the switching will be used since it is often
>possible to reserve resources in such hardware in a uni-directional sense.
>Such function will also require an extension to the signaling protocol (or
>carnal knowledge amongst the switches) and draft-lang-mpls-rsvp-oxc could
>provide such a mechanism (although is perhaps heavy handed for this use).





>Adrian
>--
>Adrian Farrel  mailto:af@datcon.co.uk
>Network Convergence Group
>Data Connection Ltd., Chester, UK
>http://www.datcon.co.uk/
>Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
>
>
> >-----Original Message-----
> >From: Jonathan Lang [mailto:jplang@calient.net]
> >Sent: Thursday, June 22, 2000 11:07 PM
> >To: 'Eric Gray'; Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric
> >Rosen'
> >Cc: Thomas D. Nadeau (E-mail); 'MPLS Mailing List'
> >Subject: RE: MPLS Architecture Issue
> >
> >
> >Eric,
> >
> >There were two drafts presented at the last meeting in Adelaide that
> >proposed bi-directional LSPs (draft-lang-mpls-rsvp-oxc-00.txt and
> >draft-saha-rsvp-optical-signaling-00.txt).  These were
> >primarily a result of
> >optical constraints, but there is no reason they couldn't be used for
> >regular LSPs.
> >
> >Jonathan
> >
> >Calient Networks
> >
> >> -----Original Message-----
> >> From: Eric Gray [mailto:EGray@zaffire.com]
> >> Sent: Thursday, June 22, 2000 1:46 PM
> >> To: Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric Rosen'
> >> Cc: Eric Gray; Thomas D. Nadeau (E-mail); 'MPLS Mailing List'
> >> Subject: MPLS Architecture Issue
> >>
> >>
> >> Eric (et al),
> >>
> >>     Tom earlier made the point that none of the
> >> MPLS drafts appear to introduce - let alone
> >> discuss or specify - the notion of bi-directional
> >> association of LSPs.  There is the notion of use
> >> of Labels under circumstances in which specific
> >> hardware uses "labels" (VPI/VCI, and possibly
> >> DLCI, values) in both directions, but this is not
> >> the same thing.
> >>
> >>     In an off-line discussion, we talked about the
> >> fact that the TE Requirements RFC (RFC2702) talks
> >> about the idea of bi-directional traffic trunks.
> >> It describes behaviors which might be hard for an
> >> NMS to model without being able to determine that
> >> an LSP-pair is used as a bidirectional LSP tunnel.
> >> But it is "only" an informational RFC.
> >>
> >>      The Framework draft briefly mentions use of
> >> bi-directional LSPs as a possible solution to error
> >> reporting problems, but - as far as I know - none
> >> of the current set of "standards track" MPLS drafts
> >> addresses the concept of pairing of LSPs to form a
> >> bi-directional tunnel or trunk.
> >>
> >>      Is it possible to add this to the Architecture
> >> at this point, do we need to create a standards track
> >> draft specifically for this purpose or is it enough
> >> to simply add appropriate "stuff" to the TE-MIB based
> >> on the informational RFC?
> >>
> >> --
> >> Eric Gray
> >>
> >




From owner-mpls@UU.NET  Fri Jun 23 14:05:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16490
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 14:05:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvw25108;
	Fri, 23 Jun 2000 18:03:20 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvw23351
	for mpls-outgoing; Fri, 23 Jun 2000 18:02:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuvw23240
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 18:02:25 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuvw04169
	for <mpls@uu.net>; Fri, 23 Jun 2000 14:02:07 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuvw23869
	for <mpls@uu.net>; Fri, 23 Jun 2000 18:02:06 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA22354
	for mpls@uu.net; Fri, 23 Jun 2000 14:02:06 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuvw22396
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 18:01:27 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvw09644
	for <mpls@UU.NET>; Fri, 23 Jun 2000 14:00:32 -0400 (EDT)
Received: from postal.redback.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postal.redback.com [155.53.12.9])
	id QQiuvw00926
	for <mpls@UU.NET>; Fri, 23 Jun 2000 18:00:31 GMT
Received: from redback.com (prz-laptop.redback.com [155.53.36.102])
	by postal.redback.com (Postfix) with ESMTP
	id 1289E2AA2D; Fri, 23 Jun 2000 11:00:31 -0700 (PDT)
Message-ID: <3953A756.996F26F1@redback.com>
Date: Fri, 23 Jun 2000 11:07:19 -0700
From: Tony Przygienda <prz@redback.com>
Organization: Siara Systems
X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Naiming Shen <naiming@redback.com>
Cc: Jeff Parker <jparker@nexabit.com>, Kireeti Kompella <kireeti@juniper.net>,
        swallow@cisco.com, mpls@UU.NET, isis-wg@juniper.net
Subject: Re: [Isis-wg] RE: LSP hierarchy with MPLS TE
References: <20000623152830.526552AA04@postal.redback.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Naiming Shen wrote:

> I think you can use the cue which normal IS-IS ignores this type of
> links, which is the links are having the default metric of (2^24 - 1).

there is a chance to confuse that with a disabled TE link of course.
Also (although that's minor) it's a disadvantage that if i choose not to
support LSP bundling. I'd loose control about which of the forwarding
adjacencies other LSRs prefer based on admin metric.

It seems to me much wiser to use the presence of the Link Mux Capability sub-TLV
as indication that only a one-way check is necessary. I assume that
sub-TLV is mandatory on forwarding adjacencies, the draft is not 100%
clear about that one.

    any clarification from the authors ?

    -- tony


>
>
>  ]> Folks,
>  ]>
>  ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt
>  ]> be accepted as a work group document.  So far I've only seen support.
>  ]> If there are no objects by 6/27, we'll declare it so.
>  ]>
>  ]> ...George
>  ]
>  ]I find this draft a useful addition to the discussion of TE, and would
>  ]support it's adoption as an MPLS group document.
>  ]
>  ]However, I am a bit puzzled by the last paragraph before
>  ]section 4.3 (bottom of page 5).
>  ]
>  ]      "Route computation procedures should not perform two-way
>  ]       connectivity check on the links used by the procedures.
>  ]       That is, the two way check should not be performed on
>  ]       one-way pipes, as they will fail."
>  ]
>  ]I agree that relaxing this test for one-way links is a Good Thing.  But
>  ]looking at the aged out draft "IS-IS extensions for Traffic Engineering"
>  ]<draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish
>  ]"forward adjacencies" that are unidirectional LSPs from point-to-point
>  ]adjacencies, where we should retain the test.
>  ]
>  ]Perhaps this will be addressed in the next rev of the IS-IS TE doc.
>  ]






From owner-mpls@UU.NET  Fri Jun 23 14:18:02 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16681
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 14:18:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvx06453;
	Fri, 23 Jun 2000 18:15:18 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvw02803
	for mpls-outgoing; Fri, 23 Jun 2000 18:14:45 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuvw02716
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 18:14:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvw06486
	for <mpls@UU.NET>; Fri, 23 Jun 2000 14:14:02 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35])
	id QQiuvw10798
	for <mpls@UU.NET>; Fri, 23 Jun 2000 18:14:02 GMT
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by ertpg14e1.nortelnetworks.com; Fri, 23 Jun 2000 10:51:33 -0400
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N3NSC8G6; Fri, 23 Jun 2000 10:51:19 -0400
Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id N2LHG1HW; Fri, 23 Jun 2000 10:51:19 -0400
Message-ID: <39537968.3D26A170@americasm01.nt.com>
Date: Fri, 23 Jun 2000 10:51:20 -0400
From: "Darek Skalecki" <dareks@nortelnetworks.com>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: MPLS <mpls@apollo.mctr.umbc.edu>
CC: mpls@UU.NET
Subject: Re: TE conversions from Reserved to unreserved bandwidth
References: <Pine.GSO.3.95.1000622094220.28746A-100000@mercury.mctr.umbc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

MPLS wrote:

> Hi,
>
> This is in reference to implementation of IGP extensions to support TE.
>
> If the IGP advertises the Reserved bandwidth per priority, then what are
> the mechanism/equations to deduce the Unreserved bandwidth per priority?
> Also how about the reverse mapping (i.e from Reserved bandwidth per
> priority how do we et the Unreserved b/w per priority).
>
> Thanks in advance,
> gargi

There are 2 priorities defined in MPLS: holding priority and setup
priority. Setup priority specifies how important it is to establish an LSP,

while holding priority specifies how important it is for an already
established LSP to hold on to its reserved resources. Both priorities have
a range of 0 (highest priority) to 7 (lowest priority). Relationship
between the priorities is the following: an LSP with higher (numerically
lower) setup priority can bump (preempt) an LSP with lower (numerically
higher) holding priority in order to acquire its reserved resources.

Note that holding priority should never be lower (numerically higher) than
setup priority or continuous bumping (preemption) may occur.

 If you know the reserved bandwidth by holding priority (BWH[h], h = 0..7)
then you can compute unreserved bandwidth by setup priority (BWS[s], s =
0..7) using the following formula:

BWS[s] = MRB - SUM_h=0_to_s(BWH[h])

where MRB is the maximum reservable bandwidth, and SUM_h=0_to_s is a crude
representation of mathermatical summation notation.

For example,

BWS[3] = MRB - (BWH[0] + BWH[1] + BWH[2] + BWH[3])
BWS[0] = MRB - (BWH[0])

If people agree then maybe the formula should make its way into one of the
drafts (OSPF/ISIS TE extensions or CR-LDP)?

Darek



From owner-mpls@UU.NET  Fri Jun 23 14:25:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16778
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 14:25:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvx16492;
	Fri, 23 Jun 2000 18:22:56 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvx04139
	for mpls-outgoing; Fri, 23 Jun 2000 18:22:25 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuvx04105
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 18:22:06 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuvx07797
	for <mpls@uu.net>; Fri, 23 Jun 2000 14:21:37 -0400 (EDT)
Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nat-01.juniper.net [208.197.169.49])
	id QQiuvx15539
	for <mpls@uu.net>; Fri, 23 Jun 2000 18:21:36 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA06050;
	Fri, 23 Jun 2000 11:21:03 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id LAA06008; Fri, 23 Jun 2000 11:20:58 -0700 (PDT)
Date: Fri, 23 Jun 2000 11:20:58 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006231820.LAA06008@kummer.juniper.net>
To: rsastry@casc.com
Subject: RE: LSP hierarchy with MPLS TE
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Ravi,

>    I have a couple of questions on the LSP hierarchy draft
>    These may be nitty gritty details. I thought I would ask them
>    anyway. 

Please do!  In the final analysis, nitty gritty details make or
break implementations (and drafts).

>    1) Do FA-LSPs span across multiple OSPF areas?  If the answer is
>       yes, 
>        a) the OSPF-TE draft need to be extended to support
>           summarization of TE-LSAs across areas.    

To date, not too much work has been done on multi-area TE path
computation.  There is a draft draft-fujita-ospf-te-summary-00.txt
on TE summarization; I think more work should be focussed on this
subject.

>        b) I am not sure how forwarding adjacencies can be represented
>           as unnumbered links.

We suggest that FAs are numbered with the router IDs of the two ends
in the case where they are not explicitly numbered.

>    2) Suppose, the metric on the path to FA-LSP tail-end changes such a
>       way that, there is a better TE path between head-end and the
>       tail-end. Then all the LSPs that follow FA-LSP path may need to
>       be rerouted (assuming they are not pinned).  This calls for
>       considerable reroute processing at the head-end of the FA-LSP.

If the head end of the above FA-LSP notices a better path and
reroutes the FA-LSP, yes, you are right, the burden is on the head
end to adjust the tunneled LSPs to take the new FA-LSP path.  There
is definitely some work here, but consider that the head end of a
'normal' TE LSP usually maps several hundred or thousand IP routes
to the LSP, and manages to (at least, it should!) handle reroutes
reasonably gracefully.  If the number of tunneled LSPs over a single
FA-LSP approaches 10s to 100s of thousands, this issue gets serious --
however, in this event, LSP hierarchy would have proven its worth :-)

Note that there is little signalling impact: either the Path messages
were going through the FA-LSP (small change to make them take the new
path), or they were unicast to the tail end (nothing changes).

>   Overall I think it is a good draft and, should be adopted as IETF
>   draft. 

Thanks!

Kireeti.


From owner-mpls@UU.NET  Fri Jun 23 14:36:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17039
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 14:36:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuvy22540;
	Fri, 23 Jun 2000 18:32:13 GMT
Received: by mail-control.mail.uu.net 
	id QQiuvy05082
	for mpls-outgoing; Fri, 23 Jun 2000 18:31:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiuvy05067
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 18:31:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuvy14524
	for <mpls@UU.NET>; Fri, 23 Jun 2000 14:31:03 -0400 (EDT)
Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nat-01.juniper.net [208.197.169.49])
	id QQiuvy20432
	for <mpls@UU.NET>; Fri, 23 Jun 2000 18:31:02 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA06878;
	Fri, 23 Jun 2000 11:30:57 -0700 (PDT)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id LAA06067; Fri, 23 Jun 2000 11:30:51 -0700 (PDT)
Date: Fri, 23 Jun 2000 11:30:51 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200006231830.LAA06067@kummer.juniper.net>
To: dareks@nortelnetworks.com, mpls@apollo.mctr.umbc.edu
Subject: Re: TE conversions from Reserved to unreserved bandwidth
Cc: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

> If the IGP advertises the Reserved bandwidth per priority, then what are
> the mechanism/equations to deduce the Unreserved bandwidth per priority?

From the expired ISIS document:

5.6 Sub-TLV 11: Unreserved bandwidth
                ^^^^^^^^^^
   
   This sub-TLV contains the amount of bandwidth reservable on this
   direction on this link.  Note that for oversubscription purposes,
   this can be greater than the bandwidth of the link.          
   
   Because of the need for priority and preemption, each head end needs 
   to know the amount of reserved bandwidth at each priority level.
   Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers.
   The units are bytes (not bits!) per second.  The values correspond to
   the bandwidth that can be reserved with a holding of priority 0
   through 7, arranged in increasing order with priority 0 occurring at
   the start of the sub-TLV, and priority 7 at the end of the sub-TLV.

From the expired OSPF document:

2.5.8  Unreserved Bandwidth
       ^^^^^^^^^^

   The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
   not yet reserved at each of the eight priority levels, in IEEE
   floating point format.  Each value will be less than or equal to the
   maximum reservable bandwidth.  The units are bytes per second.

   The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in
   length.

Kireeti.


From owner-mpls@UU.NET  Fri Jun 23 16:09:39 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18618
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 16:09:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuwe03592;
	Fri, 23 Jun 2000 20:08:02 GMT
Received: by mail-control.mail.uu.net 
	id QQiuwe07406
	for mpls-outgoing; Fri, 23 Jun 2000 20:07:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuwe07401
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 20:07:42 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuwe24709
	for <mpls@uu.net>; Fri, 23 Jun 2000 16:07:37 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuwe03161
	for <mpls@uu.net>; Fri, 23 Jun 2000 20:07:36 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA10078
	for mpls@uu.net; Fri, 23 Jun 2000 16:07:36 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiuwe07364
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 20:07:16 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuwe24608
	for <mpls@uu.net>; Fri, 23 Jun 2000 16:07:11 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQiuwe05918
	for <mpls@uu.net>; Fri, 23 Jun 2000 20:07:11 GMT
Received: from pluris.com (root@lightning.pluris.com [172.16.55.100])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA29333
	for <mpls@uu.net>; Fri, 23 Jun 2000 13:07:10 -0700 (PDT)
Message-ID: <3953C36E.69630FC0@pluris.com>
Date: Fri, 23 Jun 2000 13:07:10 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Comment on the MPLS Diffserv Extensions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

More comments to follow, but for now, can we please take out section 11
related to ECN bits out of this draft. I think ECN handling is
completely outside the scope of this draft and section 11 does not do a
good enough job of discussing it.

Bora Akyol






From owner-mpls@UU.NET  Fri Jun 23 16:45:01 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19094
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 16:45:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuwg29254;
	Fri, 23 Jun 2000 20:42:55 GMT
Received: by mail-control.mail.uu.net 
	id QQiuwg11138
	for mpls-outgoing; Fri, 23 Jun 2000 20:42:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuwg11131
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 20:42:05 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuwg01566
	for <mpls@UU.NET>; Fri, 23 Jun 2000 16:42:03 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6])
	id QQiuwg28540
	for <mpls@UU.NET>; Fri, 23 Jun 2000 20:42:03 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jun 23 16:41:37 EDT 2000
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA21224;
	Fri, 23 Jun 2000 16:42:09 -0400 (EDT)
Message-ID: <3953CC62.5DC29E80@dnrc.bell-labs.com>
Date: Fri, 23 Jun 2000 13:45:22 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
CC: Bora Akyol <akyol@pluris.com>
Subject: Re: Comment on the MPLS Diffserv Extensions
References: <3953C36E.69630FC0@pluris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


I'm in the process of writing my own comments on this I-D,
but in case I forget I want to concur with Bora here. The
section on ECN isn't necessary, and detracts from this document's
focus as a normative spec on diffserv mappings. It is sufficient
to note that use of ECN concepts might involve borrowing
EXP bits, but that additional discussion is outside the scope 
of draft-ietf-mpls-diff-ext-05.txt.

cheers,
gja

Bora Akyol wrote:
> 
> More comments to follow, but for now, can we please take out section 11
> related to ECN bits out of this draft. I think ECN handling is
> completely outside the scope of this draft and section 11 does not do a
> good enough job of discussing it.
> 
> Bora Akyol

-- 
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Fri Jun 23 17:53:08 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20115
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 17:53:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuwl05472;
	Fri, 23 Jun 2000 21:51:54 GMT
Received: by mail-control.mail.uu.net 
	id QQiuwl26533
	for mpls-outgoing; Fri, 23 Jun 2000 21:51:06 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuwl26519
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 21:50:59 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuwl13653
	for <mpls@uu.net>; Fri, 23 Jun 2000 17:50:51 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiuwl27520
	for <mpls@uu.net>; Fri, 23 Jun 2000 21:50:50 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA20789
	for mpls@uu.net; Fri, 23 Jun 2000 17:50:50 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuwl26453
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 21:50:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiuwl13601
	for <mpls@UU.NET>; Fri, 23 Jun 2000 17:50:17 -0400 (EDT)
Received: from postal.redback.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postal.redback.com [155.53.12.9])
	id QQiuwl27201
	for <mpls@UU.NET>; Fri, 23 Jun 2000 21:50:17 GMT
Received: from redback.com (malt.redback.com [155.53.12.41])
	by postal.redback.com (Postfix) with ESMTP
	id C29E72AA1D; Fri, 23 Jun 2000 14:50:16 -0700 (PDT)
To: Tony Przygienda <prz@redback.com>
Cc: Jeff Parker <jparker@nexabit.com>, Kireeti Kompella <kireeti@juniper.net>,
        swallow@cisco.com, mpls@UU.NET, isis-wg@juniper.net
Subject: Re: [Isis-wg] RE: LSP hierarchy with MPLS TE 
In-reply-to: Mail from Tony Przygienda <prz@redback.com> 
 dated Fri, 23 Jun 2000 11:07:19 PDT
 <3953A756.996F26F1@redback.com> 
Date: Fri, 23 Jun 2000 14:49:29 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20000623215016.C29E72AA1D@postal.redback.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


don't want to speak for the authors, but the difference from a
disabled TE link is that this LSP link has a usable TE metric set.
this hierarchy scheme is independent of LSP bundling, you can announce
and set different metric on different LSPs the same source/dest pair.
so i don't see why the Mux TLV should be required.

an interesting question is how do you set the link metric to
be max(1, (the TE metric of the FA-LSP path) - 1)? something like
the one mentioned in an expired draft:-)

thanks.

 ]Naiming Shen wrote:
 ]
 ]> I think you can use the cue which normal IS-IS ignores this type of
 ]> links, which is the links are having the default metric of (2^24 - 1).
 ]
 ]there is a chance to confuse that with a disabled TE link of course.
 ]Also (although that's minor) it's a disadvantage that if i choose not to
 ]support LSP bundling. I'd loose control about which of the forwarding
 ]adjacencies other LSRs prefer based on admin metric.
 ]
 ]It seems to me much wiser to use the presence of the Link Mux Capability sub-
TLV
 ]as indication that only a one-way check is necessary. I assume that
 ]sub-TLV is mandatory on forwarding adjacencies, the draft is not 100%
 ]clear about that one.
 ]
 ]    any clarification from the authors ?
 ]
 ]    -- tony
 ]
 ]
 ]>
 ]>
 ]>  ]> Folks,
 ]>  ]>
 ]>  ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.t
xt
 ]>  ]> be accepted as a work group document.  So far I've only seen support.
 ]>  ]> If there are no objects by 6/27, we'll declare it so.
 ]>  ]>
 ]>  ]> ...George
 ]>  ]
 ]>  ]I find this draft a useful addition to the discussion of TE, and would
 ]>  ]support it's adoption as an MPLS group document.
 ]>  ]
 ]>  ]However, I am a bit puzzled by the last paragraph before
 ]>  ]section 4.3 (bottom of page 5).
 ]>  ]
 ]>  ]      "Route computation procedures should not perform two-way
 ]>  ]       connectivity check on the links used by the procedures.
 ]>  ]       That is, the two way check should not be performed on
 ]>  ]       one-way pipes, as they will fail."
 ]>  ]
 ]>  ]I agree that relaxing this test for one-way links is a Good Thing.  But
 ]>  ]looking at the aged out draft "IS-IS extensions for Traffic Engineering"
 ]>  ]<draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish
 ]>  ]"forward adjacencies" that are unidirectional LSPs from point-to-point
 ]>  ]adjacencies, where we should retain the test.
 ]>  ]
 ]>  ]Perhaps this will be addressed in the next rev of the IS-IS TE doc.
 ]>  ]
 ]
 ]
 ]

- Naiming



From owner-mpls@UU.NET  Fri Jun 23 18:47:43 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22254
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 18:47:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuwp18446;
	Fri, 23 Jun 2000 22:45:55 GMT
Received: by mail-control.mail.uu.net 
	id QQiuwp11517
	for mpls-outgoing; Fri, 23 Jun 2000 22:45:35 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQiuwp11512
	for <mpls@mail-control.mail.uu.net>; Fri, 23 Jun 2000 22:45:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuwp21942
	for <mpls@UU.NET>; Fri, 23 Jun 2000 18:45:21 -0400 (EDT)
Received: from mail-green.research.att.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103])
	id QQiuwp18059
	for <mpls@UU.NET>; Fri, 23 Jun 2000 22:45:21 GMT
Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5])
	by mail-green.research.att.com (Postfix) with ESMTP
	id E5DCE1E025; Fri, 23 Jun 2000 18:45:20 -0400 (EDT)
Received: from pcalchiu (pclopez [135.207.131.94])
	by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id SAA03136;
	Fri, 23 Jun 2000 18:44:12 -0400 (EDT)
Reply-To: <alchiu@research.att.com>
From: "Angela Chiu" <alchiu@research.att.com>
To: "'Metz, E.T.'" <E.T.Metz@kpn.com>
Cc: "'Darek Skalecki'" <dareks@nortelnetworks.com>, "'mpls'" <mpls@UU.NET>,
        "'Francois Le Faucheur'" <flefauch@cisco.com>
Subject: RE: Bandwidth reservation per PSC
Date: Fri, 23 Jun 2000 18:45:28 -0400
Message-ID: <000701bfdd64$bb3edaf0$5e83cf87@pcalchiu>
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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <59063B5B4D98D311BC0D0001FA7E4522014437B3@l04.research.kpn.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eduard,

Resource class affinity attributes are different from PSCs. The attributes
associated with a traffic trunk can be used to specify the class of
resources which are to be explicitly included or excluded from the path of
the traffic trunk, e.g., excluding all satellite links for low-delay track
trunks. See RFC 2702.

Regards,
Angela

-----Original Message-----
From: Metz, E.T. [mailto:E.T.Metz@kpn.com]
Sent: Thursday, June 22, 2000 4:01 AM
To: 'Francois Le Faucheur'; alchiu@research.att.com
Cc: 'Darek Skalecki'; 'mpls'
Subject: RE: Bandwidth reservation per PSC



Hi,

isn't this already included in the current drafts? I thought there were
resource classes defined. This may not match with the PSC though.

In general, when (if) some form of classes are available, wouldn't it be
more efficient to map new types of classes to these? Instead of defining
extensions for new types of classes.

Just some thoughts.

cheers,
	Eduard

> -----Original Message-----
> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> Sent: woensdag 21 juni 2000 16:48
> To: alchiu@research.att.com
> Cc: 'Darek Skalecki'; 'mpls'; 'Francois Le Faucheur'
> Subject: RE: Bandwidth reservation per PSC
>
>
> Darek,
> I am hoping to submit something on extensions to IGPs for
> support of "Class-types". Let me know if you're interested in
> working on this.
> Francois
>
> At 17:41 20/06/2000 -0400, Angela Chiu wrote:
> >Darek,
> >
> >I don't think it is currently included in the OSPF and ISIS
> TE extensions. I
> >am not aware of anyone who is working on it. But I could be
> wrong since
> >there are so many activities around MPLS, hard to keep track
> of all of them.
> >
> >Angela
> >
> >-----Original Message-----
> >From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
> >Sent: Tuesday, June 20, 2000 4:06 PM
> >To: alchiu
> >Cc: mpls; 'Francois Le Faucheur'
> >Subject: Re: Bandwidth reservation per PSC
> >
> >
> >Thanks Angela,
> >
> >Are these extensions currently defined for OSPF and ISIS?.
> If yes then
> >please
> >provide me with a reference, and if not then is anyone
> working on them ?. I
> >can
> >only find extensions related to advertizing bandwidth
> availability per
> >priority
> >not resource class.
> >
> >Thanks,
> >
> >Darek
> >
> >
> >Angela Chiu wrote:
> >
> >> Darek,
> >>
> >> These are additional requirements for IGP extensions, as
> stated in TE
> >> Framework draft
> >>
> http://www.ietf.org/internet-drafts/draft-ietf-tewg-framework-01.txt
> >> "In order to perform constraint-based routing on a
> per-class basis for
> >LSPs,
> >> the conventional IGPs (e.g., IS-IS and OSPF) should
> provide extensions to
> >> propagate per-class resource information."
> >> Then the draft states that "per-class parameters can be
> aggregated into
> >> per-class-type parameters" for scalability improvements.
> >>
> >> Regards,
> >>
> >> Angela
> >>
> >> -----Original Message-----
> >> From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
> >> Sent: Tuesday, June 20, 2000 2:51 PM
> >> To: Francois Le Faucheur
> >> Cc: mpls@UU.NET; alchiu@att.com
> >> Subject: Re: Bandwidth reservation per PSC
> >>
> >> Thanks Francois,
> >>
> >> My question was indeed related to the distributed model.
> What I am still
> >not
> >> sure about is how bandwidth availability within OSPF/ISIS
> is advertized
> >per
> >> PSC or per family  of TE related PSCs when the TE
> extensions only imply
> >> advertizement per priority. Are colors assigned to
> different PSCs or
> >> families of TE related PSCs and bandwidth availability
> advertized per
> >> color?.
> >>
> >> Thanks,
> >>
> >> Darek
> >>
> >> Francois Le Faucheur wrote:
> >>
> >> > Darek,
> >> >
> >> > At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
> >> > >Hi,
> >> > >
> >> > >I have a question with regard to bandwidth availability
> per PSC and TE
> >> > >extensions to OSPF/ISIS.
> >> > >
> >> > >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in
> APPENDIX B Scenario 2
> >> > >about constraint based routing being
> >> > >performed separately for each PSC  where one of the
> constraints is
> >> > >availability of bandwidth from the bandwidth
> >> > >allocated to the relevant PSC.
> >> > >
> >> > >My question is how TE extensions to OSPF/ISIS support
> advertizing
> >> > >bandwidth availability per PSC. The only way I can
> >> > >think this can be achieved is by assigning different
> colors/resource
> >> > >classes to different PSCs thus advertizing bandwidth
> >> > >availability per PSC simply as bandwidth availability per
> >color/resource
> >> > >class. Is this correct?.
> >> > >
> >> > >If it is correct then how serious is the
> scaling/operational issue at
> >> > >least within OSPF since N  TE LSAs are needed for  N
> >> > >PSCs  for every link, implying lots of LSA traffic not
> to mention
> >> > >storage within LSDB (which I gather can only store
> >> > >65536 TE LSAs).
> >> > >
> >> >
> >> > First, of course , in some environments, Constraint
> Based Routing may be
> >> performed "off-line"/"in a Centralised Manner". In these
> situations,
> >per-PSC
> >> bandwidth availability can be determined by the
> centralised tool without
> >> relying on extensions to OSPF/ISIS.
> >> >
> >> > Where Constraint Based Routing is performed
> "on-line"/"in a Distributed
> >> Manner", then yes, OSPF/ISIS are required to propagate all
> necessary
> >> bandwidth information. This could be achieved in a number of ways:
> >> >         - one approach would be to advertise bandwidth
> information for
> >> every PSC. As you are pointing out above, this may lead to
> >> scaling/operational issues earlier than desired.
> >> >         - another approach would be to advertise
> bandwidth information
> >> only for each "family/class" of PSCs. A family/class of
> PSC would comprise
> >> all the PSCs which share the same bandwidth constraints.
> It is likely that
> >> multiple PSCs can share the same bandwidth constraints (eg
> >> "max-reservable-bandwidth"). For instance, multiple
> Premium/Non-real-time
> >> PSCs may share the same "max-reservable-bandwidth". In
> that case, you have
> >> traded a little bit of fine-grain control (you can't
> enforce bandwidth
> >> constraints which are different for absolutely every PSC),
> but you have
> >> significantly gained in scalability of OSPF/ISIS by "only"
> advertising 2/3
> >> available bandwidth information.
> >> >
> >> > You will find some text on the second approach in
> section "6.7 Traffic
> >> Engineering in Diffserv Environments" of
> ><draft-ietf-tewg-framework-01.txt>:
> >> >
> >> >    "Instead of having per-class parameters being configured and
> >> >    propagated on each LSR interface, per-class parameters can be
> >> >    aggregated into per-class-type parameters. The main
> motivation for
> >> >    grouping a set of classes into a class-type is to improve the
> >> >    scalability of IGP link state advertisements by propagating
> >> >    information on a per-class-type basis instead of on a
> per-class
> >> >    basis, and also to allow better bandwidth sharing
> between  classes in
> >> >    the same class-type..."
> >> >
> >> > Francois
> >> >
> >> > >Thanks,
> >> > >
> >> > >Darek Skalecki
> >> > >Nortel Networks
> >> > >
> >> >
> >> > _________________________________________________________________
> >> > Francois Le Faucheur
> >> > Development Engineer, IOS Layer 3 Services
> >> > Cisco Systems
> >> > Office Phone:           +33 4 92 96 75 64
> >> > Home Office Phone:     +33 4 92 94 00 78
> >> > Mobile :               +33 6 89 108 159
> >> > Vmail:                 +33 1 58 04 62 66
> >> > Fax:                   +33 4 92 96 79 08
> >> > Email:                  flefauch@cisco.com
> >> > _________________________________________________________________
> >> > Petra B - Les Lucioles - 291, rue Albert Caquot - 06560
> Valbonne -
> >France
> >> > _________________________________________________________________
> >
> _________________________________________________________________
> Francois Le Faucheur
> Development Engineer, IOS Layer 3 Services
> Cisco Systems
> Office Phone:   	+33 4 92 96 75 64
> Home Office Phone:     +33 4 92 94 00 78
> Mobile :               +33 6 89 108 159
> Vmail:                 +33 1 58 04 62 66
> Fax:                   +33 4 92 96 79 08
> Email:          	flefauch@cisco.com
> _________________________________________________________________
> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560
> Valbonne - France
> _________________________________________________________________
>



From owner-mpls@UU.NET  Fri Jun 23 20:39:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23542
	for <mpls-archive@lists.ietf.org>; Fri, 23 Jun 2000 20:39:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiuww21329;
	Sat, 24 Jun 2000 00:38:32 GMT
Received: by mail-control.mail.uu.net 
	id QQiuww09415
	for mpls-outgoing; Sat, 24 Jun 2000 00:37:55 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQiuww09410
	for <mpls@mail-control.mail.uu.net>; Sat, 24 Jun 2000 00:37:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiuww16045
	for <mpls@uu.net>; Fri, 23 Jun 2000 20:37:39 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQiuww18023
	for <mpls@uu.net>; Sat, 24 Jun 2000 00:37:39 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA05146
	for <mpls@uu.net>; Fri, 23 Jun 2000 17:37:38 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <M71CG3LT>; Fri, 23 Jun 2000 17:37:38 -0700
Message-ID: <E097FDA4F2FED311994000104B31A8611210ED@MONTEREY>
From: Puneet Agarwal <puneet@pluris.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: draft-ietf-mpls-diff-ext-05.txt comments
Date: Fri, 23 Jun 2000 17:37:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

1) The draft needs to detail the usage of hierarchical tunnel (HT)
especially
in the case of PHP. 

For PHP and HT to work for diffserv/MPLS the Penultimate LSR needs to know
the PHB -> EXP
mapping of the underlying encapsulated tunnels. Moreover, if a LSP is
carrying
multiple LSPs with different PHB-> EXP mapping, the penultimate LSR and even
the egress LSR (in case of no PHP) would need to determine (after Pop), the
type of the underlying LSP.

Another example to illustrate this complexity:
Consider the case when a L-LSP is sent over a prior established E-LSP. the
Penultimate LSR for the E-LSP has no knowledge of tunnels that are
hierarchically going through it. Hence when it does the penultimate POP, it
has no knowledge about the PHB->EXP encoding for the underlying L-LSP.
In order to do this correctly, one would need to maintain additional state
associated with the outer E-LSP in order to do the correct PHB-> EXP map for
the encapsulated L-LSP.

2) pg 21 - In the Pipe Model, when performing multiple push operations, the
LSR may need to be able to encode different PHB->EXP markings for each
pushed
label in the stack

3) pg 36, 3rd paragraph - recognizes --> recognize

4) pg 36, 5th paragraph: when a LSR can only support preconfigured
EXP <--> PHB mapping, if someone wants to set up the per label EXP <--> PHB
mapping, what error should the LSR return? Hopefully this error code is
different than "Diff-Serv Error" to differentiate it from invalid
EXP <--> PHB mapping.

-Puneet


From owner-mpls@UU.NET  Sun Jun 25 21:26:11 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11375
	for <mpls-archive@lists.ietf.org>; Sun, 25 Jun 2000 21:26:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivej11797;
	Mon, 26 Jun 2000 01:26:13 GMT
Received: by mail-control.mail.uu.net 
	id QQivej09736
	for mpls-outgoing; Mon, 26 Jun 2000 01:25:46 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivej09726
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 01:25:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivej04780
	for <mpls@uu.net>; Sun, 25 Jun 2000 21:25:39 -0400 (EDT)
Received: from coltrane.datcon.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.datcon.co.uk [192.91.191.4])
	id QQivej11632
	for <mpls@uu.net>; Mon, 26 Jun 2000 01:25:39 GMT
Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21)
	id <M98TB90M>; Mon, 26 Jun 2000 02:25:29 +0100
Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2A31CE@monk.datcon.co.uk>
From: Adrian Farrel <AF@datcon.co.uk>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
Cc: "'arun Viswanathan'" <arun@force10networks.com>,
        "'cheenu Srinivasan'"
	 <csrinivasan@tachion.com>, mpls@UU.NET,
        "'manis@future.futsoft.com'"
	 <manis@kailash.future.futsoft.com>
Subject: RE: MPLS TE MIB - Doubts
Date: Mon, 26 Jun 2000 02:25:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

>>At an intermediate node, the ARhop table reflects the actual 
>>routes taken by the LSPs.  Since two LSPs may have the same 
>>tunnel index and tunnel instance, it is necessary to 
>>differentiate the entries in the ARhop table by also using 
>>the sourceAddress.

>I think that you are looking at it a bit backwards. The LSPs do not
>have tunnel indexes; the tunnels point at LSPs via the cross-connects
>which they use. I don't see the case where a single instance of a
>tunnel will be using multiple LSPs.

Is there a difference in your mind between a "tunnel", an "LSP tunnel"
and an "LSP"?

I am not suggesting that "a single instance of a tunnel will be using 
multiple LSPs".  I am pointing out that two tunnels at an intermediate
node may have the same tunnel index and tunnel instance and be 
distinguishable only by the source address.  This is what you have 
noticed and used to extend the indexing of the mplsTunnelTable.

>>Now, at an intermediate node the hop table (i.e. not the ARhop table)
>>reflects the remaining part of the requested ER signaled by the
>>protocol.  Since two LSPs may have the same tunnel index and tunnel
>>instance and yet not have the same remaining ER, surely the hop table
>>also needs to be indexed by source address.

>No. At an intermediate node the HopTable should not reflect anything
>since there is no tunnel head configuration information stored there,
>just ARHop information from say the signalling protocol. Again, the 
>HopTable only contains the *configured* tunnel information, and the 
>ARHopTable contains the actual hop information. At intermediate nodes,
>the ARHopTable *may* contain the remainder of the path for that tunnel,
>and the tunnel table should also be able to identify which LSP (via 
>the XCIndex) it is using. This is something that I believe is very 
>useful for allowing network operators of very large networks containing
>dozens or hundreds of LSRs to visualize what is actually going on at 
>any LSR in their network.

Tom, I understand that you think it is useful to hold the TE MIB at 
intermediate nodes.  If that is the case, I think you should hold _all_
of the information available at the intermediate nodes and not arbitrarily
drop some.  In this case, the information to build the HopTable is
signaled by both RSVP and CR-LDP as the Explicit Route.  Further, the
information signaled as the ER is potentially significantly different
from the ARHopTable which records the actual route.

If the ARHopTable is useful to network managers at intermediate nodes,
the differences from the requested ER (i.e. the HopTable) must also be
very useful.  Consider that the HopTable specifies a loose hop but the 
ARHopTable shows the actual route taken.

>>I'm wondering whether this isn't all getting a bit messy?  It is
>>driven by the idea of maintaining the TE MIB at intermediate nodes
>>which is potentially interesting, but not within the original scope
>>of the TE MIB as I understood it.

>I think that it is potentially messy because we have not necessarily
>been clear in the draft about this since the idea of using the MIB at
>midpoints is a new one that I recently introduced. I apologize for 
>this. We are about to publish the next version of the TE MIB, and I 
>will make sure that this version contains some text explaining this
>topic.

I look forward to reading it.

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422



From owner-mpls@UU.NET  Mon Jun 26 04:17:30 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28265
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 04:17:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivfl07385;
	Mon, 26 Jun 2000 08:17:31 GMT
Received: by mail-control.mail.uu.net 
	id QQivfl18338
	for mpls-outgoing; Mon, 26 Jun 2000 08:17:06 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivfl18329
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 08:16:57 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivfl11274
	for <mpls@uu.net>; Mon, 26 Jun 2000 04:16:51 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivfl10626
	for <mpls@uu.net>; Mon, 26 Jun 2000 08:16:50 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA24466
	for mpls@uu.net; Mon, 26 Jun 2000 04:16:49 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivfl18310
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 08:16:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivfl23005
	for <mpls@UU.NET>; Mon, 26 Jun 2000 04:16:12 -0400 (EDT)
Received: from beamer.mchh.siemens.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163])
	id QQivfl05790
	for <mpls@UU.NET>; Mon, 26 Jun 2000 08:16:11 GMT
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA05468;
	Mon, 26 Jun 2000 10:15:34 +0200 (MET DST)
Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA02518;
	Mon, 26 Jun 2000 10:15:43 +0200 (MET DST)
Received: by MCHH202E with Internet Mail Service (5.5.2448.0)
	id <M9R2WJWC>; Mon, 26 Jun 2000 10:18:41 +0200
Message-ID: <3B59676F9ADBD211B5360060086E64EECC0155@MCHH237E>
From: Theimer Thomas <Thomas.Theimer@icn.siemens.de>
To: "'Eric Gray'" <EGray@zaffire.com>
Cc: "'MPLS Mailing List'" <mpls@UU.NET>
Subject: RE: MPLS Architecture Issue
Date: Mon, 26 Jun 2000 10:17:58 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

I also think it would be useful to address this issue in some more detail (at least) in the architecture document. In my view, there are two different cases of bi-directionality:

1. specific hardware (e.g. ATM, FR, most optical transport networks) may allow or require bidirectional communication to be established using MPLS. Both directions usually follow the same path through the same set of nodes, and each node along the path is aware of this association. This is addressed e.g. in draft-lang-mpls-rsvp-oxc-00.txt and draft-saha-rsvp-optical-signaling-00.txt for optical networks.

2. specific applications of MPLS may require a bidirectional communication path provided by MPLS. For this purpose, it may be sufficient to create a pair of unidirectional LSPs which are only bound together by the ingress/egress nodes. For intermediate nodes, the two LSPs are unrelated, and they may even follow different paths across the network. However, the application only works if both LSPs are up. One such application would be Tunneling Multiplexed Compressed RTP in MPLS as described in draft-theimer-tcrtp-mpls-00.txt.

So the MPLS architecture should address that

- a pair of unidirectional LSPs can be bound together to provide a bidirectional communication path

- forward and reverse direction may share the same path, either because the hardware technology works that way or because it is required in a specific application.

We should also make clear which of the cases we are talking about when referring to bidirectional LSPs.

Thomas
> -----Original Message-----
> From:	Eric Gray [SMTP:EGray@zaffire.com]
> Sent:	Thursday, June 22, 2000 10:46 PM
> To:	Ross Callon (E-mail); Arun Viswanathan (E-mail); 'Eric Rosen'
> Cc:	Eric Gray; Thomas D. Nadeau (E-mail); 'MPLS Mailing List'
> Subject:	MPLS Architecture Issue
> 
> Eric (et al),
> 
>     Tom earlier made the point that none of the
> MPLS drafts appear to introduce - let alone 
> discuss or specify - the notion of bi-directional
> association of LSPs.  There is the notion of use
> of Labels under circumstances in which specific
> hardware uses "labels" (VPI/VCI, and possibly
> DLCI, values) in both directions, but this is not
> the same thing.
> 
>     In an off-line discussion, we talked about the
> fact that the TE Requirements RFC (RFC2702) talks 
> about the idea of bi-directional traffic trunks.  
> It describes behaviors which might be hard for an 
> NMS to model without being able to determine that 
> an LSP-pair is used as a bidirectional LSP tunnel.
> But it is "only" an informational RFC.
> 
> 	The Framework draft briefly mentions use of
> bi-directional LSPs as a possible solution to error
> reporting problems, but - as far as I know - none
> of the current set of "standards track" MPLS drafts
> addresses the concept of pairing of LSPs to form a
> bi-directional tunnel or trunk.
> 
> 	Is it possible to add this to the Architecture
> at this point, do we need to create a standards track
> draft specifically for this purpose or is it enough 
> to simply add appropriate "stuff" to the TE-MIB based
> on the informational RFC?
> 
> --
> Eric Gray



From owner-mpls@UU.NET  Mon Jun 26 04:24:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28284
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 04:24:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivfl15186;
	Mon, 26 Jun 2000 08:24:45 GMT
Received: by mail-control.mail.uu.net 
	id QQivfl18725
	for mpls-outgoing; Mon, 26 Jun 2000 08:24:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivfl18716
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 08:24:12 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivfl14654
	for <mpls@UU.NET>; Mon, 26 Jun 2000 04:24:02 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6])
	id QQivfl14703
	for <mpls@UU.NET>; Mon, 26 Jun 2000 08:24:01 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jun 26 04:22:18 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id EAA03198;
	Mon, 26 Jun 2000 04:22:50 -0400 (EDT)
Message-ID: <395713AE.2605266D@dnrc.bell-labs.com>
Date: Mon, 26 Jun 2000 01:26:22 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Labs Research Silicon Valley
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: George Swallow <swallow@cisco.com>,
        Vijay Srinivasan <Vijay.Srinivasan@cosinecom.com>
CC: mpls@UU.NET
Subject: Last Call feedback on MPLS-Diff-Serv
References: <200006121753.NAA22286@lir.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

George, Vijay,

> This message marks the beginning of a last call on
> draft-ietf-mpls-diff-ext-05.txt, MPLS Support of Differentiated
> Services.
> 
> The last call ends June 26, 2000 at mid-night GMT.
> 
> ...George

So, here are some formal Last Call comments on the I-D
draft-ietf-mpls-diff-ext-05.txt, "MPLS Support of
Differentiated Services".

In principle I think this document provides suitable
technical solutions for indicating DS-style PHBs using
various types of MPLS encapsulation.

However, the document's editorial process is clearly only
in its early stages, and the I-D ought not be progressed
as currently written.

Specifically I found that the structure and wording of most
sections to be extremely verbose and repetitive, such that it
was necessary to re-read many paragraphs a few times just to
be sure of what was being said. There is also a rather high
ratio of speculative to normative text scattered throughout
the document. It will be far clearer to read and implement when
another editorial pass moves speculative text (discussions of what
could have been, might be, or might not be...) to their
own sections clearly separated from the normative text (such
as what E-LSP and L-LSPs actually are, recommended default EXP<->PHB
mappings, etc).

Section 11's discussion of ECN is also unrelated to the ostensible
goals of a document chartered to describe "MPLS Support of
Differentiated Services". ECN isn't mentioned in the abstract or
intro section (not surprisingly, since ECN isn't part of Diffserv).
Section 11 itself appears to be unsure of whether it is speculative
or normative.

******** Specific recommendations:

#1 Remove section 11.

   This can quite reasonably become another document discussing
   experimental ways in which the EXP bits can be used to support
   what even the current text admits is an experimental RFC.
   It has no place in a normative spec relating MPLS and Diffserv,
   and ought to be removed.

#2 Cite work on "MPLS Fast Restoration"

   This phrase is used a number of times in section 1's intro,
   yet there is no specific work cited to explain just what
   this feature is. Since the intro claims that this I-D provides
   support for protecting classes of service "..via MPLS Fast
   Restoration" the technique needs to be cited. If some example
   cannot be cited, alternative introductory wording ought to be
   used. (Oddly this phrase morphs into "Fast Reroute" in the
   appendices - please use one or the other consistently
   throughout the document. Citation is important because even
   in the appendices it isn't clear why this particular mode of
   operation benefits from the extenions being discussed in this
   document.)

#3 Define E-LSPs once only.

   Right now sections 1.2 is the first definition of E-LSP.
   It is relatively concise, and doesn't need to be repeated.
   Specifically, in section 3.1 the two lists of bullet items
   (beginning with "Recognizing that" and "We define that")
   are verbosely redundant and add little. A reverse ref.
   to section 1.2, with some additional clarification, is
   all we need.

#4 Define L-LSPs once only.

   Section 1.3 defines L-LSPs concisely, and section 4.1
   is verbosely redundant with section 1.3. Section 4.1 ought
   to ref. back to 1.3 with only minimal additional clarificatory
   text.

#5 Vastly simplify sections 2.6.3 and 2.6.4 (tunnel models)

   The last paragraph of 2.6.4 admits that basically the only
   difference between the Uniform and Pipe models is in the
   push/pop behaviors. At the very least 2.6.4 can be vastly
   simplified by simply specifying the 'Pipe Model' in terms
   of how it differs from the 'Uniform Model' in 2.6.3 (right
   now 2.6.4 contains a load of redundant descriptive text).

#6 Section 2.6.3, 2nd Figure

   There's a "(P)" floating to the right of "(outer header)"
   that perhaps ought not be there?  (Same for 2nd figure in
   section 2.6.4)

#7 Clarify 2.6.5

   Section 2.6.5's last sentence attempts to be normative about
   something it simultaneously declares out of scope for this
   document. Please clarify, reduce, or remove this section (the
   essence can be stated somewhere earlier in section 2 anyway).

#8 Rationalize sections 3 and 4

   Most of the processing steps are equivalent whether we are
   discussing an E-LSP or L-LSP, so there's very little
   reason to have two sections repeating much of each other.
   (E.g. for filling out things like Encaps<->PHB mappings the
    rules for E-LSPs are essentially a subset of those for L-LSPs,
    sections 3.5 and 4.5 are practically identical,
    section 3.3 is a subset of 4.3, etc...)
   A lot of the wording in both sections ought to be tightened
   up significantly to focus primarily on the normative
   statements. (Indeed, these two sections could probably be
   beneficially collapsed into one section.)

#9 Preconfigured E-LSP EXP<->PHB mapping?

   Section 3.2.1 talks about a preconfigured EXP<->PHB mapping
   but does not suggest a default. I think the document ought to
   specify an actual default for EXP 000 to map to Best Effort PHB
   (or set of defaults where *all* EXP values map to BE).

#10 Why is section 7 here?

  Section 7 repeats material that is redundant for a reader who
  gets this far into the document. Clearly the mechanisms for
  handling MPLS over PPP are documented elsewhere, and this
  document has already stated how various Encaps<->PHB mappings
  are built for E- and L-LSPs. Section 7 ought to be removed,
  perhaps to an informational/applicability document.

#11 Why are sections 8 and 9 here?

  Sections 8&9 suffer the same question of focus as section 7.
  How an ATM or FR interface operates is pretty much covered by
  existing MPLS documents - excluding perhaps the recommendation
  to use EPD for ATM, I dont see sections 8&9 adding anything
  normative to what has already been stated earlier in the document.
  They ought to follow section 7 into another document (or oblivion).

#12 Why is section 10 here?

   Again, as with section 7 there's an issue of focus here.
   No new normative text exists here, and it is at best a subset
   of section 7 anyway.

#13 Remove references to PIM as a label distribution mechanism

   In sections 3.1 and 4.1 the last paragraph speaks about MPLS using
   a variety of label distribution mechanisms, including PIM.
   The reference to PIM should be removed (unless there's a citeable
   *working group* document I'm unaware of for using PIM in this
   manner).
  
#14 Explicit cite for MPLS/BGP

   In the same paras as mentioned above, citation would be useful
   for the references to BGP being used to distribute labels
   (presumably it is [MPLS_VPN] ?)  However, it would also be
   worthwhile rephrasing the citation to not imply this is an
   MPLS WG sanctioned solution (unlike LDP, CR-LDP, and RSVP-TE
   which are WG sanctioned).

I look forward to the revised document providing much appreciated
clarity and guidance to the industry.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Mon Jun 26 08:48:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03372
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 08:48:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivgd21044;
	Mon, 26 Jun 2000 12:48:16 GMT
Received: by mail-control.mail.uu.net 
	id QQivgd17392
	for mpls-outgoing; Mon, 26 Jun 2000 12:47:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivgd17387
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 12:47:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivgd17038
	for <mpls@UU.NET>; Mon, 26 Jun 2000 08:47:27 -0400 (EDT)
From: nadas@torrentnet.com
Received: from castillo.torrentnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: castillo.torrentnet.com [4.18.161.34])
	id QQivgd17812
	for <mpls@UU.NET>; Mon, 26 Jun 2000 12:47:27 GMT
Received: from robroy (robroy.torrentnet.com [4.18.161.58])
	by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id IAA02802;
	Mon, 26 Jun 2000 08:47:14 -0400 (EDT)
To: George Swallow <swallow@cisco.com>,
        Vijay Srinivasan <Vijay.Srinivasan@cosinecom.com>
Date: Mon, 26 Jun 2000 08:47:03 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Last Call feedback on MPLS-Diff-Serv
CC: mpls@UU.NET, Grenville Armitage <gja@dnrc.bell-labs.com>
Message-ID: <39571887.219.202384@localhost>
In-reply-to: <395713AE.2605266D@dnrc.bell-labs.com>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Vijay, George, 

On 26 Jun 2000, at 1:26, Grenville Armitage wrote:

> In principle I think this document provides suitable
> technical solutions for indicating DS-style PHBs using
> various types of MPLS encapsulation.
> 
> However, the document's editorial process is clearly only
> in its early stages, and the I-D ought not be progressed
> as currently written.
> 
> Specifically I found that the structure and wording of most
> sections to be extremely verbose and repetitive, such that it
> was necessary to re-read many paragraphs a few times just to
> be sure of what was being said. There is also a rather high
> ratio of speculative to normative text scattered throughout
> the document. It will be far clearer to read and implement when
> another editorial pass moves speculative text (discussions of what
> could have been, might be, or might not be...) to their own sections
> clearly separated from the normative text (such as what E-LSP and
> L-LSPs actually are, recommended default EXP<->PHB mappings, etc).
> 
> Section 11's discussion of ECN is also unrelated to the ostensible
> goals of a document chartered to describe "MPLS Support of
> Differentiated Services". ECN isn't mentioned in the abstract or intro
> section (not surprisingly, since ECN isn't part of Diffserv). Section
> 11 itself appears to be unsure of whether it is speculative or
> normative.
[snip]


I would like to agree with Grenville, and think that rework of this 
draft along the lines he proposes would be quite useful.  

Regards,
Steve 

Stephen Nadas                           Ericsson IP Infrastructure
nadas@torrentnet.com                    920 Main Campus Drive 
Voice:  +1-919-472-9935 Fax: x/9999     Suite 500
Mobile: +1-919-522-0991                 Raleigh, NC 27606


From owner-mpls@UU.NET  Mon Jun 26 09:25:58 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04726
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 09:25:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivgf16837;
	Mon, 26 Jun 2000 13:25:59 GMT
Received: by mail-control.mail.uu.net 
	id QQivgf03076
	for mpls-outgoing; Mon, 26 Jun 2000 13:25:38 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivgf03068
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 13:25:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivgf08063
	for <mpls@UU.NET>; Mon, 26 Jun 2000 09:25:27 -0400 (EDT)
Received: from baynet.baynetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20])
	id QQivgf16408
	for <mpls@UU.NET>; Mon, 26 Jun 2000 13:25:27 GMT
Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107])
	by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id GAA04923;
	Mon, 26 Jun 2000 06:23:45 -0700 (PDT)
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6])
	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id GAA24011;
	Mon, 26 Jun 2000 06:23:38 -0700 (PDT)
Received: from bubba.engeast (bubba [192.168.136.194])
	by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP
	id JAA06388; Mon, 26 Jun 2000 09:25:08 -0400
	for 
Received: by bubba.engeast (SMI-8.6/SMI-SVR4)
	id JAA21758; Mon, 26 Jun 2000 09:25:08 -0400
From: dwilder@baynetworks.com (David Wilder)
Message-Id: <200006261325.JAA21758@bubba.engeast>
Subject: Re: MPLS TE MIB - Doubts
In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2A31CE@monk.datcon.co.uk> from
 Adrian Farrel at "Jun 26, 2000 02:25:19 am"
To: Adrian Farrel <AF@datcon.co.uk>
Date: Mon, 26 Jun 2000 09:25:08 -0400 (EDT)
CC: "Thomas D. Nadeau" <tnadeau@cisco.com>,
        "'arun Viswanathan'" <arun@force10networks.com>,
        "'cheenu Srinivasan'" <csrinivasan@tachion.com>, mpls@UU.NET,
        "'manis@future.futsoft.com'" <manis@kailash.future.futsoft.com>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
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

I'd like to know too what people are thinking is the difference between a
"tunnel", an "LSP tunnel" and an "LSP"?  I see the terms used interchangably
on this list by some but as different entities by others.

Dave

> >>At an intermediate node, the ARhop table reflects the actual 
> >>routes taken by the LSPs.  Since two LSPs may have the same 
> >>tunnel index and tunnel instance, it is necessary to 
> >>differentiate the entries in the ARhop table by also using 
> >>the sourceAddress.
> 
> >I think that you are looking at it a bit backwards. The LSPs do not
> >have tunnel indexes; the tunnels point at LSPs via the cross-connects
> >which they use. I don't see the case where a single instance of a
> >tunnel will be using multiple LSPs.
> 
> Is there a difference in your mind between a "tunnel", an "LSP tunnel"
> and an "LSP"?
> 
> I am not suggesting that "a single instance of a tunnel will be using 
> multiple LSPs".  I am pointing out that two tunnels at an intermediate
> node may have the same tunnel index and tunnel instance and be 
> distinguishable only by the source address.  This is what you have 
> noticed and used to extend the indexing of the mplsTunnelTable.
> 
> >>Now, at an intermediate node the hop table (i.e. not the ARhop table)
> >>reflects the remaining part of the requested ER signaled by the
> >>protocol.  Since two LSPs may have the same tunnel index and tunnel
> >>instance and yet not have the same remaining ER, surely the hop table
> >>also needs to be indexed by source address.
> 
> >No. At an intermediate node the HopTable should not reflect anything
> >since there is no tunnel head configuration information stored there,
> >just ARHop information from say the signalling protocol. Again, the 
> >HopTable only contains the *configured* tunnel information, and the 
> >ARHopTable contains the actual hop information. At intermediate nodes,
> >the ARHopTable *may* contain the remainder of the path for that tunnel,
> >and the tunnel table should also be able to identify which LSP (via 
> >the XCIndex) it is using. This is something that I believe is very 
> >useful for allowing network operators of very large networks containing
> >dozens or hundreds of LSRs to visualize what is actually going on at 
> >any LSR in their network.
> 
> Tom, I understand that you think it is useful to hold the TE MIB at 
> intermediate nodes.  If that is the case, I think you should hold _all_
> of the information available at the intermediate nodes and not arbitrarily
> drop some.  In this case, the information to build the HopTable is
> signaled by both RSVP and CR-LDP as the Explicit Route.  Further, the
> information signaled as the ER is potentially significantly different
> from the ARHopTable which records the actual route.
> 
> If the ARHopTable is useful to network managers at intermediate nodes,
> the differences from the requested ER (i.e. the HopTable) must also be
> very useful.  Consider that the HopTable specifies a loose hop but the 
> ARHopTable shows the actual route taken.
> 
> >>I'm wondering whether this isn't all getting a bit messy?  It is
> >>driven by the idea of maintaining the TE MIB at intermediate nodes
> >>which is potentially interesting, but not within the original scope
> >>of the TE MIB as I understood it.
> 
> >I think that it is potentially messy because we have not necessarily
> >been clear in the draft about this since the idea of using the MIB at
> >midpoints is a new one that I recently introduced. I apologize for 
> >this. We are about to publish the next version of the TE MIB, and I 
> >will make sure that this version contains some text explaining this
> >topic.
> 
> I look forward to reading it.
> 
> Regards,
> Adrian
> --
> Adrian Farrel  mailto:af@datcon.co.uk
> Network Convergence Group
> Data Connection Ltd., Chester, UK
> http://www.datcon.co.uk/
> Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
> 



From owner-mpls@UU.NET  Mon Jun 26 10:44:58 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07405
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 10:44:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivgk16455;
	Mon, 26 Jun 2000 14:44:15 GMT
Received: by mail-control.mail.uu.net 
	id QQivgk24161
	for mpls-outgoing; Mon, 26 Jun 2000 14:43:39 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivgk24140
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 14:43:24 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivgk20638
	for <mpls@uu.net>; Mon, 26 Jun 2000 10:43:18 -0400 (EDT)
Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: laurelnetworks.com [206.67.234.84])
	id QQivgk15647
	for <mpls@uu.net>; Mon, 26 Jun 2000 14:43:17 GMT
Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110])
	by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id KAA16240
	for <mpls@uu.net>; Mon, 26 Jun 2000 10:43:16 -0400
Received: (from jleu@localhost)
	by localhost.laurelnetworks.com (8.9.3/8.9.3) id KAA00944
	for mpls@uu.net; Mon, 26 Jun 2000 10:43:16 -0400
Date: Mon, 26 Jun 2000 10:43:16 -0400
From: "James R. Leu" <jleu@laurelnetworks.com>
To: mpls@UU.NET
Subject: Re: LSP hierarchy with MPLS TE
Message-ID: <20000626104316.B901@laurelnetworks.com>
Reply-To: jleu@laurelnetworks.com
References: <200006221505.LAA07660@lir.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200006221505.LAA07660@lir.cisco.com>; from swallow@cisco.com on Thu, Jun 22, 2000 at 11:05:43AM -0400
Organization: Laurel Networks
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, Jun 22, 2000 at 11:05:43AM -0400, George Swallow wrote:
> Folks,
> 
> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt
> be accepted as a work group document.  So far I've only seen support.
> If there are no objects by 6/27, we'll declare it so.

Maybe this isn't a significant issues, but:

In section "4.1.2. Link ID (OSPF only)" it states:

   The Link ID is set to the Router ID of the head end of FA-LSP.

Doesn't this conflict with RFC2328 Section 12.4.1.  Router-LSAs:

     Link type   Description       Link ID
     __________________________________________________
     1           Point-to-point    Neighbor Router ID
                 link

How does the above affect the following (from RFC2328 Section 12.4.1
as well)?

   In addition, the Link Data field is specified for each link.
   For ... numbered point-to-point links ... this field specifies
   the IP interface address of the associated router interface.
   ...
   For unnumbered point-to-point links, the Link Data field should
   be set to the unnumbered interface's MIB-II [Ref8] ifIndex value.

Jim  
-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com


From owner-mpls@UU.NET  Mon Jun 26 11:45:24 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08950
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 11:45:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivgo02143;
	Mon, 26 Jun 2000 15:44:57 GMT
Received: by mail-control.mail.uu.net 
	id QQivgo13520
	for mpls-outgoing; Mon, 26 Jun 2000 15:44:00 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivgo13505
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 15:43:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivgo00880
	for <mpls@uu.net>; Mon, 26 Jun 2000 11:43:37 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQivgo01060
	for <mpls@uu.net>; Mon, 26 Jun 2000 15:43:37 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA28394
	for <mpls@uu.net>; Mon, 26 Jun 2000 08:43:48 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA13833 for mpls@uu.net; Mon, 26 Jun 2000 11:43:34 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivgo12068
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 15:35:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivgo19759
	for <mpls@UU.NET>; Mon, 26 Jun 2000 11:35:25 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQivgo24378
	for <mpls@UU.NET>; Mon, 26 Jun 2000 15:35:25 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <MJ3J3A79>; Mon, 26 Jun 2000 11:33:00 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B8501BEA4@xover1.hjinc.com>
From: "Friedeborn, William" <wfriedeb@netplane.com>
To: "'Adrian Farrel'" <AF@datcon.co.uk>,
        "Thomas D. Nadeau"
	 <tnadeau@cisco.com>
Cc: "'arun Viswanathan'" <arun@force10networks.com>,
        "'cheenu Srinivasan'"
	 <csrinivasan@tachion.com>, mpls@UU.NET,
        "'manis@future.futsoft.com'"
	 <manis@kailash.future.futsoft.com>
Subject: RE: MPLS TE MIB - Doubts
Date: Mon, 26 Jun 2000 11:32:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

A couple of points I am a little confused on in this thread about adding a
SourceID to the Tunnel indexing scheme. 
1. Tunnel Indexing - When I look at the current indexing scheme of
TunnelIndex, TunnelInstance, there is nothing here that would indicate that
this information should have any significance  other than to the node it is
created on. In my first cut at understanding the use of Tunnels, I could see
that the ingress node could have the Tunnel objects defined via SNMP/cli.
The Tunnel instrumentation would pass the info down to the supporting
protocol statemachine (LDP or RSVP), the protocols would signal down to the
egress node creating LSR-MIB objects along the way (or on reverse trip) till
the egress node is reached, where the LSR-MIB and Tunnel objects are
created. Since my understanding of the LDP and RSVP protocols is not that
detailed, I didn't see where the Tunnel indexing info fit in LDP or RSVP
(i.e. how would this index info be passed on the LSP creation via RSVP?). It
seemed that the intent was to use the cross-connects on each node to
associate the Tunnel object using it. And the LSPID to track the sequence of
cross-connects so that one could follow an LSP from node to node via the
LSPID.

If the intent is that a tunnel definition should have more than just local
significance, shouldn't there be some tunnelID defined (like LSPID)? I can
see that adding a SourceID makes it possible to pass these locally defined
indices, but it seems odd to me that when you define a set of indices on one
machine, that another machine should know about them. 

2. Multiple LSPs on a Tunnel - Looking at the LSR-MIB I see that the
cross-connect object has a XCIndex and three other indices. I assumed these
were set up to support MP-PT, and PT-MP by keeping the XCIndex and
OutSegmentIndex constant and varying the InSegmentIfIndex/label, the MP-PT
case is achieved, and similarly the PT-MP could be done. (Is it
possible/practical to have MP-MP?). In any case, it seemed that there could
be a situation where a Tunnel had a XCIndex that referenced  more that one
row in a XC table. I wasn't sure if the multiple rows in the XC table ment
multiple LSPs? Or just a MP-PT or PT-MP single LSP?

3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also.

Hope someone can clarify the above,
Thanks,
Bill Friedeborn
 
-----Original Message-----
From: Adrian Farrel [mailto:AF@datcon.co.uk]
Sent: Sunday, June 25, 2000 9:25 PM
To: Thomas D. Nadeau
Cc: 'arun Viswanathan'; 'cheenu Srinivasan'; mpls@UU.NET;
'manis@future.futsoft.com'
Subject: RE: MPLS TE MIB - Doubts


>>At an intermediate node, the ARhop table reflects the actual 
>>routes taken by the LSPs.  Since two LSPs may have the same 
>>tunnel index and tunnel instance, it is necessary to 
>>differentiate the entries in the ARhop table by also using 
>>the sourceAddress.

>I think that you are looking at it a bit backwards. The LSPs do not
>have tunnel indexes; the tunnels point at LSPs via the cross-connects
>which they use. I don't see the case where a single instance of a
>tunnel will be using multiple LSPs.

Is there a difference in your mind between a "tunnel", an "LSP tunnel"
and an "LSP"?

I am not suggesting that "a single instance of a tunnel will be using 
multiple LSPs".  I am pointing out that two tunnels at an intermediate
node may have the same tunnel index and tunnel instance and be 
distinguishable only by the source address.  This is what you have 
noticed and used to extend the indexing of the mplsTunnelTable.

>>Now, at an intermediate node the hop table (i.e. not the ARhop table)
>>reflects the remaining part of the requested ER signaled by the
>>protocol.  Since two LSPs may have the same tunnel index and tunnel
>>instance and yet not have the same remaining ER, surely the hop table
>>also needs to be indexed by source address.

>No. At an intermediate node the HopTable should not reflect anything
>since there is no tunnel head configuration information stored there,
>just ARHop information from say the signalling protocol. Again, the 
>HopTable only contains the *configured* tunnel information, and the 
>ARHopTable contains the actual hop information. At intermediate nodes,
>the ARHopTable *may* contain the remainder of the path for that tunnel,
>and the tunnel table should also be able to identify which LSP (via 
>the XCIndex) it is using. This is something that I believe is very 
>useful for allowing network operators of very large networks containing
>dozens or hundreds of LSRs to visualize what is actually going on at 
>any LSR in their network.

Tom, I understand that you think it is useful to hold the TE MIB at 
intermediate nodes.  If that is the case, I think you should hold _all_
of the information available at the intermediate nodes and not arbitrarily
drop some.  In this case, the information to build the HopTable is
signaled by both RSVP and CR-LDP as the Explicit Route.  Further, the
information signaled as the ER is potentially significantly different
from the ARHopTable which records the actual route.

If the ARHopTable is useful to network managers at intermediate nodes,
the differences from the requested ER (i.e. the HopTable) must also be
very useful.  Consider that the HopTable specifies a loose hop but the 
ARHopTable shows the actual route taken.

>>I'm wondering whether this isn't all getting a bit messy?  It is
>>driven by the idea of maintaining the TE MIB at intermediate nodes
>>which is potentially interesting, but not within the original scope
>>of the TE MIB as I understood it.

>I think that it is potentially messy because we have not necessarily
>been clear in the draft about this since the idea of using the MIB at
>midpoints is a new one that I recently introduced. I apologize for 
>this. We are about to publish the next version of the TE MIB, and I 
>will make sure that this version contains some text explaining this
>topic.

I look forward to reading it.

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422



From owner-mpls@UU.NET  Mon Jun 26 12:51:59 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10614
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 12:51:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivgt19094;
	Mon, 26 Jun 2000 16:51:38 GMT
Received: by mail-control.mail.uu.net 
	id QQivgt04713
	for mpls-outgoing; Mon, 26 Jun 2000 16:51:03 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivgt04694
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 16:50:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivgt01987
	for <mpls@uu.net>; Mon, 26 Jun 2000 12:50:42 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivgt18259
	for <mpls@uu.net>; Mon, 26 Jun 2000 16:50:42 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDH3H>; Mon, 26 Jun 2000 09:57:08 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690808@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "George Swallow (E-mail)" <swallow@cisco.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: Re: Last Call on MPLS-Diff-Serv
Date: Mon, 26 Jun 2000 09:57:07 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

George,

One last call comment on MPLS Diff Serv (editorial 
comments via separate posting).

Explicit Congestion Notification
================================

	This section cannot remain as is if the document is
to be allowed to complete last call.

	The reference [MPLS-ECN] is no longer available (the
'00' version was replaced by a '01' version which has since
expired).  Perhaps a better reference would be:

"ECN Interactions with IP Tunnels", S. Floyd, K. Ramakrishnan
(http://www.ietf.org/internet-drafts/draft-floyd-ecn-tunnels-00.txt)

Because there is no referent for MPLS-ECN, the text in section
11 ("Explicit Congestion Notification") is not workable - since,
in the absence of work in progress on MPLS-ECN, the following 
things remain unclear (with no obvious relief in sight):

o	How many bits are needed for ECN ([ECN] uses 2 bits,
	the current text claims that a single bit is used - 
	but there is no referent from which to validate this);
o	What the position of any ECN bit(s) would be within the
	EXP field; 
o	To what packets ECN bits would be applied;
o	What the implications with respect to DiffServ treatment
	are for ECN marked MPLS encapsulated packets.  

This is by no means intended to be an exhaustive listing of the
remaining issues with interactions between DiffServ and MPLS-ECN.

Perhaps what is really needed is the ability to configure both
a set of EXP to PHB mappings and a EXP field mask to be used 
to extract the EXP bits that apply to this mapping.  For example,
if the bit arrangement is like this:

      E P P
      C H H
      T B B
        1 2

. . . X Y Y . . .

then the mask would be '0 1 1' and values 'Y Y' would be used to
determine the EXP to PHB mapping that applies to this packet.

In addition, it might be a good idea to configure - or define
signaling for - the behavior that applies to the masked out
bit(s).  Presumably, the default would be "forward unchanged".

This section - as is - should be discarded (or possibly replaced
with a more generalized approach - such as suggested above).

--
Eric Gray


George Swallow wrote:
> 
> This message marks the beginning of a last call on
> draft-ietf-mpls-diff-ext-05.txt, MPLS Support of Differentiated
> Services.
> 
> The last call ends June 26, 2000 at mid-night GMT.
> 
> ...


From owner-mpls@UU.NET  Mon Jun 26 13:39:44 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11797
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 13:39:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivgw24909;
	Mon, 26 Jun 2000 17:39:22 GMT
Received: by mail-control.mail.uu.net 
	id QQivgw21707
	for mpls-outgoing; Mon, 26 Jun 2000 17:38:46 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivgw21686
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 17:38:26 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivgw26634
	for <mpls@uu.net>; Mon, 26 Jun 2000 13:38:09 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivgw23362
	for <mpls@uu.net>; Mon, 26 Jun 2000 17:38:08 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDHSW>; Mon, 26 Jun 2000 10:44:34 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269080A@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Puneet Agarwal'" <puneet@pluris.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
Date: Mon, 26 Jun 2000 10:44:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Puneet,

	Please see embedded comments below...

--
Eric Gray

> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Friday, June 23, 2000 5:38 PM
> To: 'mpls@uu.net'
> Subject: draft-ietf-mpls-diff-ext-05.txt comments
> 
> 
> 1) The draft needs to detail the usage of hierarchical tunnel (HT)
> especially
> in the case of PHP. 
> 
> For PHP and HT to work for diffserv/MPLS the Penultimate LSR 
> needs to know the PHB -> EXP mapping of the underlying 
> encapsulated tunnels. ...

This is not exactly true, although the effect is almost
the same.  The penultimate hop may need to know how the 
EXP field in the label being popped maps to the EXP field
in the next label.  This is not the same as having to 
know how the next downstream 'LSR' maps this new EXP value
to a PHB.  In addition, it is not clear that the penultimate
LSR would ever have to _change_ the value in a tunneled 
label's EXP field since it is likely that the EXP field value 
in the label being popped was derived from the EXP field value 
in the existing label when an initial label was pushed at the 
LSP-tunnel's ingress.

> ... Moreover, if a LSP is carrying multiple LSPs with 
> different PHB-> EXP mapping, the penultimate LSR and even 
> the egress LSR (in case of no PHP) would need to determine 
> (after Pop), the type of the underlying LSP.

The penultimate LSR would not care.  It would determine the
output interface, appropriate queue and other forwarding 
information from the label it received and it would pop that
label and blind-forward the remaining packet.  That is pretty
much the definition of PHP.

The downstream LSR, on the other hand, should already know 
what type of LSP the LSP-tunneled packet is on based on the
label that it assigned in the first place, that it is now
receiving.

> 
> Another example to illustrate this complexity:
> 
> Consider the case when a L-LSP is sent over a prior established 
> E-LSP. (The) Penultimate LSR for the E-LSP has no knowledge of 
> tunnels that are hierarchically going through it. Hence when it 
> does the penultimate POP, it has no knowledge about the PHB->EXP 
> encoding for the underlying L-LSP.
> In order to do this correctly, one would need to maintain 
> additional state associated with the outer E-LSP in order to do 
> the correct PHB-> EXP map for the encapsulated L-LSP.

Assuming I understand the question, the answer is 'No'.

The PHP makes an output queuing decision based on the label 
it received - prior to popping that label.  Again, this is
how PHP is done.  The newly exposed label of the packet it 
is about to forward has only an indirect relationship to the 
PHB that the penultimate LSR needs to apply in forwarding it.

> 
> 2) pg 21 - In the Pipe Model, when performing multiple push 
> operations, the LSR may need to be able to encode different 
> PHB->EXP markings for each pushed label in the stack

Yes.  However, the LSR that pushes a label onto the stack
is - by definition - the ingress for the LSP corresponding
to that label.  This is true regardless of how many labels
it pushes onto the stack.

Because an LSR is necessarily a part of the MPLS domain for 
LSPs for which it is the ingress, it should be possible to
configure PHB <==> EXP mappings for each such LSP.  Note 
that I am not saying that all such LSPs must be part of the
same domain - just that the LSR that acts as an ingress to
all such LSPs must be within the MPLS domain for each such
LSP (it can be part of multiple MPLS domains).

> 
> ...
> 
> -Puneet
> 


From owner-mpls@UU.NET  Mon Jun 26 14:34:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13146
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 14:34:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivha07154;
	Mon, 26 Jun 2000 18:33:49 GMT
Received: by mail-control.mail.uu.net 
	id QQivha08584
	for mpls-outgoing; Mon, 26 Jun 2000 18:33:04 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivha08559
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 18:32:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivha04980
	for <mpls@uu.net>; Mon, 26 Jun 2000 14:32:49 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivha06232
	for <mpls@uu.net>; Mon, 26 Jun 2000 18:32:49 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA26579
	for mpls@uu.net; Mon, 26 Jun 2000 14:32:48 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivha08456
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 18:32:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivha04876
	for <mpls@UU.NET>; Mon, 26 Jun 2000 14:32:01 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQivha05953
	for <mpls@UU.NET>; Mon, 26 Jun 2000 18:32:00 GMT
Received: from pluris.com (root@lightning.pluris.com [172.16.55.100])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA24255;
	Mon, 26 Jun 2000 11:31:53 -0700 (PDT)
Message-ID: <3957A198.AEF5DC4F@pluris.com>
Date: Mon, 26 Jun 2000 11:31:52 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <EGray@zaffire.com>
CC: "George Swallow (E-mail)" <swallow@cisco.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: Re: Last Call on MPLS-Diff-Serv
References: <9A564CC874B5D3118FB9009027B0A662690808@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think one can only overload those 3 bits so much. As we keep on
overloading these bits, we create more and more state in every LSR on
the way which is something not desirable.

I do agree that the ECN section should be removed completely from this
document.

Bora



Eric Gray wrote:

> George,
>
> One last call comment on MPLS Diff Serv (editorial
> comments via separate posting).
>
> Explicit Congestion Notification
> ================================
>
>         This section cannot remain as is if the document is
> to be allowed to complete last call.
>
>         The reference [MPLS-ECN] is no longer available (the
> '00' version was replaced by a '01' version which has since
> expired).  Perhaps a better reference would be:
>
> "ECN Interactions with IP Tunnels", S. Floyd, K. Ramakrishnan
> (http://www.ietf.org/internet-drafts/draft-floyd-ecn-tunnels-00.txt)
>
> Because there is no referent for MPLS-ECN, the text in section
> 11 ("Explicit Congestion Notification") is not workable - since,
> in the absence of work in progress on MPLS-ECN, the following
> things remain unclear (with no obvious relief in sight):
>
> o       How many bits are needed for ECN ([ECN] uses 2 bits,
>         the current text claims that a single bit is used -
>         but there is no referent from which to validate this);
> o       What the position of any ECN bit(s) would be within the
>         EXP field;
> o       To what packets ECN bits would be applied;
> o       What the implications with respect to DiffServ treatment
>         are for ECN marked MPLS encapsulated packets.
>
> This is by no means intended to be an exhaustive listing of the
> remaining issues with interactions between DiffServ and MPLS-ECN.
>
> Perhaps what is really needed is the ability to configure both
> a set of EXP to PHB mappings and a EXP field mask to be used
> to extract the EXP bits that apply to this mapping.  For example,
> if the bit arrangement is like this:
>
>       E P P
>       C H H
>       T B B
>         1 2
>
> . . . X Y Y . . .
>
> then the mask would be '0 1 1' and values 'Y Y' would be used to
> determine the EXP to PHB mapping that applies to this packet.
>
> In addition, it might be a good idea to configure - or define
> signaling for - the behavior that applies to the masked out
> bit(s).  Presumably, the default would be "forward unchanged".
>
> This section - as is - should be discarded (or possibly replaced
> with a more generalized approach - such as suggested above).
>
> --
> Eric Gray
>
> George Swallow wrote:
> >
> > This message marks the beginning of a last call on
> > draft-ietf-mpls-diff-ext-05.txt, MPLS Support of Differentiated
> > Services.
> >
> > The last call ends June 26, 2000 at mid-night GMT.
> >
> > ...




From owner-mpls@UU.NET  Mon Jun 26 14:43:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13352
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 14:43:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivha14738;
	Mon, 26 Jun 2000 18:43:04 GMT
Received: by mail-control.mail.uu.net 
	id QQivha09891
	for mpls-outgoing; Mon, 26 Jun 2000 18:42:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivha09885
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 18:42:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivha29918
	for <mpls@uu.net>; Mon, 26 Jun 2000 14:42:13 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivha14005
	for <mpls@uu.net>; Mon, 26 Jun 2000 18:42:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA28516
	for mpls@uu.net; Mon, 26 Jun 2000 14:42:11 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivha09831
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 18:41:40 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivha06794
	for <mpls@UU.NET>; Mon, 26 Jun 2000 14:41:24 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQivha13550
	for <mpls@UU.NET>; Mon, 26 Jun 2000 18:41:23 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA25586;
	Mon, 26 Jun 2000 11:40:52 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <NCL205XP>; Mon, 26 Jun 2000 11:42:01 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40644@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Puneet Agarwal'" <puneet@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
Date: Mon, 26 Jun 2000 11:41:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Puneet,

Please see my comments:

>-----Original Message-----
>From: Puneet Agarwal [mailto:puneet@pluris.com]
>Sent: Friday, June 23, 2000 8:38 PM
>To: 'mpls@uu.net'
>Subject: draft-ietf-mpls-diff-ext-05.txt comments
>
>
>1) The draft needs to detail the usage of hierarchical tunnel (HT)
>especially
>in the case of PHP. 
>
>For PHP and HT to work for diffserv/MPLS the Penultimate LSR 
>needs to know
>the PHB -> EXP
>mapping of the underlying encapsulated tunnels. Moreover, if a LSP is
>carrying
>multiple LSPs with different PHB-> EXP mapping, the 
>penultimate LSR and even
>the egress LSR (in case of no PHP) would need to determine 
>(after Pop), the
>type of the underlying LSP.
>
>Another example to illustrate this complexity:
>Consider the case when a L-LSP is sent over a prior 
>established E-LSP. the
>Penultimate LSR for the E-LSP has no knowledge of tunnels that are
>hierarchically going through it. Hence when it does the 
>penultimate POP, it
>has no knowledge about the PHB->EXP encoding for the underlying L-LSP.
>In order to do this correctly, one would need to maintain 
>additional state
>associated with the outer E-LSP in order to do the correct 
>PHB-> EXP map for
>the encapsulated L-LSP.

Not necessarily. This restriction applies only to Uniform model. In case of
Pipe model, the PHP does not need to know anything about lower LSP, it just
pops and forwards the packet without modifying the lower label.

The case of Uniform model is already mentioned in section 2.6.6:

"- when the multiple pop operations are performed by the Penultimate LSR,
note that to perform Encoding of Diff-Serv       Information, the
Penultimate LSR needs to be aware of the "Set       of PHB-->Encaps
mappings" for the label corresponding to the      exposed header after all
the pop operations (or the PHB-->DSCP       mapping). Methods for providing
this mapping awareness are       outside the scope of this specification."

And section 2.6.3:

"Note that to do so, the Penultimate LSR needs to be aware of the       "Set
of PHB-->Encaps mappings" for the label corresponding to       the exposed
header (or the PHB-->DSCP mapping). Methods for       providing this mapping
awareness are outside the scope of this       specification."

The type of LSP is implicit in the PHB -> Encaps mapping. And the Egress LSR
must know the mapping regardless of the type of the LSP.


2) pg 21 - In the Pipe Model, when performing multiple push 
>operations, the
>LSR may need to be able to encode different PHB->EXP markings for each
>pushed
>label in the stack

This is also explained in Section 2.6.4:

"the LSP Ingress, when performing the push operation, encodes the       LSP
Diff-Serv information in the label entry that is pushed       ("outer label
entry") and encodes the Tunneled Diff-Serv       Information in the
encapsulated header (IP header or swapped      label entry)."

And Section 2.6.6:

"LSRs at different levels of LSPs are expected to operate in the same or in
different Tunneling Models."

"For support of M levels of push in the Pipe Model:
 - when performing multiple push operations, the LSR:
      o encodes Diff-Serv Information corresponding to the
        Outgoing PHB in the transmitted label entry corresponding
        to the LAST pushed label (ie the label pushed in the outer
        label entry).
      o encodes Diff-Serv Information corresponding to the
Incoming PHB in the encapsulated header (swapped label
        entry or IP header) as well as in the label entries for
        all the pushed labels (except the last pushed label)."

Which basically says that the LSR doing the PUSH operation will encode each
level of push according to its type, and the details of each type is
described in E-LSP and L-LSP sections. 

>
>3) pg 36, 3rd paragraph - recognizes --> recognize

Fine.


>4) pg 36, 5th paragraph: when a LSR can only support preconfigured
>EXP <--> PHB mapping, if someone wants to set up the per label 
>EXP <--> PHB
>mapping, what error should the LSR return? Hopefully this error code is
>different than "Diff-Serv Error" to differentiate it from invalid
>EXP <--> PHB mapping.

As mentioned in section 5.3, two scenarios may exist:

1) In case the node only supports configured E-LSP, the node does not
recognize Diffserv object at all -> "Unknown Object Error"

2) In case the node supports configured E-LSP and L-LSP, The node does not
recognize C-type = 1 (Signaled E-LSP) -> "Unknown Object C-type"

Regards,
-Shahram

>
>-Puneet
>



From owner-mpls@UU.NET  Mon Jun 26 14:45:15 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13385
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 14:45:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivha16048;
	Mon, 26 Jun 2000 18:44:40 GMT
Received: by mail-control.mail.uu.net 
	id QQivha10036
	for mpls-outgoing; Mon, 26 Jun 2000 18:44:04 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivha10012
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 18:43:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivha00608
	for <mpls@uu.net>; Mon, 26 Jun 2000 14:43:30 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivha15230
	for <mpls@uu.net>; Mon, 26 Jun 2000 18:43:29 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA28782
	for mpls@uu.net; Mon, 26 Jun 2000 14:43:29 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivha09901
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 18:42:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivha00170
	for <mpls@UU.NET>; Mon, 26 Jun 2000 14:42:38 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQivha14527
	for <mpls@UU.NET>; Mon, 26 Jun 2000 18:42:37 GMT
Received: from pluris.com (root@lightning.pluris.com [172.16.55.100])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA24511;
	Mon, 26 Jun 2000 11:42:36 -0700 (PDT)
Message-ID: <3957A41B.7FCB14C1@pluris.com>
Date: Mon, 26 Jun 2000 11:42:36 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <EGray@zaffire.com>
CC: "'Puneet Agarwal'" <puneet@pluris.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: Re: draft-ietf-mpls-diff-ext-05.txt comments
References: <9A564CC874B5D3118FB9009027B0A66269080A@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric

See my comments

Eric Gray wrote:

> Puneet,
>
>         Please see embedded comments below...
>
> --
> Eric Gray
>
> > -----Original Message-----
> > From: Puneet Agarwal [mailto:puneet@pluris.com]
> > Sent: Friday, June 23, 2000 5:38 PM
> > To: 'mpls@uu.net'
> > Subject: draft-ietf-mpls-diff-ext-05.txt comments
> >
> >
> > 1) The draft needs to detail the usage of hierarchical tunnel (HT)
> > especially
> > in the case of PHP.
> >
> > For PHP and HT to work for diffserv/MPLS the Penultimate LSR
> > needs to know the PHB -> EXP mapping of the underlying
> > encapsulated tunnels. ...
>
> This is not exactly true, although the effect is almost
> the same.  The penultimate hop may need to know how the
> EXP field in the label being popped maps to the EXP field
> in the next label.  This is not the same as having to
> know how the next downstream 'LSR' maps this new EXP value
> to a PHB.  In addition, it is not clear that the penultimate
> LSR would ever have to _change_ the value in a tunneled
> label's EXP field since it is likely that the EXP field value
> in the label being popped was derived from the EXP field value
> in the existing label when an initial label was pushed at the
> LSP-tunnel's ingress.
>

This depends whether it is PIPE or UNIFORM model. If it is uniform, then
the PHP LSR may need to change the EXP field of the inner tunnel.


>
> > ... Moreover, if a LSP is carrying multiple LSPs with
> > different PHB-> EXP mapping, the penultimate LSR and even
> > the egress LSR (in case of no PHP) would need to determine
> > (after Pop), the type of the underlying LSP.
>
> The penultimate LSR would not care.  It would determine the
> output interface, appropriate queue and other forwarding
> information from the label it received and it would pop that
> label and blind-forward the remaining packet.  That is pretty
> much the definition of PHP.
>
> The downstream LSR, on the other hand, should already know
> what type of LSP the LSP-tunneled packet is on based on the
> label that it assigned in the first place, that it is now
> receiving.
>
> >
> > Another example to illustrate this complexity:
> >
> > Consider the case when a L-LSP is sent over a prior established
> > E-LSP. (The) Penultimate LSR for the E-LSP has no knowledge of
> > tunnels that are hierarchically going through it. Hence when it
> > does the penultimate POP, it has no knowledge about the PHB->EXP
> > encoding for the underlying L-LSP.
> > In order to do this correctly, one would need to maintain
> > additional state associated with the outer E-LSP in order to do
> > the correct PHB-> EXP map for the encapsulated L-LSP.
>
> Assuming I understand the question, the answer is 'No'.
>
> The PHP makes an output queuing decision based on the label
> it received - prior to popping that label.  Again, this is
> how PHP is done.  The newly exposed label of the packet it
> is about to forward has only an indirect relationship to the
> PHB that the penultimate LSR needs to apply in forwarding it.
>

Your statement here is what I would like to see as part of the spec, but
what the spec actually says is that the E-LSP must know what it is
carrying inside if it is doing PHP so that it can offer appropriate
treatment for E-LSPs vs L-LSPs.
Of course, it punts on how you actually get this information after the
fact.


>
> >
> > 2) pg 21 - In the Pipe Model, when performing multiple push
> > operations, the LSR may need to be able to encode different
> > PHB->EXP markings for each pushed label in the stack
>
> Yes.  However, the LSR that pushes a label onto the stack
> is - by definition - the ingress for the LSP corresponding
> to that label.  This is true regardless of how many labels
> it pushes onto the stack.
>
> Because an LSR is necessarily a part of the MPLS domain for
> LSPs for which it is the ingress, it should be possible to
> configure PHB <==> EXP mappings for each such LSP.  Note
> that I am not saying that all such LSPs must be part of the
> same domain - just that the LSR that acts as an ingress to
> all such LSPs must be within the MPLS domain for each such
> LSP (it can be part of multiple MPLS domains).
>
> >
> > ...
> >
> > -Puneet
> >

My opinion of this spec is that it is much better than the 04 version
but still requires more text on the corner cases and maybe less
repetitive text as was pointed out earlier.





From owner-mpls@UU.NET  Mon Jun 26 15:46:43 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14709
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 15:46:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhf03586;
	Mon, 26 Jun 2000 19:46:25 GMT
Received: by mail-control.mail.uu.net 
	id QQivhf27623
	for mpls-outgoing; Mon, 26 Jun 2000 19:46:02 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivhf27588
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 19:45:56 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhf20547
	for <mpls@uu.net>; Mon, 26 Jun 2000 15:45:43 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivhf01976
	for <mpls@uu.net>; Mon, 26 Jun 2000 19:45:42 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA08483
	for mpls@uu.net; Mon, 26 Jun 2000 15:45:42 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivhf27443
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 19:45:02 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivhe20358
	for <mpls@UU.NET>; Mon, 26 Jun 2000 15:44:54 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQivhe02376
	for <mpls@UU.NET>; Mon, 26 Jun 2000 19:44:54 GMT
Received: from pluris.com (root@lightning.pluris.com [172.16.55.100])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA25856;
	Mon, 26 Jun 2000 12:44:52 -0700 (PDT)
Message-ID: <3957B2B4.2E47EBF6@pluris.com>
Date: Mon, 26 Jun 2000 12:44:52 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: "'Puneet Agarwal'" <puneet@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: draft-ietf-mpls-diff-ext-05.txt comments
References: <336ECDAFDF7DD311B9E30090277AEE4101B40644@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shahram
Comments within.

Shahram Davari wrote:

> Puneet,
>
> Please see my comments:
>

<<snipped>>

> >4) pg 36, 5th paragraph: when a LSR can only support preconfigured
> >EXP <--> PHB mapping, if someone wants to set up the per label
> >EXP <--> PHB
> >mapping, what error should the LSR return? Hopefully this error code is
> >different than "Diff-Serv Error" to differentiate it from invalid
> >EXP <--> PHB mapping.
>
> As mentioned in section 5.3, two scenarios may exist:
>
> 1) In case the node only supports configured E-LSP, the node does not
> recognize Diffserv object at all -> "Unknown Object Error"
>
> 2) In case the node supports configured E-LSP and L-LSP, The node does not
> recognize C-type = 1 (Signaled E-LSP) -> "Unknown Object C-type"
>

Why not have another error code for nodes that understand the DS object but can
not provide per-label context. This makes sense to me.


>
> Regards,
> -Shahram
>
> >
> >-Puneet
> >




From owner-mpls@UU.NET  Mon Jun 26 15:49:56 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14760
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 15:49:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhf05092;
	Mon, 26 Jun 2000 19:49:34 GMT
Received: by mail-control.mail.uu.net 
	id QQivhf27975
	for mpls-outgoing; Mon, 26 Jun 2000 19:49:03 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivhf27945
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 19:48:47 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivhf21109
	for <mpls@uu.net>; Mon, 26 Jun 2000 15:48:44 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivhf05435
	for <mpls@uu.net>; Mon, 26 Jun 2000 19:48:43 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDH8K>; Mon, 26 Jun 2000 12:55:09 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269080C@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "George Swallow (E-mail)" <swallow@cisco.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: Last call on MPLS-DiffServ 
Date: Mon, 26 Jun 2000 12:55:08 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

George,

	I have to agree with Grenville about the 
current state of this draft.  I understand that
going to last call is often the only way you'll
get people to do a detailed read of a draft, but
this draft is going to take me more than the 3
remaining hours to type the comments I already 
have marked up.

	I'll do my best to get something in by 4:00
P.M. Pacific time, but I don't think it would be
fair to say it will be a complete list.  I thought
I was going to have 3 more hours because - at the
bottom of it all - I'm still thinking in terms of 
East Coast time...

--
Eric Gray


From owner-mpls@UU.NET  Mon Jun 26 15:59:02 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14944
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 15:59:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhf12154;
	Mon, 26 Jun 2000 19:58:49 GMT
Received: by mail-control.mail.uu.net 
	id QQivhf28837
	for mpls-outgoing; Mon, 26 Jun 2000 19:58:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivhf28826
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 19:58:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhf12458
	for <mpls@uu.net>; Mon, 26 Jun 2000 15:57:58 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivhf11429
	for <mpls@uu.net>; Mon, 26 Jun 2000 19:57:58 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA10767
	for mpls@uu.net; Mon, 26 Jun 2000 15:57:57 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivhf28758
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 19:57:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivhf12178
	for <mpls@UU.NET>; Mon, 26 Jun 2000 15:57:29 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQivhf12145
	for <mpls@UU.NET>; Mon, 26 Jun 2000 19:57:28 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA09160;
	Mon, 26 Jun 2000 12:56:57 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <NCL2067Z>; Mon, 26 Jun 2000 12:58:06 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40647@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Bora Akyol'" <akyol@pluris.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "'Puneet Agarwal'" <puneet@pluris.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
Date: Mon, 26 Jun 2000 12:58:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Bora,

Could you please identify why/how a node could understand the Diffserv
object and the E-LSP C-type and still can't support the signaled E-LSP.

-Shahram 

>-----Original Message-----
>From: Bora Akyol [mailto:akyol@pluris.com]
>Sent: Monday, June 26, 2000 3:45 PM
>To: Shahram Davari
>Cc: 'Puneet Agarwal'; 'mpls@uu.net'
>Subject: Re: draft-ietf-mpls-diff-ext-05.txt comments
>
>
>Shahram
>Comments within.
>
>Shahram Davari wrote:
>
>> Puneet,
>>
>> Please see my comments:
>>
>
><<snipped>>
>
>> >4) pg 36, 5th paragraph: when a LSR can only support preconfigured
>> >EXP <--> PHB mapping, if someone wants to set up the per label
>> >EXP <--> PHB
>> >mapping, what error should the LSR return? Hopefully this 
>error code is
>> >different than "Diff-Serv Error" to differentiate it from invalid
>> >EXP <--> PHB mapping.
>>
>> As mentioned in section 5.3, two scenarios may exist:
>>
>> 1) In case the node only supports configured E-LSP, the node does not
>> recognize Diffserv object at all -> "Unknown Object Error"
>>
>> 2) In case the node supports configured E-LSP and L-LSP, The 
>node does not
>> recognize C-type = 1 (Signaled E-LSP) -> "Unknown Object C-type"
>>
>
>Why not have another error code for nodes that understand the 
>DS object but can
>not provide per-label context. This makes sense to me.
>
>
>>
>> Regards,
>> -Shahram
>>
>> >
>> >-Puneet
>> >
>
>



From owner-mpls@UU.NET  Mon Jun 26 16:05:09 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15076
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 16:05:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhg17224;
	Mon, 26 Jun 2000 20:04:57 GMT
Received: by mail-control.mail.uu.net 
	id QQivhg08587
	for mpls-outgoing; Mon, 26 Jun 2000 20:04:24 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivhg08021
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 20:04:15 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhg24510
	for <mpls@uu.net>; Mon, 26 Jun 2000 16:03:37 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivhg16164
	for <mpls@uu.net>; Mon, 26 Jun 2000 20:03:35 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA11881
	for mpls@uu.net; Mon, 26 Jun 2000 16:03:34 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivhg05666
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 20:03:22 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhg24265
	for <mpls@uu.net>; Mon, 26 Jun 2000 16:03:11 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQivhg15878
	for <mpls@uu.net>; Mon, 26 Jun 2000 20:03:10 GMT
Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA06795; Mon, 26 Jun 2000 16:03:06 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA21070; Mon, 26 Jun 2000 16:03:06 -0400 (EDT)
Message-Id: <200006262003.QAA21070@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: Eric Gray <EGray@zaffire.com>
cc: "George Swallow (E-mail)" <swallow@cisco.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>, swallow@cisco.com
Subject: Re: Last call on MPLS-DiffServ 
In-reply-to: Your message of "Mon, 26 Jun 2000 12:55:08 PDT."
             <9A564CC874B5D3118FB9009027B0A66269080C@ICARIAN> 
Date: Mon, 26 Jun 2000 16:03:05 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric -

> Date: Mon, 26 Jun 2000 12:55:08 -0700
                                   ^^^^

You also forgot about Daylight time so you have 'til 5pm PDT.  But I
doubt Francois will complain if he gets inputs by morning his time.

...George

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



From owner-mpls@UU.NET  Mon Jun 26 16:10:24 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15142
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 16:10:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhg21379;
	Mon, 26 Jun 2000 20:10:04 GMT
Received: by mail-control.mail.uu.net 
	id QQivhg10962
	for mpls-outgoing; Mon, 26 Jun 2000 20:09:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivhg10930
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 20:09:17 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhg25891
	for <mpls@uu.net>; Mon, 26 Jun 2000 16:08:52 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivhg20214
	for <mpls@uu.net>; Mon, 26 Jun 2000 20:08:52 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA12947
	for mpls@uu.net; Mon, 26 Jun 2000 16:08:51 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivhg10810
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 20:08:29 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivhg18817
	for <mpls@UU.NET>; Mon, 26 Jun 2000 16:08:08 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQivhg20500
	for <mpls@UU.NET>; Mon, 26 Jun 2000 20:08:08 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 967D1AD; Mon, 26 Jun 2000 22:08:07 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (mun-async15.cisco.com [10.49.255.82])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id WAA24871;
	Mon, 26 Jun 2000 22:08:00 +0200 (MET DST)
Message-Id: <200006262008.WAA24871@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Mon, 26 Jun 2000 22:05:38 +0200
To: gja@dnrc.bell-labs.com
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: Last Call feedback on MPLS-Diff-Serv
Cc: mpls@UU.NET
In-Reply-To: <395713AE.2605266D@dnrc.bell-labs.com>
References: <200006121753.NAA22286@lir.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Grenville,

Thanks for your comments. Since those comments are mainly editorials, we should be able to resolve them reasonably quickly.
Let me jumpt straight to the specific suggestions

At 01:26 26/06/2000 -0700, Grenville Armitage wrote:
[clip]
>
>******** Specific recommendations:
>
>#1 Remove section 11.
>
>   This can quite reasonably become another document discussing
>   experimental ways in which the EXP bits can be used to support
>   what even the current text admits is an experimental RFC.
>   It has no place in a normative spec relating MPLS and Diffserv,
>   and ought to be removed.
>

It has been useful and necessary for the WG to understand how ECN could share the EXP space with ECN (should ECN be required in the future), in order to progress with Diff-Serv over MPLS support. It seems appropriate to me to also reflect some of this in the Diff-Serv draft. If we had come up with a Diff-Serv solution that was incompatible with ECN, I think it woudl be useful for that document to say so. It turns out we feel that ECN and Diff-Serv could coexist and that the impact on the Diff-Serv over MPLS solution are reasonable. We might have tried to be too specific in the current text (considering the early stage of ECN over MPLS) but I think some description of why the current Diff-Serv solution does not preclude ECN and how those could share EXP space is useful information.

I'd like to hear other opionions.

>#2 Cite work on "MPLS Fast Restoration"
>
>   This phrase is used a number of times in section 1's intro,
>   yet there is no specific work cited to explain just what
>   this feature is. Since the intro claims that this I-D provides
>   support for protecting classes of service "..via MPLS Fast
>   Restoration" the technique needs to be cited. If some example
>   cannot be cited, alternative introductory wording ought to be
>   used. (Oddly this phrase morphs into "Fast Reroute" in the
>   appendices - please use one or the other consistently
>   throughout the document. Citation is important because even
>   in the appendices it isn't clear why this particular mode of
>   operation benefits from the extenions being discussed in this
>   document.)

sure, we'll include a reference to a document discussing FAst Restoration.

>
>#3 Define E-LSPs once only.
>
>   Right now sections 1.2 is the first definition of E-LSP.
>   It is relatively concise, and doesn't need to be repeated.
>   Specifically, in section 3.1 the two lists of bullet items
>   (beginning with "Recognizing that" and "We define that")
>   are verbosely redundant and add little. A reverse ref.
>   to section 1.2, with some additional clarification, is
>   all we need.
>

Fine.

>#4 Define L-LSPs once only.
>
>   Section 1.3 defines L-LSPs concisely, and section 4.1
>   is verbosely redundant with section 1.3. Section 4.1 ought
>   to ref. back to 1.3 with only minimal additional clarificatory
>   text.

Fine.

>
>#5 Vastly simplify sections 2.6.3 and 2.6.4 (tunnel models)
>
>   The last paragraph of 2.6.4 admits that basically the only
>   difference between the Uniform and Pipe models is in the
>   push/pop behaviors. At the very least 2.6.4 can be vastly
>   simplified by simply specifying the 'Pipe Model' in terms
>   of how it differs from the 'Uniform Model' in 2.6.3 (right
>   now 2.6.4 contains a load of redundant descriptive text).
>

Yes, as pointed out in the draft, the two models "only" differ in their push and pop behaviours. But the push and pop  behaviours (with/without PHP) are the complex aspects discussed in a big part of the text anyway (the swap behavior is quite straight-forward in both models). So , saying they "only" differ by push/pop doesn't mean that you would save that much text by describing operations of Pipe as delta over Uniform.

However, we could simplify 2.6.3 by combining the 2nd paragraph ("With this Uniform Model:...") with the last paragraph ("For support of the Uniform Model over an LSP ...").
Similarly we could simplify 2.6.4 by combining the 3rd paragraph ("With this Pipe Model: ...") with the two paragraphs before last ("For support of the Pipe Model over an LSP..."). 

>#6 Section 2.6.3, 2nd Figure
>
>   There's a "(P)" floating to the right of "(outer header)"
>   that perhaps ought not be there?  (Same for 2nd figure in
>   section 2.6.4)

(P) indicates the penultimate LSR in all diagrams. It appears at the right location even in the 2nd figures (ie without PHP). It insists on the fact that in those cases (P) does a swap (and not a pop) so that the "outer header" is there between (P) and (E) to carry some Diff-Serv info .

>
>#7 Clarify 2.6.5
>
>   Section 2.6.5's last sentence attempts to be normative about
>   something it simultaneously declares out of scope for this
>   document. Please clarify, reduce, or remove this section 

We can get rid of the word "may" of the last sentence so that it reads:
"Models beyond the Uniform Model and the Pipe Model are outside the scope of this specification but are not precluded by this specification".

>(the
>   essence can be stated somewhere earlier in section 2 anyway).
>

I woudl find it difficult to summarise something that explains that there could be other models, give a potential example of such other models and clarify it is outside the scope of this spec in less than 3 sentences. So I propose to leave it as it is.

>#8 Rationalize sections 3 and 4
>
>   Most of the processing steps are equivalent whether we are
>   discussing an E-LSP or L-LSP, so there's very little
>   reason to have two sections repeating much of each other.
>   (E.g. for filling out things like Encaps<->PHB mappings the
>    rules for E-LSPs are essentially a subset of those for L-LSPs,
>    sections 3.5 and 4.5 are practically identical,
>    section 3.3 is a subset of 4.3, etc...)

>  (Indeed, these two sections could probably be
>   beneficially collapsed into one section.)

I am not sure what you are calling the "two sections" (ie 3 and 4 , or 3.5 and 4.5)

Although the descriptions of E-LSPs and L-LSPs have a number of things in common, they have a lot of differences:
	- 3.2 and 4.2 are completely differnet. 3.2 uses preconfigured/signaled mappings applying on EXP only, 4.2 uses MAndatory/Default mappings applying to EXP/CLP/DE.
	- 3.4 and 4.4 are very differnet. 3.4 must have a PHB-->EXP mapping  while 4.4 may or may not have a PHB-->EXP mapping. 3.4 uses configured signaled mapping to populate it. 4.4 uses Mandatory mapping. 4.4 needs to cover the cases  of LC-ATM and LC-FR while 3.4 shoudl not. 4.4.4 is the same as 3.4.4 and already use a refernec to 3.4.4.1.
So section 3 and section 4 could not be collapsed together.

3.3 is indeeed a subset of 4.3, but 3.3 already boils down to a single paragraph so I am not sure we would gain much by replacing that with a cross-reference. Also you might have to clarify that only a subset of the cases are relevant to E-LSPs to avoid confusion. So there is not much to be gained there.

3.5 and 4.5 are the only ones that could usefully be combined. With very minor editing around, 4.5 could be replaced by a reference to 3.5. 

>   A lot of the wording in both sections ought to be tightened
>   up significantly to focus primarily on the normative
>   statements. 
>

Could you provide specific suggestions? or at least point us towards the issues you see?


>#9 Preconfigured E-LSP EXP<->PHB mapping?
>
>   Section 3.2.1 talks about a preconfigured EXP<->PHB mapping
>   but does not suggest a default. I think the document ought to
>   specify an actual default for EXP 000 to map to Best Effort PHB
>   (or set of defaults where *all* EXP values map to BE).
>

The Network Adminsitrator is expected to configure the "preconfigured EXP<->PHB mapping" depending on the BAs that are actually used in his/her network. Since differenet Network Administrators are likely to run differnet subsets of BAs it is difficult to define a Default mapping that would be generally useful. But I guess you are saying , it would be useful to have a default mapping in case the preconfigured mapping hasn't been configured at all by the Network Adminsitrator. Right?
In that case, I suppose I woudl also map all EXP values towards BE. 

Anyone else has thoughts on that?

>#10 Why is section 7 here?
>
>  Section 7 repeats material that is redundant for a reader who
>  gets this far into the document. Clearly the mechanisms for
>  handling MPLS over PPP are documented elsewhere, and this
>  document has already stated how various Encaps<->PHB mappings
>  are built for E- and L-LSPs. Section 7 ought to be removed,
>  perhaps to an informational/applicability document.

Section 7 is NOT redundant. It specifies , out of all the previously defined options, which ones are MUST and which ones are MAY for PPP interfaces. Unless you specify that you may have one implemnetation supporting one option and another implementation supporting another option which prevents actual interoperability.

We could put that text into a separate applicability document, but I don't see the point of doing this. What we have in there has been proposed and agreed for a while, and I think it is really required to achieve interoperability so that it belongs in this document.

>
>#11 Why are sections 8 and 9 here?
>
>  Sections 8&9 suffer the same question of focus as section 7.
>  How an ATM or FR interface operates is pretty much covered by
>  existing MPLS documents - excluding perhaps the recommendation
>  to use EPD for ATM, I dont see sections 8&9 adding anything
>  normative to what has already been stated earlier in the document.
>  They ought to follow section 7 into another document (or oblivion).
>

Same as above, these sections clarify which of the various options are applicable to these media.
Also it clarifies media specific issues which have come up during the WG progress (eg that the requirement is for ATM LSRs to support PHB scheduling rather than "traditional" ATM scheduling, that only two drop levels are supported , that EPD is a good idea, that the spec only covers the case where the shim layer is used...)

I believe this is useful information and should be kept.

>#12 Why is section 10 here?
>
>   Again, as with section 7 there's an issue of focus here.
>   No new normative text exists here, and it is at best a subset
>   of section 7 anyway.
>


Section 10 is NOT redundant. It specifies , out of all the previously defined options, which ones are MUST and which ones are MAY for LAN interfaces. Unless you specify that, you may have one implemnetation supporting one option and another implementation supporting another option which prevents actual interoperability.

We could easily group it with section 7 though.


>#13 Remove references to PIM as a label distribution mechanism
>
>   In sections 3.1 and 4.1 the last paragraph speaks about MPLS using
>   a variety of label distribution mechanisms, including PIM.
>   The reference to PIM should be removed (unless there's a citeable
>   *working group* document I'm unaware of for using PIM in this
>   manner).
>  

Fine.

>#14 Explicit cite for MPLS/BGP
>
>   In the same paras as mentioned above, citation would be useful
>   for the references to BGP being used to distribute labels
>   (presumably it is [MPLS_VPN] ?)  However, it would also be
>   worthwhile rephrasing the citation to not imply this is an
>   MPLS WG sanctioned solution (unlike LDP, CR-LDP, and RSVP-TE
>   which are WG sanctioned).
>

fine.



Cherio

Francois

>I look forward to the revised document providing much appreciated
>clarity and guidance to the industry.
>
>cheers,
>gja
>________________________________________________________________________
>Grenville Armitage                    http://members.home.net/garmitage/
>Bell Labs Research Silicon Valley
> 

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Mon Jun 26 16:23:31 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15292
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 16:23:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhh01610;
	Mon, 26 Jun 2000 20:23:15 GMT
Received: by mail-control.mail.uu.net 
	id QQivhh12918
	for mpls-outgoing; Mon, 26 Jun 2000 20:22:28 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivhh12913
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 20:22:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhh29459
	for <mpls@uu.net>; Mon, 26 Jun 2000 16:22:12 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivhh00618
	for <mpls@uu.net>; Mon, 26 Jun 2000 20:22:12 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA15096
	for mpls@uu.net; Mon, 26 Jun 2000 16:22:11 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivhh12861
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 20:21:50 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivhh29262
	for <mpls@UU.NET>; Mon, 26 Jun 2000 16:21:39 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQivhh00965
	for <mpls@UU.NET>; Mon, 26 Jun 2000 20:21:39 GMT
Received: from pluris.com (root@lightning.pluris.com [172.16.55.100])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA26681;
	Mon, 26 Jun 2000 13:21:32 -0700 (PDT)
Message-ID: <3957BB4B.DD1ABEBA@pluris.com>
Date: Mon, 26 Jun 2000 13:21:32 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois Le Faucheur <flefauch@cisco.com>
CC: gja@dnrc.bell-labs.com, mpls@UU.NET
Subject: Re: Last Call feedback on MPLS-Diff-Serv
References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francois

The ECN section as it is written in the document is not detailed enough. The use of only 1 bit for ECN to mean either the LSR is ECN capable and experiencing congestion or the LSR is not ECN capable is at the very least confusing.

This topic has not been widely discussed as part of the DS document. I would suggest that you remove section 11 and submit it as another ID and ask for WG to adopt this document. Then we can discuss the ECN compatibility with MPLS-DS extensions as part of the new document.

As presented in v05, the ECN section leaves too many holes as far as I am concerned.

Bora



Francois Le Faucheur wrote:

> Grenville,
>
> Thanks for your comments. Since those comments are mainly editorials, we should be able to resolve them reasonably quickly.
> Let me jumpt straight to the specific suggestions
>
> At 01:26 26/06/2000 -0700, Grenville Armitage wrote:
> [clip]
> >
> >******** Specific recommendations:
> >
> >#1 Remove section 11.
> >
> >   This can quite reasonably become another document discussing
> >   experimental ways in which the EXP bits can be used to support
> >   what even the current text admits is an experimental RFC.
> >   It has no place in a normative spec relating MPLS and Diffserv,
> >   and ought to be removed.
> >
>
> It has been useful and necessary for the WG to understand how ECN could share the EXP space with ECN (should ECN be required in the future), in order to progress with Diff-Serv over MPLS support. It seems appropriate to me to also reflect some of this in the Diff-Serv draft. If we had come up with a Diff-Serv solution that was incompatible with ECN, I think it woudl be useful for that document to say so. It turns out we feel that ECN and Diff-Serv could coexist and that the impact on the Diff-Serv over MPLS solution are reasonable. We might have tried to be too specific in the current text (considering the early stage of ECN over MPLS) but I think some description of why the current Diff-Serv solution does not preclude ECN and how those could share EXP space is useful information.
>
> I'd like to hear other opionions.
>
> >#2 Cite work on "MPLS Fast Restoration"
> >
> >   This phrase is used a number of times in section 1's intro,
> >   yet there is no specific work cited to explain just what
> >   this feature is. Since the intro claims that this I-D provides
> >   support for protecting classes of service "..via MPLS Fast
> >   Restoration" the technique needs to be cited. If some example
> >   cannot be cited, alternative introductory wording ought to be
> >   used. (Oddly this phrase morphs into "Fast Reroute" in the
> >   appendices - please use one or the other consistently
> >   throughout the document. Citation is important because even
> >   in the appendices it isn't clear why this particular mode of
> >   operation benefits from the extenions being discussed in this
> >   document.)
>
> sure, we'll include a reference to a document discussing FAst Restoration.
>
> >
> >#3 Define E-LSPs once only.
> >
> >   Right now sections 1.2 is the first definition of E-LSP.
> >   It is relatively concise, and doesn't need to be repeated.
> >   Specifically, in section 3.1 the two lists of bullet items
> >   (beginning with "Recognizing that" and "We define that")
> >   are verbosely redundant and add little. A reverse ref.
> >   to section 1.2, with some additional clarification, is
> >   all we need.
> >
>
> Fine.
>
> >#4 Define L-LSPs once only.
> >
> >   Section 1.3 defines L-LSPs concisely, and section 4.1
> >   is verbosely redundant with section 1.3. Section 4.1 ought
> >   to ref. back to 1.3 with only minimal additional clarificatory
> >   text.
>
> Fine.
>
> >
> >#5 Vastly simplify sections 2.6.3 and 2.6.4 (tunnel models)
> >
> >   The last paragraph of 2.6.4 admits that basically the only
> >   difference between the Uniform and Pipe models is in the
> >   push/pop behaviors. At the very least 2.6.4 can be vastly
> >   simplified by simply specifying the 'Pipe Model' in terms
> >   of how it differs from the 'Uniform Model' in 2.6.3 (right
> >   now 2.6.4 contains a load of redundant descriptive text).
> >
>
> Yes, as pointed out in the draft, the two models "only" differ in their push and pop behaviours. But the push and pop  behaviours (with/without PHP) are the complex aspects discussed in a big part of the text anyway (the swap behavior is quite straight-forward in both models). So , saying they "only" differ by push/pop doesn't mean that you would save that much text by describing operations of Pipe as delta over Uniform.
>
> However, we could simplify 2.6.3 by combining the 2nd paragraph ("With this Uniform Model:...") with the last paragraph ("For support of the Uniform Model over an LSP ...").
> Similarly we could simplify 2.6.4 by combining the 3rd paragraph ("With this Pipe Model: ...") with the two paragraphs before last ("For support of the Pipe Model over an LSP...").
>
> >#6 Section 2.6.3, 2nd Figure
> >
> >   There's a "(P)" floating to the right of "(outer header)"
> >   that perhaps ought not be there?  (Same for 2nd figure in
> >   section 2.6.4)
>
> (P) indicates the penultimate LSR in all diagrams. It appears at the right location even in the 2nd figures (ie without PHP). It insists on the fact that in those cases (P) does a swap (and not a pop) so that the "outer header" is there between (P) and (E) to carry some Diff-Serv info .
>
> >
> >#7 Clarify 2.6.5
> >
> >   Section 2.6.5's last sentence attempts to be normative about
> >   something it simultaneously declares out of scope for this
> >   document. Please clarify, reduce, or remove this section
>
> We can get rid of the word "may" of the last sentence so that it reads:
> "Models beyond the Uniform Model and the Pipe Model are outside the scope of this specification but are not precluded by this specification".
>
> >(the
> >   essence can be stated somewhere earlier in section 2 anyway).
> >
>
> I woudl find it difficult to summarise something that explains that there could be other models, give a potential example of such other models and clarify it is outside the scope of this spec in less than 3 sentences. So I propose to leave it as it is.
>
> >#8 Rationalize sections 3 and 4
> >
> >   Most of the processing steps are equivalent whether we are
> >   discussing an E-LSP or L-LSP, so there's very little
> >   reason to have two sections repeating much of each other.
> >   (E.g. for filling out things like Encaps<->PHB mappings the
> >    rules for E-LSPs are essentially a subset of those for L-LSPs,
> >    sections 3.5 and 4.5 are practically identical,
> >    section 3.3 is a subset of 4.3, etc...)
>
> >  (Indeed, these two sections could probably be
> >   beneficially collapsed into one section.)
>
> I am not sure what you are calling the "two sections" (ie 3 and 4 , or 3.5 and 4.5)
>
> Although the descriptions of E-LSPs and L-LSPs have a number of things in common, they have a lot of differences:
>         - 3.2 and 4.2 are completely differnet. 3.2 uses preconfigured/signaled mappings applying on EXP only, 4.2 uses MAndatory/Default mappings applying to EXP/CLP/DE.
>         - 3.4 and 4.4 are very differnet. 3.4 must have a PHB-->EXP mapping  while 4.4 may or may not have a PHB-->EXP mapping. 3.4 uses configured signaled mapping to populate it. 4.4 uses Mandatory mapping. 4.4 needs to cover the cases  of LC-ATM and LC-FR while 3.4 shoudl not. 4.4.4 is the same as 3.4.4 and already use a refernec to 3.4.4.1.
> So section 3 and section 4 could not be collapsed together.
>
> 3.3 is indeeed a subset of 4.3, but 3.3 already boils down to a single paragraph so I am not sure we would gain much by replacing that with a cross-reference. Also you might have to clarify that only a subset of the cases are relevant to E-LSPs to avoid confusion. So there is not much to be gained there.
>
> 3.5 and 4.5 are the only ones that could usefully be combined. With very minor editing around, 4.5 could be replaced by a reference to 3.5.
>
> >   A lot of the wording in both sections ought to be tightened
> >   up significantly to focus primarily on the normative
> >   statements.
> >
>
> Could you provide specific suggestions? or at least point us towards the issues you see?
>
> >#9 Preconfigured E-LSP EXP<->PHB mapping?
> >
> >   Section 3.2.1 talks about a preconfigured EXP<->PHB mapping
> >   but does not suggest a default. I think the document ought to
> >   specify an actual default for EXP 000 to map to Best Effort PHB
> >   (or set of defaults where *all* EXP values map to BE).
> >
>
> The Network Adminsitrator is expected to configure the "preconfigured EXP<->PHB mapping" depending on the BAs that are actually used in his/her network. Since differenet Network Administrators are likely to run differnet subsets of BAs it is difficult to define a Default mapping that would be generally useful. But I guess you are saying , it would be useful to have a default mapping in case the preconfigured mapping hasn't been configured at all by the Network Adminsitrator. Right?
> In that case, I suppose I woudl also map all EXP values towards BE.
>
> Anyone else has thoughts on that?
>
> >#10 Why is section 7 here?
> >
> >  Section 7 repeats material that is redundant for a reader who
> >  gets this far into the document. Clearly the mechanisms for
> >  handling MPLS over PPP are documented elsewhere, and this
> >  document has already stated how various Encaps<->PHB mappings
> >  are built for E- and L-LSPs. Section 7 ought to be removed,
> >  perhaps to an informational/applicability document.
>
> Section 7 is NOT redundant. It specifies , out of all the previously defined options, which ones are MUST and which ones are MAY for PPP interfaces. Unless you specify that you may have one implemnetation supporting one option and another implementation supporting another option which prevents actual interoperability.
>
> We could put that text into a separate applicability document, but I don't see the point of doing this. What we have in there has been proposed and agreed for a while, and I think it is really required to achieve interoperability so that it belongs in this document.
>
> >
> >#11 Why are sections 8 and 9 here?
> >
> >  Sections 8&9 suffer the same question of focus as section 7.
> >  How an ATM or FR interface operates is pretty much covered by
> >  existing MPLS documents - excluding perhaps the recommendation
> >  to use EPD for ATM, I dont see sections 8&9 adding anything
> >  normative to what has already been stated earlier in the document.
> >  They ought to follow section 7 into another document (or oblivion).
> >
>
> Same as above, these sections clarify which of the various options are applicable to these media.
> Also it clarifies media specific issues which have come up during the WG progress (eg that the requirement is for ATM LSRs to support PHB scheduling rather than "traditional" ATM scheduling, that only two drop levels are supported , that EPD is a good idea, that the spec only covers the case where the shim layer is used...)
>
> I believe this is useful information and should be kept.
>
> >#12 Why is section 10 here?
> >
> >   Again, as with section 7 there's an issue of focus here.
> >   No new normative text exists here, and it is at best a subset
> >   of section 7 anyway.
> >
>
> Section 10 is NOT redundant. It specifies , out of all the previously defined options, which ones are MUST and which ones are MAY for LAN interfaces. Unless you specify that, you may have one implemnetation supporting one option and another implementation supporting another option which prevents actual interoperability.
>
> We could easily group it with section 7 though.
>
> >#13 Remove references to PIM as a label distribution mechanism
> >
> >   In sections 3.1 and 4.1 the last paragraph speaks about MPLS using
> >   a variety of label distribution mechanisms, including PIM.
> >   The reference to PIM should be removed (unless there's a citeable
> >   *working group* document I'm unaware of for using PIM in this
> >   manner).
> >
>
> Fine.
>
> >#14 Explicit cite for MPLS/BGP
> >
> >   In the same paras as mentioned above, citation would be useful
> >   for the references to BGP being used to distribute labels
> >   (presumably it is [MPLS_VPN] ?)  However, it would also be
> >   worthwhile rephrasing the citation to not imply this is an
> >   MPLS WG sanctioned solution (unlike LDP, CR-LDP, and RSVP-TE
> >   which are WG sanctioned).
> >
>
> fine.
>
> Cherio
>
> Francois
>
> >I look forward to the revised document providing much appreciated
> >clarity and guidance to the industry.
> >
> >cheers,
> >gja
> >________________________________________________________________________
> >Grenville Armitage                    http://members.home.net/garmitage/
> >Bell Labs Research Silicon Valley
> >
>
> _________________________________________________________________
> Francois Le Faucheur
> Development Engineer, IOS Layer 3 Services
> Cisco Systems
> Office Phone:           +33 4 92 96 75 64
> Home Office Phone:     +33 4 92 94 00 78
> Mobile :               +33 6 89 108 159
> Vmail:                 +33 1 58 04 62 66
> Fax:                   +33 4 92 96 79 08
> Email:                  flefauch@cisco.com
> _________________________________________________________________
> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
> _________________________________________________________________




From owner-mpls@UU.NET  Mon Jun 26 17:06:44 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15885
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 17:06:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhk04915;
	Mon, 26 Jun 2000 21:06:30 GMT
Received: by mail-control.mail.uu.net 
	id QQivhk27632
	for mpls-outgoing; Mon, 26 Jun 2000 21:06:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivhk27567
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 21:05:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhk08665
	for <mpls@uu.net>; Mon, 26 Jun 2000 17:05:38 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQivhk03810
	for <mpls@uu.net>; Mon, 26 Jun 2000 21:05:37 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA25802
	for <mpls@uu.net>; Mon, 26 Jun 2000 14:05:48 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA14746 for mpls@uu.net; Mon, 26 Jun 2000 17:05:36 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivgo12068
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 15:35:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivgo19759
	for <mpls@UU.NET>; Mon, 26 Jun 2000 11:35:25 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQivgo24378
	for <mpls@UU.NET>; Mon, 26 Jun 2000 15:35:25 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <MJ3J3A79>; Mon, 26 Jun 2000 11:33:00 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B8501BEA4@xover1.hjinc.com>
From: "Friedeborn, William" <wfriedeb@netplane.com>
To: "'Adrian Farrel'" <AF@datcon.co.uk>,
        "Thomas D. Nadeau"
	 <tnadeau@cisco.com>
Cc: "'arun Viswanathan'" <arun@force10networks.com>,
        "'cheenu Srinivasan'"
	 <csrinivasan@tachion.com>, mpls@UU.NET,
        "'manis@future.futsoft.com'"
	 <manis@kailash.future.futsoft.com>
Subject: RE: MPLS TE MIB - Doubts
Date: Mon, 26 Jun 2000 11:32:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

A couple of points I am a little confused on in this thread about adding a
SourceID to the Tunnel indexing scheme. 
1. Tunnel Indexing - When I look at the current indexing scheme of
TunnelIndex, TunnelInstance, there is nothing here that would indicate that
this information should have any significance  other than to the node it is
created on. In my first cut at understanding the use of Tunnels, I could see
that the ingress node could have the Tunnel objects defined via SNMP/cli.
The Tunnel instrumentation would pass the info down to the supporting
protocol statemachine (LDP or RSVP), the protocols would signal down to the
egress node creating LSR-MIB objects along the way (or on reverse trip) till
the egress node is reached, where the LSR-MIB and Tunnel objects are
created. Since my understanding of the LDP and RSVP protocols is not that
detailed, I didn't see where the Tunnel indexing info fit in LDP or RSVP
(i.e. how would this index info be passed on the LSP creation via RSVP?). It
seemed that the intent was to use the cross-connects on each node to
associate the Tunnel object using it. And the LSPID to track the sequence of
cross-connects so that one could follow an LSP from node to node via the
LSPID.

If the intent is that a tunnel definition should have more than just local
significance, shouldn't there be some tunnelID defined (like LSPID)? I can
see that adding a SourceID makes it possible to pass these locally defined
indices, but it seems odd to me that when you define a set of indices on one
machine, that another machine should know about them. 

2. Multiple LSPs on a Tunnel - Looking at the LSR-MIB I see that the
cross-connect object has a XCIndex and three other indices. I assumed these
were set up to support MP-PT, and PT-MP by keeping the XCIndex and
OutSegmentIndex constant and varying the InSegmentIfIndex/label, the MP-PT
case is achieved, and similarly the PT-MP could be done. (Is it
possible/practical to have MP-MP?). In any case, it seemed that there could
be a situation where a Tunnel had a XCIndex that referenced  more that one
row in a XC table. I wasn't sure if the multiple rows in the XC table ment
multiple LSPs? Or just a MP-PT or PT-MP single LSP?

3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also.

Hope someone can clarify the above,
Thanks,
Bill Friedeborn
 
-----Original Message-----
From: Adrian Farrel [mailto:AF@datcon.co.uk]
Sent: Sunday, June 25, 2000 9:25 PM
To: Thomas D. Nadeau
Cc: 'arun Viswanathan'; 'cheenu Srinivasan'; mpls@UU.NET;
'manis@future.futsoft.com'
Subject: RE: MPLS TE MIB - Doubts


>>At an intermediate node, the ARhop table reflects the actual 
>>routes taken by the LSPs.  Since two LSPs may have the same 
>>tunnel index and tunnel instance, it is necessary to 
>>differentiate the entries in the ARhop table by also using 
>>the sourceAddress.

>I think that you are looking at it a bit backwards. The LSPs do not
>have tunnel indexes; the tunnels point at LSPs via the cross-connects
>which they use. I don't see the case where a single instance of a
>tunnel will be using multiple LSPs.

Is there a difference in your mind between a "tunnel", an "LSP tunnel"
and an "LSP"?

I am not suggesting that "a single instance of a tunnel will be using 
multiple LSPs".  I am pointing out that two tunnels at an intermediate
node may have the same tunnel index and tunnel instance and be 
distinguishable only by the source address.  This is what you have 
noticed and used to extend the indexing of the mplsTunnelTable.

>>Now, at an intermediate node the hop table (i.e. not the ARhop table)
>>reflects the remaining part of the requested ER signaled by the
>>protocol.  Since two LSPs may have the same tunnel index and tunnel
>>instance and yet not have the same remaining ER, surely the hop table
>>also needs to be indexed by source address.

>No. At an intermediate node the HopTable should not reflect anything
>since there is no tunnel head configuration information stored there,
>just ARHop information from say the signalling protocol. Again, the 
>HopTable only contains the *configured* tunnel information, and the 
>ARHopTable contains the actual hop information. At intermediate nodes,
>the ARHopTable *may* contain the remainder of the path for that tunnel,
>and the tunnel table should also be able to identify which LSP (via 
>the XCIndex) it is using. This is something that I believe is very 
>useful for allowing network operators of very large networks containing
>dozens or hundreds of LSRs to visualize what is actually going on at 
>any LSR in their network.

Tom, I understand that you think it is useful to hold the TE MIB at 
intermediate nodes.  If that is the case, I think you should hold _all_
of the information available at the intermediate nodes and not arbitrarily
drop some.  In this case, the information to build the HopTable is
signaled by both RSVP and CR-LDP as the Explicit Route.  Further, the
information signaled as the ER is potentially significantly different
from the ARHopTable which records the actual route.

If the ARHopTable is useful to network managers at intermediate nodes,
the differences from the requested ER (i.e. the HopTable) must also be
very useful.  Consider that the HopTable specifies a loose hop but the 
ARHopTable shows the actual route taken.

>>I'm wondering whether this isn't all getting a bit messy?  It is
>>driven by the idea of maintaining the TE MIB at intermediate nodes
>>which is potentially interesting, but not within the original scope
>>of the TE MIB as I understood it.

>I think that it is potentially messy because we have not necessarily
>been clear in the draft about this since the idea of using the MIB at
>midpoints is a new one that I recently introduced. I apologize for 
>this. We are about to publish the next version of the TE MIB, and I 
>will make sure that this version contains some text explaining this
>topic.

I look forward to reading it.

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422



From owner-mpls@UU.NET  Mon Jun 26 17:50:40 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16298
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 17:50:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhn06863;
	Mon, 26 Jun 2000 21:50:28 GMT
Received: by mail-control.mail.uu.net 
	id QQivhn02434
	for mpls-outgoing; Mon, 26 Jun 2000 21:50:09 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivhn02409
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 21:49:59 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhn16995
	for <mpls@UU.NET>; Mon, 26 Jun 2000 17:49:54 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQivhn06331
	for <mpls@UU.NET>; Mon, 26 Jun 2000 21:49:53 GMT
Received: from aatlas-pc (aatlas-pc.avici.com [10.1.2.92])
          by mailhost.avici.com (8.8.5/8.8.4) with SMTP
	  id RAA07534 for <mpls@UU.NET>; Mon, 26 Jun 2000 17:49:52 -0400 (EDT)
Message-Id: <4.1.20000626174509.00a2a7b0@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 26 Jun 2000 17:49:00 -0500
To: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
From: Alia Atlas <aatlas@avici.com>
Subject: Last Call feedback on MPLS-diffserv
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I have two comments on the draft.  I would like to see the draft support
signalling of the tunnelling mode; a suggested method is below.  Second, I
would like to clarify supporting bandwidth reservation on E-LSPs.  Towards each
purpose, as described below, I would suggest using a reserved bit.

There are two tunnelling modes in which each LSP could operate.
However, the draft gives no guidelines as to how to determine which
mode a given LSP should use.   I would like to suggest using one of
the reserved bits in the DIFFSERV object for this purpose, as follows:
 
   DIFFSERV object for an E-LSP:

   class = TBD, C_Type = 1  (need to get an official class num from the
   IANA with the form 0bbbbbbb)

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved                                     |T| MAPnb |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (1)                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                               ...                            //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (MAPnb)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 27 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.

        T : 1 bit
          Specifies the tunnel mode to be used by the LSP.  If 0, then the
       tunnel mode is Uniform.  If 1, the tunnel mode is Pipe.

   DIFFSERV object for an L-LSP:

   class = TBD, C_Type = 2  (class num is the same as DIFFSERV object
   for E-LSP))

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved             |T|             PSC               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 16 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.
        
        T : 1 bit
          Specifies the tunnel mode to be used by the LSP.  If 0, then the
       tunnel mode is Uniform.  If 1, the tunnel mode is Pipe.

Similar bits can be acquired from the reserved for the Diff-Serv TLV.

For RSVP, if a router cannot support the specified tunnelling mode, it would
report a 'Diff-Serv Error' with a value of 5 = "Unsupported Tunnel Mode". 
Similarly, for LDP, a status code of 0x0000001A could be used for  
"Unsupported Tunnel Mode".

I realize that this does not provide flexibility for future tunnel modes, so
more bits could be dedicated to this purpose, as and when deemed appropriate.

I would like to spend a second bit to properly support signalled bandwidth
reservations for E-LSPs.  Currently the draft has an inconsistency.

In Section 1.6, the current draft states:
  "When bandwidth requirements are signaled at establishment of an
   E-LSP, the signaled bandwidth is associated collectively to the
   whole LSP and therefore to the set of transported PSCs. Thus, LSRs
   which use the signaled bandwidth to perform admission control may
   perform admission control over global resources which are shared by
   the set of PSCs (e.g. over the total bandwidth of the link)."

In Section 5.6, the draft further specifies:
  "To establish an E-LSP or an L-LSP with bandwidth reservation, Int-
   Serv's Controlled Load service (or possibly Guaranteed Service) is
   used and the bandwidth is signaled in the SENDER_TSPEC (respectively
   FLOWSPEC) of the path (respectively Resv) message.
   ....
   The above is summarized in the following table:

           Path Message  LSP type
    Service  DIFFSERV
              Object

     GS/CL     No        E-LSP + preconf mapping + bandw reservation
     GS/CL   Yes/E-LSP   E-LSP + signaled mapping + bandw reservation
     GS/CL   Yes/L-LSP   L-LSP + bandw reservation
     COS       No        E-LSP + preconf mapping + no bandw reservation
     COS     Yes/E-LSP   E-LSP + signaled mapping + no band reservation
     COS     Yes/L-LSP   L-LSP + no bandw reservation

   Where:
        - GS stands for Guaranteed Service
        - CL stands for Controlled Load
        - COS stands for COS service"

Thus, if a RESV message contains both a TSpec with GS or CL specified and a
Diffserv object for an E-LSP, bandwidth reservation is the appropriate
behavior.  However, adequate information is not supplied to know how much
additional bandwidth each PHB used by the E-LSP should be provisioned with.

Given that it would be desirable to support bandwidth reservations associated
with E-LSPs, I would propose the following modifications to the Diffserv Object
and Diff-Serv TLV.  
DIFFSERV object for an E-LSP:

   class = TBD, C_Type = 1  (need to get an official class num from the 
   IANA with the form 0bbbbbbb)

     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |B|        Reserved                                   |T| MAPnb | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            MAP (1)                            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                                                               | 
    //                               ...                            // 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            MAP (MAPnb)                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 26 bits 
       This field is reserved. It must be set to zero on transmission 
       and must be ignored on receipt.

             B : 1 bit 
                This flag indicates whether bandwidth is explicitly specified
per MAP.  
       If it is 0, no bandwidth is explicitly signalled, and the Diffserv
object 
        is not further modified.  If it is 1, then the Diffserv object will 
       contain those bandwidths as described below: 
         
    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|        Reserved                                   |T| MAPnb | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            MAP (1)                            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            BW (1)                             | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                                                               | 
    //                               ...                            // 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            MAP (MAPnb)                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            BW (MAPnb)                         | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      BW : 32 bits 
                  Bandwidth reserved for the above PHBID.  This is specified as
a               standard IEEE floating number.  The units are bytes/sec.

When the Bandwidth flag is set, the rate signalled in the Tspec is ignored. 
Instead, the bandwidths signalled in the Diffserv Object would be used.

I am not certain how to specify this feature with LDP, because I am less
familiar with LDP.  No language in the draft exists to specify how bandwidth
reservation might be done using LDP.  Perhaps someone with greater knowledge of
LDP could take a look and determine whether it makes sense to support this
feature in LDP and how it might be done.

Please let me know what you think.

Thanks,
Alia 



From owner-mpls@UU.NET  Mon Jun 26 17:58:55 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16367
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 17:58:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhn12201;
	Mon, 26 Jun 2000 21:58:44 GMT
Received: by mail-control.mail.uu.net 
	id QQivhn03180
	for mpls-outgoing; Mon, 26 Jun 2000 21:58:28 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivhn03169
	for <mpls@mail-control.mail.uu.net>; Mon, 26 Jun 2000 21:58:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhn18199
	for <mpls@UU.NET>; Mon, 26 Jun 2000 17:58:02 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6])
	id QQivhn12385
	for <mpls@UU.NET>; Mon, 26 Jun 2000 21:58:02 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jun 26 17:57:13 EDT 2000
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA11217;
	Mon, 26 Jun 2000 17:57:48 -0400 (EDT)
Message-ID: <3957D29B.C07A40E8@dnrc.bell-labs.com>
Date: Mon, 26 Jun 2000 15:00:59 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois Le Faucheur <flefauch@cisco.com>
CC: mpls@UU.NET
Subject: ECN Re: Last Call feedback on MPLS-Diff-Serv
References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francois,

I'll pull out each major discussion point separately. In this
email my response re ECN.

	[..]
> >#1 Remove section 11.
	[..]
> It has been useful and necessary for the WG to understand how ECN could
> share the EXP space with ECN (should ECN be required in the future),
> in order to progress with Diff-Serv over MPLS support.

Regardless of the ongoing debates in other mailing lists over the
utility of ECN, it isn't necessary for *this* document to specify
anything regarding ECN support. It is sufficient that diff-ext-05
state ECN isn't precluded, there is no need for diff-ext-05 to
speculate on how ECN might be supported. Leave that for another
document.

I suggest it is sufficient to state the following in the intro,
abstract, and/or conclusion:

 "The architecture described in this document does not preclude the
  signalled or configured use of the EXP bits to support protocols
  such as ECN [ECN][MPLS_ECN]. However, techniques for supporting
  ECN in an MPLS environment are outside the scope of this document."

Done.

cheers,
gja


> It seems
> appropriate to me to also reflect some of this in the Diff-Serv draft.
> If we had come up with a Diff-Serv solution that was incompatible with
> ECN, I think it woudl be useful for that document to say so. It turns
> out we feel that ECN and Diff-Serv could coexist and that the impact on
> the Diff-Serv over MPLS solution are reasonable. We might have tried to
> be too specific in the current text (considering the early stage of ECN
> over MPLS) but I think some description of why the current Diff-Serv
> solution does not preclude ECN and how those could share EXP space is
> useful information.
	[...]
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Mon Jun 26 22:11:41 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19232
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 22:11:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivie25451;
	Tue, 27 Jun 2000 02:10:10 GMT
Received: by mail-control.mail.uu.net 
	id QQivie23466
	for mpls-outgoing; Tue, 27 Jun 2000 02:09:27 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivie23451
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 02:09:13 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivie26276
	for <mpls@UU.NET>; Mon, 26 Jun 2000 22:09:02 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQivie21216
	for <mpls@UU.NET>; Tue, 27 Jun 2000 02:09:02 GMT
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA13898;
	Mon, 26 Jun 2000 19:09:00 -0700 (PDT)
Received: by MONTEREY with Internet Mail Service (5.5.2650.21)
	id <M71CGRAT>; Mon, 26 Jun 2000 19:09:01 -0700
Message-ID: <E097FDA4F2FED311994000104B31A8611210F1@MONTEREY>
From: Puneet Agarwal <puneet@pluris.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
Date: Mon, 26 Jun 2000 19:09:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

Please see my comments below.

>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Monday, June 26, 2000 11:42 AM
>To: 'Puneet Agarwal'; 'mpls@uu.net'
>Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
>
>
>Puneet,
>
>Please see my comments:
>
>>-----Original Message-----
>>From: Puneet Agarwal [mailto:puneet@pluris.com]
>>Sent: Friday, June 23, 2000 8:38 PM
>>To: 'mpls@uu.net'
>>Subject: draft-ietf-mpls-diff-ext-05.txt comments
>>
>>
>>1) The draft needs to detail the usage of hierarchical tunnel (HT)
>>especially
>>in the case of PHP. 
>>
>>For PHP and HT to work for diffserv/MPLS the Penultimate LSR 
>>needs to know
>>the PHB -> EXP
>>mapping of the underlying encapsulated tunnels. Moreover, if a LSP is
>>carrying
>>multiple LSPs with different PHB-> EXP mapping, the 
>>penultimate LSR and even
>>the egress LSR (in case of no PHP) would need to determine 
>>(after Pop), the
>>type of the underlying LSP.
>>
>>Another example to illustrate this complexity:
>>Consider the case when a L-LSP is sent over a prior 
>>established E-LSP. the
>>Penultimate LSR for the E-LSP has no knowledge of tunnels that are
>>hierarchically going through it. Hence when it does the 
>>penultimate POP, it
>>has no knowledge about the PHB->EXP encoding for the underlying L-LSP.
>>In order to do this correctly, one would need to maintain 
>>additional state
>>associated with the outer E-LSP in order to do the correct 
>>PHB-> EXP map for
>>the encapsulated L-LSP.
>
>Not necessarily. This restriction applies only to Uniform 
>model. In case of
>Pipe model, the PHP does not need to know anything about lower 
>LSP, it just
>pops and forwards the packet without modifying the lower label.
>
>The case of Uniform model is already mentioned in section 2.6.6:
>
>"- when the multiple pop operations are performed by the 
>Penultimate LSR,
>note that to perform Encoding of Diff-Serv       Information, the
>Penultimate LSR needs to be aware of the "Set       of PHB-->Encaps
>mappings" for the label corresponding to the      exposed 
>header after all
>the pop operations (or the PHB-->DSCP       mapping). Methods 
>for providing
>this mapping awareness are       outside the scope of this 
>specification."
>
>And section 2.6.3:
>
>"Note that to do so, the Penultimate LSR needs to be aware of 
>the       "Set
>of PHB-->Encaps mappings" for the label corresponding to       
>the exposed
>header (or the PHB-->DSCP mapping). Methods for       
>providing this mapping
>awareness are outside the scope of this       specification."
>
>The type of LSP is implicit in the PHB -> Encaps mapping. And 
>the Egress LSR
>must know the mapping regardless of the type of the LSP.
>

The problem (as you stated) arises at the Penultimate LSR in the Uniform
model. If "Methods for providing this mapping awareness are outside the
scope of this specification", then you really have 2 choices for deployment:
(a) Invent your own protocol to signal the PHB-> EXP information from the
egress LSR to Penultimate LSR for each encapsulated LSP carried in the outer
LSP. The Penultimate LSR would still need to look at the encapsulted LSP to
figure out which PHB->EXP mapping to apply.
OR 
(b) Require that every encapsulated LSP have the same PHB-> EXP mapping as
the top LSP (being PHPed). This also implies that you cannot have E-LSPs
encapsulated in L-LSPs and vica-versa.

It would be nice to add this clarification to the draft (could be in an
appendix).
 

>
>2) pg 21 - In the Pipe Model, when performing multiple push 
>>operations, the
>>LSR may need to be able to encode different PHB->EXP markings for each
>>pushed
>>label in the stack
>
>This is also explained in Section 2.6.4:
>
>"the LSP Ingress, when performing the push operation, encodes 
>the       LSP
>Diff-Serv information in the label entry that is pushed       
>("outer label
>entry") and encodes the Tunneled Diff-Serv       Information in the
>encapsulated header (IP header or swapped      label entry)."
>
>And Section 2.6.6:
>
>"LSRs at different levels of LSPs are expected to operate in 
>the same or in
>different Tunneling Models."
>
>"For support of M levels of push in the Pipe Model:
> - when performing multiple push operations, the LSR:
>      o encodes Diff-Serv Information corresponding to the
>        Outgoing PHB in the transmitted label entry corresponding
>        to the LAST pushed label (ie the label pushed in the outer
>        label entry).
>      o encodes Diff-Serv Information corresponding to the
>Incoming PHB in the encapsulated header (swapped label
>        entry or IP header) as well as in the label entries for
>        all the pushed labels (except the last pushed label)."
>
>Which basically says that the LSR doing the PUSH operation 
>will encode each
>level of push according to its type, and the details of each type is
>described in E-LSP and L-LSP sections. 
>
I just wanted the draft to highlight that potentially the ingress LSR would
need to  encode a *different* PHB-> EXP mapping for *each* encapsulated
header. It would make it clear to hw designers the hw hooks they need to
implement in order to support multiple push operations. As written in the
current draft, it is very easy to miss this fact.

Thanks.

-Puneet


From owner-mpls@UU.NET  Mon Jun 26 22:54:30 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20455
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 22:54:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivih18913;
	Tue, 27 Jun 2000 02:53:57 GMT
Received: by mail-control.mail.uu.net 
	id QQivih28145
	for mpls-outgoing; Tue, 27 Jun 2000 02:53:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivih28132
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 02:53:16 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivih11697
	for <mpls@uu.net>; Mon, 26 Jun 2000 22:52:55 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivih18269
	for <mpls@uu.net>; Tue, 27 Jun 2000 02:52:54 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA18875
	for mpls@uu.net; Mon, 26 Jun 2000 22:52:53 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivih28064
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 02:52:12 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivih11295
	for <mpls@UU.NET>; Mon, 26 Jun 2000 22:52:03 -0400 (EDT)
Received: from mailman.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailman.cisco.com [171.68.225.9])
	id QQivih19608
	for <mpls@UU.NET>; Tue, 27 Jun 2000 02:52:02 GMT
Received: from cisco.com (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id TAA01212;
	Mon, 26 Jun 2000 19:51:45 -0700 (PDT)
Message-ID: <39580866.AC5EB365@cisco.com>
Date: Mon, 26 Jun 2000 18:50:30 -0700
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
CC: Venu Josyula <vjosyula@mantranet.com>,
        Santosh Gupta <santoshg@daewoo.dti.daewoo.co.kr>, mpls@UU.NET
Subject: Re: LDP + COPS
References: <002101bfda88$38062f00$100d85a5@dti.daewoo.co.kr> <001701bfdaae$b8e14940$4400a8c0@mantranet.com> <39502B24.A419C796@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


RSVP + COPS makes even more sense. And btw this is working fine today.

R.

> Yangguang Xu wrote:
> 
> Instead of LDP + COPS, CR-LDP + COPS makes more sense.
> 
> Yangguang



From owner-mpls@UU.NET  Mon Jun 26 23:31:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21107
	for <mpls-archive@lists.ietf.org>; Mon, 26 Jun 2000 23:31:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivhx17100;
	Tue, 27 Jun 2000 00:24:54 GMT
Received: by mail-control.mail.uu.net 
	id QQivhx21540
	for mpls-outgoing; Tue, 27 Jun 2000 00:23:49 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivhx21519
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 00:23:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivhx03292
	for <mpls@uu.net>; Mon, 26 Jun 2000 20:23:29 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivhx16980
	for <mpls@uu.net>; Tue, 27 Jun 2000 00:23:29 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCD2Q4>; Mon, 26 Jun 2000 17:29:54 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269080F@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: Last call comments
Date: Mon, 26 Jun 2000 17:29:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Folks,

	Here's most of my last call comments.  More may
be sent out later this evening...

IN GENERAL
==========

	Many aspects of this draft - especially those
relating to E-LSPs and L-LSPs and the Pipe Model
seem intuitive and very useful.

	There are several aspects of the uniform model
which appear complex beyond any justification I have
seen for specifying this model.

	There are concepts that have been introduced
almost completely without explanation.  An amazing
example is the concept of the multi-pop PHP that
comes up in section 2.6.6.

	The draft punts on several relevant issues.  In
particular, there seems to be no effort to justify 
some of the complexity in the specification in terms 
of real world applications for particularly difficult
combinations (such as the combination of Uniform model 
and PHP).  If the uniform model is intended for the
purpose stated by Shahram Davari (23 March, 2000), then
it would be useful to state that an example of when it
might be useful is when multiple tunnel hierarchy levels
are within the same administrative domain.

	There are far too many murky statements for the
specification to be useful in producing interoperable
implementations.  For example, from mid-page on page
18:

   "(1) Tunneling Model 1 (either Uniform or Pipe)

   "(2) Tunneling Model 2 (same as Tunneling Model 1 or different Model)"

Or at the bottom of page 16, top of page 17:

   "LSRs at different levels of LSPs are expected to operate in the same 
    or in different Tunneling Models."

I believe these may be examples of an earlier comment 
on mixing of example deployments and normative text.

	The statement that other models (besides Pipe 
and Uniform) may be supported makes me wonder why an
attempt is made to support the Uniform model (it may
be that the draft punts too late on this issue, rather
than to early on issues that derive from the Uniform
model).

	There are many repeat definitions of Acronyms
(places where the expanded version is followed by the
Acronym in parentheses).  This makes the draft look 
as if it was glued together from many pieces.  Either
the acronyms should be collected, or only the first 
instance should show both.  Currently, there are many
cases where the acronym is first used before being 
defined.

	I agree with the earlier posted comment that the
draft is excessively wordy.  It includes quotations of
large amounts of text from other drafts which are not 
necessary, it has a lot of redundancy and it looks as
if it has been cobbled together incompletely from the
work of several people.  The content is too important 
to be so hard to read.

SPECIFIC COMMENTS
=================

	The first paragraph in the introduction implies
that the same label is used at each hop.  Last sentence 
should read something like "At each LSR along the LSP, 
the label is used to label-swap and forward the packet 
to the next hop."

	Why the 4+ line quote from [DIFF_HEADER] at the 
bottom of page 2, instead of simple stating the need to 
provide flexibility for service providers?

	Section 1.6 - can signaled bandwidth also be used 
for policing packets associated with a PSC?  How does an
implementation know if it is supposed to use signaled
bandwidth to perform any of the functions mentioned in
this section (adjusting scheduling weights, admission
control and, possibly, policing)?

	In section 2.1, this statement:

  "Obviously, to enforce the Diff-Serv service differentiation the LSR
   MUST also apply the forwarding treatment corresponding to the
   Outgoing PHB."

makes no sense, given that - in the bullets that precede
it - determination of the outgoing PHB is optional.  The
bullet - based on following text - should say something to
the effect that determination of a change in outgoing PHB
is optional.

	At the bottom of page 6, the two statements:

  "(*) when the LSR performs label imposition, the incoming packet is
   received unlabelled.

  "(**) when the LSR performs label disposition, the outgoing packet is
   transmitted unlabelled."

are only true if no label stacking occurs.  It may be that 
you are just talking about the (rather difficult to follow)
figure, but it would be better (and more general) if you
use the common terms "ingress" and "egress" rather than the
terms "label imposition" and "label disposition" and simply
replace these lines with:

   "(*) ingress

   "(**) egress"

	Section 2.3 says that determination of outgoing PHB is 
optional yet goes on to say that the default is that outgoing
PHB is identical to incoming PHB.  This would be clearer if
it simply states that the determination is always done and 
the default 'determination' is that the outgoing is the same
as the incoming (this corresponds to the default "local
policy").

	Why the 8 line quote from [MPLS_ARCH] (toward bottom
of page 8)?  Simply change the next paragraph to read:

   "This specification allows that an incoming label ..."

	Same question/observation for the quote at the bottom
of page 9 and top of page 10.

	The statement "Based on these considerations ..." in
the last paragraph of section 2.6.2 seems to be a non-sequitur
- I cannot see the connection between the "considerations"
and the conclusion.  For one thing, it seems almost to conclude
that - because there is PHP in MPLS, and this makes it hard to
determine what the EXP field was at the egress, then the uniform
model (which makes it necessary to recover this information) is
justified.

	I believe that the uniform model should receive the same
treatment as "other models" - i.e. - it should be treated as out
of scope.  This removes a lot of seeming unjustified complexity 
and about two pages of text.

	In section 2.6.6 - there are bullets that talk about 
multi-pop PHP.  Currently, there is no standard way to signal 
this - nor is it reasonable to establish one.  The supposed
intent for PHP was to avoid pop-and-look-again behavior in an
egress LSR.  PHP does not currently require the penultimate
LSR to look at the label it has exposed by popping the label
stack  - so it has no means to determine that it needs to do
a second (or subsequent) pop, even if it is otherwise capable
of performing a pop-and-look-again.  These bullets should be
removed. (I'm pretty sure that there is no other MPLS draft 
that refers to the ability to pop multiple labels as a single 
atomic operation - even at the egress LSR - even though an LSR
implementation can obviously be made to do this.)

	The draft needs a list of acronyms and/or a glossary.  
The acronyms used (and, in some cases, introduced) in this 
draft include:

BA		Behavior Aggregates
DSCP		Differentiated Services Code Point
EXP		EXPerimental (bits)
E-LSP		EXP-Inferred-PSC LSP
FEC		Forwarding Equivalency Class
FTN		FEC-To-NHLFE Map
ILM		Incoming Label Map
LSP		Label Switched Path
LSR		Label Switch Router
L-LSP		Label-Only-Inferred-PSC LSP
MPLS		Multi-Protocol Label Switching
NHLFE		Next Hop Label Forwarding Entry
OA		Ordered Aggregate
PHB		Per Hop Behavior
PSC		PHB Scheduling Class

(Punting on this - as seems to be the current approach
 is just messy :-)

In addition, the following definitions would be useful
(collected in a glossary?):

Behavior Aggregate
		Packets crossing a link that require
		the same Diff-Serv behavior.
Diff-Serv	Differentiated Services.
Diff-Serv Context
		<Insert Definition HERE>
FEC		<Insert Definition HERE>
Ordered Aggregate
		Set of Behavior Aggregates sharing an 
		ordering constraint.
PHB Scheduling Class
		Set of PHBs applicable to an Ordered 
		Aggregate.



NITS
====

top of page 3 'eg.' should be 'e.g.' (two cases in the 
first paragraph on this page).  Same for top of page 4
(3 occurrences).

first paragraph in section 2.1, last sentence - can't
quite figure out what you're saying.  Suggested rewording
is:

"... the way to determine the PHB to be applied to a
 received packet and to encode the PHB into a transmitted 
 packet is different than for a non-MPLS Diff-Serv Router."
                     --------


From owner-mpls@UU.NET  Tue Jun 27 02:09:20 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04335
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 02:09:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQiviu11334;
	Tue, 27 Jun 2000 06:09:00 GMT
Received: by mail-control.mail.uu.net 
	id QQiviu00882
	for mpls-outgoing; Tue, 27 Jun 2000 06:08:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQiviu00867
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 06:08:29 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQiviu14329
	for <mpls@uu.net>; Tue, 27 Jun 2000 02:08:16 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQiviu11018
	for <mpls@uu.net>; Tue, 27 Jun 2000 06:08:15 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA00349
	for mpls@uu.net; Tue, 27 Jun 2000 02:08:15 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQiviu00830
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 06:07:56 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQiviu26014
	for <mpls@UU.NET>; Tue, 27 Jun 2000 02:07:43 -0400 (EDT)
Received: from lohi.eng.telia.fi by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQiviu10380
	for <mpls@UU.NET>; Tue, 27 Jun 2000 06:07:42 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id JAA28909;
	Tue, 27 Jun 2000 09:07:38 +0300
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14680.17578.442593.697375@lohi.eng.telia.fi>
Date: Tue, 27 Jun 2000 09:07:38 +0300 (EEST)
To: Grenville Armitage <gja@dnrc.bell-labs.com>
Cc: Francois Le Faucheur <flefauch@cisco.com>, mpls@UU.NET
Subject: ECN Re: Last Call feedback on MPLS-Diff-Serv
In-Reply-To: <3957D29B.C07A40E8@dnrc.bell-labs.com>
References: <200006121753.NAA22286@lir.cisco.com>
	<200006262008.WAA24871@europe.cisco.com>
	<3957D29B.C07A40E8@dnrc.bell-labs.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Grenville Armitage writes:

 >  "The architecture described in this document does not preclude the
 >   signalled or configured use of the EXP bits to support protocols
 >   such as ECN [ECN][MPLS_ECN]. However, techniques for supporting
 >   ECN in an MPLS environment are outside the scope of this document."

i too think that enc should not be part of this document. the above
wording is fine.

-- juha



From owner-mpls@UU.NET  Tue Jun 27 06:45:33 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06400
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 06:45:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivjn19123;
	Tue, 27 Jun 2000 10:45:19 GMT
Received: by mail-control.mail.uu.net 
	id QQivjm11491
	for mpls-outgoing; Tue, 27 Jun 2000 10:44:41 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivjm11482
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 10:44:36 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivjm16939
	for <mpls@uu.net>; Tue, 27 Jun 2000 06:44:27 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivjm18561
	for <mpls@uu.net>; Tue, 27 Jun 2000 10:44:27 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA11516
	for mpls@uu.net; Tue, 27 Jun 2000 06:44:26 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivjm11441
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 10:44:02 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivjm16774
	for <mpls@uu.net>; Tue, 27 Jun 2000 06:44:01 -0400 (EDT)
Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQivjm18369
	for <mpls@uu.net>; Tue, 27 Jun 2000 10:44:01 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06275;
	Tue, 27 Jun 2000 06:44:00 -0400 (EDT)
Message-Id: <200006271044.GAA06275@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-08.txt
Date: Tue, 27 Jun 2000 06:44:00 -0400
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		: LDP Specification
	Author(s)	: L. Andersson,  P. Doolan, N. Feldman,
                          A. Fredette,  B. Thomas 
	Filename	: draft-ietf-mpls-ldp-08.txt
	Pages		: 135
	Date		: 26-Jun-00
	
An overview of Multi Protocol Label Switching (MPLS) is provided in
[FRAMEWORK] and a proposed architecture in [ARCH].  A fundamental
concept in MPLS is that two Label Switching Routers (LSRs) must agree
on the meaning of the labels used to forward traffic between and
through them.  This common understanding is achieved by using a set
of procedures, called a label distribution protocol, by which one LSR
informs another of label bindings it has made.  This document defines
a set of such procedures called LDP (for Label Distribution Protocol)
by which LSRs distribute labels to support MPLS forwarding along
normally routed paths [LDPAPPLIC].

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

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-08.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-08.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:	<20000626112339.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-08.txt

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

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

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Tue Jun 27 07:01:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06867
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 07:01:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivjo26673;
	Tue, 27 Jun 2000 11:01:14 GMT
Received: by mail-control.mail.uu.net 
	id QQivjo14540
	for mpls-outgoing; Tue, 27 Jun 2000 11:00:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivjo14441
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 11:00:37 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivjo24442
	for <mpls@uu.net>; Tue, 27 Jun 2000 07:00:27 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivjo28207
	for <mpls@uu.net>; Tue, 27 Jun 2000 11:00:27 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA12929
	for mpls@uu.net; Tue, 27 Jun 2000 07:00:26 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivjo13043
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 11:00:01 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivjn00917
	for <mpls@UU.NET>; Tue, 27 Jun 2000 06:59:49 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQivjn25576
	for <mpls@UU.NET>; Tue, 27 Jun 2000 10:59:49 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA27455
	for <mpls@UU.NET>; Tue, 27 Jun 2000 04:00:00 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id GAA24149 for <mpls@UU.NET>; Tue, 27 Jun 2000 06:59:48 -0400 (EDT)
Message-Id: <200006271059.GAA24149@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: mpls@UU.NET
Subject: Re: I-D ACTION:draft-ietf-mpls-ldp-08.txt 
In-reply-to: Your message of "Tue, 27 Jun 2000 06:44:00 EDT."
             <200006271044.GAA06275@ietf.org> 
Date: Tue, 27 Jun 2000 06:59:48 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

New draft ldp-08.txt differs from ldp-07.txt only in that it removes
support for 17-bit DLCIs as labels for Frame Relay.

This change was made to address an issue brought up during the recently
concluded LDP last call, and is compatible with the recently posted
draft-ietf-mpls-fr-06.txt (Use of Label Switching on Frame Relay
Networks Specification").

Bob


> 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		: LDP Specification
> 	Author(s)	: L. Andersson,  P. Doolan, N. Feldman,
>                           A. Fredette,  B. Thomas 
> 	Filename	: draft-ietf-mpls-ldp-08.txt
> 	Pages		: 135
> 	Date		: 26-Jun-00
> 	
> An overview of Multi Protocol Label Switching (MPLS) is provided in
> [FRAMEWORK] and a proposed architecture in [ARCH].  A fundamental
> concept in MPLS is that two Label Switching Routers (LSRs) must agree
> on the meaning of the labels used to forward traffic between and
> through them.  This common understanding is achieved by using a set
> of procedures, called a label distribution protocol, by which one LSR
> informs another of label bindings it has made.  This document defines
> a set of such procedures called LDP (for Label Distribution Protocol)
> by which LSRs distribute labels to support MPLS forwarding along
> normally routed paths [LDPAPPLIC].




From owner-mpls@UU.NET  Tue Jun 27 11:35:45 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15745
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 11:35:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivkg29366;
	Tue, 27 Jun 2000 15:35:02 GMT
Received: by mail-control.mail.uu.net 
	id QQivkg02574
	for mpls-outgoing; Tue, 27 Jun 2000 15:34:26 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivkg02567
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 15:34:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivkg18101
	for <mpls@UU.NET>; Tue, 27 Jun 2000 11:34:05 -0400 (EDT)
Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ennovatenetworks.com [208.227.99.254])
	id QQivkg01572
	for <mpls@UU.NET>; Tue, 27 Jun 2000 15:34:05 GMT
Received: from tworster (dhcp168.tst.ennovatenetworks.com [10.1.3.168])
	by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA28693;
	Tue, 27 Jun 2000 11:33:31 -0400 (EDT)
	(envelope-from tom@ennovatenetworks.com)
From: "tom worster" <tom@ennovatenetworks.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
Date: Tue, 27 Jun 2000 11:33:59 -0400
Message-ID: <000701bfe04d$1e188410$a803010a@tst.ennovatenetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B40647@nt-exchange-bby.pmc-sierra.bc.ca>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of 
Shahram Davari

> Bora,
> 
> Could you please identify why/how a node could understand the Diffserv
> object and the E-LSP C-type and still can't support the 
> signaled E-LSP.
> 
> -Shahram 
>
> >From: Bora Akyol [mailto:akyol@pluris.com]
>
      <snip>
> >
> >Why not have another error code for nodes that understand the 
> >DS object but can
> >not provide per-label context. This makes sense to me.


i think bora's suggestion makes sense.

one example that fits: you recently described a method of 
cacheing exp->phb mappings (excerpt from your mail below). the 
method was an example of an lsr design that requires less 
memory in total than one that stores a mapping with each lsp. 
it's probably not worth using that cacheing method unless the 
maximum number of mappings the lsr can cache is designed to be 
smaller than the maximum number of lsps it can simultaneously 
support. if the mapping cache were to be exhausted, the error 
code bora described would be appropriate.

none of the error/status codes defined seem appropriate in
this case: the ds object/tlv was not unexpected; the 
mapping is not invalid; and the phbs are not unsupported.
"cannot provide per-label context" sounds like it would
fit.

another example: for reasons associated with routeing, a 
network may want to keep certain sets of phbs separated 
from each other on different lsps. in such a case, lsrs might 
be configured to not accept certain combinations of phbids 
in an e-lsp ds object/tlv. (i can imagine other reasons to
use similar policies.)

c u
tom



> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram
> Davari
> Sent: Tuesday, June 06, 2000 11:54 AM
> To: 'tom worster'; curtis@avici.com
> Cc: 'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET
> Subject: RE: MPLS Diffserv Extensions related questions/comments 

  <snip>

> Regarding the reduction of per-LSP memory; well it all 
> depends on what you
> are comparing it to. One solution which will reduce the 
> per-LSP memory and
> still uses the signaled EXP->PHB mapping is to build a few 
> general purpose
> EXP->PHB mapping tables (in each LSR), from the first few LSP setup
> messages, and use them as an index in per-LSP ILM/NHLFE 
> tables.  Using this
> method, the amount of per-LSP memory is less than  or equal to your
> proposal.





From owner-mpls@UU.NET  Tue Jun 27 12:11:10 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17108
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 12:11:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivki24329;
	Tue, 27 Jun 2000 16:10:02 GMT
Received: by mail-control.mail.uu.net 
	id QQivki17178
	for mpls-outgoing; Tue, 27 Jun 2000 16:09:27 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivki17135
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 16:09:12 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivki05413
	for <mpls@uu.net>; Tue, 27 Jun 2000 12:08:48 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivki26482
	for <mpls@uu.net>; Tue, 27 Jun 2000 16:08:48 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDJHV>; Tue, 27 Jun 2000 09:15:16 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690813@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "Francois Le Faucheur (E-mail)" <flefauch@cisco.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: Last call comments
Date: Tue, 27 Jun 2000 09:15:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

> Folks,
> 
> 	Here's most of my last call comments.  More may
> be sent out later this evening.

And here they are.   

> 
> 
> SPECIFIC COMMENTS
> =================
> 

	The redefinitions of E-LSP and L-LSP are - as
Grenville has already pointed out (comments 3 & 4)
- not too useful.  If there is a reason for including 
all of this, it would make sense to abstract those 
portions that are repeated in sections 3.1 and 4.1 
(almost all of the text) into a section that specifies 
stuff relating to any kind of DiffServ LSP and just 
list the E-LSP and L-LSP specific stuff in sections 
3.1 and 4.1.  I am not too sure what the authors had
hoped to specify in this text, so I can not be sure 
there is a reason for including it.

	I also agree with Grenville's comments 13 and 14
and add to his first comment that - like the Uniform
model - ECN needs either to be better documented or
not included.  If there were a relatively mature draft
that stated how ECN would be done using the EXT bits,
then it is obvious that this draft would have to address
how its usage of the EXT bits can be coordinated with 
the ECN usage.  As it now is, this section seems to be
trying to establish backward compatibility with some
non-existant function.

Aditional acronyms:

AF		Assured Forwarding
CE		Congestion Experienced (not needed if section 11 is removed)
CLP		Cell Loss Priority
COPS		Common Open Policy Service [ref RFC 2748]
CS		(?)
DE		Discard Eligibility
DF		Default Forwarding (?)
ECN		Explicit Congestion Notification
ECT		(? - not needed if section 11 is removed)
EF		Expedited Forwarding
SNMP		Simple Network Management Protocol

> 
> NITS
> ====
> 

toward top of page 36, "An RSVP router that does
recognizes the DIFFSERV ..." should be changed to
"... that does recognize ...".  You might also 
change "RSVP router" to "LSR" since "RSVP" is 
implied by the sectional context.

several more occurences of 'eg.' (search and 
replace?)...

> 
> 


From owner-mpls@UU.NET  Tue Jun 27 12:42:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17957
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 12:42:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivkk16289;
	Tue, 27 Jun 2000 16:41:10 GMT
Received: by mail-control.mail.uu.net 
	id QQivkk20630
	for mpls-outgoing; Tue, 27 Jun 2000 16:40:46 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivkk20622
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 16:40:41 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivkk22769
	for <mpls@UU.NET>; Tue, 27 Jun 2000 12:40:29 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivkk19514
	for <mpls@UU.NET>; Tue, 27 Jun 2000 16:40:29 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDJKL>; Tue, 27 Jun 2000 09:46:57 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690814@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Puneet Agarwal'"
	 <puneet@pluris.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Cc: Eric Gray <EGray@zaffire.com>
Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
Date: Tue, 27 Jun 2000 09:46:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

	Thanks for the helpful pointers.

	Could you please explain how 1) the egress would
signal to the penultimate hop that it needs to do multiple
pops or 2) how the penultimate hop would be able to do it
on its own (given that it is not supposed to look at the
rest of the packet having popped one label)?  Has someone
secretly allocated the special label values '4' to mean
implicit NULL/PHP twice, '5' to mean implicit NULL/PHP
three times, and so on?  PHP is architecturally a signaled
- as opposed to a local - behavior.

	Also, see comments in line...

--
Eric Gray

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Monday, June 26, 2000 11:42 AM
> To: 'Puneet Agarwal'; 'mpls@uu.net'
> Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
> 
> 
> Puneet,
> 
> Please see my comments:
> 
> >-----Original Message-----
> >From: Puneet Agarwal [mailto:puneet@pluris.com]
> >Sent: Friday, June 23, 2000 8:38 PM
> >To: 'mpls@uu.net'
> >Subject: draft-ietf-mpls-diff-ext-05.txt comments
> >
> >
> >1) The draft needs to detail the usage of hierarchical tunnel (HT)
> >especially in the case of PHP. 
> >
> >For PHP and HT to work for diffserv/MPLS the Penultimate LSR 
> >needs to know the PHB -> EXP mapping of the underlying 
> >encapsulated tunnels. Moreover, if a LSP is carrying multiple 
> >LSPs with different PHB-> EXP mapping, the penultimate LSR 
> >and even the egress LSR (in case of no PHP) would need to 
> >determine (after Pop), the type of the underlying LSP.
> >
> >Another example to illustrate this complexity:
> >Consider the case when a L-LSP is sent over a prior established 
> >E-LSP. the Penultimate LSR for the E-LSP has no knowledge of 
> >tunnels that are hierarchically going through it. Hence when it 
> >does the penultimate POP, it has no knowledge about the PHB->EXP 
> >encoding for the underlying L-LSP.
> >In order to do this correctly, one would need to maintain 
> >additional state associated with the outer E-LSP in order to do 
> >the correct PHB-> EXP map for the encapsulated L-LSP.
> 
> Not necessarily. This restriction applies only to Uniform 
> model. In case of Pipe model, the PHP does not need to know 
> anything about lower LSP, it just pops and forwards the 
> packet without modifying the lower label.
> 
> The case of Uniform model is already mentioned in section 2.6.6:
> 
> "- when the multiple pop operations are performed by the 
> Penultimate LSR, note that to perform Encoding of Diff-Serv       
> Information, the Penultimate LSR needs to be aware of the 
> "Set of PHB-->Encaps mappings" for the label corresponding 
> to the exposed header after all the pop operations (or the 
> PHB-->DSCP mapping). Methods for providing this mapping 
> awareness are outside the scope of this specification."

As stated in my last call comments, the above text makes no
sense and should be removed.  Multi-pop PHP is a non-starter.

> 
> And section 2.6.3:
> 
> "Note that to do so, the Penultimate LSR needs to be aware 
> of the "Set of PHB-->Encaps mappings" for the label 
> corresponding to the exposed header (or the PHB-->DSCP 
> mapping). Methods for providing this mapping awareness are 
> outside the scope of this specification."

I don't think that you can punt on this one.  The specific
example that you yourself gave for when the Uniform model
is useful involved a usage of LSP tunnels in which DiffServ
and the LSP Tunnel usage were orthogonal.  In this case, the
mapping is presumably 'simple identity' (i.e. - within the 
same administrative domain, the PHB is likely to be 'uniform' 
throughout the administrative domain; therefore PHB-p maps to
PHB-q if and only if PHB-p = PHB-q).

No one has proposed an application for the Uniform model in
which this would not be the case.  In addition, the intuitive
meaning of 'Uniform' implies this behavior.  Therefore, not
stating this simplistic relationship leaves too many options
available to the implementer and will most likely lead to a
lot of interoperability problems.

> 
> The type of LSP is implicit in the PHB -> Encaps mapping. And 
> the Egress LSR must know the mapping regardless of the type of 
> the LSP.
> 
  ... <snip> ...
> 
> And Section 2.6.6:
> 
> "LSRs at different levels of LSPs are expected to operate in 
> the same or in different Tunneling Models."

This specific statement is also mentioned in my last call
comments.  Its informational content is dubious at best,
being analogous to "an orange is either the same as an apple
or different".

> 
  ... <snip> ...
> 
> Regards,
> -Shahram
> 
> >
> >-Puneet
> >
> 


From owner-mpls@UU.NET  Tue Jun 27 13:18:39 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18629
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 13:18:39 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivkn11032;
	Tue, 27 Jun 2000 17:17:57 GMT
Received: by mail-control.mail.uu.net 
	id QQivkn05465
	for mpls-outgoing; Tue, 27 Jun 2000 17:17:30 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivkn05458
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 17:17:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivkn12812
	for <mpls@uu.net>; Tue, 27 Jun 2000 13:17:17 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivkn14723
	for <mpls@uu.net>; Tue, 27 Jun 2000 17:17:16 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA25903
	for mpls@uu.net; Tue, 27 Jun 2000 13:17:15 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivkn05423
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 17:16:57 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivkn07045
	for <mpls@UU.NET>; Tue, 27 Jun 2000 13:16:49 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQivkn14409
	for <mpls@UU.NET>; Tue, 27 Jun 2000 17:16:49 GMT
Received: from pluris.com (root@lightning.pluris.com [172.16.55.100])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA08396;
	Tue, 27 Jun 2000 10:16:31 -0700 (PDT)
Message-ID: <3958E16F.A65DCA65@pluris.com>
Date: Tue, 27 Jun 2000 10:16:31 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Juha Heinanen <jh@lohi.eng.telia.fi>
CC: Grenville Armitage <gja@dnrc.bell-labs.com>,
        Francois Le Faucheur <flefauch@cisco.com>, mpls@UU.NET
Subject: Re: ECN Re: Last Call feedback on MPLS-Diff-Serv
References: <200006121753.NAA22286@lir.cisco.com>
		<200006262008.WAA24871@europe.cisco.com>
		<3957D29B.C07A40E8@dnrc.bell-labs.com> <14680.17578.442593.697375@lohi.eng.telia.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Juha

Tell us something we did not know already. You are a co-author of this
document, so unless section 11 went in there without you looking, you must
have approved of it ;-)

Bora


Juha Heinanen wrote:

> Grenville Armitage writes:
>
>  >  "The architecture described in this document does not preclude the
>  >   signalled or configured use of the EXP bits to support protocols
>  >   such as ECN [ECN][MPLS_ECN]. However, techniques for supporting
>  >   ECN in an MPLS environment are outside the scope of this document."
>
> i too think that enc should not be part of this document. the above
> wording is fine.
>
> -- juha




From owner-mpls@UU.NET  Tue Jun 27 13:33:44 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18967
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 13:33:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivko26193;
	Tue, 27 Jun 2000 17:33:04 GMT
Received: by mail-control.mail.uu.net 
	id QQivko07189
	for mpls-outgoing; Tue, 27 Jun 2000 17:32:38 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivko07179
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 17:32:31 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivko09873
	for <mpls@uu.net>; Tue, 27 Jun 2000 13:32:18 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivko25561
	for <mpls@uu.net>; Tue, 27 Jun 2000 17:32:18 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA28345
	for mpls@uu.net; Tue, 27 Jun 2000 13:32:17 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivko07121
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 17:31:49 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivko21038
	for <mpls@UU.NET>; Tue, 27 Jun 2000 13:31:45 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQivko25139
	for <mpls@UU.NET>; Tue, 27 Jun 2000 17:31:44 GMT
Received: from pluris.com (root@lightning.pluris.com [172.16.55.100])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA09124;
	Tue, 27 Jun 2000 10:31:42 -0700 (PDT)
Message-ID: <3958E4FD.4638D804@pluris.com>
Date: Tue, 27 Jun 2000 10:31:41 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Juha Heinanen <jh@lohi.eng.telia.fi>, mpls@UU.NET
Subject: Re: ECN Re: Last Call feedback on MPLS-Diff-Serv
References: <200006121753.NAA22286@lir.cisco.com>
			<200006262008.WAA24871@europe.cisco.com>
			<3957D29B.C07A40E8@dnrc.bell-labs.com> <14680.17578.442593.697375@lohi.eng.telia.fi> <3958E16F.A65DCA65@pluris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

My apologies.

I take my comment back, I read it way too quickly (and missed the "not" in
Juha's statement) and was punchy at the keyboard. I guess need more coffee
this morning.

Again, my apologies to both Juha and the MPLS WG,

Overall, I think the ECN part of this draft detracts from the main focus of
this draft, I think Greenville's statement in an earlier email should suffice.
If the other authors would like to submit another ID that addresses the full
scope of ECN, I would fully support this.

Bora

Bora Akyol wrote:

> Juha
>
> Tell us something we did not know already. You are a co-author of this
> document, so unless section 11 went in there without you looking, you must
> have approved of it ;-)
>
> Bora
>
> Juha Heinanen wrote:
>
> > Grenville Armitage writes:
> >
> >  >  "The architecture described in this document does not preclude the
> >  >   signalled or configured use of the EXP bits to support protocols
> >  >   such as ECN [ECN][MPLS_ECN]. However, techniques for supporting
> >  >   ECN in an MPLS environment are outside the scope of this document."
> >
> > i too think that enc should not be part of this document. the above
> > wording is fine.
> >
> > -- juha




From owner-mpls@UU.NET  Tue Jun 27 13:52:41 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19175
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 13:52:38 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivkp06259;
	Tue, 27 Jun 2000 17:52:10 GMT
Received: by mail-control.mail.uu.net 
	id QQivkp09292
	for mpls-outgoing; Tue, 27 Jun 2000 17:51:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivkp09284
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 17:51:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivkp02013
	for <mpls@uu.net>; Tue, 27 Jun 2000 13:51:09 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivkp09322
	for <mpls@uu.net>; Tue, 27 Jun 2000 17:51:08 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA01536
	for mpls@uu.net; Tue, 27 Jun 2000 13:51:08 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivkp09136
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 17:50:51 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivkp13262
	for <mpls@UU.NET>; Tue, 27 Jun 2000 13:50:07 -0400 (EDT)
Received: from lohi.eng.telia.fi by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.telia.fi [195.10.149.18])
	id QQivkp04660
	for <mpls@UU.NET>; Tue, 27 Jun 2000 17:50:06 GMT
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-21) id UAA30127;
	Tue, 27 Jun 2000 20:50:02 +0300
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14680.59722.658665.541185@lohi.eng.telia.fi>
Date: Tue, 27 Jun 2000 20:50:02 +0300 (EEST)
To: Bora Akyol <akyol@pluris.com>
Cc: Grenville Armitage <gja@dnrc.bell-labs.com>,
        Francois Le Faucheur <flefauch@cisco.com>, mpls@UU.NET
Subject: Re: ECN Re: Last Call feedback on MPLS-Diff-Serv
In-Reply-To: <3958E16F.A65DCA65@pluris.com>
References: <200006121753.NAA22286@lir.cisco.com>
	<200006262008.WAA24871@europe.cisco.com>
	<3957D29B.C07A40E8@dnrc.bell-labs.com>
	<14680.17578.442593.697375@lohi.eng.telia.fi>
	<3958E16F.A65DCA65@pluris.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bora Akyol writes:

 > Tell us something we did not know already. You are a co-author of this
 > document, so unless section 11 went in there without you looking, you must
 > have approved of it ;-)

there are many things in the i-d that i have not "approved".  i'm
only one of many authors and don't think i have veto rights.  

in addition to the ecn stuff, i, for example, didn't think that we need
more than one kind of lsps and i didn't like the new terms mode terms,
but would have prefered the already existing terms network and service
interworking.

-- juha



From owner-mpls@UU.NET  Tue Jun 27 17:22:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25047
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 17:22:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivld10804;
	Tue, 27 Jun 2000 21:22:20 GMT
Received: by mail-control.mail.uu.net 
	id QQivld10031
	for mpls-outgoing; Tue, 27 Jun 2000 21:21:45 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivld10021
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 21:21:44 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivld24508
	for <mpls@uu.net>; Tue, 27 Jun 2000 17:21:33 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivld02438
	for <mpls@uu.net>; Tue, 27 Jun 2000 21:21:32 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA01994
	for mpls@uu.net; Tue, 27 Jun 2000 17:21:31 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivld09914
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 21:21:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivld24329
	for <mpls@UU.NET>; Tue, 27 Jun 2000 17:20:47 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQivld01829
	for <mpls@UU.NET>; Tue, 27 Jun 2000 21:20:47 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA07584;
	Tue, 27 Jun 2000 14:20:45 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <NCLJAKN0>; Tue, 27 Jun 2000 14:21:56 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40651@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric Gray'" <EGray@zaffire.com>,
        "MPLS Mailing List (E-mail)"
	 <mpls@UU.NET>
Subject: RE: Last call comments
Date: Tue, 27 Jun 2000 14:21:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Eric,

I will leave most of the editorial changes to Francois:

>-----Original Message-----
>From: Eric Gray [mailto:EGray@zaffire.com]
>Sent: Monday, June 26, 2000 8:30 PM
>To: MPLS Mailing List (E-mail)
>Subject: Last call comments
>
>
>Folks,
>
>	Here's most of my last call comments.  More may
>be sent out later this evening...
>
>IN GENERAL
>==========
>
>	Many aspects of this draft - especially those
>relating to E-LSPs and L-LSPs and the Pipe Model
>seem intuitive and very useful.
>
>	There are several aspects of the uniform model
>which appear complex beyond any justification I have
>seen for specifying this model.
>
>	There are concepts that have been introduced
>almost completely without explanation.  An amazing
>example is the concept of the multi-pop PHP that
>comes up in section 2.6.6.
>
>	The draft punts on several relevant issues.  In
>particular, there seems to be no effort to justify 
>some of the complexity in the specification in terms 
>of real world applications for particularly difficult
>combinations (such as the combination of Uniform model 
>and PHP).  If the uniform model is intended for the
>purpose stated by Shahram Davari (23 March, 2000), then
>it would be useful to state that an example of when it
>might be useful is when multiple tunnel hierarchy levels
>are within the same administrative domain.
>
>	There are far too many murky statements for the
>specification to be useful in producing interoperable
>implementations.  For example, from mid-page on page
>18:
>
>   "(1) Tunneling Model 1 (either Uniform or Pipe)
>
>   "(2) Tunneling Model 2 (same as Tunneling Model 1 or 
>different Model)"

This is a useful statement. We just need to change the wording. For example
to:

  "(1) Tunneling level 1 (either Uniform or Pipe)

  "(2) Tunneling level 2 (either Uniform or Pipe)"

Do you see anything wrong with this new wording?


>Or at the bottom of page 16, top of page 17:
>
>   "LSRs at different levels of LSPs are expected to operate 
>in the same 
>    or in different Tunneling Models."
>
>I believe these may be examples of an earlier comment 
>on mixing of example deployments and normative text.
>

This is actually a normative text. Let me re-write it and see if you agree:

"It is not necessary for the LSRs at different levels of LSPs to operate in
the same tunneling mode".


>	The statement that other models (besides Pipe 
>and Uniform) may be supported makes me wonder why an
>attempt is made to support the Uniform model (it may
>be that the draft punts too late on this issue, rather
>than to early on issues that derive from the Uniform
>model).

>	There are many repeat definitions of Acronyms
>(places where the expanded version is followed by the
>Acronym in parentheses).  This makes the draft look 
>as if it was glued together from many pieces.  Either
>the acronyms should be collected, or only the first 
>instance should show both.  Currently, there are many
>cases where the acronym is first used before being 
>defined.

There are many new concepts in this draft, that are not published in any
document before. Besides this is a large document, and finding the  first
instance of an acronym is not easy. I don't see any harm in writing the
expanded version, if it makes reading the text easier. However, this is an
editorial issue and if others object, we can easily remove the expanded
versions.

Could you please clearly identify the acronyms that are use before being
introduced. That way we could correct them.

>
>	I agree with the earlier posted comment that the
>draft is excessively wordy.  It includes quotations of
>large amounts of text from other drafts which are not 
>necessary, it has a lot of redundancy and it looks as
>if it has been cobbled together incompletely from the
>work of several people.  The content is too important 
>to be so hard to read.\

Eric, we are dealing with many combinations and options and modes in this
draft which require stating the precise operation in each case. We have
signaled E-LSP, configured E-LSP, L-LSP, Pipe model, uniform model, with
PHP, without PHP, ATM, FR, PPP, error handling, ...

If we want to remove all the redundancies, then we are left with a mesh of
interconnected text. A reader which for example is interested in L-LSP with
PHP in pipe model in PPP will need to go so many times back and forth in the
document that will probably be confused. This is a potential for
interoperability problem. 

So although it may add to the volume of the draft, but I think it makes
reading the text much easier.

>
>SPECIFIC COMMENTS
>=================
>
>	The first paragraph in the introduction implies
>that the same label is used at each hop.  Last sentence 
>should read something like "At each LSR along the LSP, 
>the label is used to label-swap and forward the packet 
>to the next hop."

Fine.


>
>	Why the 4+ line quote from [DIFF_HEADER] at the 
>bottom of page 2, instead of simple stating the need to 
>provide flexibility for service providers?

>	Section 1.6 - can signaled bandwidth also be used 
>for policing packets associated with a PSC?  How does an
>implementation know if it is supposed to use signaled
>bandwidth to perform any of the functions mentioned in
>this section (adjusting scheduling weights, admission
>control and, possibly, policing)?

Signaled BW can potentially be used for all of the above. The way to
identify which one, and how, is out of the scope of this document (New
extensions to signaling may be required). All we have tried to do is to not
preclude BW signaling in MPLS+Diffserv operations the way that CoS object
did), that is all. If you like we can write that the details are outside the
scope of this document. 

>
>	In section 2.1, this statement:
>
>  "Obviously, to enforce the Diff-Serv service differentiation the LSR
>   MUST also apply the forwarding treatment corresponding to the
>   Outgoing PHB."
>
>makes no sense, given that - in the bullets that precede
>it - determination of the outgoing PHB is optional.  The
>bullet - based on following text - should say something to
>the effect that determination of a change in outgoing PHB
>is optional.
>

Off course determining the outgoing PHB is mandatory. The optional part is
determining it through local policy and traffic conditioning. How about this
new wording for the 2nd bullet:

 - Outgoing PHB Determination, which may be a copy of the incoming PHB or
may be via optional Local Policy and Traffic Conditioning (B).


>	At the bottom of page 6, the two statements:
>
>  "(*) when the LSR performs label imposition, the incoming packet is
>   received unlabelled.
>
>  "(**) when the LSR performs label disposition, the outgoing packet is
>   transmitted unlabelled."
>
>are only true if no label stacking occurs.  It may be that 
>you are just talking about the (rather difficult to follow)
>figure, but it would be better (and more general) if you
>use the common terms "ingress" and "egress" rather than the
>terms "label imposition" and "label disposition" and simply
>replace these lines with:
>
>   "(*) ingress
>
>   "(**) egress"

>	Section 2.3 says that determination of outgoing PHB is 
>optional yet goes on to say that the default is that outgoing
>PHB is identical to incoming PHB.  This would be clearer if
>it simply states that the determination is always done and 
>the default 'determination' is that the outgoing is the same
>as the incoming (this corresponds to the default "local
>policy").

Sam as above. We will clarify.

>
>	Why the 8 line quote from [MPLS_ARCH] (toward bottom
>of page 8)?  Simply change the next paragraph to read:
>
>   "This specification allows that an incoming label ..."
>
>	Same question/observation for the quote at the bottom
>of page 9 and top of page 10.
>
>	The statement "Based on these considerations ..." in
>the last paragraph of section 2.6.2 seems to be a non-sequitur
>- I cannot see the connection between the "considerations"
>and the conclusion.  For one thing, it seems almost to conclude
>that - because there is PHP in MPLS, and this makes it hard to
>determine what the EXP field was at the egress, then the uniform
>model (which makes it necessary to recover this information) is
>justified.
>

May be we should say "based on these observations...".
But I can't understand why you can't see any connection between the first 3
bullets and the conclusion? In the first 3 bullets We have shown that from
the Diffserv perspective an MPLS tunnel basically is a tunnel, very similar
to IP tunnel. So for Diffserv purpose we can use the same tunneling modes as
the IP tunnel.

>	I believe that the uniform model should receive the same
>treatment as "other models" - i.e. - it should be treated as out
>of scope.  This removes a lot of seeming unjustified complexity 
>and about two pages of text.

Why? What would you do if you hadn't had MPLS? the Diffserv operation in
Uniform model is exactly identical to Diffserv over non-MPLS network. Do you
also think that we should remove the support of Diffserv transiting non-MPLS
networks?  

>
>	In section 2.6.6 - there are bullets that talk about 
>multi-pop PHP.  Currently, there is no standard way to signal 
>this - nor is it reasonable to establish one.  The supposed
>intent for PHP was to avoid pop-and-look-again behavior in an
>egress LSR.  PHP does not currently require the penultimate
>LSR to look at the label it has exposed by popping the label
>stack  - so it has no means to determine that it needs to do
>a second (or subsequent) pop, even if it is otherwise capable
>of performing a pop-and-look-again.  These bullets should be
>removed. (I'm pretty sure that there is no other MPLS draft 
>that refers to the ability to pop multiple labels as a single 
>atomic operation - even at the egress LSR - even though an LSR
>implementation can obviously be made to do this.)
>
>	The draft needs a list of acronyms and/or a glossary.  
>The acronyms used (and, in some cases, introduced) in this 
>draft include:
>
>BA		Behavior Aggregates
>DSCP		Differentiated Services Code Point
>EXP		EXPerimental (bits)
>E-LSP		EXP-Inferred-PSC LSP
>FEC		Forwarding Equivalency Class
>FTN		FEC-To-NHLFE Map
>ILM		Incoming Label Map
>LSP		Label Switched Path
>LSR		Label Switch Router
>L-LSP		Label-Only-Inferred-PSC LSP
>MPLS		Multi-Protocol Label Switching
>NHLFE		Next Hop Label Forwarding Entry
>OA		Ordered Aggregate
>PHB		Per Hop Behavior
>PSC		PHB Scheduling Class
>
>(Punting on this - as seems to be the current approach
> is just messy :-)
>
>In addition, the following definitions would be useful
>(collected in a glossary?):
>
>Behavior Aggregate
>		Packets crossing a link that require
>		the same Diff-Serv behavior.
>Diff-Serv	Differentiated Services.
>Diff-Serv Context
>		<Insert Definition HERE>
>FEC		<Insert Definition HERE>
>Ordered Aggregate
>		Set of Behavior Aggregates sharing an 
>		ordering constraint.
>PHB Scheduling Class
>		Set of PHBs applicable to an Ordered 
>		Aggregate.
>
>
>
>NITS
>====
>
>top of page 3 'eg.' should be 'e.g.' (two cases in the 
>first paragraph on this page).  Same for top of page 4
>(3 occurrences).
>
>first paragraph in section 2.1, last sentence - can't
>quite figure out what you're saying.  Suggested rewording
>is:
>
>"... the way to determine the PHB to be applied to a
> received packet and to encode the PHB into a transmitted 
> packet is different than for a non-MPLS Diff-Serv Router."
>                     --------
>

Thanks,

-Shahram



From owner-mpls@UU.NET  Tue Jun 27 17:26:07 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25131
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 17:26:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivld13281;
	Tue, 27 Jun 2000 21:25:46 GMT
Received: by mail-control.mail.uu.net 
	id QQivld10435
	for mpls-outgoing; Tue, 27 Jun 2000 21:25:02 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivld10406
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 21:24:53 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivld24866
	for <mpls@UU.NET>; Tue, 27 Jun 2000 17:24:40 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivld04158
	for <mpls@UU.NET>; Tue, 27 Jun 2000 21:24:24 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDKB2>; Tue, 27 Jun 2000 14:30:53 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269081E@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Francois Le Faucheur'" <flefauch@cisco.com>, gja@dnrc.bell-labs.com
Cc: mpls@UU.NET
Subject: RE: Last Call feedback on MPLS-Diff-Serv
Date: Tue, 27 Jun 2000 14:30:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Francois,

	I doubt that characterizing Grenville's comments
as mainly editorial is entirely accurate. :-)

	See replies below.

> -----Original Message-----
> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> Sent: Monday, June 26, 2000 1:06 PM
> To: gja@dnrc.bell-labs.com
> Cc: mpls@UU.NET
> Subject: Re: Last Call feedback on MPLS-Diff-Serv
> 
> 
> Grenville,
> 
> Thanks for your comments. Since those comments are mainly 
> editorials, we should be able to resolve them reasonably quickly.
> Let me jumpt straight to the specific suggestions
> 
> At 01:26 26/06/2000 -0700, Grenville Armitage wrote:
> [clip]
> >
> >******** Specific recommendations:
> >
> >#1 Remove section 11.
> >
> >   This can quite reasonably become another document discussing
> >   experimental ways in which the EXP bits can be used to support
> >   what even the current text admits is an experimental RFC.
> >   It has no place in a normative spec relating MPLS and Diffserv,
> >   and ought to be removed.
> >
> 
> It has been useful and necessary for the WG to understand how 
> ECN could share the EXP space with ECN (should ECN be 
> required in the future), in order to progress with Diff-Serv 
> over MPLS support. It seems appropriate to me to also reflect 
> some of this in the Diff-Serv draft. If we had come up with a 
> Diff-Serv solution that was incompatible with ECN, I think it 
> woudl be useful for that document to say so. It turns out we 
> feel that ECN and Diff-Serv could coexist and that the impact 
> on the Diff-Serv over MPLS solution are reasonable. We might 
> have tried to be too specific in the current text 
> (considering the early stage of ECN over MPLS) but I think 
> some description of why the current Diff-Serv solution does 
> not preclude ECN and how those could share EXP space is 
> useful information.
> 
> I'd like to hear other opionions.

Okay.  Here's my opinion (assume the usual disclaimer).

I agree with you that - if there was a standard (or even a
reasonably mature draft of a standard) approach for using
one or more of the EXP bits for ECN - then MPLS-DiffServ 
would need to either state that the two usages are mutually
exclusive, or specify how they work together.

As I recall, however, the draft on this subject was not too
well received and the authors have not had sufficient time
and/or interest to re-fresh it on the ftp server.  Note that
I am not opposed to the idea, but I have issues with the way
in which it seems to keep cropping up in unexpected ways.

I'm not convinced that there's anything sneaky going on with
this.  In fact, I'm fairly convinced that there is not.  But
the track record for this work does not look good.  Luckily,
I'm a naive sort of person who believes in happy acidents and
overwhelming coincidence. :-)

First, the draft was misnamed - making it appear as if it 
had already been accepted as a working group draft.  Most
likely this was a simple slip up.  This was brought up as
an issue after the Oslo meeting.

Then it was added to the MPLS working group Internet drafts 
web page as a working group draft - in spite of the fact it 
was very definitely NOT accepted as such after the Oslo 
meeting.  This was, I believe - a result of the combination 
of automated web-page production tools and the first unhappy 
misnaming accident.  This was pointed out at the Washington 
meeting.

Then it took several months to correct the web page list to
reflect the fact that this draft was not accepted by the WG.
This delay was certainly impacted by the well-known backlog 
on the ID queue as well as work loads elsewhere.  The draft 
was removed from the MPLS working group drafts site at about
the same time as it expired.

Now it seems as if ECN has been tacked onto the DiffServ draft
like a pork-barrel rider on a congressional appropriations bill.
It's a fortunate thing that my basic naivete is pretty robust.

Since there is no available work on MPLS-ECN, including it
in this draft seems an awful lot like an attempt to boot
strap such work.  This might not be a bad thing, but it 
would definitely be an out-of-scope activity for a standard's 
track document on DiffServ support in MPLS.

Now, you've heard another opinion.

  ... <snip> ...

> 
> >
> >#5 Vastly simplify sections 2.6.3 and 2.6.4 (tunnel models)
> >
> >   The last paragraph of 2.6.4 admits that basically the only
> >   difference between the Uniform and Pipe models is in the
> >   push/pop behaviors. At the very least 2.6.4 can be vastly
> >   simplified by simply specifying the 'Pipe Model' in terms
> >   of how it differs from the 'Uniform Model' in 2.6.3 (right
> >   now 2.6.4 contains a load of redundant descriptive text).
> >
> 
> Yes, as pointed out in the draft, the two models "only" 
> differ in their push and pop behaviours. But the push and pop 
>  behaviours (with/without PHP) are the complex aspects 
> discussed in a big part of the text anyway (the swap behavior 
> is quite straight-forward in both models). So , saying they 
> "only" differ by push/pop doesn't mean that you would save 
> that much text by describing operations of Pipe as delta over 
> Uniform.

Alternatively, the Uniform model could be treated as yet 
another example of "other models" - i.e. - out of scope.

> 
> However, we could simplify 2.6.3 by combining the 2nd 
> paragraph ("With this Uniform Model:...") with the last 
> paragraph ("For support of the Uniform Model over an LSP ...").
> Similarly we could simplify 2.6.4 by combining the 3rd 
> paragraph ("With this Pipe Model: ...") with the two 
> paragraphs before last ("For support of the Pipe Model over 
> an LSP..."). 
> 

  ... <snip> ...

> 
> >
> >#7 Clarify 2.6.5
> >
> >   Section 2.6.5's last sentence attempts to be normative about
> >   something it simultaneously declares out of scope for this
> >   document. Please clarify, reduce, or remove this section 
> 
> We can get rid of the word "may" of the last sentence so that 
> it reads:
> "Models beyond the Uniform Model and the Pipe Model are 
> outside the scope of this specification but are not precluded 
> by this specification".
> 
> >(the
> >   essence can be stated somewhere earlier in section 2 anyway).
> >

I looked through the mail archive and was not able
to determine the reason why it was felt to be very
important to include a separate model.  It seems to
me that the entire concept can be captured by very
simply stating something like this:

   "When a label is popped off of the label stack,
    the value in the EXP bits field may either be
    copied (or otherwise derived) from the EXP bits 
    field in the label being removed, or left as is.  
    Copying (or otherwise deriving) the value from 
    the label popped to the newly exposed label may 
    result in changing the value of those bits that 
    existed previously.  This could make sense, for
    example, if the LSPs corresponding to the two 
    labels are both within the same DiffServ domain.

   "Deriving the EXP bits value in the newly exposed
    label from the EXP bits in the popped label has
    implications on PHP behavior.  Specifics of these
    implications and mechanisms for deriving the EXP
    bit values in this case are out of scope for this
    document."

Note that you cannot mandate that an LSR performing 
PHP MUST be able to perform such a mapping if you do
not specify how such a mapping MAY be done.  

	With the above two paragraphs, you can delete 
all references to two models (Pipe and Uniform) and
all text dealing with 'differences' between them.

	Let's try not to make this tougher than it is.

> 
> I woudl find it difficult to summarise something that 
> explains that there could be other models, give a potential 
> example of such other models and clarify it is outside the 
> scope of this spec in less than 3 sentences. So I propose to 
> leave it as it is.
> 
> >#8 Rationalize sections 3 and 4
> >
> >   Most of the processing steps are equivalent whether we are
> >   discussing an E-LSP or L-LSP, so there's very little
> >   reason to have two sections repeating much of each other.
> >   (E.g. for filling out things like Encaps<->PHB mappings the
> >    rules for E-LSPs are essentially a subset of those for L-LSPs,
> >    sections 3.5 and 4.5 are practically identical,
> >    section 3.3 is a subset of 4.3, etc...)
> 
> >  (Indeed, these two sections could probably be
> >   beneficially collapsed into one section.)
> 
> I am not sure what you are calling the "two sections" (ie 3 
> and 4 , or 3.5 and 4.5)
> 
> Although the descriptions of E-LSPs and L-LSPs have a number 
> of things in common, they have a lot of differences:
> 	- 3.2 and 4.2 are completely differnet. 3.2 uses 
> preconfigured/signaled mappings applying on EXP only, 4.2 
> uses MAndatory/Default mappings applying to EXP/CLP/DE.
> 	- 3.4 and 4.4 are very differnet. 3.4 must have a 
> PHB-->EXP mapping  while 4.4 may or may not have a PHB-->EXP 
> mapping. 3.4 uses configured signaled mapping to populate it. 
> 4.4 uses Mandatory mapping. 4.4 needs to cover the cases  of 
> LC-ATM and LC-FR while 3.4 shoudl not. 4.4.4 is the same as 
> 3.4.4 and already use a refernec to 3.4.4.1.
> So section 3 and section 4 could not be collapsed together.
> 
> 3.3 is indeeed a subset of 4.3, but 3.3 already boils down to 
> a single paragraph so I am not sure we would gain much by 
> replacing that with a cross-reference. Also you might have to 
> clarify that only a subset of the cases are relevant to 
> E-LSPs to avoid confusion. So there is not much to be gained there.
> 
> 3.5 and 4.5 are the only ones that could usefully be 
> combined. With very minor editing around, 4.5 could be 
> replaced by a reference to 3.5. 
> 
> >   A lot of the wording in both sections ought to be tightened
> >   up significantly to focus primarily on the normative
> >   statements. 
> >
> 
> Could you provide specific suggestions? or at least point us 
> towards the issues you see?
> 
> 
> >#9 Preconfigured E-LSP EXP<->PHB mapping?
> >
> >   Section 3.2.1 talks about a preconfigured EXP<->PHB mapping
> >   but does not suggest a default. I think the document ought to
> >   specify an actual default for EXP 000 to map to Best Effort PHB
> >   (or set of defaults where *all* EXP values map to BE).
> >
> 
> The Network Adminsitrator is expected to configure the 
> "preconfigured EXP<->PHB mapping" depending on the BAs that 
> are actually used in his/her network. Since differenet 
> Network Administrators are likely to run differnet subsets of 
> BAs it is difficult to define a Default mapping that would be 
> generally useful. But I guess you are saying , it would be 
> useful to have a default mapping in case the preconfigured 
> mapping hasn't been configured at all by the Network 
> Adminsitrator. Right?
> In that case, I suppose I woudl also map all EXP values towards BE. 
> 
> Anyone else has thoughts on that?
> 
> >#10 Why is section 7 here?
> >
> >  Section 7 repeats material that is redundant for a reader who
> >  gets this far into the document. Clearly the mechanisms for
> >  handling MPLS over PPP are documented elsewhere, and this
> >  document has already stated how various Encaps<->PHB mappings
> >  are built for E- and L-LSPs. Section 7 ought to be removed,
> >  perhaps to an informational/applicability document.
> 
> Section 7 is NOT redundant. It specifies , out of all the 
> previously defined options, which ones are MUST and which 
> ones are MAY for PPP interfaces. Unless you specify that you 
> may have one implemnetation supporting one option and another 
> implementation supporting another option which prevents 
> actual interoperability.
> 
> We could put that text into a separate applicability 
> document, but I don't see the point of doing this. What we 
> have in there has been proposed and agreed for a while, and I 
> think it is really required to achieve interoperability so 
> that it belongs in this document.
> 
> >
> >#11 Why are sections 8 and 9 here?
> >
> >  Sections 8&9 suffer the same question of focus as section 7.
> >  How an ATM or FR interface operates is pretty much covered by
> >  existing MPLS documents - excluding perhaps the recommendation
> >  to use EPD for ATM, I dont see sections 8&9 adding anything
> >  normative to what has already been stated earlier in the document.
> >  They ought to follow section 7 into another document (or oblivion).
> >
> 
> Same as above, these sections clarify which of the various 
> options are applicable to these media.
> Also it clarifies media specific issues which have come up 
> during the WG progress (eg that the requirement is for ATM 
> LSRs to support PHB scheduling rather than "traditional" ATM 
> scheduling, that only two drop levels are supported , that 
> EPD is a good idea, that the spec only covers the case where 
> the shim layer is used...)
> 
> I believe this is useful information and should be kept.
> 
> >#12 Why is section 10 here?
> >
> >   Again, as with section 7 there's an issue of focus here.
> >   No new normative text exists here, and it is at best a subset
> >   of section 7 anyway.
> >
> 
> 
> Section 10 is NOT redundant. It specifies , out of all the 
> previously defined options, which ones are MUST and which 
> ones are MAY for LAN interfaces. Unless you specify that, you 
> may have one implemnetation supporting one option and another 
> implementation supporting another option which prevents 
> actual interoperability.
> 
> We could easily group it with section 7 though.
> 
> 
> >#13 Remove references to PIM as a label distribution mechanism
> >
> >   In sections 3.1 and 4.1 the last paragraph speaks about MPLS using
> >   a variety of label distribution mechanisms, including PIM.
> >   The reference to PIM should be removed (unless there's a citeable
> >   *working group* document I'm unaware of for using PIM in this
> >   manner).
> >  
> 
> Fine.
> 
> >#14 Explicit cite for MPLS/BGP
> >
> >   In the same paras as mentioned above, citation would be useful
> >   for the references to BGP being used to distribute labels
> >   (presumably it is [MPLS_VPN] ?)  However, it would also be
> >   worthwhile rephrasing the citation to not imply this is an
> >   MPLS WG sanctioned solution (unlike LDP, CR-LDP, and RSVP-TE
> >   which are WG sanctioned).
> >
> 
> fine.
> 
> 
> 
> Cherio
> 
> Francois
> 
> >I look forward to the revised document providing much appreciated
> >clarity and guidance to the industry.
> >
> >cheers,
> >gja
> >_____________________________________________________________
> ___________
> >Grenville Armitage                    
> http://members.home.net/garmitage/
> >Bell Labs Research Silicon Valley
> > 
> 
> _________________________________________________________________
> Francois Le Faucheur   
> Development Engineer, IOS Layer 3 Services 
> Cisco Systems 
> Office Phone:   	+33 4 92 96 75 64
> Home Office Phone:     +33 4 92 94 00 78
> Mobile :               +33 6 89 108 159
> Vmail:                 +33 1 58 04 62 66
> Fax:                   +33 4 92 96 79 08
> Email:          	flefauch@cisco.com
> _________________________________________________________________
> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 
> Valbonne - France
> _________________________________________________________________ 
> 


From owner-mpls@UU.NET  Tue Jun 27 18:14:54 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25826
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 18:14:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivlg17503;
	Tue, 27 Jun 2000 22:14:35 GMT
Received: by mail-control.mail.uu.net 
	id QQivlg25064
	for mpls-outgoing; Tue, 27 Jun 2000 22:14:10 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivlg25059
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 22:14:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivlg19536
	for <mpls@UU.NET>; Tue, 27 Jun 2000 18:14:04 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49])
	id QQivlg17010
	for <mpls@UU.NET>; Tue, 27 Jun 2000 22:14:02 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Tue Jun 27 18:13:52 EDT 2000
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA22199;
	Tue, 27 Jun 2000 18:14:27 -0400 (EDT)
Message-ID: <39592802.78555A7D@dnrc.bell-labs.com>
Date: Tue, 27 Jun 2000 15:17:38 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: Re: Last call comments
References: <336ECDAFDF7DD311B9E30090277AEE4101B40651@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Shahram Davari wrote:
	[...]

> If we want to remove all the redundancies, then we are left with a mesh of
> interconnected text.

I think we're looking for a well constructed piece of text that
clearly and without repetition shows how MPLS-with-DiffServ is
built from basic building blocks. This tends to form a tree, rather
than a mesh.

	[..]
> So although it may add to the volume of the draft, but I think it makes
> reading the text much easier.

You may have a sense of clarity because you've been immersed in the
document for a long time. Last calls are meant to elicit fresh
perspectives, and my fresh perspective is that the document requires
far greater conciseness in order to achieve clarity.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Tue Jun 27 19:46:08 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26738
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 19:46:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivln15366;
	Tue, 27 Jun 2000 23:45:50 GMT
Received: by mail-control.mail.uu.net 
	id QQivln15162
	for mpls-outgoing; Tue, 27 Jun 2000 23:45:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivln15152
	for <mpls@mail-control.mail.uu.net>; Tue, 27 Jun 2000 23:45:23 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivln14183
	for <mpls@UU.NET>; Tue, 27 Jun 2000 19:45:14 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivlm07568
	for <mpls@UU.NET>; Tue, 27 Jun 2000 23:44:58 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDK34>; Tue, 27 Jun 2000 16:51:27 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690820@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: Last call comments
Date: Tue, 27 Jun 2000 16:51:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

	Please understand that I am not attacking the
current version of the draft.  George gave us a short
amount of time in which to 'give it our best shot'.

	Bang.  :-)

	Please see below.  For the sake of brevity, I
have heavily edited included text without inserting
appropriate <snip> indications...

> >
> >   "(1) Tunneling Model 1 (either Uniform or Pipe)
> >
> >   "(2) Tunneling Model 2 (same as Tunneling Model 1 or 
> >different Model)"
> 
> This is a useful statement. We just need to change the 
> wording. For example
> to:
> 
>   "(1) Tunneling level 1 (either Uniform or Pipe)
> 
>   "(2) Tunneling level 2 (either Uniform or Pipe)"
> 
> Do you see anything wrong with this new wording?
> 

Part of the problem, is that I do not believe that
two models are needed.  I mention that in separate
mail, so I will suspend disbelief for most of this 
reply.  This is NOT the same as placid acceptance 
of the 2 models.

This wording is not much clearer.  I might suggest 

   "(1) Tunneling level 1
    (2) Tunneling level 2

   "The relationship between the two levels may be
    based on either the Pipe or the Uniform model."

Note that the model relates to how the two levels
INTERACT and therefore is not a characteristic of
the levels themselves.

The problem that still remains with the suggested 
text is that it still does not convey the meaning
you want.  Thus I would further suggest

   "(1) Tunneling level 1
    (2) Tunneling level 2
    (3) Tunneling level 3

   "The relationship between levels 1 and 2, and
    between 2 and 3 may be based on either the
    Pipe or the Uniform model. The relationships 
    need not be the same in all cases."

> 
> >Or at the bottom of page 16, top of page 17:
> >
> >   "LSRs at different levels of LSPs are expected to operate 
> >in the same 
> >    or in different Tunneling Models."
> >
> >I believe these may be examples of an earlier comment 
> >on mixing of example deployments and normative text.
> >
> 
> This is actually a normative text. Let me re-write it and see 
> if you agree:
> 
> "It is not necessary for the LSRs at different 
>  levels of LSPs to operate in the same tunneling 
>  mode".

An interestingly complicated statement.  If an
LSR is used to carry (perhaps tunneled) labeled
packets, even when it does not see the (tunneled)
labels, is the LSR _at_ the level of these labeled 
packets?

Maybe

   "In multilevel LSP tunneling, there is no
    requirement for consistent tunneling modes
    at all levels."

Note that this is not phrased as a positive
statement (DO ... as opposed to DON'T DO ...)
and I'm not sure how it could be.

> >	There are many repeat definitions of Acronyms
> >(places where the expanded version is followed by the
> >Acronym in parentheses).  This makes the draft look 
> >as if it was glued together from many pieces.  Either
> >the acronyms should be collected, or only the first 
> >instance should show both.  Currently, there are many
> >cases where the acronym is first used before being 
> >defined.
> 
> There are many new concepts in this draft, that are not 
> published in any document before. Besides this is a large 
> document, and finding the first instance of an acronym 
> is not easy. I don't see any harm in writing the expanded 
> version, if it makes reading the text easier. 
> However, this is an editorial issue and if others object, 
> we can easily remove the expanded versions.

Or you could add a section that defines the acronyms.
I think somebody may have thoughtfully provided you
with the text for this section.

BTW - the fact that there are many new concepts in
this draft (notably the two models) is part of the
problem I'm having with the fact that it is going
through 'last call' right now.

  ... <text justifying redundancy moved to new thread> ...

> 
> >	Section 1.6 - can signaled bandwidth also be used 
> >for policing packets associated with a PSC?  How does an
> >implementation know if it is supposed to use signaled
> >bandwidth to perform any of the functions mentioned in
> >this section (adjusting scheduling weights, admission
> >control and, possibly, policing)?
> 
> Signaled BW can potentially be used for all of the above. 
> The way to identify which one, and how, is out of the 
> scope of this document (New extensions to signaling may 
> be required). All we have tried to do is to not preclude 
> BW signaling in MPLS+Diffserv operations the way that CoS 
> object did), that is all. If you like we can write that 
> the details are outside the scope of this document. 

My opinion: it is not particularly useful to declare work
that MUST be done before the current work is useable as
"out of scope" unless it is not important HOW it is done.
Otherwise, a likely result of the current work is that it
will succeed only in making more new work than it manages 
to complete.  This - I believe - is in the category of
diminishing returns and should be discouraged.  In this 
case, it is important HOW it is done.  Otherwise, signaling
bandwidth will not be both useful and interoperable.  Plus,
one of the points I am making is that at least one possible
case was omitted.

> 
> >
> >	In section 2.1, this statement:
> >
> >  "Obviously, to enforce the Diff-Serv service 
> >   differentiation the LSR MUST also apply the 
> >   forwarding treatment corresponding to the
> >   Outgoing PHB."
> >
> >makes no sense, given that - in the bullets that precede
> >it - determination of the outgoing PHB is optional.  The
> >bullet - based on following text - should say something to
> >the effect that determination of a change in outgoing PHB
> >is optional.
> >
> 
> Off course determining the outgoing PHB is mandatory. The 
> optional part is determining it through local policy and 
> traffic conditioning. 
> How about this new wording for the 2nd bullet:
> 
>  - Outgoing PHB Determination, which may be a copy of the 
>    incoming PHB or may be via optional Local Policy and 
>    Traffic Conditioning (B).

Okay.

> >	The statement "Based on these considerations ..." in
> >the last paragraph of section 2.6.2 seems to be a non-sequitur
> >- I cannot see the connection between the "considerations"
> >and the conclusion.  For one thing, it seems almost to conclude
> >that - because there is PHP in MPLS, and this makes it hard to
> >determine what the EXP field was at the egress, then the uniform
> >model (which makes it necessary to recover this information) is
> >justified.
> >
> 
> May be we should say "based on these observations...".
> But I can't understand why you can't see any connection 
> between the first 3 bullets and the conclusion? In the 
> first 3 bullets We have shown that from the Diffserv 
> perspective an MPLS tunnel basically is a tunnel, very 
> similar to IP tunnel. So for Diffserv purpose we can use 
> the same tunneling modes as the IP tunnel.

Help me out here, by pretending I'm really very stupid.

Are the Pipe and Uniform models characteristic of IP
tunnel support for DiffServ that is documented in one
or more of the references listed in this draft?  If
so, which reference?

The first 3 bullets do indeed show that MPLS support
of DiffServ is in some ways like IP tunneling support
of DiffServ.  The second set of 2 bullets shows that
MPLS support of DiffServ may be unlike IP tunneling 
support of DiffServ in one way (see BTW below).  From
these considerations, I would conclude that DiffServ
over MPLS may be like and unlike DiffServ support over
IP Tunnels.  Not a very useful conclusion.

Is one of the two models intended to represent DiffServ
support over MPLS that is identical to DiffServ support
over IP Tunnels?  If so, this is far from clear.

BTW - the fact that there is no standard way to do PHP
for IP tunneling is not the same as saying it cannot be
done.  You could look at it as proxy termination of an
IP tunnel.  Also, as it is possible for IP-in-IP tunnels
to be nested, it is also possible to terminate more than
one level of IP-in-IP tunneling at the same point in the 
network.  To say that the fact that LSPs are used in MPLS 
(nested or otherwise) makes MPLS different from IP tunnels
is not a particularly interesting tautology.

So, how do you arrive at the conclusion that two models
are required based on the (boiled down) observation that
MPLS support of DiffServ is like IP Tunnels support of
DiffServ?  Please spell it out for me.

> 
> >	I believe that the uniform model should receive the same
> >treatment as "other models" - i.e. - it should be treated as out
> >of scope.  This removes a lot of seeming unjustified complexity 
> >and about two pages of text.
> 
> Why? What would you do if you hadn't had MPLS? the Diffserv 
> operation in Uniform model is exactly identical to Diffserv 
> over non-MPLS network. Do you also think that we should 
> remove the support of Diffserv transiting non-MPLS networks? 

I haven't seen a draft or RFC on supporting DiffServ over IP
Tunnels.

I do not see one listed as a reference in the MPLS-DiffServ
draft.  

Therefore, I have to go with what I have seen for IP in IP 
tunneling.  The RFC (RFC 2003) for this states that the IP
header in the tunneled IP packet is left alone except for
changing the TTL value.  This implies to me that - for IP 
in IP tunneling at least - the combination of DiffServ and 
IP in IP tunneling results in what we are currently calling 
the Pipe model.  This makes a surprising amount of sense to
me.  From this, I conclude that the "Uniform" model is an 
aberration and I ask for better justification for it than I 
have seen so far.  At the most, it may be necessary to state
that the EXP bit values may be derived from corresponding 
values in a popped label.  See other mail for wording on this.
 
> >
> >	The draft needs a list of acronyms and/or a glossary.  
> >The acronyms used (and, in some cases, introduced) in this 
> >draft include:
> >
> >BA		Behavior Aggregates
> >DSCP		Differentiated Services Code Point
> >EXP		EXPerimental (bits)
> >E-LSP		EXP-Inferred-PSC LSP
> >FEC		Forwarding Equivalency Class
> >FTN		FEC-To-NHLFE Map
> >ILM		Incoming Label Map
> >LSP		Label Switched Path
> >LSR		Label Switch Router
> >L-LSP		Label-Only-Inferred-PSC LSP
> >MPLS		Multi-Protocol Label Switching
> >NHLFE		Next Hop Label Forwarding Entry
> >OA		Ordered Aggregate
> >PHB		Per Hop Behavior
> >PSC		PHB Scheduling Class
> >

Oh, wait.  What's this?  it looks like a partial list 
of acronyms.  :-)

> 
> Thanks,
> 
> -Shahram
> 


From owner-mpls@UU.NET  Tue Jun 27 22:31:17 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00300
	for <mpls-archive@lists.ietf.org>; Tue, 27 Jun 2000 22:31:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivly22141;
	Wed, 28 Jun 2000 02:30:37 GMT
Received: by mail-control.mail.uu.net 
	id QQivly00870
	for mpls-outgoing; Wed, 28 Jun 2000 02:30:12 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivly00860
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 02:30:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivly19569
	for <mpls@UU.NET>; Tue, 27 Jun 2000 22:30:03 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivly21383
	for <mpls@UU.NET>; Wed, 28 Jun 2000 02:30:01 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDKXC>; Tue, 27 Jun 2000 19:35:40 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690821@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: Last call comments
Date: Tue, 27 Jun 2000 19:35:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

	A few people pointed out that there is a draft
(newer than the one listed in the MPLS-DiffServ
draft) which I had missed earlier on the web page
for DiffServ working group drafts.

    http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-01.txt

This draft does define Uniform and Pipe models.  I
read the part of this draft that defines these two
models and still am not sure why the Uniform model
is needed, but I assume that there has been a lot
of discussion on this on a mailing list which I've
admittedly paid less attention to (though a quick
screening of the mail archive only turned up one
comment on the topic in the last 9 or 10 months).

	However, now that I know where this comes from,
I am even more convinced that this should be treated
as out of scope for the MPLS DiffServ draft.  My
thinking is based on the considerations that the draft
on DiffServ tunnels is only in its second iteration as 
a working group draft (and may be relatively immature)
and was downgraded (from a standards track draft) to an
Informational RFC track document just a few days ago.  
The current level of maturity for that draft means that 
it is possible that one or the other of the two models 
may still be removed and the fact that it is now meant 
to be informational means that there is less incentive 
for working group members to expend effort to ensure 
that it accurately reflects what the implementers are 
really implementing and the users are really using.

	That draft currently assumes that the DS field is
strictly copied (from inner to outer on tunnel ingress
and from outer to inner on tunnel egress).  Clearly,
the restrictions imposed by mapping the DS byte to the
smaller EXP field (or DE/CLP bit) means that there may
not be a consistent way to "copy" this information from
one label to another.   However, this fact means that 
the process of mapping one value to the next will most
likely result in information loss.  This information
loss will most probably lead to degradation in service 
intended for DiffServ labeled packets - since it seems 
unlikely to be a good policy to always upgrade service 
in this case.  Consequently, the Uniform model is very
unlikely to be useful when it is not possible to copy
EXP bit values from one label to another.

	On top of this, the discussion I expected to see
in the DiffServ mail archive was a discussion of the
consequences of 'punishing' packets that have made it
through a tunnel successfully by carrying forward any
degradation in their service that may have occurred 
while transiting the tunnel.  Typically there is some
cost associated with tunneling packets and this is a
'sunk cost' once the packet has succeeded in making
it through the tunnel.  It then seems a little strange
to drop this packet at a congestion point when it was
not dropped within the tunnel and would not have been
dropped if it still had the PHB it had on entering the
tunnel.  This may be a 'belief system' issue but, when
combined with the likelihood of losing information in
mapping (as opposed to copying) EXP bit values from
one label to another, there seems to be less reason
to explicitly specify this behavior in MPLS DiffServ.

	Minimally, the draft needs to say a lot less on
the subject of the two models in order to avoid being
locked into a position in which it 1) cannot be moved
forward until the DiffServ Tunnels draft is progressed
and 2) is inconsistent in its usage with that work.

--
Eric Gray



From owner-mpls@UU.NET  Wed Jun 28 03:47:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16636
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 03:47:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivmt02408;
	Wed, 28 Jun 2000 07:46:16 GMT
Received: by mail-control.mail.uu.net 
	id QQivmt12258
	for mpls-outgoing; Wed, 28 Jun 2000 07:45:39 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivmt12253
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 07:45:33 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivmt05716
	for <mpls@uu.net>; Wed, 28 Jun 2000 03:45:12 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivmt01663
	for <mpls@uu.net>; Wed, 28 Jun 2000 07:45:03 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA11551
	for mpls@uu.net; Wed, 28 Jun 2000 03:45:03 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivms12017
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 07:44:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivms05650
	for <mpls@UU.NET>; Wed, 28 Jun 2000 03:44:18 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQivms01293
	for <mpls@UU.NET>; Wed, 28 Jun 2000 07:44:18 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id BCE67F9; Wed, 28 Jun 2000 09:44:17 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp18.cisco.com [144.254.60.40])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id JAA07801;
	Wed, 28 Jun 2000 09:44:16 +0200 (MET DST)
Message-Id: <200006280744.JAA07801@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Wed, 28 Jun 2000 09:39:46 +0200
To: Alia Atlas <aatlas@avici.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: Last Call feedback on MPLS-diffserv
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
In-Reply-To: <4.1.20000626174509.00a2a7b0@mailhost.avici.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Alia,

At 17:49 26/06/2000 -0500, Alia Atlas wrote:
>Hi,
>
>I have two comments on the draft.  I would like to see the draft support
>signalling of the tunnelling mode; 

This is something that has been discussed already. Please see the thread "RE: Hierarchical Tunnel Establishment in RSVP-TE" on the alias. The outcome of the thread was in essence that it was not clear that this would actually be required and that it could be added later if/when such requirement is clarified. Your colleague Curtis proposed updated wording to that effect to which we agreed:
=It may be better if the
=wording in draft-ietf-mpls-diff-ext-05.txt declared the signaling to
=set uniform or pipe on a per LSP basis as out of scope rather than
=precluding it so that a later document can define the signaling if
=there is a need.

Also, I suspect that if we wanted to have full support of the Uniform/Pipe Models through signalling for all cases we might need to do something more (eg see the issue that with uniform & PHP the Penultimate Hop has to be aware of the mappings of encapsulated LSP). 

> Second, I
>would like to clarify supporting bandwidth reservation on E-LSPs.  

What you are discussing below is actually the ability to signal bandwidth on a per-PSC basis within an E-LSP. THis is a potential option which has been discussed at length already since it had been requested by Curtis. 
The bottom line is that the current spec already has quite a number of options and these existing options currently let you (i) "route" together multiple PSCs and signal/reserve bandwidth on an aggregate basis across those PSCs (using E-LSPs), (ii) "route" separately individual PSC and signal/reserve bandwidth on a per-PSC basis (using L-LSPs). Signaling per-PSC bandwidth over E-LSPs woudl allow the ability to "route" multiple PSCs together while signalling/reserving bandwidth on a per-PSC basis. I polled the group on this very topic and the conclusion was that the benefits of this last option did not justify yet another option for the first version of the spec.

Thanks

Francois

>Towards each
>purpose, as described below, I would suggest using a reserved bit.
>
>There are two tunnelling modes in which each LSP could operate.
>However, the draft gives no guidelines as to how to determine which
>mode a given LSP should use.   I would like to suggest using one of
>the reserved bits in the DIFFSERV object for this purpose, as follows:
> 
>   DIFFSERV object for an E-LSP:
>
>   class = TBD, C_Type = 1  (need to get an official class num from the
>   IANA with the form 0bbbbbbb)
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |        Reserved                                     |T| MAPnb |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            MAP (1)                            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    //                               ...                            //
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                            MAP (MAPnb)                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Reserved : 27 bits
>       This field is reserved. It must be set to zero on transmission
>       and must be ignored on receipt.
>
>        T : 1 bit
>          Specifies the tunnel mode to be used by the LSP.  If 0, then the
>       tunnel mode is Uniform.  If 1, the tunnel mode is Pipe.
>
>   DIFFSERV object for an L-LSP:
>
>   class = TBD, C_Type = 2  (class num is the same as DIFFSERV object
>   for E-LSP))
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |        Reserved             |T|             PSC               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Reserved : 16 bits
>       This field is reserved. It must be set to zero on transmission
>       and must be ignored on receipt.
>        
>        T : 1 bit
>          Specifies the tunnel mode to be used by the LSP.  If 0, then the
>       tunnel mode is Uniform.  If 1, the tunnel mode is Pipe.
>
>Similar bits can be acquired from the reserved for the Diff-Serv TLV.
>
>For RSVP, if a router cannot support the specified tunnelling mode, it would
>report a 'Diff-Serv Error' with a value of 5 = "Unsupported Tunnel Mode". 
>Similarly, for LDP, a status code of 0x0000001A could be used for  
>"Unsupported Tunnel Mode".
>
>I realize that this does not provide flexibility for future tunnel modes, so
>more bits could be dedicated to this purpose, as and when deemed appropriate.
>
>I would like to spend a second bit to properly support signalled bandwidth
>reservations for E-LSPs.  Currently the draft has an inconsistency.
>
>In Section 1.6, the current draft states:
>  "When bandwidth requirements are signaled at establishment of an
>   E-LSP, the signaled bandwidth is associated collectively to the
>   whole LSP and therefore to the set of transported PSCs. Thus, LSRs
>   which use the signaled bandwidth to perform admission control may
>   perform admission control over global resources which are shared by
>   the set of PSCs (e.g. over the total bandwidth of the link)."
>
>In Section 5.6, the draft further specifies:
>  "To establish an E-LSP or an L-LSP with bandwidth reservation, Int-
>   Serv's Controlled Load service (or possibly Guaranteed Service) is
>   used and the bandwidth is signaled in the SENDER_TSPEC (respectively
>   FLOWSPEC) of the path (respectively Resv) message.
>   ....
>   The above is summarized in the following table:
>
>           Path Message  LSP type
>    Service  DIFFSERV
>              Object
>
>     GS/CL     No        E-LSP + preconf mapping + bandw reservation
>     GS/CL   Yes/E-LSP   E-LSP + signaled mapping + bandw reservation
>     GS/CL   Yes/L-LSP   L-LSP + bandw reservation
>     COS       No        E-LSP + preconf mapping + no bandw reservation
>     COS     Yes/E-LSP   E-LSP + signaled mapping + no band reservation
>     COS     Yes/L-LSP   L-LSP + no bandw reservation
>
>   Where:
>        - GS stands for Guaranteed Service
>        - CL stands for Controlled Load
>        - COS stands for COS service"
>
>Thus, if a RESV message contains both a TSpec with GS or CL specified and a
>Diffserv object for an E-LSP, bandwidth reservation is the appropriate
>behavior.  However, adequate information is not supplied to know how much
>additional bandwidth each PHB used by the E-LSP should be provisioned with.
>
>Given that it would be desirable to support bandwidth reservations associated
>with E-LSPs, I would propose the following modifications to the Diffserv Object
>and Diff-Serv TLV.  
>DIFFSERV object for an E-LSP:
>
>   class = TBD, C_Type = 1  (need to get an official class num from the 
>   IANA with the form 0bbbbbbb)
>
>     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 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |B|        Reserved                                   |T| MAPnb | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                            MAP (1)                            | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                                                               | 
>    //                               ...                            // 
>    |                                                               | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                            MAP (MAPnb)                        | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Reserved : 26 bits 
>       This field is reserved. It must be set to zero on transmission 
>       and must be ignored on receipt.
>
>             B : 1 bit 
>                This flag indicates whether bandwidth is explicitly specified
>per MAP.  
>       If it is 0, no bandwidth is explicitly signalled, and the Diffserv
>object 
>        is not further modified.  If it is 1, then the Diffserv object will 
>       contain those bandwidths as described below: 
>         
>    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|        Reserved                                   |T| MAPnb | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                            MAP (1)                            | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                            BW (1)                             | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                                                               | 
>    //                               ...                            // 
>    |                                                               | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                            MAP (MAPnb)                        | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    |                            BW (MAPnb)                         | 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      BW : 32 bits 
>                  Bandwidth reserved for the above PHBID.  This is specified as
>a               standard IEEE floating number.  The units are bytes/sec.
>
>When the Bandwidth flag is set, the rate signalled in the Tspec is ignored. 
>Instead, the bandwidths signalled in the Diffserv Object would be used.
>
>I am not certain how to specify this feature with LDP, because I am less
>familiar with LDP.  No language in the draft exists to specify how bandwidth
>reservation might be done using LDP.  Perhaps someone with greater knowledge of
>LDP could take a look and determine whether it makes sense to support this
>feature in LDP and how it might be done.
>
>Please let me know what you think.
>
>Thanks,
>Alia 
> 


_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Wed Jun 28 04:48:27 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17001
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 04:48:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivmx07027;
	Wed, 28 Jun 2000 08:47:53 GMT
Received: by mail-control.mail.uu.net 
	id QQivmx26516
	for mpls-outgoing; Wed, 28 Jun 2000 08:47:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivmx26506
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 08:47:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivmx04605
	for <mpls@uu.net>; Wed, 28 Jun 2000 04:47:04 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivmx24438
	for <mpls@uu.net>; Wed, 28 Jun 2000 08:47:03 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA14544
	for mpls@uu.net; Wed, 28 Jun 2000 04:47:03 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivmx26489
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 08:46:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivmx04307
	for <mpls@UU.NET>; Wed, 28 Jun 2000 04:46:27 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQivmx24083
	for <mpls@UU.NET>; Wed, 28 Jun 2000 08:46:26 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 3E150121; Wed, 28 Jun 2000 10:46:26 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp18.cisco.com [144.254.60.40])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id KAA26175;
	Wed, 28 Jun 2000 10:46:25 +0200 (MET DST)
Message-Id: <200006280846.KAA26175@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Wed, 28 Jun 2000 09:50:57 +0200
To: Eric Gray <EGray@zaffire.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: RE: Last call comments
Cc: "Francois Le Faucheur (E-mail)" <flefauch@cisco.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>
In-Reply-To: <9A564CC874B5D3118FB9009027B0A662690813@ICARIAN>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 09:15 27/06/2000 -0700, Eric Gray wrote:
>> Folks,
>> 
>> 	Here's most of my last call comments.  More may
>> be sent out later this evening.
>
>And here they are.   
>
>> 
>> 
>> SPECIFIC COMMENTS
>> =================
>> 
>
>	The redefinitions of E-LSP and L-LSP are - as
>Grenville has already pointed out (comments 3 & 4)
>- not too useful.  If there is a reason for including 
>all of this, it would make sense to abstract those 
>portions that are repeated in sections 3.1 and 4.1 
>(almost all of the text) into a section that specifies 
>stuff relating to any kind of DiffServ LSP and just 
>list the E-LSP and L-LSP specific stuff in sections 
>3.1 and 4.1.  I am not too sure what the authors had
>hoped to specify in this text, so I can not be sure 
>there is a reason for including it.

We've already discussed this and have a proposal on how to adress this.

>
>	I also agree with Grenville's comments 13 and 14
>and add to his first comment that - like the Uniform
>model - ECN needs either to be better documented or
>not included.  If there were a relatively mature draft
>that stated how ECN would be done using the EXT bits,
>then it is obvious that this draft would have to address
>how its usage of the EXT bits can be coordinated with 
>the ECN usage.  As it now is, this section seems to be
>trying to establish backward compatibility with some
>non-existant function.

>

We've already discussed this and have a proposal on how to adress this.


>Aditional acronyms:
>
>AF		Assured Forwarding
>CE		Congestion Experienced (not needed if section 11 is removed)
>CLP		Cell Loss Priority
>COPS		Common Open Policy Service [ref RFC 2748]
>CS		(?)
>DE		Discard Eligibility
>DF		Default Forwarding (?)
>ECN		Explicit Congestion Notification
>ECT		(? - not needed if section 11 is removed)
>EF		Expedited Forwarding
>SNMP		Simple Network Management Protocol
>

thanks

>> 
>> NITS
>> ====
>> 
>
>toward top of page 36, "An RSVP router that does
>recognizes the DIFFSERV ..." should be changed to
>"... that does recognize ...".  You might also 
>change "RSVP router" to "LSR" since "RSVP" is 
>implied by the sectional context.
>
>several more occurences of 'eg.' (search and 
>replace?)...
>

fine.


>> 
>> 
> 
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Wed Jun 28 04:49:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17023
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 04:49:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivmx25101;
	Wed, 28 Jun 2000 08:48:00 GMT
Received: by mail-control.mail.uu.net 
	id QQivmx26517
	for mpls-outgoing; Wed, 28 Jun 2000 08:47:19 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivmx26507
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 08:47:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivmx04603
	for <mpls@uu.net>; Wed, 28 Jun 2000 04:47:03 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivmx24437
	for <mpls@uu.net>; Wed, 28 Jun 2000 08:47:03 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA14543
	for mpls@uu.net; Wed, 28 Jun 2000 04:47:02 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivmx26490
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 08:46:35 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivmx04331
	for <mpls@UU.NET>; Wed, 28 Jun 2000 04:46:30 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQivmx06139
	for <mpls@UU.NET>; Wed, 28 Jun 2000 08:46:30 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 65A8712C; Wed, 28 Jun 2000 10:46:29 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp18.cisco.com [144.254.60.40])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id KAA26186;
	Wed, 28 Jun 2000 10:46:26 +0200 (MET DST)
Message-Id: <200006280846.KAA26186@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Wed, 28 Jun 2000 10:42:10 +0200
To: Eric Gray <EGray@zaffire.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: Last call comments
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
In-Reply-To: <9A564CC874B5D3118FB9009027B0A66269080F@ICARIAN>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

At 17:29 26/06/2000 -0700, Eric Gray wrote:
>Folks,
>
>       Here's most of my last call comments.  More may
>be sent out later this evening...
>
>IN GENERAL
>==========
>
>       Many aspects of this draft - especially those
>relating to E-LSPs and L-LSPs and the Pipe Model
>seem intuitive and very useful.
>
>       There are several aspects of the uniform model
>which appear complex beyond any justification I have
>seen for specifying this model.
>

Two motivations are already mentiond in the draft for why the Uniform model is
seenm as very useful. This summarises discussions we have had on that topic and
corresponding conclusions:

"Use of the Uniform Model allows LSPs to span Diff-Serv domain boundaries
without any other measure in place than an inter-domain Traffic Conditioning
Agreement at the physical boundary between the Diff-Serv domains and operating
exclusively on the "outer" header, since the meaningful Diff-Serv information
is always visible and modifiable in the outmost label entry.

The Uniform Model for Diff-Serv over MPLS is such that, from the Diff-Serv
perspective, operations are exactly identical to the operations if MPLS was not
used."

The Uniform model is useful and should stay in this draft.



>       There are concepts that have been introduced
>almost completely without explanation.  An amazing
>example is the concept of the multi-pop PHP that
>comes up in section 2.6.6.
>

You are correct. The last paragraph of section 2.6.6 should be removed as it
does not discuss a useful situation. thanbks for catching that.

>       The draft punts on several relevant issues.  In
>particular, there seems to be no effort to justify 
>some of the complexity in the specification in terms 
>of real world applications for particularly difficult
>combinations (such as the combination of Uniform model 
>and PHP).  If the uniform model is intended for the

See above. You may have missed the earlier discussions on the alias but this
was discussed. and there is corresponding text in the spec already giving an
example of where uniform is useful.

I feel that PHP has been justified enough by the MPLS architecture document.

>purpose stated by Shahram Davari (23 March, 2000), then
>it would be useful to state that an example of when it
>might be useful is when multiple tunnel hierarchy levels
>are within the same administrative domain.
>
>       There are far too many murky statements for the
>specification to be useful in producing interoperable
>implementations.  For example, from mid-page on page
>18:
>
>   "(1) Tunneling Model 1 (either Uniform or Pipe)
>
>   "(2) Tunneling Model 2 (same as Tunneling Model 1 or different Model)"
>

As Shahram explained, the point here is that the two levels of tunnels don't
have to use the same tunneling modes. I believe this must be said. I let
Shahram work with you on better wording.

>Or at the bottom of page 16, top of page 17:
>
>   "LSRs at different levels of LSPs are expected to operate in the same 
>    or in different Tunneling Models."
>

this is the same point.

>I believe these may be examples of an earlier comment 
>on mixing of example deployments and normative text.
>
>       The statement that other models (besides Pipe 
>and Uniform) may be supported makes me wonder why an
>attempt is made to support the Uniform model (it may
>be that the draft punts too late on this issue, rather
>than to early on issues that derive from the Uniform
>model).
>

The reason we "attempt" to support uniform is that the group's agreed on the
alias that it was useful .

>       There are many repeat definitions of Acronyms
>(places where the expanded version is followed by the
>Acronym in parentheses).  This makes the draft look 
>as if it was glued together from many pieces.  Either
>the acronyms should be collected, or only the first 
>instance should show both.  Currently, there are many
>cases where the acronym is first used before being 
>defined.
>
>       I agree with the earlier posted comment that the
>draft is excessively wordy.  It includes quotations of
>large amounts of text from other drafts which are not 
>necessary, it has a lot of redundancy and it looks as
>if it has been cobbled together incompletely from the
>work of several people.  The content is too important 
>to be so hard to read.
>
>SPECIFIC COMMENTS
>=================
>
>       The first paragraph in the introduction implies
>that the same label is used at each hop.  Last sentence 
>should read something like "At each LSR along the LSP, 
>the label is used to label-swap and forward the packet 
>to the next hop."
>
>       Why the 4+ line quote from [DIFF_HEADER] at the 
>bottom of page 2, instead of simple stating the need to 
>provide flexibility for service providers?
>
>       Section 1.6 - can signaled bandwidth also be used 
>for policing packets associated with a PSC?  How does an
>implementation know if it is supposed to use signaled
>bandwidth to perform any of the functions mentioned in
>this section (adjusting scheduling weights, admission
>control and, possibly, policing)?
>

same as usual: outside the scope of this spec, could be by local config,
policy, SNMP,...
do you think it would add value to state so?
should we also state the same regarding how the router decides to establish
E-LSPs and L-LSPs and use Configured-mapping instead of signaled mapping etc ?

>       In section 2.1, this statement:
>
>  "Obviously, to enforce the Diff-Serv service differentiation the LSR
>   MUST also apply the forwarding treatment corresponding to the
>   Outgoing PHB."
>
>makes no sense, given that - in the bullets that precede

the statement is actaully correct. What needs to be changed is the fact that it
is the Local Policy/Traffic Conditioning which is optional (rather than the
Outgoing PHB determination). We'll do that.

>it - determination of the outgoing PHB is optional.  The
>bullet - based on following text - should say something to
>the effect that determination of a change in outgoing PHB
>is optional.
>
>       At the bottom of page 6, the two statements:
>
>  "(*) when the LSR performs label imposition, the incoming packet is
>   received unlabelled.
>
>  "(**) when the LSR performs label disposition, the outgoing packet is
>   transmitted unlabelled."
>
>are only true if no label stacking occurs.  It may be that 
>you are just talking about the (rather difficult to follow)
>figure, but it would be better (and more general) if you
>use the common terms "ingress" and "egress" rather than the
>terms "label imposition" and "label disposition" and simply
>replace these lines with:
>
>   "(*) ingress
>
>   "(**) egress"
>

agreed.

>       Section 2.3 says that determination of outgoing PHB is 
>optional yet goes on to say that the default is that outgoing
>PHB is identical to incoming PHB.  This would be clearer if
>it simply states that the determination is always done and 
>the default 'determination' is that the outgoing is the same
>as the incoming (this corresponds to the default "local
>policy").

see above,

>
>       Why the 8 line quote from [MPLS_ARCH] (toward bottom
>of page 8)?  Simply change the next paragraph to read:
>
>   "This specification allows that an incoming label ..."
>

I think we are in the realm of editorial style here. We have had multiple
requests for clarifying the relationship of this spec to the ARCH. Quoting the
paragraph gives the exact context to which the following statement relates.  I
see it as valuable and think it makes reading easier. 
It doesn't terribly matter to me, though . 

>       Same question/observation for the quote at the bottom
>of page 9 and top of page 10.
>

same as above.

>       The statement "Based on these considerations ..." in
>the last paragraph of section 2.6.2 seems to be a non-sequitur
>- I cannot see the connection between the "considerations"
>and the conclusion.  For one thing, it seems almost to conclude
>that - because there is PHP in MPLS, and this makes it hard to
>determine what the EXP field was at the egress, then the uniform
>model (which makes it necessary to recover this information) is
>justified.
>

that is not what it is concluding.

here's the train of thought:
        - (a) LSPs look from above like tunnels---> (b) thus the DS models
applying to tunnels apply to LSPs
        - (c) LSPs have minor transport differences -->(d) thus we need to
accomodate those
except w've stated it as 
(a)+(b)-->(c)+(d)

No?

>       I believe that the uniform model should receive the same
>treatment as "other models" - i.e. - it should be treated as out
>of scope.  This removes a lot of seeming unjustified complexity 
>and about two pages of text.
>

Not agreed . See above.

>       In section 2.6.6 - there are bullets that talk about 
>multi-pop PHP.  Currently, there is no standard way to signal 
>this - nor is it reasonable to establish one.  The supposed
>intent for PHP was to avoid pop-and-look-again behavior in an
>egress LSR.  PHP does not currently require the penultimate
>LSR to look at the label it has exposed by popping the label
>stack  - so it has no means to determine that it needs to do
>a second (or subsequent) pop, even if it is otherwise capable
>of performing a pop-and-look-again.  These bullets should be
>removed. (I'm pretty sure that there is no other MPLS draft 
>that refers to the ability to pop multiple labels as a single 
>atomic operation - even at the egress LSR - even though an LSR
>implementation can obviously be made to do this.)
>

Agreed. The text on multi-pop PHP in 2.6.6 will be removed.

>       The draft needs a list of acronyms and/or a glossary.  
>The acronyms used (and, in some cases, introduced) in this 
>draft include:
>
>BA             Behavior Aggregates
>DSCP           Differentiated Services Code Point
>EXP            EXPerimental (bits)
>E-LSP          EXP-Inferred-PSC LSP
>FEC            Forwarding Equivalency Class
>FTN            FEC-To-NHLFE Map
>ILM            Incoming Label Map
>LSP            Label Switched Path
>LSR            Label Switch Router
>L-LSP          Label-Only-Inferred-PSC LSP
>MPLS           Multi-Protocol Label Switching
>NHLFE          Next Hop Label Forwarding Entry
>OA             Ordered Aggregate
>PHB            Per Hop Behavior
>PSC            PHB Scheduling Class
>
>(Punting on this - as seems to be the current approach
> is just messy :-)
>

fine

>In addition, the following definitions would be useful
>(collected in a glossary?):
>
>Behavior Aggregate
>               Packets crossing a link that require
>               the same Diff-Serv behavior.
>Diff-Serv      Differentiated Services.
>Diff-Serv Context
>               <Insert Definition HERE>
>FEC            <Insert Definition HERE>
>Ordered Aggregate
>               Set of Behavior Aggregates sharing an 
>               ordering constraint.
>PHB Scheduling Class
>               Set of PHBs applicable to an Ordered 
>               Aggregate.
>
>

I would prefer to leave them out.
As you may recollect the concepts of OA and PSC have come out of this work on
DS over MPLS. We initially created teh definition and had them in this
document. Now that ownership of these acronyms/definitions has been fully
transfered to the Diff-Serv group and that there are in teh process of being
finalised , I think we should just refer to the appropriate document as
currently done.

>
>NITS
>====
>
>top of page 3 'eg.' should be 'e.g.' (two cases in the 
>first paragraph on this page).  Same for top of page 4
>(3 occurrences).
>
>first paragraph in section 2.1, last sentence - can't
>quite figure out what you're saying.  Suggested rewording
>is:
>
>"... the way to determine the PHB to be applied to a
> received packet and to encode the PHB into a transmitted 
> packet is different than for a non-MPLS Diff-Serv Router."
>

you're proposing to replace "different to" by "differnet than" (or did I miss
other proposed changes?).
then fine.

thanks

Francois
                     --------
>  
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Wed Jun 28 06:50:46 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17953
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 06:50:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivnf15347;
	Wed, 28 Jun 2000 10:50:10 GMT
Received: by mail-control.mail.uu.net 
	id QQivnf24941
	for mpls-outgoing; Wed, 28 Jun 2000 10:49:55 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivnf24936
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 10:49:45 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivnf23552
	for <mpls@uu.net>; Wed, 28 Jun 2000 06:49:39 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivnf03639
	for <mpls@uu.net>; Wed, 28 Jun 2000 10:49:38 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA19914
	for mpls@uu.net; Wed, 28 Jun 2000 06:49:38 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivnf24925
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 10:49:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivnf23429
	for <mpls@uu.net>; Wed, 28 Jun 2000 06:49:00 -0400 (EDT)
Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQivnf03183
	for <mpls@uu.net>; Wed, 28 Jun 2000 10:49:00 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17900;
	Wed, 28 Jun 2000 06:48:59 -0400 (EDT)
Message-Id: <200006281048.GAA17900@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-worster-mpls-in-ip-00.txt
Date: Wed, 28 Jun 2000 06:48:59 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: MPLS Label Stack Encapsulation in IP
	Author(s)	: T. Worster, A. Malis, Y. Katsube
	Filename	: draft-worster-mpls-in-ip-00.txt
	Pages		: 6
	Date		: 27-Jun-00
	
Several useful applications of MPLS tunnels based on LSPs with
second level labels between non adjacent LSRs have been
identified: IP-VPNs and VoIP over MPLS are just two examples. This
tunnelling technique can easily be extended to non-MPLS core
networks.
This Internet-Draft explains the motivation for encapsulating MPLS
messages in IP and provides the protocol specification of the
encapsulation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-worster-mpls-in-ip-00.txt

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-worster-mpls-in-ip-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-worster-mpls-in-ip-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.

--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:	<20000627121829.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-worster-mpls-in-ip-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-worster-mpls-in-ip-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--





From owner-mpls@UU.NET  Wed Jun 28 07:32:49 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18987
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 07:32:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivni28329;
	Wed, 28 Jun 2000 11:31:32 GMT
Received: by mail-control.mail.uu.net 
	id QQivni08216
	for mpls-outgoing; Wed, 28 Jun 2000 11:31:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivni08146
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 11:31:04 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivni27997
	for <mpls@UU.NET>; Wed, 28 Jun 2000 07:30:52 -0400 (EDT)
Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: griffin.host4u.net [209.150.128.163])
	id QQivni27762
	for <mpls@UU.NET>; Wed, 28 Jun 2000 11:30:52 GMT
Received: from nfloat.labn.net (labn.net [209.204.240.82])
	by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id GAA08422;
	Wed, 28 Jun 2000 06:30:23 -0500
Message-Id: <4.3.2.7.2.20000627115155.00c0af00@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 27 Jun 2000 19:19:04 -0400
To: Yakov Rekhter <yakov@cisco.com>
From: Lou Berger <lberger@labn.net>
Subject: Re: Question on draft-kompella-lsp-hierarchy-00.txt 
Cc: Rohit Chhapolia <rohit@globespan.net>, mpls@UU.NET
In-Reply-To: <200006222158.OAA19312@omega.cisco.com>
References: <Your message of "Thu, 22 Jun 2000 16:48:07 EDT." <39527B87.B0A4FAA6@globespan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,

IP encapsulation *is* required on path messages as intermediate nodes may 
process the PATH message even if a router alert isn't included.

IP encapsulation of the Resv is beneficial as it ensures intermediate nodes 
don't hand the RSVP message to the RSVP code/module.  This is an 
optimization, hence "may" or "should" is appropriate.

Lou


At 02:57 PM 6/22/00 -0700, Yakov Rekhter wrote:
>Rohit,
>
> > In the section 5.1, it is suggested that Path/Resv message
> > should be encapsulated in another IP header if sent
> > as unicast over the control plane. Can you please
> > clarify why is this required?
>
>See below....
>
> > It should be possible to send the Resv message as it is.
>
>Agreed.
>
> > Path message can be sent without router alert to the
> > next hop IP address. In this case, IP address of the tail
> > end of the FA-LSP.
>
>Agreed.
>
>We'll correct the text in the next iteration of this document.
>
>Yakov.



From owner-mpls@UU.NET  Wed Jun 28 08:51:15 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21337
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 08:51:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivnn26540;
	Wed, 28 Jun 2000 12:50:42 GMT
Received: by mail-control.mail.uu.net 
	id QQivnn24694
	for mpls-outgoing; Wed, 28 Jun 2000 12:50:16 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivnn24689
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 12:50:14 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivnn07687
	for <mpls@UU.NET>; Wed, 28 Jun 2000 08:50:04 -0400 (EDT)
Received: from sepahan.iut.ac.ir by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sepahan.iut.ac.ir [194.165.10.30])
	id QQivnn16450
	for <mpls@UU.NET>; Wed, 28 Jun 2000 12:49:29 GMT
Received: from localhost (s7627237@localhost)
	by sepahan.iut.ac.ir (8.9.3/8.9.3) with ESMTP id RAA06119;
	Wed, 28 Jun 2000 17:18:09 +0430
Date: Wed, 28 Jun 2000 17:18:09 +0430 (IRST)
From: Manshaee Mohammad-Hossein <s7627237@sepahan.iut.ac.ir>
To: Eric Gray <EGray@zaffire.com>
cc: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: A question about PPP and POS
In-Reply-To: <9A564CC874B5D3118FB9009027B0A662690820@ICARIAN>
Message-ID: <Pine.LNX.4.10.10006281711561.6019-100000@sepahan.iut.ac.ir>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

Is there any draft for MPLS over SONET or PPP ...?

Would you please explain about this subject for me?

Best regards,

MH Manshaei


 




From owner-mpls@UU.NET  Wed Jun 28 08:56:24 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21520
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 08:56:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivnn00144;
	Wed, 28 Jun 2000 12:55:56 GMT
Received: by mail-control.mail.uu.net 
	id QQivnn24960
	for mpls-outgoing; Wed, 28 Jun 2000 12:55:35 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivnn24955
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 12:55:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivnn26363
	for <mpls@UU.NET>; Wed, 28 Jun 2000 08:55:22 -0400 (EDT)
Received: from baynet.baynetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20])
	id QQivnn20496
	for <mpls@UU.NET>; Wed, 28 Jun 2000 12:55:21 GMT
Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107])
	by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id FAA21493;
	Wed, 28 Jun 2000 05:53:46 -0700 (PDT)
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6])
	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id FAA21724;
	Wed, 28 Jun 2000 05:53:42 -0700 (PDT)
Received: from bubba.engeast (bubba [192.168.136.194])
	by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP
	id IAA22884; Wed, 28 Jun 2000 08:55:14 -0400
	for 
Received: by bubba.engeast (SMI-8.6/SMI-SVR4)
	id IAA25953; Wed, 28 Jun 2000 08:55:13 -0400
From: dwilder@baynetworks.com (David Wilder)
Message-Id: <200006281255.IAA25953@bubba.engeast>
Subject: Re: A question about PPP and POS
In-Reply-To: <Pine.LNX.4.10.10006281711561.6019-100000@sepahan.iut.ac.ir> from
 Manshaee Mohammad-Hossein at "Jun 28, 2000 05:18:09 pm"
To: Manshaee Mohammad-Hossein <s7627237@sepahan.iut.ac.ir>
Date: Wed, 28 Jun 2000 08:55:13 -0400 (EDT)
CC: Eric Gray <EGray@zaffire.com>,
        "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
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

Hi,

The MPLS Label stack encoding Draft (draft-ietf-mpls-label-encaps-07.txt)
discusses PPP.

Dave

> 
> Hi,
> 
> Is there any draft for MPLS over SONET or PPP ...?
> 
> Would you please explain about this subject for me?
> 
> Best regards,
> 
> MH Manshaei
> 
> 
>  
> 
> 



From owner-mpls@UU.NET  Wed Jun 28 09:44:46 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22971
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 09:44:46 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivnq03426;
	Wed, 28 Jun 2000 13:43:52 GMT
Received: by mail-control.mail.uu.net 
	id QQivnq09335
	for mpls-outgoing; Wed, 28 Jun 2000 13:43:17 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivnq09322
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 13:43:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivnq16768
	for <mpls@UU.NET>; Wed, 28 Jun 2000 09:42:50 -0400 (EDT)
Received: from mason2.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mason2.gmu.edu [129.174.1.11])
	id QQivnq02447
	for <mpls@UU.NET>; Wed, 28 Jun 2000 13:42:35 GMT
Received: from localhost (rpapneja@localhost)
	by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA01375;
	Wed, 28 Jun 2000 09:42:33 -0400 (EDT)
Date: Wed, 28 Jun 2000 09:42:33 -0400 (EDT)
From: Rajiv Papneja <rpapneja@osf1.gmu.edu>
X-Sender: rpapneja@mason2.gmu.edu
To: LI-CHUNG CHANG <lchang4@osf1.gmu.edu>, Haoxin Song <hsong@osf1.gmu.edu>
cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: Re: A question about PPP and POS
In-Reply-To: <Pine.LNX.4.10.10006281711561.6019-100000@sepahan.iut.ac.ir>
Message-ID: <Pine.OSF.4.21.0006280934020.32573-100000@mason2.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi there 

 Any more comments on this : 

--------
Hi Manshaee,

 There is one draft available that discusses MPLS-TE for
Sonet/SDH(draft-bernstein-mpls-sonet-00.txt). I hope this will be of some
help to you.

 Regards

 Rajiv
   

On Wed, 28 Jun 2000, Manshaee Mohammad-Hossein wrote:

> 
> Hi,
> 
> Is there any draft for MPLS over SONET or PPP ...?
> 
> Would you please explain about this subject for me?
> 
> Best regards,
> 
> MH Manshaei
> 
> 
>  
> 
> 
> 





From owner-mpls@UU.NET  Wed Jun 28 10:05:24 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23520
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 10:05:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivns10029;
	Wed, 28 Jun 2000 14:04:35 GMT
Received: by mail-control.mail.uu.net 
	id QQivns16855
	for mpls-outgoing; Wed, 28 Jun 2000 14:04:15 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivns16783
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 14:04:10 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivns20642
	for <mpls@uu.net>; Wed, 28 Jun 2000 10:04:01 -0400 (EDT)
Received: from web5302.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5302.mail.yahoo.com [216.115.106.111])
	id QQivns09553
	for <mpls@uu.net>; Wed, 28 Jun 2000 14:04:01 GMT
Message-ID: <20000628140400.29313.qmail@web5302.mail.yahoo.com>
Received: from [192.32.148.69] by web5302.mail.yahoo.com; Wed, 28 Jun 2000 07:04:00 PDT
Date: Wed, 28 Jun 2000 07:04:00 -0700 (PDT)
From: Pratik Shah <pms_tech@yahoo.com>
Subject: crldp mpls implementation on FreeBSD ??
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi

I am looking for a  LDP-CRLDP mpls implementation on
FreeBSD. The one on NIST is RSVP based.

Can anyone guide me to a resource, if there is one.

Thanks,
Pratik.

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/


From owner-mpls@UU.NET  Wed Jun 28 13:25:03 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28359
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 13:25:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivof09683;
	Wed, 28 Jun 2000 17:24:03 GMT
Received: by mail-control.mail.uu.net 
	id QQivof19416
	for mpls-outgoing; Wed, 28 Jun 2000 17:23:43 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivof19402
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 17:23:36 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivof16550
	for <mpls@UU.NET>; Wed, 28 Jun 2000 13:23:20 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivof02830
	for <mpls@UU.NET>; Wed, 28 Jun 2000 17:23:05 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDL3X>; Wed, 28 Jun 2000 10:29:34 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690829@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Francois Le Faucheur'" <flefauch@cisco.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>,
        Eric Gray
	 <EGray@zaffire.com>
Subject: RE: Last call comments
Date: Wed, 28 Jun 2000 10:29:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Francois,

	Thanks for the well considered replies.

	See several embedded replies below.  Please 
pardon the numerous "clippings".


> >
> >       There are several aspects of the uniform model
> >which appear complex beyond any justification I have
> >seen for specifying this model.
> >
> 
> Two motivations are already mentioned in the draft for why the 
> Uniform model is seen as very useful. This summarises 
> discussions we have had on that topic and corresponding 
> conclusions:
> 
> "Use of the Uniform Model allows LSPs to span Diff-Serv 
>  domain boundaries without any other measure in place 
>  than an inter-domain Traffic Conditioning Agreement at 
>  the physical boundary between the Diff-Serv domains and 
>  operating exclusively on the "outer" header, since the 
>  meaningful Diff-Serv information is always visible and 
>  modifiable in the outmost label entry.
> 
>  The Uniform Model for Diff-Serv over MPLS is such that, 
>  from the Diff-Serv perspective, operations are exactly 
>  identical to the operations if MPLS was not used."
> 
> The Uniform model is useful and should stay in this draft.

If the Uniform model is to stay in the draft, then it is
not sufficient to say that the means for mapping the PHB
represented by EXP bits in the label being popped to the
PHB in the newly exposed label is "out of scope".  This
means that there may be significant work left to do for
this draft.  Or not.

The reason why it is not sufficient to punt on this is
because the putative intent is to preserve operations
"exactly identical to the operations if MPLS was not used."
Therefore, the means for ensuring that the PHB that results
from the combination of PHB demotion within an LSP and the
mapping this demoted PHB to a PHB at the LSP egress (or 
penultimate hop) is the same as the PHB that would have 
resulted if the demotion occurred outside of the LSP.

This complication further breaks down into the issue of
whether or not demotion can occur within an LSP and the
issue of how a demotion represented by the flipping of
a single bit is to be mapped to a specific demotion in
a 3 bit EXP field (in an MPLS label) or a 6 bit DS field
(in an IP header).  If the PHB cannot be changed within
an LSP, than the use of the Uniform model is unjustified 
(the field copied outward and then inward cannot have 
changed - therefore the effort to copy it is wasted).
So, for the uniform model to make sense, it must be
possible that the PHB would change (demotion, promotion
or other modification) within an LSP.  I'll allow that
there may be some strange application for nested policing
or traffic conditioning behavior that is expected to have
a concatenated effect on traffic even as it leaves lower
level LSP tunnels, so this may be the case.

From my reading of sections 3.4.2 and 3.4.3, it appears
to me that demotion may be somewhat problematic if using
either ATM or FR since setting the DE/CLP bit seems to
uniformly transform an EF PHB to an AF PHB.  Unless I've
misunderstood something pretty fundamental, that would
make the new PHB no longer a part of the same OA within
an E-LSP.  Even if this is not an issue, it WILL make 
mapping the result to the same PHB that would have been
the result if MPLS were not used somewhat non-trivial.

(By the way, has anyone considered the impact on ATM
 and FR hardware behavior of using the CLP/DE values
 given in this version of the specification?  Or is it
 the assumption that MPLS over ATM/FR will interpret
 these bits differently in hardware than they have been
 interpreted previously?) 

On the other hand, if the EXP field is used for PHB 
determination within an LSP, I do not see why we need
to say anything more than that the EXP field in the 
label being popped is copied to the label thus exposed
when using the uniform model.  The fact that it might 
be mapped to a new PHB just before, or just after, this 
copy operation (e.g. - based on a local DiffServ domain 
policy) is completely orthogonal to the copy operation 
itself.

So, if my understanding is correct, the only useful
"mapping" of EXP field values at egress/PHP is a copy
operation.  This immensely simplifies what we have to
implement to support the uniform model.  In addition,
it also makes almost all of the discussion of the two
models and differences in related behavior go away.

> 
> >       The draft punts on several relevant issues.  In
> >particular, there seems to be no effort to justify 
> >some of the complexity in the specification in terms 
> >of real world applications for particularly difficult
> >combinations (such as the combination of Uniform model 
> >and PHP).  If the uniform model is intended for the
> 
> See above. You may have missed the earlier discussions on 
> the alias but this was discussed. and there is corresponding 
> text in the spec already giving an example of where uniform 
> is useful.

I did a search (using Netscape's 'Search Messages' function)
for all MPLS related messages containing the word 'uniform'.
I also read the minutes from Adelaide (I'm not going to be
forever apologizing for not having been able to get there).
The 'discussion' in each case was decidedly one-sided.  I
did not notice anyone, other than the authors of the draft,
clamoring for inclusion of the uniform model.  I did a like
search in the DiffServ mailing list - which I already said
something about in a different message - and found a similar
silence from the throngs.

This is the first draft in which the two models are discussed
and it is also the draft on which we have been asked to give
last call comments.  I stated that the Uniform model is not
sufficiently well documented and should be removed.  You say
it stays.

Sounds perfectly reasonable to me.  You still need to address
the issue that it is not sufficiently well documented.

> 
> I feel that PHP has been justified enough by the MPLS 
> architecture document.

Let's not pretend that I didn't say "the combination of 
Uniform model and PHP".                  ===========
              ===

I am perfectly well aware that PHP is here to stay.  The
combination of the Uniform model and PHP is a complexity
that many may find difficult to swallow.  And, unlike PHP
in general, it is a NEW complexity.

> 
> The reason we "attempt" to support uniform is that the 
> group's agreed on the alias that it was useful.

The group 'agreed' (mostly by its silence) that it would
be useful to specify something about the Uniform model.
You folks have made one attempt to do this and my comment
is that it is either not enough, or too much.  See above.

> >
> >       Section 1.6 - can signaled bandwidth also be used 
> >for policing packets associated with a PSC?  How does an
> >implementation know if it is supposed to use signaled
> >bandwidth to perform any of the functions mentioned in
> >this section (adjusting scheduling weights, admission
> >control and, possibly, policing)?
> >
> 
> same as usual: outside the scope of this spec, could be by 
> local config, policy, SNMP,...
> do you think it would add value to state so?

How would you configure which function to apply for each
specific LSP for which bandwidth might be signaled?  Will
this be a global, per-interface or per-LSP parameter?  If
it is supposed to be per-LSP, why bother with signaling?

Can the signaled bandwidth be used for one purpose at one
LSR along the LSP and another at another LSR?  This affects
the scope of configuration since, if it is expected to be
consistent, then it must be configured either per-LSP or
globally within a DiffServ domain.

Is the list of potential functions intended to be exhaustive?  
If so, then it needs more entries.  If not, and the bandwidth 
signaled is intended to be used consistently throughout an
LSP, then what is the minimal set of possible functions that
every LSP should support in order to achieve a useful level
of interoperability?

> 
> >In addition, the following definitions would be useful
> >(collected in a glossary?):
> >
> >Behavior Aggregate
> >               Packets crossing a link that require
> >               the same Diff-Serv behavior.
> >Diff-Serv      Differentiated Services.
> >Diff-Serv Context
> >               <Insert Definition HERE>
> >FEC            <Insert Definition HERE>
> >Ordered Aggregate
> >               Set of Behavior Aggregates sharing an 
> >               ordering constraint.
> >PHB Scheduling Class
> >               Set of PHBs applicable to an Ordered 
> >               Aggregate.
> >
> >
> 
> I would prefer to leave them out.

Okay by me.  It might be useful if there was a statement
somewhere stating where these definitions can be found.
Of course, if the answer is not simple, it might be easier
to just include the definitions.  There are precedents
among the other MPLS drafts.

> 
> Francois
>                      --------
> >  
> _________________________________________________________________
> Francois Le Faucheur   
> Development Engineer, IOS Layer 3 Services 
> Cisco Systems 
> Office Phone:   	+33 4 92 96 75 64
> Home Office Phone:     +33 4 92 94 00 78
> Mobile :               +33 6 89 108 159
> Vmail:                 +33 1 58 04 62 66
> Fax:                   +33 4 92 96 79 08
> Email:          	flefauch@cisco.com
> _________________________________________________________________
> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 
> Valbonne - France
> _________________________________________________________________ 
> 


From owner-mpls@UU.NET  Wed Jun 28 13:42:12 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28726
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 13:42:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivog15795;
	Wed, 28 Jun 2000 17:41:15 GMT
Received: by mail-control.mail.uu.net 
	id QQivog21307
	for mpls-outgoing; Wed, 28 Jun 2000 17:40:44 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivog21291
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 17:40:34 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivog22668
	for <mpls@UU.NET>; Wed, 28 Jun 2000 13:40:25 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivog15104
	for <mpls@UU.NET>; Wed, 28 Jun 2000 17:40:24 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDLQW>; Wed, 28 Jun 2000 10:46:54 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269082C@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Francois Le Faucheur'" <flefauch@cisco.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>,
        Eric Gray
	 <EGray@zaffire.com>
Subject: RE: Last call comments
Date: Wed, 28 Jun 2000 10:46:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Francois,

	Again, thanks for the reply and pardon clippings.

	See comment below.

--
Eric Gray

> 
> >
> >	I also agree with Grenville's comments 13 and 14
> >and add to his first comment that - like the Uniform
> >model - ECN needs either to be better documented or
> >not included.  If there were a relatively mature draft
> >that stated how ECN would be done using the EXT bits,
> >then it is obvious that this draft would have to address
> >how its usage of the EXT bits can be coordinated with 
> >the ECN usage.  As it now is, this section seems to be
> >trying to establish backward compatibility with some
> >non-existant function.
> 
> >
> 
> We've already discussed this and have a proposal on how to 
> adress this.

For the record, are you saying that you plan to adopt the 
wording suggested by Grenville (and tentatively accepted
by Juha)?

> _________________________________________________________________
> Francois Le Faucheur   
> Development Engineer, IOS Layer 3 Services 
> Cisco Systems 
> Office Phone:   	+33 4 92 96 75 64
> Home Office Phone:     +33 4 92 94 00 78
> Mobile :               +33 6 89 108 159
> Vmail:                 +33 1 58 04 62 66
> Fax:                   +33 4 92 96 79 08
> Email:          	flefauch@cisco.com
> _________________________________________________________________
> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 
> Valbonne - France
> _________________________________________________________________ 
> 


From owner-mpls@UU.NET  Wed Jun 28 15:03:27 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01984
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 15:03:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivom19886;
	Wed, 28 Jun 2000 19:02:45 GMT
Received: by mail-control.mail.uu.net 
	id QQivom18924
	for mpls-outgoing; Wed, 28 Jun 2000 19:02:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivom18445
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 19:02:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivom02989
	for <mpls@uu.net>; Wed, 28 Jun 2000 15:01:56 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivom18943
	for <mpls@uu.net>; Wed, 28 Jun 2000 19:01:56 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA19371
	for mpls@uu.net; Wed, 28 Jun 2000 15:01:55 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivom16396
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 19:01:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivom02554
	for <mpls@UU.NET>; Wed, 28 Jun 2000 15:01:13 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQivom25724
	for <mpls@UU.NET>; Wed, 28 Jun 2000 19:01:13 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA18787;
	Wed, 28 Jun 2000 11:59:57 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <NCLJAVLA>; Wed, 28 Jun 2000 12:01:10 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4065A@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric Gray'" <EGray@zaffire.com>,
        "'Francois Le Faucheur'"
	 <flefauch@cisco.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: Last call comments
Date: Wed, 28 Jun 2000 12:00:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

Thanks for your comments. Here are some answers:

>-----Original Message-----
>From: Eric Gray [mailto:EGray@zaffire.com]
>Sent: Wednesday, June 28, 2000 1:29 PM
>To: 'Francois Le Faucheur'
>Cc: MPLS Mailing List (E-mail); Eric Gray
>Subject: RE: Last call comments
>
>
>Francois,
>
>	Thanks for the well considered replies.
>
>	See several embedded replies below.  Please 
>pardon the numerous "clippings".
>
>
>> >
>> >       There are several aspects of the uniform model
>> >which appear complex beyond any justification I have
>> >seen for specifying this model.
>> >
>> 
>> Two motivations are already mentioned in the draft for why the 
>> Uniform model is seen as very useful. This summarises 
>> discussions we have had on that topic and corresponding 
>> conclusions:
>> 
>> "Use of the Uniform Model allows LSPs to span Diff-Serv 
>>  domain boundaries without any other measure in place 
>>  than an inter-domain Traffic Conditioning Agreement at 
>>  the physical boundary between the Diff-Serv domains and 
>>  operating exclusively on the "outer" header, since the 
>>  meaningful Diff-Serv information is always visible and 
>>  modifiable in the outmost label entry.
>> 
>>  The Uniform Model for Diff-Serv over MPLS is such that, 
>>  from the Diff-Serv perspective, operations are exactly 
>>  identical to the operations if MPLS was not used."
>> 
>> The Uniform model is useful and should stay in this draft.
>
>If the Uniform model is to stay in the draft, then it is
>not sufficient to say that the means for mapping the PHB
>represented by EXP bits in the label being popped to the
>PHB in the newly exposed label is "out of scope".  This
>means that there may be significant work left to do for
>this draft.  Or not.

Eric, let's not confuse people. We didn't say that in the Uniform model, the
mapping from top label to the lower label is out of the scope. What we  said
is that if PHP is not used, then Uniform model can be implemented easily,
because the egress node HAS the mapping information for both top and lower
label. While in the PHP case, the penultimate node requires mapping
information for the lower label, that it normally does not have. 

What we said is that the way to provide this information in the PHP mode is
out of the scope of this draft. That doesn't mean that people can't use
Uniform model NOW, the non-PHP mode can always be used successfully and
easily. 

>
>The reason why it is not sufficient to punt on this is
>because the putative intent is to preserve operations
>"exactly identical to the operations if MPLS was not used."
>Therefore, the means for ensuring that the PHB that results
>from the combination of PHB demotion within an LSP and the
>mapping this demoted PHB to a PHB at the LSP egress (or 
>penultimate hop) is the same as the PHB that would have 
>resulted if the demotion occurred outside of the LSP.
>

Please see above.

>This complication further breaks down into the issue of
>whether or not demotion can occur within an LSP and the
>issue of how a demotion represented by the flipping of
>a single bit is to be mapped to a specific demotion in
>a 3 bit EXP field (in an MPLS label) or a 6 bit DS field
>(in an IP header).  

Yes, the PHB might be changed (even the diffserv WG has not intentionally
precluded traffic conditioning within a network). What you are talking is
mapping from top label, which is an L-LSP to the lower label which is an
E-LSP, or to the IP header (DSCP). This is easily done in ultimate hop
(non-PHP), because ultimate hop is acting as an LSR for both upper and lower
label, and therefore has all the mapping information for both.


If the PHB cannot be changed within
>an LSP, than the use of the Uniform model is unjustified 
>(the field copied outward and then inward cannot have 
>changed - therefore the effort to copy it is wasted).

Please see above.

>So, for the uniform model to make sense, it must be
>possible that the PHB would change (demotion, promotion
>or other modification) within an LSP.  I'll allow that
>there may be some strange application for nested policing
>or traffic conditioning behavior that is expected to have
>a concatenated effect on traffic even as it leaves lower
>level LSP tunnels, so this may be the case.

Sure.

>
>From my reading of sections 3.4.2 and 3.4.3, it appears
>to me that demotion may be somewhat problematic if using
>either ATM or FR since setting the DE/CLP bit seems to
>uniformly transform an EF PHB to an AF PHB.

I think you have misunderstood these sections. As we have mentioned in the
draft, LC-ATM interfaces can not support E-LSP (they only support L-LSP).
That is why in these sections we have talked about non-LC-ATM interfaces. By
that we mean an E-LSP which is transiting a  Normal ATM network. To do so
you obviously need one VC per PSC. So when we talk about PHB->CLP mapping,
we actually mean Drop Precedence ->CLP mapping, and we have assumed that the
PSC is derived from the VC (or VCID). So it is impossible to transform from
EF to AF by flipping CLP bit.

  Unless I've
>misunderstood something pretty fundamental, that would
>make the new PHB no longer a part of the same OA within
>an E-LSP.  Even if this is not an issue, it WILL make 
>mapping the result to the same PHB that would have been
>the result if MPLS were not used somewhat non-trivial.
>
>(By the way, has anyone considered the impact on ATM
> and FR hardware behavior of using the CLP/DE values
> given in this version of the specification?  Or is it
> the assumption that MPLS over ATM/FR will interpret
> these bits differently in hardware than they have been
> interpreted previously?)

As I said, CLP/DE bits are always interpreted as drop-precedence. Be it in
ATM, MPLS, or this draft.

>
>On the other hand, if the EXP field is used for PHB 
>determination within an LSP, I do not see why we need
>to say anything more than that the EXP field in the 
>label being popped is copied to the label thus exposed
>when using the uniform model.

Because various levels of the tunnel may use different EXP<->PHB mapping.


  The fact that it might 
>be mapped to a new PHB just before, or just after, this 
>copy operation (e.g. - based on a local DiffServ domain 
>policy) is completely orthogonal to the copy operation 
>itself.

Please see above.

>
>So, if my understanding is correct, the only useful
>"mapping" of EXP field values at egress/PHP is a copy
>operation.  This immensely simplifies what we have to
>implement to support the uniform model.  In addition,
>it also makes almost all of the discussion of the two
>models and differences in related behavior go away.
>

This is not generally true. This is only true if different levels of
hierarchy use exactly the same mapping, and the upper and lower label are
the same type of LSP.

>> 
>> >       The draft punts on several relevant issues.  In
>> >particular, there seems to be no effort to justify 
>> >some of the complexity in the specification in terms 
>> >of real world applications for particularly difficult
>> >combinations (such as the combination of Uniform model 
>> >and PHP).  If the uniform model is intended for the
>> 
>> See above. You may have missed the earlier discussions on 
>> the alias but this was discussed. and there is corresponding 
>> text in the spec already giving an example of where uniform 
>> is useful.
>
>I did a search (using Netscape's 'Search Messages' function)
>for all MPLS related messages containing the word 'uniform'.
>I also read the minutes from Adelaide (I'm not going to be
>forever apologizing for not having been able to get there).
>The 'discussion' in each case was decidedly one-sided.  I
>did not notice anyone, other than the authors of the draft,
>clamoring for inclusion of the uniform model.  I did a like
>search in the DiffServ mailing list - which I already said
>something about in a different message - and found a similar
>silence from the throngs.
>
>This is the first draft in which the two models are discussed
>and it is also the draft on which we have been asked to give
>last call comments.  I stated that the Uniform model is not
>sufficiently well documented and should be removed.  You say
>it stays.
>
>Sounds perfectly reasonable to me.  You still need to address
>the issue that it is not sufficiently well documented.

I hop I could address those issues above.

>
>> 
>> I feel that PHP has been justified enough by the MPLS 
>> architecture document.
>
>Let's not pretend that I didn't say "the combination of 
>Uniform model and PHP".                  ===========
>              ===
>
>I am perfectly well aware that PHP is here to stay.  The
>combination of the Uniform model and PHP is a complexity
>that many may find difficult to swallow.  And, unlike PHP
>in general, it is a NEW complexity.
>
>> 
>> The reason we "attempt" to support uniform is that the 
>> group's agreed on the alias that it was useful.
>
>The group 'agreed' (mostly by its silence) that it would
>be useful to specify something about the Uniform model.
>You folks have made one attempt to do this and my comment
>is that it is either not enough, or too much.  See above.
>
>> >
>> >       Section 1.6 - can signaled bandwidth also be used 
>> >for policing packets associated with a PSC?  How does an
>> >implementation know if it is supposed to use signaled
>> >bandwidth to perform any of the functions mentioned in
>> >this section (adjusting scheduling weights, admission
>> >control and, possibly, policing)?
>> >
>> 
>> same as usual: outside the scope of this spec, could be by 
>> local config, policy, SNMP,...
>> do you think it would add value to state so?
>
>How would you configure which function to apply for each
>specific LSP for which bandwidth might be signaled?  Will
>this be a global, per-interface or per-LSP parameter?  If
>it is supposed to be per-LSP, why bother with signaling?
>
>Can the signaled bandwidth be used for one purpose at one
>LSR along the LSP and another at another LSR?  This affects
>the scope of configuration since, if it is expected to be
>consistent, then it must be configured either per-LSP or
>globally within a DiffServ domain.
>
>Is the list of potential functions intended to be exhaustive?  
>If so, then it needs more entries.  If not, and the bandwidth 
>signaled is intended to be used consistently throughout an
>LSP, then what is the minimal set of possible functions that
>every LSP should support in order to achieve a useful level
>of interoperability?
>


As I mentioned in my previous email, we are not trying to address these
issues in this draft. The point we are trying to make is that contrary to
the CoS object which required to discard the BW information in RSVP
messages, we want to keep the door open and do not require to discard BW
information when Diffserv object is present. Since this is in conflict with
CoS object, we have tried to resolve the conflict by providing a table of
all possible combinations and outcomes.

>> 
>> >In addition, the following definitions would be useful
>> >(collected in a glossary?):
>> >
>> >Behavior Aggregate
>> >               Packets crossing a link that require
>> >               the same Diff-Serv behavior.
>> >Diff-Serv      Differentiated Services.
>> >Diff-Serv Context
>> >               <Insert Definition HERE>
>> >FEC            <Insert Definition HERE>
>> >Ordered Aggregate
>> >               Set of Behavior Aggregates sharing an 
>> >               ordering constraint.
>> >PHB Scheduling Class
>> >               Set of PHBs applicable to an Ordered 
>> >               Aggregate.
>> >
>> >
>> 
>> I would prefer to leave them out.
>
>Okay by me.  It might be useful if there was a statement
>somewhere stating where these definitions can be found.
>Of course, if the answer is not simple, it might be easier
>to just include the definitions.  There are precedents
>among the other MPLS drafts.
>
>> 
>> Francois
>>                      --------
>> >  
>> _________________________________________________________________
>> Francois Le Faucheur   
>> Development Engineer, IOS Layer 3 Services 
>> Cisco Systems 
>> Office Phone:   	+33 4 92 96 75 64
>> Home Office Phone:     +33 4 92 94 00 78
>> Mobile :               +33 6 89 108 159
>> Vmail:                 +33 1 58 04 62 66
>> Fax:                   +33 4 92 96 79 08
>> Email:          	flefauch@cisco.com
>> _________________________________________________________________
>> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 
>> Valbonne - France
>> _________________________________________________________________ 
>> 
>



From owner-mpls@UU.NET  Wed Jun 28 15:38:51 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02598
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 15:38:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivoo22649;
	Wed, 28 Jun 2000 19:38:31 GMT
Received: by mail-control.mail.uu.net 
	id QQivoo28387
	for mpls-outgoing; Wed, 28 Jun 2000 19:37:57 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivoo28373
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 19:37:46 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivoo22431
	for <mpls@UU.NET>; Wed, 28 Jun 2000 15:37:27 -0400 (EDT)
Received: from rambo.globespan.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p1.globespan.net [209.191.59.250])
	id QQivoo21128
	for <mpls@UU.NET>; Wed, 28 Jun 2000 19:37:12 GMT
Received: from globespan.net (ROHIT [192.168.25.21]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id NN04FJYM; Wed, 28 Jun 2000 15:36:21 -0400
Message-ID: <395A53CC.4AD3BE14@globespan.net>
Date: Wed, 28 Jun 2000 15:36:44 -0400
From: Rohit Chhapolia <rohit@globespan.net>
Organization: Globespan, Inc.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>
CC: Yakov Rekhter <yakov@cisco.com>, mpls@UU.NET
Subject: Re: Question on draft-kompella-lsp-hierarchy-00.txt
References: <Your message of "Thu, 22 Jun 2000 16:48:07 EDT." <39527B87.B0A4FAA6@globespan.net> <4.3.2.7.2.20000627115155.00c0af00@mail.labn.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Lou,

Probably I don't understand something here. But I think
that if a message is not addressed directly to a node and
RA isn't included, it will be forwarded by the IP layer to
the next hop based on the destination address. It should be
treated just like any other data packet in this regard.

Rohit

Lou Berger wrote:
> 
> Yakov,
> 
> IP encapsulation *is* required on path messages as intermediate nodes may
> process the PATH message even if a router alert isn't included.
> 
> IP encapsulation of the Resv is beneficial as it ensures intermediate nodes
> don't hand the RSVP message to the RSVP code/module.  This is an
> optimization, hence "may" or "should" is appropriate.
> 
> Lou
> 
> At 02:57 PM 6/22/00 -0700, Yakov Rekhter wrote:
> >Rohit,
> >
> > > In the section 5.1, it is suggested that Path/Resv message
> > > should be encapsulated in another IP header if sent
> > > as unicast over the control plane. Can you please
> > > clarify why is this required?
> >
> >See below....
> >
> > > It should be possible to send the Resv message as it is.
> >
> >Agreed.
> >
> > > Path message can be sent without router alert to the
> > > next hop IP address. In this case, IP address of the tail
> > > end of the FA-LSP.
> >
> >Agreed.
> >
> >We'll correct the text in the next iteration of this document.
> >
> >Yakov.

-- 
Rohit Chhapolia
Globespan, Inc.
voice: 732-345-6237
mailto:rohit@globespan.net
http://www.globespan.net


From owner-mpls@UU.NET  Wed Jun 28 16:39:35 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03896
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 16:39:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivos18942;
	Wed, 28 Jun 2000 20:39:06 GMT
Received: by mail-control.mail.uu.net 
	id QQivos16452
	for mpls-outgoing; Wed, 28 Jun 2000 20:38:42 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivos16447
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 20:38:40 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivos02921
	for <mpls@uu.net>; Wed, 28 Jun 2000 16:38:21 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivos18193
	for <mpls@uu.net>; Wed, 28 Jun 2000 20:38:21 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA02843
	for mpls@uu.net; Wed, 28 Jun 2000 16:38:20 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivos16364
	for <mpls@mail-control.mail.uu.net>; Wed, 28 Jun 2000 20:37:51 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivos23402
	for <mpls@UU.NET>; Wed, 28 Jun 2000 16:37:39 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQivos17640
	for <mpls@UU.NET>; Wed, 28 Jun 2000 20:37:39 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id NAA05707;
	Wed, 28 Jun 2000 13:18:47 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <NCLJAW3D>; Wed, 28 Jun 2000 13:20:00 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4065B@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric Gray'" <EGray@zaffire.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: Last call comments
Date: Wed, 28 Jun 2000 13:19:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Eric,

Thanks for your comments. Here are my response:

>-----Original Message-----
>From: Eric Gray [mailto:EGray@zaffire.com]
>Sent: Tuesday, June 27, 2000 7:51 PM
>To: 'Shahram Davari'
>Cc: MPLS Mailing List (E-mail)
>Subject: RE: Last call comments
>
>
>Shahram,
>
>	Please understand that I am not attacking the
>current version of the draft.  George gave us a short
>amount of time in which to 'give it our best shot'.
>
>	Bang.  :-)
>
>	Please see below.  For the sake of brevity, I
>have heavily edited included text without inserting
>appropriate <snip> indications...
>
>> >
>> >   "(1) Tunneling Model 1 (either Uniform or Pipe)
>> >
>> >   "(2) Tunneling Model 2 (same as Tunneling Model 1 or 
>> >different Model)"
>> 
>> This is a useful statement. We just need to change the 
>> wording. For example
>> to:
>> 
>>   "(1) Tunneling level 1 (either Uniform or Pipe)
>> 
>>   "(2) Tunneling level 2 (either Uniform or Pipe)"
>> 
>> Do you see anything wrong with this new wording?
>> 
>
>Part of the problem, is that I do not believe that
>two models are needed.  I mention that in separate
>mail, so I will suspend disbelief for most of this 
>reply.  This is NOT the same as placid acceptance 
>of the 2 models.
>
>This wording is not much clearer.  I might suggest 
>
>   "(1) Tunneling level 1
>    (2) Tunneling level 2
>
>   "The relationship between the two levels may be
>    based on either the Pipe or the Uniform model."
>
>Note that the model relates to how the two levels
>INTERACT and therefore is not a characteristic of
>the levels themselves.
>
>The problem that still remains with the suggested 
>text is that it still does not convey the meaning
>you want.  Thus I would further suggest
>
>   "(1) Tunneling level 1
>    (2) Tunneling level 2
>    (3) Tunneling level 3
>
>   "The relationship between levels 1 and 2, and
>    between 2 and 3 may be based on either the
>    Pipe or the Uniform model. The relationships 
>    need not be the same in all cases."
>

Sure. It looks fine.


>> 
>> >Or at the bottom of page 16, top of page 17:
>> >
>> >   "LSRs at different levels of LSPs are expected to operate 
>> >in the same 
>> >    or in different Tunneling Models."
>> >
>> >I believe these may be examples of an earlier comment 
>> >on mixing of example deployments and normative text.
>> >
>> 
>> This is actually a normative text. Let me re-write it and see 
>> if you agree:
>> 
>> "It is not necessary for the LSRs at different 
>>  levels of LSPs to operate in the same tunneling 
>>  mode".
>
>An interestingly complicated statement.  If an
>LSR is used to carry (perhaps tunneled) labeled
>packets, even when it does not see the (tunneled)
>labels, is the LSR _at_ the level of these labeled 
>packets?
>
>Maybe
>
>   "In multilevel LSP tunneling, there is no
>    requirement for consistent tunneling modes
>    at all levels."
>

Sure. It looks fine.


>Note that this is not phrased as a positive
>statement (DO ... as opposed to DON'T DO ...)
>and I'm not sure how it could be.
>
>> >	There are many repeat definitions of Acronyms
>> >(places where the expanded version is followed by the
>> >Acronym in parentheses).  This makes the draft look 
>> >as if it was glued together from many pieces.  Either
>> >the acronyms should be collected, or only the first 
>> >instance should show both.  Currently, there are many
>> >cases where the acronym is first used before being 
>> >defined.
>> 
>> There are many new concepts in this draft, that are not 
>> published in any document before. Besides this is a large 
>> document, and finding the first instance of an acronym 
>> is not easy. I don't see any harm in writing the expanded 
>> version, if it makes reading the text easier. 
>> However, this is an editorial issue and if others object, 
>> we can easily remove the expanded versions.
>
>Or you could add a section that defines the acronyms.
>I think somebody may have thoughtfully provided you
>with the text for this section.

Sure we will do that.

>
>BTW - the fact that there are many new concepts in
>this draft (notably the two models) is part of the
>problem I'm having with the fact that it is going
>through 'last call' right now.
>
>  ... <text justifying redundancy moved to new thread> ...
>
>> 
>> >	Section 1.6 - can signaled bandwidth also be used 
>> >for policing packets associated with a PSC?  How does an
>> >implementation know if it is supposed to use signaled
>> >bandwidth to perform any of the functions mentioned in
>> >this section (adjusting scheduling weights, admission
>> >control and, possibly, policing)?
>> 
>> Signaled BW can potentially be used for all of the above. 
>> The way to identify which one, and how, is out of the 
>> scope of this document (New extensions to signaling may 
>> be required). All we have tried to do is to not preclude 
>> BW signaling in MPLS+Diffserv operations the way that CoS 
>> object did), that is all. If you like we can write that 
>> the details are outside the scope of this document. 
>
>My opinion: it is not particularly useful to declare work
>that MUST be done before the current work is useable as
>"out of scope" unless it is not important HOW it is done.
>Otherwise, a likely result of the current work is that it
>will succeed only in making more new work than it manages 
>to complete.  This - I believe - is in the category of
>diminishing returns and should be discouraged.  In this 
>case, it is important HOW it is done.  Otherwise, signaling
>bandwidth will not be both useful and interoperable.  Plus,
>one of the points I am making is that at least one possible
>case was omitted.
>

I have addressed this issue in my previous email. I hope you are convinced.

>> 
>> >
>> >	In section 2.1, this statement:
>> >
>> >  "Obviously, to enforce the Diff-Serv service 
>> >   differentiation the LSR MUST also apply the 
>> >   forwarding treatment corresponding to the
>> >   Outgoing PHB."
>> >
>> >makes no sense, given that - in the bullets that precede
>> >it - determination of the outgoing PHB is optional.  The
>> >bullet - based on following text - should say something to
>> >the effect that determination of a change in outgoing PHB
>> >is optional.
>> >
>> 
>> Off course determining the outgoing PHB is mandatory. The 
>> optional part is determining it through local policy and 
>> traffic conditioning. 
>> How about this new wording for the 2nd bullet:
>> 
>>  - Outgoing PHB Determination, which may be a copy of the 
>>    incoming PHB or may be via optional Local Policy and 
>>    Traffic Conditioning (B).
>
>Okay.
>
>> >	The statement "Based on these considerations ..." in
>> >the last paragraph of section 2.6.2 seems to be a non-sequitur
>> >- I cannot see the connection between the "considerations"
>> >and the conclusion.  For one thing, it seems almost to conclude
>> >that - because there is PHP in MPLS, and this makes it hard to
>> >determine what the EXP field was at the egress, then the uniform
>> >model (which makes it necessary to recover this information) is
>> >justified.
>> >
>> 
>> May be we should say "based on these observations...".
>> But I can't understand why you can't see any connection 
>> between the first 3 bullets and the conclusion? In the 
>> first 3 bullets We have shown that from the Diffserv 
>> perspective an MPLS tunnel basically is a tunnel, very 
>> similar to IP tunnel. So for Diffserv purpose we can use 
>> the same tunneling modes as the IP tunnel.
>
>Help me out here, by pretending I'm really very stupid.
>
>Are the Pipe and Uniform models characteristic of IP
>tunnel support for DiffServ that is documented in one
>or more of the references listed in this draft?  If
>so, which reference?
>
>The first 3 bullets do indeed show that MPLS support
>of DiffServ is in some ways like IP tunneling support
>of DiffServ.  The second set of 2 bullets shows that
>MPLS support of DiffServ may be unlike IP tunneling 
>support of DiffServ in one way (see BTW below).  From
>these considerations, I would conclude that DiffServ
>over MPLS may be like and unlike DiffServ support over
>IP Tunnels.  Not a very useful conclusion.
>
>Is one of the two models intended to represent DiffServ
>support over MPLS that is identical to DiffServ support
>over IP Tunnels?  If so, this is far from clear.
>
>BTW - the fact that there is no standard way to do PHP
>for IP tunneling is not the same as saying it cannot be
>done.  You could look at it as proxy termination of an
>IP tunnel.  Also, as it is possible for IP-in-IP tunnels
>to be nested, it is also possible to terminate more than
>one level of IP-in-IP tunneling at the same point in the 
>network.  To say that the fact that LSPs are used in MPLS 
>(nested or otherwise) makes MPLS different from IP tunnels
>is not a particularly interesting tautology.
>
>So, how do you arrive at the conclusion that two models
>are required based on the (boiled down) observation that
>MPLS support of DiffServ is like IP Tunnels support of
>DiffServ?  Please spell it out for me.
>

I believe Francois has covered this.

>> 
>> >	I believe that the uniform model should receive the same
>> >treatment as "other models" - i.e. - it should be treated as out
>> >of scope.  This removes a lot of seeming unjustified complexity 
>> >and about two pages of text.
>> 
>> Why? What would you do if you hadn't had MPLS? the Diffserv 
>> operation in Uniform model is exactly identical to Diffserv 
>> over non-MPLS network. Do you also think that we should 
>> remove the support of Diffserv transiting non-MPLS networks? 
>
>I haven't seen a draft or RFC on supporting DiffServ over IP
>Tunnels.
>

I think you have found now.

>I do not see one listed as a reference in the MPLS-DiffServ
>draft.  
>
>Therefore, I have to go with what I have seen for IP in IP 
>tunneling.  The RFC (RFC 2003) for this states that the IP
>header in the tunneled IP packet is left alone except for
>changing the TTL value.  This implies to me that - for IP 
>in IP tunneling at least - the combination of DiffServ and 
>IP in IP tunneling results in what we are currently calling 
>the Pipe model.  This makes a surprising amount of sense to
>me.  From this, I conclude that the "Uniform" model is an 
>aberration and I ask for better justification for it than I 
>have seen so far.  At the most, it may be necessary to state
>that the EXP bit values may be derived from corresponding 
>values in a popped label.  See other mail for wording on this.
> 
>> >
>> >	The draft needs a list of acronyms and/or a glossary.  
>> >The acronyms used (and, in some cases, introduced) in this 
>> >draft include:
>> >
>> >BA		Behavior Aggregates
>> >DSCP		Differentiated Services Code Point
>> >EXP		EXPerimental (bits)
>> >E-LSP		EXP-Inferred-PSC LSP
>> >FEC		Forwarding Equivalency Class
>> >FTN		FEC-To-NHLFE Map
>> >ILM		Incoming Label Map
>> >LSP		Label Switched Path
>> >LSR		Label Switch Router
>> >L-LSP		Label-Only-Inferred-PSC LSP
>> >MPLS		Multi-Protocol Label Switching
>> >NHLFE		Next Hop Label Forwarding Entry
>> >OA		Ordered Aggregate
>> >PHB		Per Hop Behavior
>> >PSC		PHB Scheduling Class
>> >
>

Fine.

>Oh, wait.  What's this?  it looks like a partial list 
>of acronyms.  :-)
>
>> 
>> Thanks,
>> 
>> -Shahram
>> 
>

Regards,
-Shahram



From owner-mpls@UU.NET  Wed Jun 28 20:35:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06840
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 20:35:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivpi08654;
	Thu, 29 Jun 2000 00:34:34 GMT
Received: by mail-control.mail.uu.net 
	id QQivpi27458
	for mpls-outgoing; Thu, 29 Jun 2000 00:34:14 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivpi27442
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 00:34:02 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivpi17063
	for <mpls@UU.NET>; Wed, 28 Jun 2000 20:33:55 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivpi08218
	for <mpls@UU.NET>; Thu, 29 Jun 2000 00:33:54 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDMQL>; Wed, 28 Jun 2000 17:40:24 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A662690834@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        Eric Gray
	 <EGray@zaffire.com>,
        "'Francois Le Faucheur'" <flefauch@cisco.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: Last call comments
Date: Wed, 28 Jun 2000 17:40:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

	Thanks for the clarification on use of DE/CLP.

	Could you please move the paragraph that says
"the Uniform Model allows LSPs to span Diff-Serv domain 
boundaries" (toward the bottom of page 12) to a spot
closer to the point at which this model is defined (e.g.
- 2.6.3).  This paragraph makes some things much clearer. 

	Let me see if I understand now.

The reason why the penultimate hop needs to perform the
EXP'->EXP conversion is because the next hop LSR cannot
tell the difference between PHP'd packets and non-PHP'd
packets therefore all packets have to arrive with correct
EXP (or DSCP) value for the applicable LSP stacking level.

	Is this correct?

	I seem to recall that there is not a lot of current 
interest in LSPs that span service boundaries.  So is it 
fair to say that there may not be a need to support the 
Uniform model in the very near future?  Yet the Uniform
model is specified as the 'base mandatory mode'.  The Pipe
model is clearly simpler to support with or without PHP
and the biggest operational difference is that it requires
LSP tunnels to be bound by DS Domains - which is likely to
be the dominant mode of operation in any case.  Can you 
provide additional clarification on this?

	A big part of my concern is that any LSR is likely 
to need to support PHP. The Uniform model imposes additional 
configuration requirements on penultimate hops.  This is 
bound to increase the configuration required in the network 
as a whole.  While configuration is an easy out in specifying 
protocol, it's not usually a GOOD THING.  What's more, the
specification should say what approach must be provided - so
that, for example, the need to specify a standard MIB for
configuring the required information is clear.

--
Eric Gray



From owner-mpls@UU.NET  Wed Jun 28 22:14:45 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08420
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 22:14:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivpo18596;
	Thu, 29 Jun 2000 02:14:28 GMT
Received: by mail-control.mail.uu.net 
	id QQivpo29491
	for mpls-outgoing; Thu, 29 Jun 2000 02:14:14 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivpo29480
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 02:14:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivpo17054
	for <mpls@UU.NET>; Wed, 28 Jun 2000 22:14:03 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49])
	id QQivpo18284
	for <mpls@UU.NET>; Thu, 29 Jun 2000 02:14:02 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Wed Jun 28 22:12:30 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA04674;
	Wed, 28 Jun 2000 22:13:07 -0400 (EDT)
Message-ID: <395AB187.5462D46D@dnrc.bell-labs.com>
Date: Wed, 28 Jun 2000 19:16:39 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Labs Research Silicon Valley
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois Le Faucheur <flefauch@cisco.com>
CC: mpls@UU.NET
Subject: E-LSP EXP<->PHB mapping Re: Last Call feedback on MPLS-Diff-Serv
References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francois,

I'm gradually getting time to continue our discussion of
my other points. In this email, my suggestion #9:

Francois Le Faucheur wrote:
	[..]
> >#9 Preconfigured E-LSP EXP<->PHB mapping?
> >
> >   Section 3.2.1 talks about a preconfigured EXP<->PHB mapping
> >   but does not suggest a default. I think the document ought to
> >   specify an actual default for EXP 000 to map to Best Effort PHB
> >   (or set of defaults where *all* EXP values map to BE).
> >
> 
> The Network Adminsitrator is expected to configure the
> "preconfigured EXP<->PHB mapping" depending on the BAs that
> are actually used in his/her network. Since differenet Network
> Administrators are likely to run differnet subsets of BAs it is
> difficult to define a Default mapping that would be generally
> useful.

Agreed, generally useful non-BE mappings would be hard to
get WG agreement on.

> But I guess you are saying , it would be useful to have
> a default mapping in case the preconfigured mapping hasn't been
> configured at all by the Network Adminsitrator. Right?

Yes. I contemplated suggesting a set of eight BAs, but
didn't want to open up a can of worms regarding which
eight BAs are important enough to mandate that an LSR
support. So....

> In that case, I suppose I woudl also map all EXP values
> towards BE.

Yes, I think it would be beneficial for the text to at least
nominate the default behavior for every EXP value (or at least
EXP=000) to be Best Effort. Although such a default is kind
of intuitive, its worth stating. The text can easily reassure
readers that local configuration is always entitled to override
the default.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Wed Jun 28 23:19:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09672
	for <mpls-archive@lists.ietf.org>; Wed, 28 Jun 2000 23:19:54 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivpt18201;
	Thu, 29 Jun 2000 03:19:36 GMT
Received: by mail-control.mail.uu.net 
	id QQivpt17570
	for mpls-outgoing; Thu, 29 Jun 2000 03:18:54 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivpt17550
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 03:18:39 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivpt25699
	for <mpls@uu.net>; Wed, 28 Jun 2000 23:18:21 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivpt28276
	for <mpls@uu.net>; Thu, 29 Jun 2000 03:18:20 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA03498
	for mpls@uu.net; Wed, 28 Jun 2000 23:18:20 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivpt17444
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 03:17:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivpt02559
	for <mpls@UU.NET>; Wed, 28 Jun 2000 23:17:18 -0400 (EDT)
Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pluris.com [208.227.9.12])
	id QQivpt16528
	for <mpls@UU.NET>; Thu, 29 Jun 2000 03:17:03 GMT
Received: from pluris.com (volsung.pluris.com [172.16.50.19])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA07805;
	Wed, 28 Jun 2000 20:16:59 -0700 (PDT)
Message-ID: <395ABFAA.E2F54722@pluris.com>
Date: Wed, 28 Jun 2000 20:16:58 -0700
From: Bora Akyol <akyol@pluris.com>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <EGray@zaffire.com>
CC: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Francois Le Faucheur'" <flefauch@cisco.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: Re: Last call comments
References: <9A564CC874B5D3118FB9009027B0A662690834@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric

I personally find the uniform model more useful than the pipe model. For
a transit backbone carrier, uniform model may make more sense than the
pipe model. The pipe model makes more sense VPNs, OXCs, etc.

Bora


Eric Gray wrote:

> Shahram,
>
>         Thanks for the clarification on use of DE/CLP.
>
>         Could you please move the paragraph that says
> "the Uniform Model allows LSPs to span Diff-Serv domain
> boundaries" (toward the bottom of page 12) to a spot
> closer to the point at which this model is defined (e.g.
> - 2.6.3).  This paragraph makes some things much clearer.
>
>         Let me see if I understand now.
>
> The reason why the penultimate hop needs to perform the
> EXP'->EXP conversion is because the next hop LSR cannot
> tell the difference between PHP'd packets and non-PHP'd
> packets therefore all packets have to arrive with correct
> EXP (or DSCP) value for the applicable LSP stacking level.
>
>         Is this correct?
>
>         I seem to recall that there is not a lot of current
> interest in LSPs that span service boundaries.  So is it
> fair to say that there may not be a need to support the
> Uniform model in the very near future?  Yet the Uniform
> model is specified as the 'base mandatory mode'.  The Pipe
> model is clearly simpler to support with or without PHP
> and the biggest operational difference is that it requires
> LSP tunnels to be bound by DS Domains - which is likely to
> be the dominant mode of operation in any case.  Can you
> provide additional clarification on this?
>
>         A big part of my concern is that any LSR is likely
> to need to support PHP. The Uniform model imposes additional
> configuration requirements on penultimate hops.  This is
> bound to increase the configuration required in the network
> as a whole.  While configuration is an easy out in specifying
> protocol, it's not usually a GOOD THING.  What's more, the
> specification should say what approach must be provided - so
> that, for example, the need to specify a standard MIB for
> configuring the required information is clear.
>
> --
> Eric Gray




From owner-mpls@UU.NET  Thu Jun 29 00:14:24 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10417
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 00:14:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivpw19426;
	Thu, 29 Jun 2000 04:14:04 GMT
Received: by mail-control.mail.uu.net 
	id QQivpw04177
	for mpls-outgoing; Thu, 29 Jun 2000 04:13:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivpw04161
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 04:13:34 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivpw02133
	for <mpls@UU.NET>; Thu, 29 Jun 2000 00:13:20 -0400 (EDT)
Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: griffin.host4u.net [209.150.128.163])
	id QQivpw00175
	for <mpls@UU.NET>; Thu, 29 Jun 2000 04:13:20 GMT
Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196])
	by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id XAA25783;
	Wed, 28 Jun 2000 23:13:07 -0500
Message-Id: <4.3.2.7.2.20000628205239.00db5540@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 28 Jun 2000 20:53:40 -0400
To: Rohit Chhapolia <rohit@globespan.net>
From: Lou Berger <lberger@labn.net>
Subject: Re: Question on draft-kompella-lsp-hierarchy-00.txt
Cc: Lou Berger <lberger@labn.net>, Yakov Rekhter <yakov@cisco.com>,
        mpls@UU.NET
In-Reply-To: <395A53CC.4AD3BE14@globespan.net>
References: <Your message of "Thu, 22 Jun 2000 16:48:07 EDT." <39527B87.B0A4FAA6@globespan.net>
 <4.3.2.7.2.20000627115155.00c0af00@mail.labn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Go back to RFC2205.  It allows for interception of protocol 46 even when RA 
is *not* included....

Lou

At 03:36 PM 6/28/00 -0400, Rohit Chhapolia wrote:
>Lou,
>
>Probably I don't understand something here. But I think
>that if a message is not addressed directly to a node and
>RA isn't included, it will be forwarded by the IP layer to
>the next hop based on the destination address. It should be
>treated just like any other data packet in this regard.
>
>Rohit
>
>Lou Berger wrote:
> >
> > Yakov,
> >
> > IP encapsulation *is* required on path messages as intermediate nodes may
> > process the PATH message even if a router alert isn't included.
> >
> > IP encapsulation of the Resv is beneficial as it ensures intermediate nodes
> > don't hand the RSVP message to the RSVP code/module.  This is an
> > optimization, hence "may" or "should" is appropriate.
> >
> > Lou
> >
> > At 02:57 PM 6/22/00 -0700, Yakov Rekhter wrote:
> > >Rohit,
> > >
> > > > In the section 5.1, it is suggested that Path/Resv message
> > > > should be encapsulated in another IP header if sent
> > > > as unicast over the control plane. Can you please
> > > > clarify why is this required?
> > >
> > >See below....
> > >
> > > > It should be possible to send the Resv message as it is.
> > >
> > >Agreed.
> > >
> > > > Path message can be sent without router alert to the
> > > > next hop IP address. In this case, IP address of the tail
> > > > end of the FA-LSP.
> > >
> > >Agreed.
> > >
> > >We'll correct the text in the next iteration of this document.
> > >
> > >Yakov.
>
>--
>Rohit Chhapolia
>Globespan, Inc.
>voice: 732-345-6237
>mailto:rohit@globespan.net
>http://www.globespan.net



From owner-mpls@UU.NET  Thu Jun 29 01:05:25 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10790
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 01:05:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivqa19927;
	Thu, 29 Jun 2000 05:05:03 GMT
Received: by mail-control.mail.uu.net 
	id QQivqa19747
	for mpls-outgoing; Thu, 29 Jun 2000 05:04:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivqa19685
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 05:04:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivqa18413
	for <mpls@UU.NET>; Thu, 29 Jun 2000 01:04:03 -0400 (EDT)
Received: from sasi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sasi.com [164.164.56.2])
	id QQivqa28539
	for <mpls@UU.NET>; Thu, 29 Jun 2000 05:04:00 GMT
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id KAA18650
	for <mpls@UU.NET>; Thu, 29 Jun 2000 10:32:52 +0530 (IST)
Received: from pcd75.sasi.com ([10.0.16.75]) by sasi.com; Thu, 29 Jun 2000 10:32:51 +0000 (IST)
Received: from localhost (gbnaidu@localhost)
	by pcd75.sasi.com (8.9.3/8.9.3) with ESMTP id KAA02597;
	Thu, 29 Jun 2000 10:32:43 +0530
Date: Thu, 29 Jun 2000 10:32:42 +0530 (IST)
From: "G.B.Naidu" <gbnaidu@sasi.com>
To: Pratik Shah <pms_tech@yahoo.com>
cc: mpls@UU.NET
Subject: Re: crldp mpls implementation on FreeBSD ??
In-Reply-To: <20000628140400.29313.qmail@web5302.mail.yahoo.com>
Message-ID: <Pine.LNX.4.21.0006291029430.763-100000@pcd75.sasi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Pratik,

currently there is no full pledged LDP implementation on FreeBSD. NIST
people are planning to bring it out.

I have done a customised LDP and kernel packet handler on FreeBSD. But I
cant give it to public due to privacy problems.  May be you or someone
interested can take this up and work. I am willing to help, but am quite
busy with the projects.

I would love to have some MPLS on FreeBSD.

regards
--gb

 On Wed, 28 Jun 2000, Pratik Shah
wrote:

> Hi
> 
> I am looking for a  LDP-CRLDP mpls implementation on
> FreeBSD. The one on NIST is RSVP based.
> 
> Can anyone guide me to a resource, if there is one.
> 
> Thanks,
> Pratik.
> 
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> 

-- 



From owner-mpls@UU.NET  Thu Jun 29 01:59:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16332
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 01:59:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivqd19753;
	Thu, 29 Jun 2000 05:59:16 GMT
Received: by mail-control.mail.uu.net 
	id QQivqd26028
	for mpls-outgoing; Thu, 29 Jun 2000 05:58:47 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivqd26007
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 05:58:31 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivqd12368
	for <mpls@uu.net>; Thu, 29 Jun 2000 01:58:26 -0400 (EDT)
Received: from sasi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sasi.com [164.164.56.2])
	id QQivqd19127
	for <mpls@uu.net>; Thu, 29 Jun 2000 05:58:23 GMT
Received: from samar (sasi.com [164.164.56.2])
	by sasi.com (8.9.3/8.9.3) with SMTP id LAA21010
	for <mpls@uu.net>; Thu, 29 Jun 2000 11:27:13 +0530 (IST)
Received: from pcd75.sasi.com ([10.0.16.75]) by sasi.com; Thu, 29 Jun 2000 11:27:11 +0000 (IST)
Received: from localhost (gbnaidu@localhost)
	by pcd75.sasi.com (8.9.3/8.9.3) with ESMTP id LAA02623
	for <mpls@uu.net>; Thu, 29 Jun 2000 11:27:06 +0530
Date: Thu, 29 Jun 2000 11:27:06 +0530 (IST)
From: "G.B.Naidu" <gbnaidu@sasi.com>
To: mpls@UU.NET
Subject: MPLS deployment...
Message-ID: <Pine.LNX.4.21.0006291125441.763-100000@pcd75.sasi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

I am interested to know about the various issues involved in the MPLS
deploument and interoperability. Could some one show me some pointers or
any inputs.

thanks
--gb

-- 



From owner-mpls@UU.NET  Thu Jun 29 08:00:13 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27352
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 08:00:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivrb25341;
	Thu, 29 Jun 2000 11:59:53 GMT
Received: by mail-control.mail.uu.net 
	id QQivrb07094
	for mpls-outgoing; Thu, 29 Jun 2000 11:59:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivrb07089
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 11:59:28 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivrb19609
	for <mpls@uu.net>; Thu, 29 Jun 2000 07:59:20 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivrb24759
	for <mpls@uu.net>; Thu, 29 Jun 2000 11:59:19 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA26703
	for mpls@uu.net; Thu, 29 Jun 2000 07:59:19 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivrb07077
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 11:59:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivrb19557
	for <mpls@UU.NET>; Thu, 29 Jun 2000 07:58:51 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQivrb24472
	for <mpls@UU.NET>; Thu, 29 Jun 2000 11:58:51 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 9DA4D114; Thu, 29 Jun 2000 13:58:49 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp18.cisco.com [144.254.60.40])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id NAA29465;
	Thu, 29 Jun 2000 13:58:47 +0200 (MET DST)
Message-Id: <200006291158.NAA29465@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Thu, 29 Jun 2000 13:56:15 +0200
To: Grenville Armitage <gja@dnrc.bell-labs.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: E-LSP EXP<->PHB mapping Re: Last Call feedback on
  MPLS-Diff-Serv
Cc: Francois Le Faucheur <flefauch@cisco.com>, mpls@UU.NET
In-Reply-To: <395AB187.5462D46D@dnrc.bell-labs.com>
References: <200006121753.NAA22286@lir.cisco.com>
 <200006262008.WAA24871@europe.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Grenville,

At 19:16 28/06/2000 -0700, Grenville Armitage wrote:
>Francois,
>
>I'm gradually getting time to continue our discussion of
>my other points. In this email, my suggestion #9:
>
>Francois Le Faucheur wrote:
>	[..]
>> >#9 Preconfigured E-LSP EXP<->PHB mapping?
>> >
>> >   Section 3.2.1 talks about a preconfigured EXP<->PHB mapping
>> >   but does not suggest a default. I think the document ought to
>> >   specify an actual default for EXP 000 to map to Best Effort PHB
>> >   (or set of defaults where *all* EXP values map to BE).
>> >
>> 
>> The Network Adminsitrator is expected to configure the
>> "preconfigured EXP<->PHB mapping" depending on the BAs that
>> are actually used in his/her network. Since differenet Network
>> Administrators are likely to run differnet subsets of BAs it is
>> difficult to define a Default mapping that would be generally
>> useful.
>
>Agreed, generally useful non-BE mappings would be hard to
>get WG agreement on.
>
>> But I guess you are saying , it would be useful to have
>> a default mapping in case the preconfigured mapping hasn't been
>> configured at all by the Network Adminsitrator. Right?
>
>Yes. I contemplated suggesting a set of eight BAs, but
>didn't want to open up a can of worms regarding which
>eight BAs are important enough to mandate that an LSR
>support. So....
>
>> In that case, I suppose I woudl also map all EXP values
>> towards BE.
>
>Yes, I think it would be beneficial for the text to at least
>nominate the default behavior for every EXP value (or at least
>EXP=000) to be Best Effort. Although such a default is kind
>of intuitive, its worth stating. The text can easily reassure
>readers that local configuration is always entitled to override
>the default.
>

makes sense to me. unless someone raises issues with this, we will add that default mapping.
thanks

Francois

>cheers,
>gja
>________________________________________________________________________
>Grenville Armitage                    http://members.home.net/garmitage/
>Bell Labs Research Silicon Valley
> 
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Thu Jun 29 08:42:16 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28867
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 08:42:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivre21443;
	Thu, 29 Jun 2000 12:41:51 GMT
Received: by mail-control.mail.uu.net 
	id QQivre21091
	for mpls-outgoing; Thu, 29 Jun 2000 12:41:29 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivre21063
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 12:41:23 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivre09429
	for <mpls@uu.net>; Thu, 29 Jun 2000 08:41:21 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivre20996
	for <mpls@uu.net>; Thu, 29 Jun 2000 12:41:21 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA00041
	for mpls@uu.net; Thu, 29 Jun 2000 08:41:20 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivre21045
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 12:40:59 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivre09115
	for <mpls@UU.NET>; Thu, 29 Jun 2000 08:40:44 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQivre20625
	for <mpls@UU.NET>; Thu, 29 Jun 2000 12:40:43 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id 95B85168; Thu, 29 Jun 2000 14:40:42 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp18.cisco.com [144.254.60.40])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA14465;
	Thu, 29 Jun 2000 14:40:40 +0200 (MET DST)
Message-Id: <200006291240.OAA14465@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Thu, 29 Jun 2000 14:36:36 +0200
To: Eric Gray <EGray@zaffire.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: RE: Last call comments
Cc: "'Francois Le Faucheur'" <flefauch@cisco.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>,
        Eric Gray <EGray@zaffire.com>, gja@dnrc.bell-labs.com
In-Reply-To: <9A564CC874B5D3118FB9009027B0A66269082C@ICARIAN>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 10:46 28/06/2000 -0700, Eric Gray wrote:
>Francois,
>
>	Again, thanks for the reply and pardon clippings.
>
>	See comment below.
>
>--
>Eric Gray
>
>> 
>> >
>> >	I also agree with Grenville's comments 13 and 14
>> >and add to his first comment that - like the Uniform
>> >model - ECN needs either to be better documented or
>> >not included.  If there were a relatively mature draft
>> >that stated how ECN would be done using the EXT bits,
>> >then it is obvious that this draft would have to address
>> >how its usage of the EXT bits can be coordinated with 
>> >the ECN usage.  As it now is, this section seems to be
>> >trying to establish backward compatibility with some
>> >non-existant function.
>> 
>> >
>> 
>> We've already discussed this and have a proposal on how to 
>> adress this.
>
>For the record, are you saying that you plan to adopt the 
>wording suggested by Grenville (and tentatively accepted
>by Juha)?
>

Yes.

>> _________________________________________________________________
>> Francois Le Faucheur   
>> Development Engineer, IOS Layer 3 Services 
>> Cisco Systems 
>> Office Phone:   	+33 4 92 96 75 64
>> Home Office Phone:     +33 4 92 94 00 78
>> Mobile :               +33 6 89 108 159
>> Vmail:                 +33 1 58 04 62 66
>> Fax:                   +33 4 92 96 79 08
>> Email:          	flefauch@cisco.com
>> _________________________________________________________________
>> Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 
>> Valbonne - France
>> _________________________________________________________________ 
>> 
> 
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Thu Jun 29 09:21:40 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06409
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 09:21:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivrh18229;
	Thu, 29 Jun 2000 13:21:06 GMT
Received: by mail-control.mail.uu.net 
	id QQivrh04626
	for mpls-outgoing; Thu, 29 Jun 2000 13:20:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivrh04621
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 13:20:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivrh00617
	for <mpls@uu.net>; Thu, 29 Jun 2000 09:20:08 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivrh00787
	for <mpls@uu.net>; Thu, 29 Jun 2000 13:20:07 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA03823
	for mpls@uu.net; Thu, 29 Jun 2000 09:20:07 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivrh04580
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 13:19:33 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivrh00461
	for <mpls@UU.NET>; Thu, 29 Jun 2000 09:19:24 -0400 (EDT)
Received: from ogma.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ogma.cisco.com [144.254.74.39])
	id QQivrh00155
	for <mpls@UU.NET>; Thu, 29 Jun 2000 13:19:24 GMT
Received: from europe.cisco.com (europe.cisco.com [144.254.52.73])
	by ogma.cisco.com (Postfix) with ESMTP
	id EB85BB5; Thu, 29 Jun 2000 15:19:23 +0200 (MET DST)
Received: from flefauch-8kcdt.cisco.com (nice-dhcp18.cisco.com [144.254.60.40])
	by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA29591;
	Thu, 29 Jun 2000 15:19:22 +0200 (MET DST)
Message-Id: <200006291319.PAA29591@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Thu, 29 Jun 2000 15:16:35 +0200
To: Eric Gray <EGray@zaffire.com>
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: RE: Last call comments
Cc: "'Francois Le Faucheur'" <flefauch@cisco.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>,
        Eric Gray <EGray@zaffire.com>
In-Reply-To: <9A564CC874B5D3118FB9009027B0A662690829@ICARIAN>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

At 10:29 28/06/2000 -0700, Eric Gray wrote:
>Francois,
>
>	Thanks for the well considered replies.
>
>	See several embedded replies below.  Please 
>pardon the numerous "clippings".
>
>
>> >

I have clipped the parts Shahram has already answered.

>> 
>> >       The draft punts on several relevant issues.  In
>> >particular, there seems to be no effort to justify 
>> >some of the complexity in the specification in terms 
>> >of real world applications for particularly difficult
>> >combinations (such as the combination of Uniform model 
>> >and PHP).  If the uniform model is intended for the
>> 
>> See above. You may have missed the earlier discussions on 
>> the alias but this was discussed. and there is corresponding 
>> text in the spec already giving an example of where uniform 
>> is useful.
>
>I did a search (using Netscape's 'Search Messages' function)
>for all MPLS related messages containing the word 'uniform'.
>I also read the minutes from Adelaide (I'm not going to be
>forever apologizing for not having been able to get there).

Refering to earlier discussion was not to prompt apologies from you, it was to let you know that there is some earlier discussion that are worth considering before jumping to any conclusion.

>The 'discussion' in each case was decidedly one-sided.  I
>did not notice anyone, other than the authors of the draft,
>clamoring for inclusion of the uniform model.  I did a like

Most discussion on this topic actually happened before we proposed applying the work of "Diff-Serv over Tunnel" to MPLS. Consequently, it happened before the terms uniform and pipe were proposed.

Ken Ballou initiated a thread which lead to an argument for support of uniform model.
Also, you will find included at the bottom a email from Curtis which I take as an endorsment of the proposal for Uniform model and pipe model.
Neither are co-authors.
I have not seen a single message arguing against support of uniform model until yours (there's been messages arguing for pipe model but those were not arguing against uniform model).

So, I'll just assume your above judgment of one-sidedness resulted from an incomplete "search" on related material.


>search in the DiffServ mailing list - which I already said
>something about in a different message - and found a similar
>silence from the throngs.
>
>This is the first draft in which the two models are discussed
>and it is also the draft on which we have been asked to give
>last call comments.  I stated that the Uniform model is not
>sufficiently well documented and should be removed.  You say
>it stays.
>
>Sounds perfectly reasonable to me.  You still need to address
>the issue that it is not sufficiently well documented.
>

Shahram's working on this with you.



>> 
>> >In addition, the following definitions would be useful
>> >(collected in a glossary?):
>> >
>> >Behavior Aggregate
>> >               Packets crossing a link that require
>> >               the same Diff-Serv behavior.
>> >Diff-Serv      Differentiated Services.
>> >Diff-Serv Context
>> >               <Insert Definition HERE>
>> >FEC            <Insert Definition HERE>
>> >Ordered Aggregate
>> >               Set of Behavior Aggregates sharing an 
>> >               ordering constraint.
>> >PHB Scheduling Class
>> >               Set of PHBs applicable to an Ordered 
>> >               Aggregate.
>> >
>> >
>> 
>> I would prefer to leave them out.
>
>Okay by me.  It might be useful if there was a statement
>somewhere stating where these definitions can be found.
>Of course, if the answer is not simple, it might be easier
>to just include the definitions.  There are precedents
>among the other MPLS drafts.
>

Current draft already has the following references in section 1:

"The Diff-Serv model defines [DIFF_NEW] the set of Behavior Aggregates which share an ordering constraint to constitute an "Ordered Aggregate (OA)". It also defines the set of one or more PHBs that are applied to this set of Behavior Aggregates to constitute a "PHB Scheduling Class (PSC)"."

"In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP packets crossing a link and requiring the same Diff-Serv behavior are said to constitute a Behavior Aggregate (BA)"

what more exactly do you suggest we need?

thanks

Francois

>> 
>> Francois
>>                      --------
>> >  
>In message <336ECDAFDF7DD311B9E30090277AEE4101B40467@nt-exchange-bby.pmc-sierra
>.bc.ca>, Shahram Davari writes:
>> Curtis,
>> 
>> "uniform" model means that the LSP tunnel will treat the packets consistent
>> with the treatment that the packet would get if there was no LSP tunnel.
>> this is useful when both the tunnel and the network on its ingress/egress
>> belong to the same administrative domain.
>> 
>> "Tunnel" mode means that the packets may be treated differently (under
>> another PHB) when they are passing through the LSP, but as soon as they
>> emerge from the other side of the Tunnel, they will continue with their
>> original PHB (the PHB before entering the Tunnel). This may be useful when a
>> service provider wants to Tunnel its traffic through another administrative
>> domain. For example a service provider A may need to pass AF-PHB traffic
>> through domain B (which is not under his control and offers only EF-PHB).
>> 
>> Regards,
>> -Shahram
>
>
>Francois' prior message makes sense now.
>
>Thanks,
>
>Curtis

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________ 



From owner-mpls@UU.NET  Thu Jun 29 09:58:28 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08023
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 09:58:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivrj27664;
	Thu, 29 Jun 2000 13:58:04 GMT
Received: by mail-control.mail.uu.net 
	id QQivrj07304
	for mpls-outgoing; Thu, 29 Jun 2000 13:57:32 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivrj07279
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 13:57:20 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivrj18366;
	Thu, 29 Jun 2000 09:56:59 -0400 (EDT)
Received: from fsnt.future.futusoft.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQivrj14028;
	Thu, 29 Jun 2000 13:56:40 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000715421@fsnt.future.futusoft.com>;
 Thu, 29 Jun 2000 19:38:18 +0530
Received: from arumugamr (arumugamr.future.futsoft.com [10.0.6.51]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id TAA13757; Thu, 29 Jun 2000 19:25:34 +0530
Received: by localhost with Microsoft MAPI; Thu, 29 Jun 2000 19:30:37 +0530
Message-Id: <01BFE200.80A15F80.arumugamr@future.futsoft.com>
From: ARUMUGAM R <arumugamr@future.futsoft.com>
To: "'awduche@uu.net'" <awduche@UU.NET>,
        "'lberger@labn.net'"
	 <lberger@labn.net>,
        "'vijay@torrentnet.com'"
	 <vijay@torrentnet.com>,
        "'tony1@home.net'" <tony1@home.net>,
        "'dhg@juniper.net'" <dhg@juniper.net>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Need for RRO Object in the Error  Mesg.
Date: Thu, 29 Jun 2000 19:30:36 +0530
Organization: FSPL
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Hi,
This message is regarding to the need of RRO object in the PathErr message 
& ResvErr Mesg if the size of the RRO exceeds the Maximum MTU.
Is it not enough to send the error message alone to the Ingress of the 
tunnel to get it removed?
Is there any specific requirement for sending the RRO with the massage?
Whether the Ingress of the tunnel makes use of that RRO in the Error 
message?
If it didn't , isn't a overhead of adding the RRO?
Suppose if i receive a ErrorSpec with ErrorSpec Code as RRO Notify and if i 
didn't get a RRO with it?, do i drop the message or continue forwarding to 
the Ingress of the Tunnel.
Thanks in advance.
Regards
Aru
------------------------------------------------------------------------  
--------
Arumugam R
Senior Software Engineer,
Future Software Pvt Ltd.
Chennai - 35
Fone-4330550 Extn-332
------------------------------------------------------------------------  
--------





From owner-mpls@UU.NET  Thu Jun 29 10:17:04 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08560
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 10:17:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivrl28957;
	Thu, 29 Jun 2000 14:16:44 GMT
Received: by mail-control.mail.uu.net 
	id QQivrl20359
	for mpls-outgoing; Thu, 29 Jun 2000 14:16:07 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivrl20290
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 14:15:54 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivrl10873
	for <mpls@UU.NET>; Thu, 29 Jun 2000 10:15:36 -0400 (EDT)
Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQivrl10761
	for <mpls@UU.NET>; Thu, 29 Jun 2000 14:15:31 GMT
Received: from santosh (santosh [165.133.13.16])
	by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with SMTP id TAA29994
	for <mpls@UU.NET>; Thu, 29 Jun 2000 19:40:13 -0600 (GMT)
Message-ID: <00f301bfe1d4$75f6fb20$100d85a5@dti.daewoo.co.kr>
Reply-To: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
To: <mpls@UU.NET>
Subject: COPS - Unsolicited Decision Message
Date: Thu, 29 Jun 2000 19:45:21 +0530
Organization: Daewoo Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00F0_01BFE202.8F847DA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00F0_01BFE202.8F847DA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello
    I am working on COPS ( rfc 2748 ) and have the following doubt.

All Request Messages going from PEP to PDP have a unique Handle. PEP is =
supposed to ensure this uniqueness for the TCP connection with the PDP. =
For all solicited Decisions from PDP to PEP  Handle of the corresponding =
Request Message is sent.=20
My question is: What is the Handle for Unsolicited Decision Message from =
PEP to PDP ?

From the RFC what I make out is that PDP doesnt keep any track of =
Handle. It simply performs comparison to find the context of incoming =
message. So how does it decide which Handle to use?=20

Santosh Gupta

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I am working on COPS =
( rfc 2748=20
) and have&nbsp;the following doubt.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>All Request Messages going from PEP to =
PDP have a=20
unique Handle. PEP is supposed to ensure this uniqueness for the TCP =
connection=20
with the PDP. For all solicited Decisions from PDP to PEP&nbsp; =
Handle&nbsp;of=20
the corresponding Request Message is sent. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>My question is: What is the Handle for =
Unsolicited=20
Decision Message from PEP to PDP ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>From the RFC what I make out is that =
PDP doesnt=20
keep any track of Handle. It simply performs comparison to find the =
context of=20
incoming message. So how does it decide which Handle to use? =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Santosh =
Gupta</FONT></DIV></BODY></HTML>

------=_NextPart_000_00F0_01BFE202.8F847DA0--



From owner-mpls@UU.NET  Thu Jun 29 10:19:19 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08606
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 10:19:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivrl13222;
	Thu, 29 Jun 2000 14:19:01 GMT
Received: by mail-control.mail.uu.net 
	id QQivrl20707
	for mpls-outgoing; Thu, 29 Jun 2000 14:18:32 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivrl20695
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 14:18:28 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivrl11295
	for <mpls@UU.NET>; Thu, 29 Jun 2000 10:18:13 -0400 (EDT)
Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx2.tellabs.com [204.68.180.51])
	id QQivrl12557
	for <mpls@UU.NET>; Thu, 29 Jun 2000 14:18:12 GMT
Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged))
	by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id JAA11717
	for <mpls@UU.NET>; Thu, 29 Jun 2000 09:18:03 -0500 (CDT)
Received: from tellabs.com (tlab-138-111-22-139.tellabs.com [138.111.22.139] (may be forged))
	by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA08887
	for <mpls@UU.NET>; Thu, 29 Jun 2000 09:17:52 -0500 (CDT)
Message-ID: <395B5A71.EB2EBAAC@tellabs.com>
Date: Thu, 29 Jun 2000 09:17:21 -0500
From: Changcheng Huang <changcheng.huang@tellabs.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: new draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

A new draft titled "Extensions to RSVP-TE for MPLS Path Protection" is
available at

http://search.ietf.org/internet-drafts/draft-chang-mpls-rsvpte-path-protection-ext-00.txt

Your comments are welcomed.

Chang

--
Changcheng Huang
Tellabs
Changcheng.Huang@tellabs.com
4951 Indiana Avenue, MS 64
Lisle, IL 60532
Tel: (630) 512-7954
Fax: (630) 512-8037




From owner-mpls@UU.NET  Thu Jun 29 10:25:44 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08793
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 10:25:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivrl05690;
	Thu, 29 Jun 2000 14:25:06 GMT
Received: by mail-control.mail.uu.net 
	id QQivrl21451
	for mpls-outgoing; Thu, 29 Jun 2000 14:24:47 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivrl21439
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 14:24:41 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivrl03621
	for <mpls@uu.net>; Thu, 29 Jun 2000 10:24:37 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivrl05159
	for <mpls@uu.net>; Thu, 29 Jun 2000 14:24:36 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA12442
	for mpls@uu.net; Thu, 29 Jun 2000 10:24:35 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivrl21411
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 14:24:22 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivrl03423
	for <mpls@UU.NET>; Thu, 29 Jun 2000 10:24:19 -0400 (EDT)
Received: from sword.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sword.cisco.com [161.44.208.100])
	id QQivrl04582
	for <mpls@UU.NET>; Thu, 29 Jun 2000 14:24:03 GMT
Received: from jayang-nt (kan-dhcp209-123.cisco.com [161.44.209.123]) by sword.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA04828; Thu, 29 Jun 2000 10:09:21 -0400 (EDT)
Message-Id: <4.2.0.58.20000629102318.0204d780@sword.cisco.com>
X-Sender: jayang@sword.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 29 Jun 2000 10:23:33 -0400
To: "G.B.Naidu" <gbnaidu@sasi.com>, mpls@UU.NET
From: Jason Yang <jayang@cisco.com>
Subject: Re: MPLS deployment...
In-Reply-To: <Pine.LNX.4.21.0006291125441.763-100000@pcd75.sasi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Go
http://www.cisco.com/warp/public/cc/cisco/mkt/ios/tag/index.shtml

Jason
At 11:27 AM 6/29/00 +0530, G.B.Naidu wrote:

>Hi,
>
>I am interested to know about the various issues involved in the MPLS
>deploument and interoperability. Could some one show me some pointers or
>any inputs.
>
>thanks
>--gb
>
>--
>




From owner-mpls@UU.NET  Thu Jun 29 10:55:18 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09793
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 10:55:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivrn28824;
	Thu, 29 Jun 2000 14:54:58 GMT
Received: by mail-control.mail.uu.net 
	id QQivrn24608
	for mpls-outgoing; Thu, 29 Jun 2000 14:54:28 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivrn24595
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 14:54:19 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivrn21262
	for <mpls@UU.NET>; Thu, 29 Jun 2000 10:54:11 -0400 (EDT)
Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQivrn28063
	for <mpls@UU.NET>; Thu, 29 Jun 2000 14:53:55 GMT
Received: from avici.com (swdev23.avici.com [10.1.2.229])
          by mailhost.avici.com (8.8.5/8.8.4) with ESMTP
	  id KAA14518 for <mpls@UU.NET>; Thu, 29 Jun 2000 10:53:54 -0400 (EDT)
Message-Id: <200006291453.KAA14518@mailhost.avici.com>
X-Mailer: exmh version 2.1.1 10/15/1999
From: Markus Jork <mjork@avici.com>
To: mpls@UU.NET
Subject: Re: Need for RRO Object in the Error Mesg. 
In-reply-to: Your message of "Thu, 29 Jun 2000 19:30:36 +0530."
             <01BFE200.80A15F80.arumugamr@future.futsoft.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 29 Jun 2000 10:53:53 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

arumugamr@future.futsoft.com said:
> This message is regarding to the need of RRO object in the PathErr
> message  & ResvErr Mesg if the size of the RRO exceeds the Maximum
> MTU. Is it not enough to send the error message alone to the Ingress
> of the  tunnel to get it removed? 

I also don't see much value in including the RRO object in the
error message and think this requirement should be removed from
the spec.
In addition, this part of the spec conflicts with section 3 and
section 4.4 of the same spec (draft-ietf-mpls-rsvp-lsp-tunnel-05)
which say that an RRO is only included in Path and Resv messages.

Markus



From owner-mpls@UU.NET  Thu Jun 29 11:10:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10256
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 11:10:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivro21619;
	Thu, 29 Jun 2000 15:09:41 GMT
Received: by mail-control.mail.uu.net 
	id QQivro03377
	for mpls-outgoing; Thu, 29 Jun 2000 15:09:08 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivro03340
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 15:09:06 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivro21170
	for <mpls@UU.NET>; Thu, 29 Jun 2000 11:07:32 -0400 (EDT)
Received: from bmailnj.iphighway.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.89.157.130])
	id QQivro08388
	for <mpls@UU.NET>; Thu, 29 Jun 2000 15:07:32 GMT
Received: by BMAILNJ with Internet Mail Service (5.5.2650.21)
	id <N7C5WABD>; Thu, 29 Jun 2000 11:02:02 -0400
Message-ID: <6399122981E1D211AB490090271E0AA38B1D97@BMAILNJ>
From: "Francis Reichmeyer (IPHighway MA)" <FranR@iphighway.com>
To: "'Santosh Gupta '" <santoshg@daewoo.dti.daewoo.co.kr>,
        "'mpls@UU.NET '"
	 <mpls@UU.NET>
Subject: RE: COPS - Unsolicited Decision Message
Date: Thu, 29 Jun 2000 11:02:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

In the outsourcing model, Unsolicited Decision is used to make
changes/updats to a previous (Solicited) decision. In that case
the same Handle used in the previous decison is used in the 
Unsolicited decision.
The Unsolicited Decision is primarily used in the provisioning
management model. The PEP supplies a Handle in its initial
Request to the PDP and that Handle is used in the Decision
messages. See the cops-pr draft (draft-ietf-rap-pr-02.txt) for more
details.
Thanks,
-Fran
 

-----Original Message-----
From: Santosh Gupta
To: mpls@UU.NET
Sent: 06/29/2000 10:15 AM
Subject: COPS - Unsolicited Decision Message

Hello
    I am working on COPS ( rfc 2748 ) and have the following doubt.
 
All Request Messages going from PEP to PDP have a unique Handle. PEP is
supposed to ensure this uniqueness for the TCP connection with the PDP.
For all solicited Decisions from PDP to PEP  Handle of the corresponding
Request Message is sent. 
My question is: What is the Handle for Unsolicited Decision Message from
PEP to PDP ?
 
From the RFC what I make out is that PDP doesnt keep any track of
Handle. It simply performs comparison to find the context of incoming
message. So how does it decide which Handle to use? 
 
Santosh Gupta


From owner-mpls@UU.NET  Thu Jun 29 11:14:08 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10387
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 11:14:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivro25249;
	Thu, 29 Jun 2000 15:13:48 GMT
Received: by mail-control.mail.uu.net 
	id QQivro06659
	for mpls-outgoing; Thu, 29 Jun 2000 15:13:05 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivro06639
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 15:12:58 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivro02091
	for <mpls@uu.net>; Thu, 29 Jun 2000 11:12:45 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQivro24272
	for <mpls@uu.net>; Thu, 29 Jun 2000 15:12:44 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA11005
	for <mpls@uu.net>; Thu, 29 Jun 2000 08:12:54 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA05917 for mpls@uu.net; Thu, 29 Jun 2000 11:12:42 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivrn24557
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 14:53:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivrn21072
	for <mpls@UU.NET>; Thu, 29 Jun 2000 10:53:49 -0400 (EDT)
Received: from hawk.CrescentNetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.177.194.54])
	id QQivrn27835
	for <mpls@UU.NET>; Thu, 29 Jun 2000 14:53:32 GMT
Received: from crescentnetworks.com (langille.in.crescentnets.com [192.168.29.105])
	by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id KAA26132;
	Thu, 29 Jun 2000 10:53:29 -0400 (EDT)
Message-ID: <395B63D2.8A80CC36@crescentnetworks.com>
Date: Thu, 29 Jun 2000 10:57:22 -0400
From: Paul Langille <langille@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Friedeborn, William" <wfriedeb@netplane.com>
CC: mpls@UU.NET
Subject: Re: MPLS TE MIB - Doubts
References: <7BF58A904536D411ADD400508BC97B8501BEA4@xover1.hjinc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


    Hi William. In the following text I have a few 'answers'. Standard
disclaimer of course! (My answers may not be totally accurate. If this is the
case then I am sure that someone will speak up!)

"Friedeborn, William" wrote:

> A couple of points I am a little confused on in this thread about adding a
> SourceID to the Tunnel indexing scheme.
> 1. Tunnel Indexing - When I look at the current indexing scheme of
> TunnelIndex, TunnelInstance, there is nothing here that would indicate that
> this information should have any significance  other than to the node it is
> created on.

I believe that this is correct.

> In my first cut at understanding the use of Tunnels, I could see
> that the ingress node could have the Tunnel objects defined via SNMP/cli.
> The Tunnel instrumentation would pass the info down to the supporting
> protocol statemachine (LDP or RSVP), the protocols would signal down to the
> egress node creating LSR-MIB objects along the way (or on reverse trip) till
> the egress node is reached, where the LSR-MIB and Tunnel objects are
> created. Since my understanding of the LDP and RSVP protocols is not that
> detailed, I didn't see where the Tunnel indexing info fit in LDP or RSVP
> (i.e. how would this index info be passed on the LSP creation via RSVP?). It
> seemed that the intent was to use the cross-connects on each node to
> associate the Tunnel object using it. And the LSPID to track the sequence of
> cross-connects so that one could follow an LSP from node to node via the
> LSPID.

This is basically correct also. (You may need more than the LSP ID to uniquely
identify an LSP. See the following text.)

>
>
> If the intent is that a tunnel definition should have more than just local
> significance, shouldn't there be some tunnelID defined (like LSPID)? I can
> see that adding a SourceID makes it possible to pass these locally defined
> indices, but it seems odd to me that when you define a set of indices on one
> machine, that another machine should know about them.

Have a look at draft-ietf-mpls-rsvp-lsp-tunnel-05.txt and focus on the session
object and the sender template. The session object contains the  "IPv4 tunnel
end point address", "Tunnel ID", and the "Extended Tunnel ID". If you make the
Extended Tunnel ID equal to the tunnel ingress node's IP address then you have
uniquely identified the two ends of the tunnel. The Tunnel ID is used to
identify multiple tunnels between the same source and destination. (I believe
this is what you are looking for.)
If you now want to move traffic from one tunnel to another without disrupting
service (aka "make-before-brake") you would keep the same session object and
modify the LSP ID in the sender template. (This is explained much better in
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.)
I think the use of the Source ID (and the Tunnel ID) will be clearer in the next
version of the MIB. (Right Tom?)

>
>
> 2. Multiple LSPs on a Tunnel - Looking at the LSR-MIB I see that the
> cross-connect object has a XCIndex and three other indices. I assumed these
> were set up to support MP-PT, and PT-MP by keeping the XCIndex and
> OutSegmentIndex constant and varying the InSegmentIfIndex/label, the MP-PT
> case is achieved, and similarly the PT-MP could be done. (Is it
> possible/practical to have MP-MP?). In any case, it seemed that there could
> be a situation where a Tunnel had a XCIndex that referenced  more that one
> row in a XC table. I wasn't sure if the multiple rows in the XC table ment
> multiple LSPs? Or just a MP-PT or PT-MP single LSP?
>
> 3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also.

First let's get rid of one of the terms. I think that a "tunnel" and an "LSP
tunnel" in the context of the TE MIB are the same things. So throw out "tunnel".
It is too general.

So what is the difference between an LSP and an LSP tunnel? If you look in
section 2.1 of draft-ietf-mpls-rsvp-lsp-tunnel-05.txt it has the following text:

"The ingress node of an LSP can use a variety of means to determine which
packets are assigned a
particular label.  Once a label is assigned to a set of packets, the label
effectively defines the "flow" through the LSP.  We refer to such an LSP as an
"LSP tunnel" because the traffic through it is opaque to intermediate nodes
along the label switched path."

I think the difference is related to the signaling. To me an LSP has a 'hop by
hop' feel to it (e.g. LDP). When signaling an LSP the FEC is passed along to
each node in the path. This gives the intermediate nodes a hint about the data
that will traverse the LSP. For LSP tunnels the FEC decision is made at the head
end of  the LSP tunnel. From a signaling perspective, the nodes along the (LSP
tunnel) path do not know anything about the data traversing the LSP tunnel. The
beauty (or the confusing part) of all this is that the label swap operation is
the same for both LSPs and LSP tunnels.
Does this help or did I make it worse?

    Paul


>
>
> Hope someone can clarify the above,
> Thanks,
> Bill Friedeborn
>
>

--
Paul Langille                e-mail: langille@crescentnetworks.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824





From owner-mpls@UU.NET  Thu Jun 29 11:41:43 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11595
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 11:41:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivrq03424;
	Thu, 29 Jun 2000 15:41:18 GMT
Received: by mail-control.mail.uu.net 
	id QQivrq10182
	for mpls-outgoing; Thu, 29 Jun 2000 15:40:52 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivrq10174
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 15:40:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivrq27120
	for <mpls@UU.NET>; Thu, 29 Jun 2000 11:40:36 -0400 (EDT)
Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.99.125.2])
	id QQivrq15466
	for <mpls@UU.NET>; Thu, 29 Jun 2000 15:40:20 GMT
Received: by BGSLC02 with Internet Mail Service (5.5.2650.21)
	id <N569NLB5>; Thu, 29 Jun 2000 09:32:42 -0600
Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE6DE@BGSLC02>
From: Irwin Lazar <ILazar@tbg.com>
To: "'G.B.Naidu'" <gbnaidu@sasi.com>, mpls@UU.NET
Subject: RE: MPLS deployment...
Date: Thu, 29 Jun 2000 09:32:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi GB,
We've got tons of relevant information on the MPLS Resource Center at
http://www.mplsrc.com/, we also run a mailing list that is for discussion of
MPLS operational isues.

Irwin

-----Original Message-----
From: G.B.Naidu [mailto:gbnaidu@sasi.com]
Sent: Thursday, June 29, 2000 1:57 AM
To: mpls@UU.NET
Subject: MPLS deployment...



Hi,

I am interested to know about the various issues involved in the MPLS
deploument and interoperability. Could some one show me some pointers or
any inputs.

thanks
--gb

-- 


From owner-mpls@UU.NET  Thu Jun 29 15:43:17 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18698
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 15:43:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivsg08499;
	Thu, 29 Jun 2000 19:42:47 GMT
Received: by mail-control.mail.uu.net 
	id QQivsg18439
	for mpls-outgoing; Thu, 29 Jun 2000 19:42:22 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivsg18434
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 19:42:20 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivsg18683
	for <mpls@uu.net>; Thu, 29 Jun 2000 15:42:10 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivsg08005
	for <mpls@uu.net>; Thu, 29 Jun 2000 19:42:09 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA24926
	for mpls@uu.net; Thu, 29 Jun 2000 15:42:09 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivsg18405
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 19:41:48 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivsg07905
	for <mpls@UU.NET>; Thu, 29 Jun 2000 15:41:22 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivsg07403
	for <mpls@UU.NET>; Thu, 29 Jun 2000 19:41:22 GMT
Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA24831;
	Thu, 29 Jun 2000 15:41:21 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA20399; Thu, 29 Jun 2000 15:41:21 -0400 (EDT)
Message-Id: <200006291941.PAA20399@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: Markus Jork <mjork@avici.com>
cc: mpls@UU.NET, swallow@cisco.com
Subject: Re: Need for RRO Object in the Error Mesg. 
In-reply-to: Your message of "Thu, 29 Jun 2000 10:53:53 EDT."
             <200006291453.KAA14518@mailhost.avici.com> 
Date: Thu, 29 Jun 2000 15:41:20 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> arumugamr@future.futsoft.com said:
> > This message is regarding to the need of RRO object in the PathErr
> > message  & ResvErr Mesg if the size of the RRO exceeds the Maximum
> > MTU. Is it not enough to send the error message alone to the Ingress
> > of the  tunnel to get it removed? 
> 
> I also don't see much value in including the RRO object in the
> error message and think this requirement should be removed from
> the spec.
> In addition, this part of the spec conflicts with section 3 and
> section 4.4 of the same spec (draft-ietf-mpls-rsvp-lsp-tunnel-05)
> which say that an RRO is only included in Path and Resv messages.
> 
> Markus

Seems that a number of folks would like to see this disappear.  Does
anyone want to argue for keeping it?  If not I'll remove it from the
next rev (which will be out before the cut-off).

...George

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



From owner-mpls@UU.NET  Thu Jun 29 16:13:43 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19323
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 16:13:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivsi00944;
	Thu, 29 Jun 2000 20:12:51 GMT
Received: by mail-control.mail.uu.net 
	id QQivsi02002
	for mpls-outgoing; Thu, 29 Jun 2000 20:12:21 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivsi01992
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 20:12:16 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivsi13345
	for <mpls@uu.net>; Thu, 29 Jun 2000 16:11:55 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivsi00081
	for <mpls@uu.net>; Thu, 29 Jun 2000 20:11:50 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA29210
	for mpls@uu.net; Thu, 29 Jun 2000 16:11:49 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivsi01924
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 20:11:30 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivsi04976
	for <mpls@uu.net>; Thu, 29 Jun 2000 16:11:23 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQivsi16756
	for <mpls@uu.net>; Thu, 29 Jun 2000 20:11:23 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA13757; Thu, 29 Jun 2000 16:11:22 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-196.cisco.com [161.44.134.196])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA35979;
	Thu, 29 Jun 2000 16:13:04 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000629160159.04b7e630@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 29 Jun 2000 16:12:03 -0400
To: manikantan <manis@future.futsoft.com>, "'Adrian Farrel'" <AF@datcon.co.uk>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: MPLS TE MIB - Doubts
Cc: "'arun Viswanathan'" <arun@force10networks.com>,
        "'cheenu Srinivasan'" <csrinivasan@tachion.com>,
        "'manis@future.futsoft.com'" <manis@kailash.future.futsoft.com>,
        mpls@UU.NET
In-Reply-To: <01BFDD0A.82FB9340.manis@future.futsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Comments are inline.

>I have some doubts. Can you please clarify me.
>
>#mplsTunnelHopEntry  OBJECT-TYPE
>#SYNTAX        MplsTunnelHopEntry
>#MAX-ACCESS    not-accessible
>#STATUS        current
>#DESCRIPTION
>#"An entry in this table represents a tunnel hop.  An entry is created by a
>#network administrator for signaled ERLSP set up by an MPLS signaling
>#protocol."
>#INDEX { mplsTunnelHopListIndex, mplsTunnelHopIndex }
>#::= { mplsTunnelHopTable 1 }
>
>It has been proposed/suggested as above, the index definition for
>TunnelHopEntry in the forthcoming TE MIB.
>
>(Probably the MIB might be help understand better. Since it is in the
>draft stage and we use the indices in our discussion, I request you this 
>clarification.
>Sorry if I have missed some mails where you might have clarified, if so
>just please refer them).
>
>1) My understanding of the mplsTunnelHopListIndex, is that it is an index
>    to a list of ER Hops.
>    i.e. when the rows in the Tunnel Hop Table are to be created, I can
>    create rows with the following indices combination.
>    a) mplsTunnelHopListIndex = 1, mplsTunnelHopIndex  = 1
>    b) mplsTunnelHopListIndex = 1, mplsTunnelHopIndex  = 2
>    c) mplsTunnelHopListIndex = 1, mplsTunnelHopIndex  = 3
>    d) mplsTunnelHopListIndex = 2, mplsTunnelHopIndex  = 1
>    e) mplsTunnelHopListIndex = 2, mplsTunnelHopIndex  = 2
>    f) mplsTunnelHopListIndex = 2, mplsTunnelHopIndex  = 3
>
>   Now I have two ER Hop Lists which has 3 ER hops each.
>
>   Is my understanding correct?

         Yes, I believe that you are correct. However,
we have modified the tunnelEntry to contain an extra
object, which would be the primary index into the
mplsTunnelHopTable. This would obiate the need to
extend the indexing of the hop entries in the
same way in which the tunnelTable was extended recently.
This change has the added advantage of the tunnelHopTable
indexing being totally independent of how the tunnelTable
is indexed.

>2) If my above understanding is wrong, then the following questions
>    are not valid.
>
>    a) If I am right, then my questions are how are we associating the
>    ER Hops to the tunnels?

         We always have associated them.


>3) Though with the earlier MIB we were forced to configure the
>    ER Hop information again and again for different tunnels (when
>    a ER hop is shared by a set of tunnels, or otherwise set of
>    tunnels pass through the same ER Hop), It was straight forward
>    and easy to implement.  Clarifications will help me appreciate
>    the new hop table proposal.

         Exactly. If we use the indexing scheme described above,
it is very easy for multiple tunnels to point at the same set
of ERHops.

         --Tom






From owner-mpls@UU.NET  Thu Jun 29 16:39:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19703
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 16:39:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivsk20765;
	Thu, 29 Jun 2000 20:39:16 GMT
Received: by mail-control.mail.uu.net 
	id QQivsk04376
	for mpls-outgoing; Thu, 29 Jun 2000 20:38:51 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivsk04371
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 20:38:49 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivsk19884
	for <mpls@uu.net>; Thu, 29 Jun 2000 16:38:48 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivsk20267
	for <mpls@uu.net>; Thu, 29 Jun 2000 20:38:47 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA02977
	for mpls@uu.net; Thu, 29 Jun 2000 16:38:46 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivsk04344
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 20:38:25 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivsk19559
	for <mpls@UU.NET>; Thu, 29 Jun 2000 16:38:09 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQivsk19800
	for <mpls@UU.NET>; Thu, 29 Jun 2000 20:38:09 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA16937; Thu, 29 Jun 2000 16:38:08 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-196.cisco.com [161.44.134.196])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA36079;
	Thu, 29 Jun 2000 16:39:53 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000629162144.0425af00@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 29 Jun 2000 16:38:41 -0400
To: Paul Langille <langille@CrescentNetworks.com>,
        "Friedeborn, William" <wfriedeb@netplane.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>,
        arun Viswanathan <arun@force10networks.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: MPLS TE MIB - Doubts
Cc: mpls@UU.NET
In-Reply-To: <395B63D2.8A80CC36@crescentnetworks.com>
References: <7BF58A904536D411ADD400508BC97B8501BEA4@xover1.hjinc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


> > A couple of points I am a little confused on in this thread about adding a
> > SourceID to the Tunnel indexing scheme.
> > 1. Tunnel Indexing - When I look at the current indexing scheme of
> > TunnelIndex, TunnelInstance, there is nothing here that would indicate that
> > this information should have any significance  other than to the node it is
> > created on.
>
>I believe that this is correct.

         It has been suggested that the tunnel indexes be the same
at each hop along the route of the tunnel. Doing so makes it
a whole lot easier for the management application to put the
pieces of the tunnel together. But note that the configuration
of the tunnel is only done at origination point of the tunnel
(i.e.: head). This is also why the tunnelIngressRouterId was
added to the indexing of the tunnelEntry.

> > In my first cut at understanding the use of Tunnels, I could see
> > that the ingress node could have the Tunnel objects defined via SNMP/cli.
> > The Tunnel instrumentation would pass the info down to the supporting
> > protocol statemachine (LDP or RSVP), the protocols would signal down to the
> > egress node creating LSR-MIB objects along the way (or on reverse trip)
> > the egress node is reached, where the LSR-MIB and Tunnel objects are
> > created. Since my understanding of the LDP and RSVP protocols is not that
> > detailed, I didn't see where the Tunnel indexing info fit in LDP or RSVP
> > (i.e. how would this index info be passed on the LSP creation via RSVP?).
> > seemed that the intent was to use the cross-connects on each node to
> > associate the Tunnel object using it. And the LSPID to track the 
> sequence of
> > cross-connects so that one could follow an LSP from node to node via the
> > LSPID.
>
>This is basically correct also. (You may need more than the LSP ID to 
>uniquely identify an LSP. See the following text.)

         Yes, this is true.

> > If the intent is that a tunnel definition should have more than just local
> > significance, shouldn't there be some tunnelID defined (like LSPID)? I can
> > see that adding a SourceID makes it possible to pass these locally defined
> > indices, but it seems odd to me that when you define a set of indices 
> on >one machine, that another machine should know about them.
>
>Have a look at draft-ietf-mpls-rsvp-lsp-tunnel-05.txt and focus on the session
>object and the sender template. The session object contains the  "IPv4 tunnel
>end point address", "Tunnel ID", and the "Extended Tunnel ID". If you make the
>Extended Tunnel ID equal to the tunnel ingress node's IP address then you have
>uniquely identified the two ends of the tunnel. The Tunnel ID is used to
>identify multiple tunnels between the same source and destination. (I believe
>this is what you are looking for.)
>If you now want to move traffic from one tunnel to another without disrupting
>service (aka "make-before-brake") you would keep the same session object and
>modify the LSP ID in the sender template. (This is explained much better in
>draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.)
>I think the use of the Source ID (and the Tunnel ID) will be clearer in 
>the next version of the MIB. (Right Tom?)

         Yes, this is correct.


> > 2. Multiple LSPs on a Tunnel - Looking at the LSR-MIB I see that the
> > cross-connect object has a XCIndex and three other indices. I assumed these
> > were set up to support MP-PT, and PT-MP by keeping the XCIndex and
> > OutSegmentIndex constant and varying the InSegmentIfIndex/label, the MP-PT
> > case is achieved, and similarly the PT-MP could be done. (Is it
> > possible/practical to have MP-MP?). In any case, it seemed that there could
> > be a situation where a Tunnel had a XCIndex that referenced  more that one
> > row in a XC table. I wasn't sure if the multiple rows in the XC table ment
> > multiple LSPs? Or just a MP-PT or PT-MP single LSP?

         First of all, the TE MIB model only supports point-to-point
TE tunnels. However, you are correct in pointing out that
a particular XCentry can facilitate multiple in and outSegments
in a MP-MP or PT-MP situation.

> > 3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also.
>
>First let's get rid of one of the terms. I think that a "tunnel" and an "LSP
>tunnel" in the context of the TE MIB are the same things. So throw out 
>"tunnel". It is too general.

         No LSP Tunnel. The use of "tunnel" in the TE MIB
refers to the specific parameters used to describe a
traffic engineered tunnel which may or may not result in
the formation of an LSP.

         --Tom





From owner-mpls@UU.NET  Thu Jun 29 16:44:18 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19752
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 16:44:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivsk24037;
	Thu, 29 Jun 2000 20:43:02 GMT
Received: by mail-control.mail.uu.net 
	id QQivsk04592
	for mpls-outgoing; Thu, 29 Jun 2000 20:42:37 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivsk04587
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 20:42:32 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivsk22014
	for <mpls@uu.net>; Thu, 29 Jun 2000 16:42:25 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivsk08794
	for <mpls@uu.net>; Thu, 29 Jun 2000 20:42:24 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA03748
	for mpls@uu.net; Thu, 29 Jun 2000 16:42:23 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivsk04574
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 20:41:55 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivsk21643
	for <mpls@uu.net>; Thu, 29 Jun 2000 16:41:46 -0400 (EDT)
Received: from funnel.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQivsk08298
	for <mpls@uu.net>; Thu, 29 Jun 2000 20:41:45 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA17329; Thu, 29 Jun 2000 16:41:38 -0400 (EDT)
Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-196.cisco.com [161.44.134.196])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAA36090;
	Thu, 29 Jun 2000 16:43:25 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000629161254.04b70bb0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 29 Jun 2000 16:42:12 -0400
To: Adrian Farrel <AF@datcon.co.uk>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: MPLS TE MIB - Doubts
Cc: "'arun Viswanathan'" <arun@force10networks.com>,
        "'cheenu Srinivasan'" <csrinivasan@tachion.com>, mpls@UU.NET,
        "'manis@future.futsoft.com'" <manis@kailash.future.futsoft.com>
In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2A31CE@monk.datcon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi,

>Tom, I understand that you think it is useful to hold the TE MIB at
>intermediate nodes.  If that is the case, I think you should hold _all_
>of the information available at the intermediate nodes and not arbitrarily
>drop some.

         Nothing precludes an implementation from doing so.

         --Tom





From owner-mpls@UU.NET  Thu Jun 29 17:23:52 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20364
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 17:23:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivsn22558;
	Thu, 29 Jun 2000 21:23:16 GMT
Received: by mail-control.mail.uu.net 
	id QQivsn19677
	for mpls-outgoing; Thu, 29 Jun 2000 21:22:57 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivsn19668
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 21:22:52 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivsn25851
	for <mpls@uu.net>; Thu, 29 Jun 2000 17:22:37 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivsn06877
	for <mpls@uu.net>; Thu, 29 Jun 2000 21:22:22 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA08602
	for mpls@uu.net; Thu, 29 Jun 2000 17:22:21 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivsn19546
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 21:21:54 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivsn25703
	for <mpls@uu.net>; Thu, 29 Jun 2000 17:21:35 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivsn06337
	for <mpls@uu.net>; Thu, 29 Jun 2000 21:21:34 GMT
Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA08464
	for <mpls@uu.net>; Thu, 29 Jun 2000 17:21:34 -0400 (EDT)
Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA12970 for <mpls@uu.net>; Thu, 29 Jun 2000 17:21:33 -0400 (EDT)
Message-Id: <200006292121.RAA12970@lir.cisco.com>
X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: If you're not Jeffery Wheeler please delete
Date: Thu, 29 Jun 2000 17:21:33 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

All -

Sorry for the wide distribution.

Jeff -

Could you send me your new email and update me on the status of the
framework document?

Thanks,

...George

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






From owner-mpls@UU.NET  Thu Jun 29 17:42:11 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20629
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 17:42:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivso19597;
	Thu, 29 Jun 2000 21:41:40 GMT
Received: by mail-control.mail.uu.net 
	id QQivso20772
	for mpls-outgoing; Thu, 29 Jun 2000 21:41:17 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivso20767
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 21:41:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivso19627
	for <mpls@uu.net>; Thu, 29 Jun 2000 17:41:03 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivso19035
	for <mpls@uu.net>; Thu, 29 Jun 2000 21:41:03 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA10984
	for mpls@uu.net; Thu, 29 Jun 2000 17:41:02 -0400 (EDT)
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivso20658
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 21:40:38 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivso19217
	for <mpls@UU.NET>; Thu, 29 Jun 2000 17:40:19 -0400 (EDT)
Received: from hawk.CrescentNetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.177.194.54])
	id QQivso18528
	for <mpls@UU.NET>; Thu, 29 Jun 2000 21:40:18 GMT
Received: from crescentnetworks.com (langille.in.crescentnets.com [192.168.29.105])
	by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id RAA14009;
	Thu, 29 Jun 2000 17:40:11 -0400 (EDT)
Message-ID: <395BC322.6DD7E429@crescentnetworks.com>
Date: Thu, 29 Jun 2000 17:44:02 -0400
From: Paul Langille <langille@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
CC: "Friedeborn, William" <wfriedeb@netplane.com>,
        cheenu Srinivasan <csrinivasan@tachion.com>,
        arun Viswanathan <arun@force10networks.com>, mpls@UU.NET
Subject: Re: MPLS TE MIB - Doubts
References: <7BF58A904536D411ADD400508BC97B8501BEA4@xover1.hjinc.com> <4.3.2.7.2.20000629162144.0425af00@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


    Hi Tom. I apologize. I did not mean to imply that these comments would be
incorporated into the MIB. I was just trying to shed some light on some commonly
used terms. I choose the term "LSP tunnel" over "tunnel" based on the text in
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.

    I must say I am surprised by your 'tunnel statement' below. I thought that the
TE MIB was based on RSVP and CR-LDP (explicitly routed) LSPs. I did not think of it
as a general tunnel MIB. Don't get me wrong, I don't mean to imply that this is a
bad thing. I did not realize the scope was this broad. I guess the first comment I
have is that the text at the front of the MIB needs to reflect this.

            Paul

"Thomas D. Nadeau" wrote:
<snip>

>
>
> > > 3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also.
> >
> >First let's get rid of one of the terms. I think that a "tunnel" and an "LSP
> >tunnel" in the context of the TE MIB are the same things. So throw out
> >"tunnel". It is too general.
>
>          No LSP Tunnel. The use of "tunnel" in the TE MIB
> refers to the specific parameters used to describe a
> traffic engineered tunnel which may or may not result in
> the formation of an LSP.
>
>          --Tom

--
Paul Langille                e-mail: langille@crescentnetworks.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824





From owner-mpls@UU.NET  Thu Jun 29 19:32:55 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23014
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 19:32:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivsw14899;
	Thu, 29 Jun 2000 23:32:38 GMT
Received: by mail-control.mail.uu.net 
	id QQivsw20524
	for mpls-outgoing; Thu, 29 Jun 2000 23:32:18 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivsw20519
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 23:32:08 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivsw15735
	for <mpls@UU.NET>; Thu, 29 Jun 2000 19:32:02 -0400 (EDT)
Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49])
	id QQivsw28752
	for <mpls@UU.NET>; Thu, 29 Jun 2000 23:32:02 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jun 29 19:30:58 EDT 2000
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA14548;
	Thu, 29 Jun 2000 19:31:35 -0400 (EDT)
Message-ID: <395BDD14.C402E9F3@dnrc.bell-labs.com>
Date: Thu, 29 Jun 2000 16:34:44 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois Le Faucheur <flefauch@cisco.com>
CC: mpls@UU.NET
Subject: Clarifying 2.6.5 Re: Last Call feedback on MPLS-Diff-Serv
References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francois,

Continuing discussion of section 2.6.5:

Francois Le Faucheur wrote:
	[..]
> >#7 Clarify 2.6.5
> >
> >   Section 2.6.5's last sentence attempts to be normative about
> >   something it simultaneously declares out of scope for this
> >   document. Please clarify, reduce, or remove this section
> 
> We can get rid of the word "may" of the last sentence so that it
> reads: "Models beyond the Uniform Model and the Pipe Model are
> outside the scope of this specification but are not precluded by
> this specification".

Assuming 2.6.5 is needed, it would be sufficient for the final
sentence to read "Models beyond the Uniform Model and the Pipe
Model are outside the scope of this specification."

However....

> >(the
> >   essence can be stated somewhere earlier in section 2 anyway).
> >
> 
> I woudl find it difficult to summarise something that explains
> that there could be other models, give a potential example of
> such other models and clarify it is outside the scope of this
> spec in less than 3 sentences. So I propose to leave it as it is.

Since I dont think this document even needs to speculate on the
form of alternative models beyond Uniform and Pipe, there's really
no need for multiple sentences. And in fact the intent of 2.6.5 would
be captured perfectly by modifying the last paragraph of
section 2.6.2 (where the modelling scope of 2.6 is described) to
conclude with:

  "[..]These two models are the Uniform Model and the Pipe Model and
   their operations over MPLS is described in the following sections.
   Discussion and definition of alternative tunneling models are
   outside the scope of this specification."

(Defining something as outside the scope of "this specification"
automatically leaves the door open for future specifications to
cover such things)

Voila, section 2.6 now simplified :)  This is my recommendation.


cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Thu Jun 29 19:57:12 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23232
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 19:57:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivsx12754;
	Thu, 29 Jun 2000 23:56:51 GMT
Received: by mail-control.mail.uu.net 
	id QQivsx21833
	for mpls-outgoing; Thu, 29 Jun 2000 23:56:24 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivsx21828
	for <mpls@mail-control.mail.uu.net>; Thu, 29 Jun 2000 23:56:19 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivsx23373
	for <mpls@UU.NET>; Thu, 29 Jun 2000 19:56:16 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6])
	id QQivsx28749
	for <mpls@UU.NET>; Thu, 29 Jun 2000 23:56:01 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jun 29 19:55:58 EDT 2000
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA14751;
	Thu, 29 Jun 2000 19:56:36 -0400 (EDT)
Message-ID: <395BE2F2.1D526BB3@dnrc.bell-labs.com>
Date: Thu, 29 Jun 2000 16:59:46 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Francois Le Faucheur <flefauch@cisco.com>
CC: mpls@UU.NET
Subject: Figures in 2.6.3&2.6.4 Re: Last Call feedback on MPLS-Diff-Serv
References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francois,

Use of "(P)" in second figures of 2.6.3 and 2.6.4:

Francois Le Faucheur wrote:
	[..]
> >#6 Section 2.6.3, 2nd Figure
> >
> >   There's a "(P)" floating to the right of "(outer header)"
> >   that perhaps ought not be there?  (Same for 2nd figure in
> >   section 2.6.4)
> 
> (P) indicates the penultimate LSR in all diagrams. It appears at the
> right location even in the 2nd figures (ie without PHP). It insists
> on the fact that in those cases (P) does a swap (and not a pop) so
> that the "outer header" is there between (P) and (E) to carry some
> Diff-Serv info .

Okay, I now understand the intent. But now I'm not sure the ASCII art
is clear. In the non-PHP examples the "(P)" _appears_ to sit two hops
prior to the "(E)" LSR, which is confusing. (Alternatively, it isn't
clear from the ASCII art how to distinguish LSRs and links and
therefore derive the message you intend about where the egress
hops and penultimate hops exist. I can't figure out if the "(M)"
represent LSRs or links using 'meaningful diffserv info' - my
initial read took them as LSRs.) Perhaps the ASCII art could
be clarified (or we could just assume readers know that non-PHP
means "label swap all the way"?)

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Thu Jun 29 23:38:08 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27443
	for <mpls-archive@lists.ietf.org>; Thu, 29 Jun 2000 23:38:08 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivtm05271;
	Fri, 30 Jun 2000 03:37:46 GMT
Received: by mail-control.mail.uu.net 
	id QQivtm18148
	for mpls-outgoing; Fri, 30 Jun 2000 03:37:25 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivtm18143
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 03:37:18 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivtm04878
	for <mpls@UU.NET>; Thu, 29 Jun 2000 23:37:16 -0400 (EDT)
Received: from smtprch2.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15])
	id QQivtm04895
	for <mpls@UU.NET>; Fri, 30 Jun 2000 03:37:16 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Thu, 29 Jun 2000 22:33:39 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <NQCK3HFV>; Thu, 29 Jun 2000 22:36:46 -0500
Message-ID: <F033F6FEF3F1D111BD150000F8CD14310366D4EF@zcard007.ca.nortel.com>
From: "Bilel Jamoussi" <jamoussi@nortelnetworks.com>
To: "'Adrian Farrel'" <AF@datcon.co.uk>, Subodh Mathur <subodh@dtix.com>,
        mpls <mpls@UU.NET>
Cc: "Peter Ashwood-Smith" <petera@nortelnetworks.com>
Subject: RE: Preemption TLV in CR-LDP
Date: Thu, 29 Jun 2000 22:36:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFE244.6A65B1AA"
X-Orig: <jamoussi@americasm01.nt.com>
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_01BFE244.6A65B1AA
Content-Type: text/plain;
	charset="ISO-8859-1"

CRLDP v4 will clarify this point to use "default values" in this case.

Bilel.

-----Original Message-----
From: Adrian Farrel [mailto:AF@datcon.co.uk]
Sent: Sunday, April 23, 2000 10:56 PM
To: Subodh Mathur; mpls
Cc: Jamoussi, Bilel [BL3:2001-M:EXCH]; Ashwood-Smith, Peter
[CAR:CS57:EXCH]
Subject: RE: Preemption TLV in CR-LDP


Hi Subodh,

I can offer you a couple of references...

From section 2.3...

   The exact rules determining bumping are an
   aspect of network policy.

Which implies that although the ingress has a right to 
expect some generalized behavior based on holding and
setup priorities, they can not precisely predict the
rules for bumping that will be applied in the network.

From section 4.4...

   The default value of the setup and holding priorities 
   should be in the middle of the range (e.g., 4)

I would suggest that if the Preemption TLV is not present
the sender is not bothered about the risk of being bumped.
This means that each LSR can apply whatever local network
policy it likes (although ideally this would be co-ordinated
across the network).

It would make sense to me to choose from
- use "default values"
- use lowest values

Regards,
Adrian
--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


>-----Original Message-----
>From: Subodh Mathur [mailto:subodh@dtix.com]
>Sent: Friday, April 21, 2000 3:22 PM
>To: Peter Ashwood-Smith; mpls; Bilel Jamoussi
>Subject: Preemption TLV in CR-LDP
>
>
>Hi,
>How will setting up of a CR LSP with Preemption TLV will deal with an
>existing CR LSP which has been setup without using optional 
>Preemption TLV?.
>Assuming there is a contention of resources between them. The draft on
>CR-LDP does not make it clear or I might have missed it.
>Thanks,
>Subodh Mathur
>Digital Technology Inc.,
>Bedford, MA 01730
>

------_=_NextPart_001_01BFE244.6A65B1AA
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.2651.65">
<TITLE>RE: Preemption TLV in CR-LDP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>CRLDP v4 will clarify this point to use &quot;default values&quot; in this case.</FONT>
</P>

<P><FONT SIZE=2>Bilel.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Adrian Farrel [<A HREF="mailto:AF@datcon.co.uk">mailto:AF@datcon.co.uk</A>]</FONT>
<BR><FONT SIZE=2>Sent: Sunday, April 23, 2000 10:56 PM</FONT>
<BR><FONT SIZE=2>To: Subodh Mathur; mpls</FONT>
<BR><FONT SIZE=2>Cc: Jamoussi, Bilel [BL3:2001-M:EXCH]; Ashwood-Smith, Peter</FONT>
<BR><FONT SIZE=2>[CAR:CS57:EXCH]</FONT>
<BR><FONT SIZE=2>Subject: RE: Preemption TLV in CR-LDP</FONT>
</P>
<BR>

<P><FONT SIZE=2>Hi Subodh,</FONT>
</P>

<P><FONT SIZE=2>I can offer you a couple of references...</FONT>
</P>

<P><FONT SIZE=2>From section 2.3...</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; The exact rules determining bumping are an</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; aspect of network policy.</FONT>
</P>

<P><FONT SIZE=2>Which implies that although the ingress has a right to </FONT>
<BR><FONT SIZE=2>expect some generalized behavior based on holding and</FONT>
<BR><FONT SIZE=2>setup priorities, they can not precisely predict the</FONT>
<BR><FONT SIZE=2>rules for bumping that will be applied in the network.</FONT>
</P>

<P><FONT SIZE=2>From section 4.4...</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; The default value of the setup and holding priorities </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; should be in the middle of the range (e.g., 4)</FONT>
</P>

<P><FONT SIZE=2>I would suggest that if the Preemption TLV is not present</FONT>
<BR><FONT SIZE=2>the sender is not bothered about the risk of being bumped.</FONT>
<BR><FONT SIZE=2>This means that each LSR can apply whatever local network</FONT>
<BR><FONT SIZE=2>policy it likes (although ideally this would be co-ordinated</FONT>
<BR><FONT SIZE=2>across the network).</FONT>
</P>

<P><FONT SIZE=2>It would make sense to me to choose from</FONT>
<BR><FONT SIZE=2>- use &quot;default values&quot;</FONT>
<BR><FONT SIZE=2>- use lowest values</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
<BR><FONT SIZE=2>Adrian</FONT>
<BR><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Adrian Farrel&nbsp; <A HREF="mailto:af@datcon.co.uk">mailto:af@datcon.co.uk</A></FONT>
<BR><FONT SIZE=2>Network Convergence Group</FONT>
<BR><FONT SIZE=2>Data Connection Ltd., Chester, UK</FONT>
<BR><FONT SIZE=2><A HREF="http://www.datcon.co.uk/" TARGET="_blank">http://www.datcon.co.uk/</A></FONT>
<BR><FONT SIZE=2>Tel: +44 (0) 1244 313440&nbsp; Fax: +44 (0) 1244 312422</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt;From: Subodh Mathur [<A HREF="mailto:subodh@dtix.com">mailto:subodh@dtix.com</A>]</FONT>
<BR><FONT SIZE=2>&gt;Sent: Friday, April 21, 2000 3:22 PM</FONT>
<BR><FONT SIZE=2>&gt;To: Peter Ashwood-Smith; mpls; Bilel Jamoussi</FONT>
<BR><FONT SIZE=2>&gt;Subject: Preemption TLV in CR-LDP</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Hi,</FONT>
<BR><FONT SIZE=2>&gt;How will setting up of a CR LSP with Preemption TLV will deal with an</FONT>
<BR><FONT SIZE=2>&gt;existing CR LSP which has been setup without using optional </FONT>
<BR><FONT SIZE=2>&gt;Preemption TLV?.</FONT>
<BR><FONT SIZE=2>&gt;Assuming there is a contention of resources between them. The draft on</FONT>
<BR><FONT SIZE=2>&gt;CR-LDP does not make it clear or I might have missed it.</FONT>
<BR><FONT SIZE=2>&gt;Thanks,</FONT>
<BR><FONT SIZE=2>&gt;Subodh Mathur</FONT>
<BR><FONT SIZE=2>&gt;Digital Technology Inc.,</FONT>
<BR><FONT SIZE=2>&gt;Bedford, MA 01730</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFE244.6A65B1AA--


From owner-mpls@UU.NET  Fri Jun 30 03:54:49 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11381
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 03:54:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivud24487;
	Fri, 30 Jun 2000 07:54:24 GMT
Received: by mail-control.mail.uu.net 
	id QQivud16243
	for mpls-outgoing; Fri, 30 Jun 2000 07:53:47 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivud16237
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 07:53:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivud19378
	for <mpls@UU.NET>; Fri, 30 Jun 2000 03:53:29 -0400 (EDT)
Received: from smtprch1.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14])
	id QQivud23818
	for <mpls@UU.NET>; Fri, 30 Jun 2000 07:53:14 GMT
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Thu, 29 Jun 2000 23:36:57 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <NQCK3HN1>; Thu, 29 Jun 2000 23:35:16 -0500
Message-ID: <F033F6FEF3F1D111BD150000F8CD14310366D4F3@zcard007.ca.nortel.com>
From: "Bilel Jamoussi" <jamoussi@nortelnetworks.com>
To: "'chetan@samsung.co.kr'" <chetan@samsung.co.kr>, mpls@UU.NET
Subject: RE: Few clarifications in CR-LDP-3
Date: Thu, 29 Jun 2000 23:35:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFE24C.96616D64"
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_01BFE24C.96616D64
Content-Type: text/plain;
	charset="ISO-8859-1"

Chetan,

Thanks for your comments. Clarification #1 well taken.

Bilel.

-----Original Message-----
From: chetan@samsung.co.kr [mailto:chetan@samsung.co.kr]
Sent: Thursday, October 07, 1999 4:58 AM
To: Jamoussi, Bilel [BL3:2001-I:EXCH]; mpls@UU.NET
Subject: Few clarifications in CR-LDP-3


Hi,


Clarification #1
Page 4 of the CR-LDP draft 3
---------------------------------------------------------------
"2.1 Strict and Loose Explicit Routes

   Like any other LSP a CR-LSP is a path through an MPLS network. The
   difference is that while other paths are setup solely based on
   information in routing tables or from a management system, the
   constraint-based route is calculated at one point at the edge of
   network based on criteria, including but not limited to routing
   information. The intention is that this functionality shall give
   desired special characteristics to the LSP in order to better
   support the traffic sent over the LSP. The reason for setting up CR-
   LSPs might be that one wants to assign certain bandwidth or other
   Service Class characteristics to the LSP, or that one wants to make
   sure that alternative routes use physically separate paths through
   the network.

   An explicit route is represented in a Label Request Message as a
   list of nodes or groups of nodes along the constraint-based route.
   When the CR-LSP is established, all or a subset of the nodes in a
   group may be traversed by the LSP.  Certain operations to be
   performed along the path can also be encoded in the constraint-based
   route."

Can the first paragraph under section 2.1 be moved under Section 2
"Constraint-based Routing Overview"?
I felt this as that paragraph is talking generally about CR-LSPs and not
"explicitly" about Explicit Routes













------_=_NextPart_001_01BFE24C.96616D64
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Few clarifications in CR-LDP-3</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Chetan,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for your comments. Clarification #1 well =
taken.</FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: chetan@samsung.co.kr [<A =
HREF=3D"mailto:chetan@samsung.co.kr">mailto:chetan@samsung.co.kr</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Thursday, October 07, 1999 4:58 AM</FONT>
<BR><FONT SIZE=3D2>To: Jamoussi, Bilel [BL3:2001-I:EXCH]; =
mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Subject: Few clarifications in CR-LDP-3</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Clarification #1</FONT>
<BR><FONT SIZE=3D2>Page 4 of the CR-LDP draft 3</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
</FONT>
<BR><FONT SIZE=3D2>&quot;2.1 Strict and Loose Explicit Routes</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Like any other LSP a CR-LSP is a path =
through an MPLS network. The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; difference is that while other paths =
are setup solely based on</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; information in routing tables or from a =
management system, the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; constraint-based route is calculated at =
one point at the edge of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; network based on criteria, including =
but not limited to routing</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; information. The intention is that this =
functionality shall give</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; desired special characteristics to the =
LSP in order to better</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; support the traffic sent over the LSP. =
The reason for setting up CR-</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; LSPs might be that one wants to assign =
certain bandwidth or other</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Service Class characteristics to the =
LSP, or that one wants to make</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; sure that alternative routes use =
physically separate paths through</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the network.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; An explicit route is represented in a =
Label Request Message as a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; list of nodes or groups of nodes along =
the constraint-based route.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; When the CR-LSP is established, all or =
a subset of the nodes in a</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; group may be traversed by the =
LSP.&nbsp; Certain operations to be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; performed along the path can also be =
encoded in the constraint-based</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; route.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Can the first paragraph under section 2.1 be moved =
under Section 2 &quot;Constraint-based Routing Overview&quot;?</FONT>
<BR><FONT SIZE=3D2>I felt this as that paragraph is talking generally =
about CR-LSPs and not &quot;explicitly&quot; about Explicit =
Routes</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFE24C.96616D64--


From owner-mpls@UU.NET  Fri Jun 30 06:27:04 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12294
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 06:27:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivun14613;
	Fri, 30 Jun 2000 10:25:19 GMT
Received: by mail-control.mail.uu.net 
	id QQivun27878
	for mpls-outgoing; Fri, 30 Jun 2000 10:24:50 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivun27871
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 10:24:32 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivun22589;
	Fri, 30 Jun 2000 06:24:26 -0400 (EDT)
Received: from fsnt.future.futusoft.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQivun14018;
	Fri, 30 Jun 2000 10:24:22 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000720008@fsnt.future.futusoft.com>;
 Fri, 30 Jun 2000 16:06:21 +0530
Received: from arumugamr (arumugamr.future.futsoft.com [10.0.6.51]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id PAA31739; Fri, 30 Jun 2000 15:52:57 +0530
Received: by localhost with Microsoft MAPI; Fri, 30 Jun 2000 15:58:01 +0530
Message-Id: <01BFE2AB.F7ADA2E0.arumugamr@future.futsoft.com>
From: ARUMUGAM R <arumugamr@future.futsoft.com>
To: "'awduche@uu.net'" <awduche@UU.NET>,
        "'lberger@labn.net'"
	 <lberger@labn.net>,
        "'dhg@juniper.net'" <dhg@juniper.net>,
        "'tony1@home.net'" <tony1@home.net>,
        "'vijay@torrentnet.com'" <vijay@torrentnet.com>,
        "'swallow@cisco.com'" <swallow@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Multiple RRO's
Date: Fri, 30 Jun 2000 15:58:00 +0530
Organization: FSPL
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
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

Hi,
This is another doubt regarding RRO object.
In the RSVP Tunnel establishment, it is given that if multiple RRO's are encountered in
the Resv message between two FILTER_SPEC only the first one is valid and the others
should be omitted (Section 4.4.) 
Whether there can be another RRO following additional FILTER_SPEC?.
When does this situation arises, since the tunnel is going to be unique one?
Particularly in the Tunnel Reroute Condition whether there can be old RRO following
old LABEL obj and new RRO followed by new LABEL object.
Both the RRO's are seperated by old FILTER_SPEC and new FILTER_SPEC.
Can a situation stated above can occur since the old FILTER_SPEC and old LABEL objects
being part of refreshing the Resv message and 
new FILTER_SPEC, LABEL object being part of Reroute condition.

Note:- Consideration is from a Intermediate node , two resv messages are received from 
different NextHops because of reroute Condition and my PHOP does not change because of
reroute to whom i have to forward the Reserve message.
Thanks in advance.
Regards
Aru
--------------------------------------------------------------------------------
Arumugam R
Senior Software Engineer,
Future Software Pvt Ltd.
Chennai - 35
Fone-4330550 Extn-332
--------------------------------------------------------------------------------





From owner-mpls@UU.NET  Fri Jun 30 06:35:05 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12553
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 06:35:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivuo19630;
	Fri, 30 Jun 2000 10:33:29 GMT
Received: by mail-control.mail.uu.net 
	id QQivuo28361
	for mpls-outgoing; Fri, 30 Jun 2000 10:33:09 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivuo28356
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 10:33:07 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivuo23483
	for <mpls@uu.net>; Fri, 30 Jun 2000 06:32:55 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivuo00548
	for <mpls@uu.net>; Fri, 30 Jun 2000 10:32:54 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA21752
	for mpls@uu.net; Fri, 30 Jun 2000 06:32:53 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivuo28343
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 10:32:27 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivuo23449
	for <mpls@uu.net>; Fri, 30 Jun 2000 06:32:21 -0400 (EDT)
Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQivuo00267
	for <mpls@uu.net>; Fri, 30 Jun 2000 10:32:21 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12526;
	Fri, 30 Jun 2000 06:32:19 -0400 (EDT)
Message-Id: <200006301032.GAA12526@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: mpls@UU.NET
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Use of Label Switching on Frame Relay
	 Networks Specification to Proposed Standard
Date: Fri, 30 Jun 2000 06:32:19 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk



The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:

o Use of Label Switching on Frame Relay Networks Specification
	<draft-ietf-mpls-fr-06.txt>

o MPLS using ATM VC Switching
	<draft-ietf-mpls-atm-04.txt>

These documents are the product of the Multiprotocol Label Switching
Working Group.  The IESG contact persons are David Oran and Rob
Coltun.

 
 
Technical Summary
 
These documents extend and clarify the relevant portions of MPLS
architecture and the Label Distribution Protocol by specifying in more
detail the procedures which are to be used when distributing labels to
or from ATM and Frame Relay LSRs. They also specify the MPLS
encapsulations to be used when sending labeled packets to or from
ATM and Frame Relay LSRs.

Working Group Summary

There was no significant dissent from the working group
on these drafts.

Protocol Quality

These specs were reviewed for the IESG by Rob Coltun.
There are implementations of both mechanisms.

Note to RFC Editor:

Please remove Appendix A on draft-ietf-mpls-fr-05.txt prior to 
publication.
-



From owner-mpls@UU.NET  Fri Jun 30 09:58:53 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17654
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 09:58:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivvb06909;
	Fri, 30 Jun 2000 13:58:28 GMT
Received: by mail-control.mail.uu.net 
	id QQivvb15897
	for mpls-outgoing; Fri, 30 Jun 2000 13:57:51 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivvb15873
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 13:57:42 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivvb20918
	for <mpls@uu.net>; Fri, 30 Jun 2000 09:56:57 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQivvb26507
	for <mpls@uu.net>; Fri, 30 Jun 2000 13:56:57 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA21246
	for <mpls@uu.net>; Fri, 30 Jun 2000 06:57:08 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09331 for mpls@uu.net; Fri, 30 Jun 2000 09:56:55 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivuw28148
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 12:44:09 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivuw07480
	for <mpls@UU.NET>; Fri, 30 Jun 2000 08:44:03 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQivuw03570
	for <mpls@UU.NET>; Fri, 30 Jun 2000 12:43:48 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <NYPNW8R9>; Fri, 30 Jun 2000 08:40:48 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B85025AC2@xover1.netplane.com>
From: "Sanford, Bill" <bills@netplane.com>
To: "'George Swallow'" <swallow@cisco.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: Need for RRO Object in the Error Mesg. 
Date: Fri, 30 Jun 2000 08:40:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

In 4.4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, the three possible uses
for the RRO are loop detection, up-to-date detailed path information
hop-by-hop about RSVP sessions, and to populate the EXPLICIT_ROUTE object.
In all my interoperability testing, all of these scenarios are handled by
the PATH and RESV message types.  

We should let the "RRO too large for MTU" subcode return in the ERROR SPEC
object without having to return the RRO.

Bill

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Thursday, June 29, 2000 3:41 PM
> To: Markus Jork
> Cc: mpls@UU.NET; swallow@cisco.com
> Subject: Re: Need for RRO Object in the Error Mesg. 
> 
> 
> > arumugamr@future.futsoft.com said:
> > > This message is regarding to the need of RRO object in the PathErr
> > > message  & ResvErr Mesg if the size of the RRO exceeds the Maximum
> > > MTU. Is it not enough to send the error message alone to 
> the Ingress
> > > of the  tunnel to get it removed? 
> > 
> > I also don't see much value in including the RRO object in the
> > error message and think this requirement should be removed from
> > the spec.
> > In addition, this part of the spec conflicts with section 3 and
> > section 4.4 of the same spec (draft-ietf-mpls-rsvp-lsp-tunnel-05)
> > which say that an RRO is only included in Path and Resv messages.
> > 
> > Markus
> 
> Seems that a number of folks would like to see this disappear.  Does
> anyone want to argue for keeping it?  If not I'll remove it from the
> next rev (which will be out before the cut-off).
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 



From owner-mpls@UU.NET  Fri Jun 30 10:18:22 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18051
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 10:18:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivvd20803;
	Fri, 30 Jun 2000 14:17:53 GMT
Received: by mail-control.mail.uu.net 
	id QQivvd29076
	for mpls-outgoing; Fri, 30 Jun 2000 14:17:08 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivvd29053
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 14:16:57 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivvd19620
	for <mpls@uu.net>; Fri, 30 Jun 2000 10:16:50 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivvd19760
	for <mpls@uu.net>; Fri, 30 Jun 2000 14:16:34 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA09194
	for mpls@uu.net; Fri, 30 Jun 2000 10:16:33 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivvd28917
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 14:16:13 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivvd24404
	for <mpls@UU.NET>; Fri, 30 Jun 2000 10:15:54 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQivvd09749
	for <mpls@UU.NET>; Fri, 30 Jun 2000 14:15:38 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA21512;
	Fri, 30 Jun 2000 07:15:30 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <NCLJBLJT>; Fri, 30 Jun 2000 07:16:47 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B4066D@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Grenville Armitage'" <gja@dnrc.bell-labs.com>,
        Francois Le Faucheur
	 <flefauch@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Figures in 2.6.3&2.6.4 Re: Last Call feedback on MPLS-Diff-Se
	rv
Date: Fri, 30 Jun 2000 07:16:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Grenville,

Good catch. How about removing the parentheses surrounding (E), (I), (P) and
add to the bottom of the figures the definition of E, I and P. In
other words how about this:

         ========== LSP ==========================>
                 +--Swap-(M)-...-Swap-(M)--+
                /        (outer header)     \
              (M)                           (M)
              /                               \
   >--(M)--Push...............(x)............Pop-(M)--E--(M)->
             I            (inner header)      P

(M) represents the Meaningful Diff-Serv information encoded in the
   corresponding header.   
(x) represents non-meaningful Diff-Serv information.

 I  represents the tunnel's Ingress node
 E  represents the tunnel's Egress node
 P  represents the tunnel's Penultimate node.


Cheers,
-Shahram 

>-----Original Message-----
>From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com]
>Sent: Thursday, June 29, 2000 8:00 PM
>To: Francois Le Faucheur
>Cc: mpls@UU.NET
>Subject: Figures in 2.6.3&2.6.4 Re: Last Call feedback on 
>MPLS-Diff-Serv
>
>
>Francois,
>
>Use of "(P)" in second figures of 2.6.3 and 2.6.4:
>
>Francois Le Faucheur wrote:
>	[..]
>> >#6 Section 2.6.3, 2nd Figure
>> >
>> >   There's a "(P)" floating to the right of "(outer header)"
>> >   that perhaps ought not be there?  (Same for 2nd figure in
>> >   section 2.6.4)
>> 
>> (P) indicates the penultimate LSR in all diagrams. It appears at the
>> right location even in the 2nd figures (ie without PHP). It insists
>> on the fact that in those cases (P) does a swap (and not a pop) so
>> that the "outer header" is there between (P) and (E) to carry some
>> Diff-Serv info .
>
>Okay, I now understand the intent. But now I'm not sure the ASCII art
>is clear. In the non-PHP examples the "(P)" _appears_ to sit two hops
>prior to the "(E)" LSR, which is confusing. (Alternatively, it isn't
>clear from the ASCII art how to distinguish LSRs and links and
>therefore derive the message you intend about where the egress
>hops and penultimate hops exist. I can't figure out if the "(M)"
>represent LSRs or links using 'meaningful diffserv info' - my
>initial read took them as LSRs.) Perhaps the ASCII art could
>be clarified (or we could just assume readers know that non-PHP
>means "label swap all the way"?)
>
>cheers,
>gja
>_______________________________________________________________
>_________
>Grenville Armitage                    
>http://members.home.net/garmitage/
>Bell Labs Research Silicon Valley
>



From owner-mpls@UU.NET  Fri Jun 30 11:46:52 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19989
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 11:46:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivvj13073;
	Fri, 30 Jun 2000 15:46:29 GMT
Received: by mail-control.mail.uu.net 
	id QQivvj19030
	for mpls-outgoing; Fri, 30 Jun 2000 15:45:59 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivvj19021
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 15:45:50 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivvj09266
	for <mpls@UU.NET>; Fri, 30 Jun 2000 11:45:40 -0400 (EDT)
Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged))
	id QQivvj20599
	for <mpls@UU.NET>; Fri, 30 Jun 2000 15:45:25 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2650.21)
	id <MTQCDP1H>; Fri, 30 Jun 2000 08:51:54 -0700
Message-ID: <9A564CC874B5D3118FB9009027B0A66269083E@ICARIAN>
From: Eric Gray <EGray@zaffire.com>
To: "'Sanford, Bill'" <bills@netplane.com>,
        "'George Swallow'"
	 <swallow@cisco.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: Need for RRO Object in the Error Mesg. 
Date: Fri, 30 Jun 2000 08:51:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Bill,

	This is probably a good idea - though one
reason for including the RRO is that it might be
a good way to tell if the cause is that a message
has looped undetected for some reason.

--
Eric Gray

> -----Original Message-----
> From: Sanford, Bill [mailto:bills@netplane.com]
> Sent: Friday, June 30, 2000 5:41 AM
> To: 'George Swallow'
> Cc: 'mpls@UU.NET'
> Subject: RE: Need for RRO Object in the Error Mesg. 
> 
> 
> In 4.4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, the three 
> possible uses
> for the RRO are loop detection, up-to-date detailed path information
> hop-by-hop about RSVP sessions, and to populate the 
> EXPLICIT_ROUTE object.
> In all my interoperability testing, all of these scenarios 
> are handled by
> the PATH and RESV message types.  
> 
> We should let the "RRO too large for MTU" subcode return in 
> the ERROR SPEC
> object without having to return the RRO.
> 
> Bill
> 
> > -----Original Message-----
> > From: George Swallow [mailto:swallow@cisco.com]
> > Sent: Thursday, June 29, 2000 3:41 PM
> > To: Markus Jork
> > Cc: mpls@UU.NET; swallow@cisco.com
> > Subject: Re: Need for RRO Object in the Error Mesg. 
> > 
> > 
> > > arumugamr@future.futsoft.com said:
> > > > This message is regarding to the need of RRO object in 
> the PathErr
> > > > message  & ResvErr Mesg if the size of the RRO exceeds 
> the Maximum
> > > > MTU. Is it not enough to send the error message alone to 
> > the Ingress
> > > > of the  tunnel to get it removed? 
> > > 
> > > I also don't see much value in including the RRO object in the
> > > error message and think this requirement should be removed from
> > > the spec.
> > > In addition, this part of the spec conflicts with section 3 and
> > > section 4.4 of the same spec (draft-ietf-mpls-rsvp-lsp-tunnel-05)
> > > which say that an RRO is only included in Path and Resv messages.
> > > 
> > > Markus
> > 
> > Seems that a number of folks would like to see this disappear.  Does
> > anyone want to argue for keeping it?  If not I'll remove it from the
> > next rev (which will be out before the cut-off).
> > 
> > ...George
> > 
> > ==================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
> > 
> 


From owner-mpls@UU.NET  Fri Jun 30 12:04:06 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20544
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 12:04:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivvk24499;
	Fri, 30 Jun 2000 16:03:33 GMT
Received: by mail-control.mail.uu.net 
	id QQivvk26042
	for mpls-outgoing; Fri, 30 Jun 2000 16:03:11 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache02.uu.net [153.39.50.42])
	id QQivvk25822
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 16:03:03 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivvk15756
	for <mpls@uu.net>; Fri, 30 Jun 2000 12:02:46 -0400 (EDT)
Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQivvk23799
	for <mpls@uu.net>; Fri, 30 Jun 2000 16:02:45 GMT
Received: (from erosen@localhost)
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA23211
	for mpls@uu.net; Fri, 30 Jun 2000 12:02:44 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivvk24661
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 16:02:15 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivvk11807
	for <mpls@UU.NET>; Fri, 30 Jun 2000 12:02:07 -0400 (EDT)
Received: from procyon.pmc-sierra.bc.ca by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1])
	id QQivvk01824
	for <mpls@UU.NET>; Fri, 30 Jun 2000 16:02:07 GMT
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA13213;
	Fri, 30 Jun 2000 09:02:02 -0700 (PDT)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <NCLJBM4K>; Fri, 30 Jun 2000 09:03:19 -0700
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B40672@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Grenville Armitage'"
	 <gja@dnrc.bell-labs.com>,
        Francois Le Faucheur <flefauch@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Figures in 2.6.3&2.6.4 Re: Last Call feedback on MPLS-Diff-Se
	 rv
Date: Fri, 30 Jun 2000 09:03:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Grenville,

Accordingly, we could remove the (P) from the non-PHP figures too.

Regards,
-Shahram

>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Friday, June 30, 2000 10:17 AM
>To: 'Grenville Armitage'; Francois Le Faucheur
>Cc: mpls@UU.NET
>Subject: RE: Figures in 2.6.3&2.6.4 Re: Last Call feedback on
>MPLS-Diff-Se rv
>
>
>Hi Grenville,
>
>Good catch. How about removing the parentheses surrounding 
>(E), (I), (P) and
>add to the bottom of the figures the definition of E, I and P. In
>other words how about this:
>
>         ========== LSP ==========================>
>                 +--Swap-(M)-...-Swap-(M)--+
>                /        (outer header)     \
>              (M)                           (M)
>              /                               \
>   >--(M)--Push...............(x)............Pop-(M)--E--(M)->
>             I            (inner header)      P
>
>(M) represents the Meaningful Diff-Serv information encoded in the
>   corresponding header.   
>(x) represents non-meaningful Diff-Serv information.
>
> I  represents the tunnel's Ingress node
> E  represents the tunnel's Egress node
> P  represents the tunnel's Penultimate node.
>
>
>Cheers,
>-Shahram 
>
>>-----Original Message-----
>>From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com]
>>Sent: Thursday, June 29, 2000 8:00 PM
>>To: Francois Le Faucheur
>>Cc: mpls@UU.NET
>>Subject: Figures in 2.6.3&2.6.4 Re: Last Call feedback on 
>>MPLS-Diff-Serv
>>
>>
>>Francois,
>>
>>Use of "(P)" in second figures of 2.6.3 and 2.6.4:
>>
>>Francois Le Faucheur wrote:
>>	[..]
>>> >#6 Section 2.6.3, 2nd Figure
>>> >
>>> >   There's a "(P)" floating to the right of "(outer header)"
>>> >   that perhaps ought not be there?  (Same for 2nd figure in
>>> >   section 2.6.4)
>>> 
>>> (P) indicates the penultimate LSR in all diagrams. It appears at the
>>> right location even in the 2nd figures (ie without PHP). It insists
>>> on the fact that in those cases (P) does a swap (and not a pop) so
>>> that the "outer header" is there between (P) and (E) to carry some
>>> Diff-Serv info .
>>
>>Okay, I now understand the intent. But now I'm not sure the ASCII art
>>is clear. In the non-PHP examples the "(P)" _appears_ to sit two hops
>>prior to the "(E)" LSR, which is confusing. (Alternatively, it isn't
>>clear from the ASCII art how to distinguish LSRs and links and
>>therefore derive the message you intend about where the egress
>>hops and penultimate hops exist. I can't figure out if the "(M)"
>>represent LSRs or links using 'meaningful diffserv info' - my
>>initial read took them as LSRs.) Perhaps the ASCII art could
>>be clarified (or we could just assume readers know that non-PHP
>>means "label swap all the way"?)
>>
>>cheers,
>>gja
>>_______________________________________________________________
>>_________
>>Grenville Armitage                    
>>http://members.home.net/garmitage/
>>Bell Labs Research Silicon Valley
>>
>



From owner-mpls@UU.NET  Fri Jun 30 12:20:52 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21118
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 12:20:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivvl14483;
	Fri, 30 Jun 2000 16:20:29 GMT
Received: by mail-control.mail.uu.net 
	id QQivvl02427
	for mpls-outgoing; Fri, 30 Jun 2000 16:20:11 GMT
Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41])
	id QQivvl02422
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 16:20:08 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivvl24574
	for <mpls@UU.NET>; Fri, 30 Jun 2000 12:20:02 -0400 (EDT)
Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP 
	(peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6])
	id QQivvl05576
	for <mpls@UU.NET>; Fri, 30 Jun 2000 16:20:01 GMT
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Jun 30 12:18:13 EDT 2000
Received: from dnrc.bell-labs.com (ex-vpn67.pa.bell-labs.com [135.250.1.67])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA20423;
	Fri, 30 Jun 2000 12:18:51 -0400 (EDT)
Message-ID: <395CC93F.2432C6F8@dnrc.bell-labs.com>
Date: Fri, 30 Jun 2000 09:22:23 -0700
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Labs Research Silicon Valley
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: mpls@UU.NET
Subject: Re: Figures in 2.6.3&2.6.4 Re: Last Call feedback on MPLS-Diff-Serv
References: <336ECDAFDF7DD311B9E30090277AEE4101B40672@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Shahram,

I like the revised ASCII art. Removing the P in the
non-PHP figures will be fine with me, thanks!

cheers,
gja

Shahram Davari wrote:
> 
> Hi Grenville,
> 
> Accordingly, we could remove the (P) from the non-PHP figures too.
> 
> Regards,
> -Shahram
> 
> >-----Original Message-----
> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> >Sent: Friday, June 30, 2000 10:17 AM
> >To: 'Grenville Armitage'; Francois Le Faucheur
> >Cc: mpls@UU.NET
> >Subject: RE: Figures in 2.6.3&2.6.4 Re: Last Call feedback on
> >MPLS-Diff-Se rv
> >
> >
> >Hi Grenville,
> >
> >Good catch. How about removing the parentheses surrounding
> >(E), (I), (P) and
> >add to the bottom of the figures the definition of E, I and P. In
> >other words how about this:
> >
> >         ========== LSP ==========================>
> >                 +--Swap-(M)-...-Swap-(M)--+
> >                /        (outer header)     \
> >              (M)                           (M)
> >              /                               \
> >   >--(M)--Push...............(x)............Pop-(M)--E--(M)->
> >             I            (inner header)      P
> >
> >(M) represents the Meaningful Diff-Serv information encoded in the
> >   corresponding header.
> >(x) represents non-meaningful Diff-Serv information.
> >
> > I  represents the tunnel's Ingress node
> > E  represents the tunnel's Egress node
> > P  represents the tunnel's Penultimate node.
> >
> >
> >Cheers,
> >-Shahram
	[..]
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley


From owner-mpls@UU.NET  Fri Jun 30 13:23:42 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22700
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 13:23:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivvp27081;
	Fri, 30 Jun 2000 17:22:54 GMT
Received: by mail-control.mail.uu.net 
	id QQivvp18365
	for mpls-outgoing; Fri, 30 Jun 2000 17:22:31 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivvp18355
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 17:22:24 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivvp24697
	for <mpls@uu.net>; Fri, 30 Jun 2000 13:21:57 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQivvp26247
	for <mpls@uu.net>; Fri, 30 Jun 2000 17:21:56 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA14185
	for <mpls@uu.net>; Fri, 30 Jun 2000 10:22:07 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA10017 for mpls@uu.net; Fri, 30 Jun 2000 13:21:54 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivvp18084
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 17:17:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivvp24036
	for <mpls@UU.NET>; Fri, 30 Jun 2000 13:16:58 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQivvp13681
	for <mpls@UU.NET>; Fri, 30 Jun 2000 17:16:57 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <NYPNW85P>; Fri, 30 Jun 2000 13:13:55 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B85025AC7@xover1.netplane.com>
From: "Sanford, Bill" <bills@netplane.com>
To: "'Eric Gray'" <EGray@zaffire.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: Need for RRO Object in the Error Mesg. 
Date: Fri, 30 Jun 2000 13:13:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric, 

If a PATH message has looped (given that RRO is used), either the loop will
be detected and the LSP will fail, the LSP will be established or the RRO
will be dropped mid-stream and loop before reaching the destination node.
If the RRO is to big and not looping, the intermediate node should send an
error to the Ingress and drop the RRO from the LSP and keep it moving to the
destination node.  If the LSP gets into a loop and causes the RRO to grow to
beyond the MAX MTU, the RRO should have detected it and stop at the first
instance of the loop.  If the RRO is dropped and the LSP loops before
reaching the destination node, how could you then tell if a loop has occured
if the MAX MTU isn't increased to go to the destination node?

If a RESV message has looped, the last paragraph in 4.4.4 of
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, "For Resv messages containing a
forwarding loop, the router simply drops the message.  Resv messages should
not loop if Path messages do not loop."

> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Friday, June 30, 2000 11:52 AM
> To: 'Sanford, Bill'; 'George Swallow'
> Cc: 'mpls@UU.NET'
> Subject: RE: Need for RRO Object in the Error Mesg. 
> 
> 
> Bill,
> 
> 	This is probably a good idea - though one
> reason for including the RRO is that it might be
> a good way to tell if the cause is that a message
> has looped undetected for some reason.
> 
> --
> Eric Gray
> 
> > -----Original Message-----
> > From: Sanford, Bill [mailto:bills@netplane.com]
> > Sent: Friday, June 30, 2000 5:41 AM
> > To: 'George Swallow'
> > Cc: 'mpls@UU.NET'
> > Subject: RE: Need for RRO Object in the Error Mesg. 
> > 
> > 
> > In 4.4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, the three 
> > possible uses
> > for the RRO are loop detection, up-to-date detailed path information
> > hop-by-hop about RSVP sessions, and to populate the 
> > EXPLICIT_ROUTE object.
> > In all my interoperability testing, all of these scenarios 
> > are handled by
> > the PATH and RESV message types.  
> > 
> > We should let the "RRO too large for MTU" subcode return in 
> > the ERROR SPEC
> > object without having to return the RRO.
> > 
> > Bill
> > 
> > > -----Original Message-----
> > > From: George Swallow [mailto:swallow@cisco.com]
> > > Sent: Thursday, June 29, 2000 3:41 PM
> > > To: Markus Jork
> > > Cc: mpls@UU.NET; swallow@cisco.com
> > > Subject: Re: Need for RRO Object in the Error Mesg. 
> > > 
> > > 
> > > > arumugamr@future.futsoft.com said:
> > > > > This message is regarding to the need of RRO object in 
> > the PathErr
> > > > > message  & ResvErr Mesg if the size of the RRO exceeds 
> > the Maximum
> > > > > MTU. Is it not enough to send the error message alone to 
> > > the Ingress
> > > > > of the  tunnel to get it removed? 
> > > > 
> > > > I also don't see much value in including the RRO object in the
> > > > error message and think this requirement should be removed from
> > > > the spec.
> > > > In addition, this part of the spec conflicts with section 3 and
> > > > section 4.4 of the same spec 
> (draft-ietf-mpls-rsvp-lsp-tunnel-05)
> > > > which say that an RRO is only included in Path and Resv 
> messages.
> > > > 
> > > > Markus
> > > 
> > > Seems that a number of folks would like to see this 
> disappear.  Does
> > > anyone want to argue for keeping it?  If not I'll remove 
> it from the
> > > next rev (which will be out before the cut-off).
> > > 
> > > ...George
> > > 
> > > ==================================================================
> > > George Swallow       Cisco Systems                   
> (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> > > 
> > 
> 



From owner-mpls@UU.NET  Fri Jun 30 15:05:53 2000
Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24549
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 15:05:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivvw24589;
	Fri, 30 Jun 2000 19:05:22 GMT
Received: by mail-control.mail.uu.net 
	id QQivvw16848
	for mpls-outgoing; Fri, 30 Jun 2000 19:04:56 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivvw16843
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 19:04:53 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivvw11237
	for <mpls@uu.net>; Fri, 30 Jun 2000 15:04:18 -0400 (EDT)
Received: from iol.unh.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mars.iol.unh.edu [132.177.121.222])
	id QQivvw06144
	for <mpls@uu.net>; Fri, 30 Jun 2000 19:04:18 GMT
Received: from localhost (jzou@localhost)
	by iol.unh.edu (8.9.3/8.9.3) with ESMTP id PAA26627
	for <mpls@uu.net>; Fri, 30 Jun 2000 15:04:17 -0400 (EDT)
Date: Fri, 30 Jun 2000 15:04:17 -0400
From: Jie Zou <jzou@mars.iol.unh.edu>
To: mpls@UU.NET
Subject: Several questions about RSVP
Message-ID: <Pine.SGI.4.20.0006301451190.26207-100000@mars.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


I hope some one can help me.

I have some questions about RSVP-TE on
"draft-ietf-mpls-rsvp-lsp-tunnel-05.txt":

1. On page 18, section 4.2
	"L3PID an identifier of the layer 3 protocal using this path.
	 Standard Ethertype values are used"
   My question is where I can find out these Standard Ethertype values on
   the layer 3 protocal ? 

2. On page 21, line 8, section 4.2.1,
        "The LABEL_REQUEST SHOULD be stored in the Path State Block", to
this, my consideration is that the LRO SHOULD be stored in the Path State
Block in the intermediate nodes, not ingress node and egress node.
        But there is another possible: the LRO is stored in all nodes
including ingress and egress node. Which one is correct or there is
another explaination?


3. on page 48, line 16, section 5.3

        "On receipt of a message containing a HELLO REQUEST object, the
   receiver MUST generate a Hello message containing a HELLO ACK object"

        "The receiver SHOULD also verify that the neighbor has not reset.
   This is done by comparing the sender's Src_Instance field value with
   the previously received value.  If the value differs, then a node
   MUST treat the neighbor as if communication has been lost."

 my confused is about "the previously received value": if the receiver
 received a message containing a HRO first time(no previously
 received value), then the value should be difference(I guess), then the
 communication has been lost at the first time by the explaination of
 draft. It seems that establishing communication is not possible. But it
 is possible. The question is how they can do it.


Thanks


Jie Zou


-------------------
MPLS Consortium
IOL, UNH
-------------------





From owner-mpls@UU.NET  Fri Jun 30 16:50:34 2000
Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26212
	for <mpls-archive@lists.ietf.org>; Fri, 30 Jun 2000 16:50:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQivwd15628;
	Fri, 30 Jun 2000 20:49:55 GMT
Received: by mail-control.mail.uu.net 
	id QQivwd07872
	for mpls-outgoing; Fri, 30 Jun 2000 20:49:29 GMT
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: intcache03.uu.net [153.39.7.42])
	id QQivwd07852
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 20:49:19 GMT
Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69])
	id QQivwd27172
	for <mpls@uu.net>; Fri, 30 Jun 2000 16:49:09 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88])
	id QQivwd14824
	for <mpls@uu.net>; Fri, 30 Jun 2000 20:48:54 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA12880
	for <mpls@uu.net>; Fri, 30 Jun 2000 13:49:05 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA10449 for mpls@uu.net; Fri, 30 Jun 2000 16:48:52 -0400 (EDT)
Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41])
	id QQivvp18084
	for <mpls@mail-control.mail.uu.net>; Fri, 30 Jun 2000 17:17:30 GMT
Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68])
	id QQivvp24036
	for <mpls@UU.NET>; Fri, 30 Jun 2000 13:16:58 -0400 (EDT)
Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.160.241.130])
	id QQivvp13681
	for <mpls@UU.NET>; Fri, 30 Jun 2000 17:16:57 GMT
Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21)
	id <NYPNW85P>; Fri, 30 Jun 2000 13:13:55 -0400
Message-ID: <7BF58A904536D411ADD400508BC97B85025AC7@xover1.netplane.com>
From: "Sanford, Bill" <bills@netplane.com>
To: "'Eric Gray'" <EGray@zaffire.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: Need for RRO Object in the Error Mesg. 
Date: Fri, 30 Jun 2000 13:13:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric, 

If a PATH message has looped (given that RRO is used), either the loop will
be detected and the LSP will fail, the LSP will be established or the RRO
will be dropped mid-stream and loop before reaching the destination node.
If the RRO is to big and not looping, the intermediate node should send an
error to the Ingress and drop the RRO from the LSP and keep it moving to the
destination node.  If the LSP gets into a loop and causes the RRO to grow to
beyond the MAX MTU, the RRO should have detected it and stop at the first
instance of the loop.  If the RRO is dropped and the LSP loops before
reaching the destination node, how could you then tell if a loop has occured
if the MAX MTU isn't increased to go to the destination node?

If a RESV message has looped, the last paragraph in 4.4.4 of
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, "For Resv messages containing a
forwarding loop, the router simply drops the message.  Resv messages should
not loop if Path messages do not loop."

> -----Original Message-----
> From: Eric Gray [mailto:EGray@zaffire.com]
> Sent: Friday, June 30, 2000 11:52 AM
> To: 'Sanford, Bill'; 'George Swallow'
> Cc: 'mpls@UU.NET'
> Subject: RE: Need for RRO Object in the Error Mesg. 
> 
> 
> Bill,
> 
> 	This is probably a good idea - though one
> reason for including the RRO is that it might be
> a good way to tell if the cause is that a message
> has looped undetected for some reason.
> 
> --
> Eric Gray
> 
> > -----Original Message-----
> > From: Sanford, Bill [mailto:bills@netplane.com]
> > Sent: Friday, June 30, 2000 5:41 AM
> > To: 'George Swallow'
> > Cc: 'mpls@UU.NET'
> > Subject: RE: Need for RRO Object in the Error Mesg. 
> > 
> > 
> > In 4.4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, the three 
> > possible uses
> > for the RRO are loop detection, up-to-date detailed path information
> > hop-by-hop about RSVP sessions, and to populate the 
> > EXPLICIT_ROUTE object.
> > In all my interoperability testing, all of these scenarios 
> > are handled by
> > the PATH and RESV message types.  
> > 
> > We should let the "RRO too large for MTU" subcode return in 
> > the ERROR SPEC
> > object without having to return the RRO.
> > 
> > Bill
> > 
> > > -----Original Message-----
> > > From: George Swallow [mailto:swallow@cisco.com]
> > > Sent: Thursday, June 29, 2000 3:41 PM
> > > To: Markus Jork
> > > Cc: mpls@UU.NET; swallow@cisco.com
> > > Subject: Re: Need for RRO Object in the Error Mesg. 
> > > 
> > > 
> > > > arumugamr@future.futsoft.com said:
> > > > > This message is regarding to the need of RRO object in 
> > the PathErr
> > > > > message  & ResvErr Mesg if the size of the RRO exceeds 
> > the Maximum
> > > > > MTU. Is it not enough to send the error message alone to 
> > > the Ingress
> > > > > of the  tunnel to get it removed? 
> > > > 
> > > > I also don't see much value in including the RRO object in the
> > > > error message and think this requirement should be removed from
> > > > the spec.
> > > > In addition, this part of the spec conflicts with section 3 and
> > > > section 4.4 of the same spec 
> (draft-ietf-mpls-rsvp-lsp-tunnel-05)
> > > > which say that an RRO is only included in Path and Resv 
> messages.
> > > > 
> > > > Markus
> > > 
> > > Seems that a number of folks would like to see this 
> disappear.  Does
> > > anyone want to argue for keeping it?  If not I'll remove 
> it from the
> > > next rev (which will be out before the cut-off).
> > > 
> > > ...George
> > > 
> > > ==================================================================
> > > George Swallow       Cisco Systems                   
> (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> > > 
> > 
>