From owner-mpls@UU.NET Tue Apr 1 01:03:31 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14331 for ; Tue, 1 Apr 2003 01:03:29 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimh26382 for ; Tue, 1 Apr 2003 03:55:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoimh23845; Tue, 1 Apr 2003 03:54:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoimf06677 for mpls-outgoing; Tue, 1 Apr 2003 03:29:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoimf06672 for ; Tue, 1 Apr 2003 03:28:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoimf11344 for ; Tue, 1 Apr 2003 03:28:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimf22586 for ; Tue, 1 Apr 2003 03:28:35 GMT Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQoimf22580 for ; Tue, 1 Apr 2003 03:28:35 GMT Received: from aatlas-lt.avici.com (b2vpnpc35.avici.com [10.2.101.35]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id h313SPC16534; Mon, 31 Mar 2003 22:28:26 -0500 (EST) Message-Id: <5.1.0.14.2.20030331222623.01fc16c8@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 31 Mar 2003 22:28:49 -0500 To: Shahram Davari From: Alia Atlas Subject: RE: [PWE3] MPLS PID Cc: "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 02:40 PM 3/31/2003 -0800, Shahram Davari wrote: >I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network >is fundamentally wrong, and is impossible to do for all ECMP >implementations such as the one that I described in earlier emails in >which both the first nibble and the CRC are used to detect IP. I don't believe that it is at all impossible to use the first nibble to determine a potential IPv4 packet and then use the header checksum to confirm it. This method works just fine. >The best way to solve this problem is to do ECMP only based on label >stack. Doing so should be >easier than introducing new standard. But doing ECMP on the label stack yields much larger micro-flows than doing ECMP based upon the IP headers inside, if possible. Thus, there is worse load-balancing of the flows across the network. Alia From owner-mpls@UU.NET Tue Apr 1 02:03:07 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17646 for ; Tue, 1 Apr 2003 02:03:06 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimu05838 for ; Tue, 1 Apr 2003 07:05:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoimu05507; Tue, 1 Apr 2003 07:05:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQoims15503 for mpls-outgoing; Tue, 1 Apr 2003 06:39:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoims15493 for ; Tue, 1 Apr 2003 06:39:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoims13672 for ; Tue, 1 Apr 2003 06:38:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoims22936 for ; Tue, 1 Apr 2003 06:38:40 GMT Received: from relay2.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQoims22914 for ; Tue, 1 Apr 2003 06:38:39 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h316cbE23558 for ; Tue, 1 Apr 2003 08:38:37 +0200 (MET DST) Received: from alcatel.be ([138.203.137.2]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003040108383537:1403 ; Tue, 1 Apr 2003 08:38:35 +0200 Message-ID: <3E89335B.E1691D6E@alcatel.be> Date: Tue, 01 Apr 2003 08:36:11 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Check MPLS WG Consensus (on soft preemption) References: <200303311906.OAA05305@bifocal.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 08:38:35, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 08:38:37, Serialize complete at 04/01/2003 08:38:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi, to address the following comment exchange: ----- > > > The preference for the RRO flag is that like the protect-inuse, > > > the ingress knows which hops it does not have resources on. > > > Consider the path A-B-C-...Z. If hops D-E and G-H have preempted, > > > but all of the hops are near 100% utilized, the ingress knows it > > > can share bandwidth with its prior LSP on all hops for which the > > > RRO flag bit is not set. Its harder to do that with a collection > > > of path-err messages. > > That's perfectly correct and one of the reasons why we ended up > > with this scheme. Otherwise, the HE would have had to wait for some > > unknown period of time (to make sure it has received all the PERR > > from the set of preempting nodes) before triggering a new CSPF on > > the modified topology > OK. But I don't see how using Resv lets you know when all of the > premption is complete. Since in your example preemption of D-E is > likely to happen first it will trigger a Resv reporting just one > hop as preempted. Later there will be another Resv that indicates > D-E and G-H as preempted. Sometime later there might be another > Resv indicating further preemption down near Z. The only advantage > seems to be that the Resv gives you a list of preemptions that have > happened (saving the HE from having to maintain that list itself). > It does not remove the "unknown period of time" issue. ----- we may consider two modes, a fast one using PathErr messages (or even Notify messages) to the sender (optimizing the time performance), and a trace mode using the RRO but with a prior notification to the receiver so that the complete trace is available through the RRO at the sender side before making a decision (optimizing the resource performance), i have got the impression that the current solution tries to optimize both at the same time but as mentioned by adrian it doesn't seem to be feasible thanks, - dimitri. George Swallow wrote: > > In San Francisco the workgroup showed support for making > > MPLS Traffic Engineering Soft preemption > draft-meyer-mpls-soft-preemption-00.txt > > an MPLS WG Document. This message is to solicit any further comments > prior to making a final determination. > > Please reply by 4/7 24:00 GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Tue Apr 1 03:17:36 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00988 for ; Tue, 1 Apr 2003 03:17:36 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimz14804 for ; Tue, 1 Apr 2003 08:20:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoimz14566; Tue, 1 Apr 2003 08:19:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoimx09416 for mpls-outgoing; Tue, 1 Apr 2003 07:47:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoimx09411 for ; Tue, 1 Apr 2003 07:47:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoimx12248 for ; Tue, 1 Apr 2003 07:47:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimx00769 for ; Tue, 1 Apr 2003 07:47:17 GMT Received: from p-mail1.rd.francetelecom.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail1.rd.francetelecom.com [195.101.245.15]) id QQoimx00758 for ; Tue, 1 Apr 2003 07:47:16 GMT Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Tue, 01 Apr 2003 09:47:33 +0200 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Apr 2003 09:47:08 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F822.E54424A0" x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Check MPLS WG Consensus (on nodeid-subobject) Date: Tue, 1 Apr 2003 09:47:07 +0200 Message-ID: <1FB136FD10CE33409C882630E299F5BE1EDC41@lanmhs30.rd.francetelecom.fr> Thread-Topic: RE: Check MPLS WG Consensus (on nodeid-subobject) Thread-Index: AcL4IuU9vTUZBhd4TOqaEpc1VwQqwA== From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: , "George Swallow" X-OriginalArrivalTime: 01 Apr 2003 07:47:08.0793 (UTC) FILETIME=[E5CF2690:01C2F822] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2F822.E54424A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree for support of this draft JL >In San Francisco the workgroup showed support for making > Definition of an RRO node-id subobject > draft-vasseur-mpls-nodeid-subobject-00.txt > >an MPLS WG Document. This message is to solicit any further comments >prior to making a final determination. > >Please reply by 4/7 24:00 GMT. > >...George > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 ------_=_NextPart_001_01C2F822.E54424A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Check MPLS WG Consensus (on nodeid-subobject)

I agree for = support of this draft

JL


>In San = Francisco the workgroup showed support for making
>   Definition of an RRO node-id = subobject
>     = draft-vasseur-mpls-nodeid-subobject-00.txt
>
>an MPLS = WG Document.  This message is to solicit any further = comments
>prior = to making a final determination.
>
>Please = reply by 4/7 24:00 GMT.
>
>...George
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>George = Swallow          Cisco = Systems           =         (978) 936-1398
>          &nbs= p;            = ;  250 Apollo Drive
>          &nbs= p;            = ;  Chelmsford, Ma 01824


------_=_NextPart_001_01C2F822.E54424A0-- From owner-mpls@UU.NET Tue Apr 1 03:58:58 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01443 for ; Tue, 1 Apr 2003 03:58:57 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoinc24839 for ; Tue, 1 Apr 2003 09:01:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoinc24448; Tue, 1 Apr 2003 09:01:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQoina01439 for mpls-outgoing; Tue, 1 Apr 2003 08:36:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoina01427 for ; Tue, 1 Apr 2003 08:36:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoina21047 for ; Tue, 1 Apr 2003 08:35:56 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoina09374 for ; Tue, 1 Apr 2003 08:35:55 GMT Received: from sa.infonet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sa.infonet.com [192.157.130.21]) id QQoina09360 for ; Tue, 1 Apr 2003 08:35:55 GMT Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id h318ZoZt019792; Tue, 1 Apr 2003 08:35:50 GMT Received: from zhangr2.info.net (lasi254.us.info.net [204.140.71.254]) by delta.info.net with ESMTP id IAA22220; Tue, 1 Apr 2003 08:35:49 GMT Message-Id: <5.2.0.9.2.20030401003138.02e60e50@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Apr 2003 00:32:06 -0800 To: "LE ROUX Jean-Louis FTRD/DAC/LAN" , , "George Swallow" From: raymond zhang Subject: RE: Check MPLS WG Consensus (on nodeid-subobject) In-Reply-To: <1FB136FD10CE33409C882630E299F5BE1EDC41@lanmhs30.rd.francet elecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I echo JL's comments in support of this draft... Raymond At 09:47 AM 4/1/2003 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote: >I agree for support of this draft > >JL > > >In San Francisco the workgroup showed support for making > > Definition of an RRO node-id subobject > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > >an MPLS WG Document. This message is to solicit any further comments > >prior to making a final determination. > > > >Please reply by 4/7 24:00 GMT. > > > >...George > > > >====================================================================== > >George Swallow Cisco Systems (978) 936-1398 > > 250 Apollo Drive > > Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 1 04:11:24 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01664 for ; Tue, 1 Apr 2003 04:11:23 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimz28994 for ; Tue, 1 Apr 2003 08:16:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoimz28224; Tue, 1 Apr 2003 08:16:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQoimw08776 for mpls-outgoing; Tue, 1 Apr 2003 07:42:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoimw08771 for ; Tue, 1 Apr 2003 07:42:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoimw26828 for ; Tue, 1 Apr 2003 07:41:25 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimw18106 for ; Tue, 1 Apr 2003 07:41:25 GMT Received: from p-mail2 by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.com [193.49.124.32]) id QQoimw18086 for ; Tue, 1 Apr 2003 07:41:24 GMT Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail2 with InterScan Messaging Security Suite; Tue, 01 Apr 2003 09:46:39 +0200 Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Apr 2003 09:41:15 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Check MPLS WG Consensus (on soft preemption) Date: Tue, 1 Apr 2003 09:41:15 +0200 Message-ID: <1FB136FD10CE33409C882630E299F5BED0FA87@lanmhs30.rd.francetelecom.fr> Thread-Topic: Check MPLS WG Consensus (on soft preemption) Thread-Index: AcL4GvxNiCOg7kHqR9K7D92aCZ211gABoPjg From: "LE ROUX Jean-Louis FTRD/DAC/LAN" To: , "George Swallow" X-OriginalArrivalTime: 01 Apr 2003 07:41:15.0927 (UTC) FILETIME=[137C1270:01C2F822] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA01664 I agree for support of this draft JL George Swallow wrote: > > In San Francisco the workgroup showed support for making > > MPLS Traffic Engineering Soft preemption > draft-meyer-mpls-soft-preemption-00.txt > > an MPLS WG Document. This message is to solicit any further comments > prior to making a final determination. > > Please reply by 4/7 24:00 GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 1 04:30:20 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02095 for ; Tue, 1 Apr 2003 04:30:19 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoine20865 for ; Tue, 1 Apr 2003 09:32:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoine20329; Tue, 1 Apr 2003 09:32:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoinc21357 for mpls-outgoing; Tue, 1 Apr 2003 09:05:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoinc21351 for ; Tue, 1 Apr 2003 09:05:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoinc05707 for ; Tue, 1 Apr 2003 09:04:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoinc03332 for ; Tue, 1 Apr 2003 09:04:35 GMT Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQoinc02964 for ; Tue, 1 Apr 2003 09:04:25 GMT Received: from notes600.cc.telcordia.com (notes600.cc.telcordia.com [128.96.109.65]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id EAA24981 for ; Tue, 1 Apr 2003 04:02:07 -0500 (EST) Subject: William W. Nattrass/Telcordia is out of the office. From: "William W. Nattrass" To: mpls@UU.NET Message-ID: Date: Tue, 1 Apr 2003 04:02:06 -0500 X-MIMETrack: Serialize by Router on notes600/Telcordia(Release 5.0.6a |January 17, 2001) at 04/01/2003 04:02:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I will be out of the office starting 03/30/2003 and will not return until 04/07/2003. Please leave me voice mail on (732) 699-3502 and I will call you, as I check my voice mail each day. Thanks! Bill From owner-mpls@UU.NET Tue Apr 1 05:51:15 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03531 for ; Tue, 1 Apr 2003 05:51:15 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoinj16443 for ; Tue, 1 Apr 2003 10:53:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoinj16181; Tue, 1 Apr 2003 10:53:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQoinh16589 for mpls-outgoing; Tue, 1 Apr 2003 10:27:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoinh16582 for ; Tue, 1 Apr 2003 10:27:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoinh21353 for ; Tue, 1 Apr 2003 10:26:43 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoinh22890 for ; Tue, 1 Apr 2003 10:26:42 GMT Received: from bt0g2p.god.bel.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc136.alcatel.be [195.207.101.136]) id QQoinh22859 for ; Tue, 1 Apr 2003 10:26:41 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h31AQfJ25817 for ; Tue, 1 Apr 2003 12:26:41 +0200 Received: from alcatel.be ([138.203.67.27]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003040112263979:2876 ; Tue, 1 Apr 2003 12:26:39 +0200 Message-ID: <3E8968C6.8994326B@alcatel.be> Date: Tue, 01 Apr 2003 12:24:06 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) References: <1FB136FD10CE33409C882630E299F5BE1EDC41@lanmhs30.rd.francetelecom.fr> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 12:26:39, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 12:26:41, Serialize complete at 04/01/2003 12:26:41 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit several points here, first i'd like to know how this relates to the current polling of inter-area req's to worked out in the scope of the tewg ? then i thought that inter-area/inter-as solution development were within the scope of the ccamp wg (just to be sure that we also keep some consistence on the work is organised within the sub-ip area) now independently of the work organisation, this i-d is valuable when backup tunnels are used and i think the following i-d "complements" the proposed solution using detour lsp's for this real problem being "abr node protection and as border node protection": http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-protection-00.txt thanks, - dimitri. > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > I agree for support of this draft > > JL > > >In San Francisco the workgroup showed support for making > > Definition of an RRO node-id subobject > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > >an MPLS WG Document. This message is to solicit any further comments > > >prior to making a final determination. > > > >Please reply by 4/7 24:00 GMT. > > > >...George > > > >====================================================================== > > >George Swallow Cisco Systems (978) > 936-1398 > > 250 Apollo Drive > > Chelmsford, Ma 01824 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Tue Apr 1 09:40:55 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14559 for ; Tue, 1 Apr 2003 09:40:55 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiny02324 for ; Tue, 1 Apr 2003 14:43:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiny01724; Tue, 1 Apr 2003 14:43:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQoinx17282 for mpls-outgoing; Tue, 1 Apr 2003 14:17:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoinx17277 for ; Tue, 1 Apr 2003 14:17:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoinx20358 for ; Tue, 1 Apr 2003 14:16:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoinx03223 for ; Tue, 1 Apr 2003 14:16:26 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQoinx03213 for ; Tue, 1 Apr 2003 14:16:25 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31EFXV05918; Tue, 1 Apr 2003 09:15:33 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 09:15:33 -0500 Message-ID: From: "David Allan" To: "'Dan Tappan'" , Shahram Davari Cc: "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET Subject: RE: [PWE3] MPLS PID Date: Tue, 1 Apr 2003 09:15:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F859.2763DBCE" 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_01C2F859.2763DBCE Content-Type: text/plain; charset="iso-8859-1" Dan: The issue specific to ECMP is granularity vs. other trade offs (such as requiring control words, losing path consistency etc.), there is simply no free lunch. Obviously you cannot hash one label. If there is no usable label stack, consider FEC/incoming interface, sure it is not as fine grained as hashing the payload, the point is there are options that are less destructive to other useful properties. I think we can all agree with the argument that on paper, the finer the microflow classification the better for load spreading of a single LSP, do we have real measurement to back that up where there are large numbers of LSPs, or are we well into diminshing returns at that point? NOW If there are issues w.r.t. MPLS here, they are: 1) are we going to permanently break the paradigm where labels are PIDs?, because that's where we're headed. IMHO that's fairly fundamental. MPLS cannot just carry "anything" via signalled convention, because intermediate boxes are making their own assumptions as to what the payload is. 2) if we codify snooping the first nybble, it still does not fix ECMP hashing of reserved labels, we're still in the woods. We also hang out to dry work in PWE3 and other SDOs that are not compliant with this "new" convention. If the goal is that ECMP trumps the MPLS architecture, we have a few things to fix, not just the PID. If the goal is that MPLS must be backwards compliant with deployed or may be deployed ECMP gear making PW 1st nybbles == 0 is only a start. However I consider there to be a lot of practical difficulties with such a dictate, mandating that all future work to support proprietary and therefore unknowable implementations (a.k.a. arbitrary layer violations) is a bit of an oxymoron. cheers Dave > > You keep talking about using the label stack. Consider the case: > - at the end of an LSP, where the forwarding operation is > "pop and forward" > - and where the packets being carried are IP > - and there is ECMP on the output paths > > How is one supposed to make the ECMP decision in that case? > There's only > one label, so hashing on the label stack will only choose a > single path. > > And don't say "well, it's ok to look at the IP packet in that > case". If > it's "fundamentally wrong" to look at the data, as opposed to > the label(s), > in the packet to make an ECMP decision in the middle of the > LSP, then it's > "fundamentally wrong" at the end. > > Or is that case acceptable, because the particular pre-standard > implementation that you're trying to protect won't encounter it? > > Is it a layer violation for an IP ECMP implementation to look at the > TCP/UDP ports when spreading the traffic over paths? Or to > look under an > IPinIP tunnel header? Or for a WFQ implementation to look at > any packet > fields? Maybe, but there can be practical value in doing so. > > For that matter, if we're worrying about layer violations, > why is it ok to > look below the top label (as in "hash the label stack"). > Isn't that also a > layer violation? > > If your answer is "you know what the labels are, but you > don't know that > what the encapsulated data is" then that's the whole point of > this PID > discussion. > > IMO, if you want to make an argument based on architectural > purity and > "layering" then you need to stick with the top label. In any > other case > we've decided what we are, we're just arguing over the price. > > But, in fact I don't accept that any of these are layer > violations. In all > these cases, the fundamental forwarding decision is on the outermost > header. Any examination of underlying data is simply selecting finer > granularity of flows. In most of these discussions "layer > violation" is > simply a debating trick, holding out for OSI architectural > purity as when > all else fails. > > As I see it there are two possible approaches: > > 1. Require that an LSP set up for an IP L3PID or IP FEC carry > IP packets. 2. Allow non-IP packets on such an LSP, but > require that they be > distinguishable. > > The simple facts are: > - it turns out that [2] has value operationally, otherwise we > wouldn't be > having this discussion > - there is a proposal on the table which provides a backward > compatible > way to achieve [2], without affecting any fielded, standardized, > implementations. > - the only negative impact of the proposal is on existing > implementations > of pre-standard drafts. And we all know the risks of > implementing prior to > standardization. Even there, an operator can deploy the pre-standard > implementation, as long as they avoid [2]. > > Why isn't this a no-brainer? > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C2F859.2763DBCE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] MPLS PID

Dan:

The issue specific to ECMP is granularity vs. other = trade offs (such as requiring control words, losing path consistency = etc.), there is simply no free lunch. Obviously you cannot hash one = label. If there is no usable label stack, consider FEC/incoming = interface, sure it is not as fine grained as hashing the payload, the = point is there are options that are less destructive to other useful = properties.

I think we can all agree with the argument that on = paper, the finer the microflow classification the better for load = spreading of a single LSP, do we have real measurement to back that up = where there are large numbers of LSPs, or are we well into diminshing = returns at that point?

NOW If there are issues w.r.t. MPLS here, they = are:

1) are we going to permanently break the paradigm = where labels are PIDs?, because that's where we're headed. IMHO that's = fairly fundamental. MPLS cannot just carry "anything" via = signalled convention, because intermediate boxes are making their own = assumptions as to what the payload is.

2) if we codify snooping the first nybble, it still = does not fix ECMP hashing of reserved labels, we're still in the woods. = We also hang out to dry work in PWE3 and other SDOs that are not = compliant with this "new" convention.

If the goal is that ECMP trumps the MPLS = architecture, we have a few things to fix, not just the PID. If the = goal is that MPLS must be backwards compliant with deployed or may be = deployed ECMP gear making PW 1st nybbles =3D=3D 0 is only a start. =

However I consider there to be a lot of practical = difficulties with such a dictate, mandating that all future work to = support proprietary and therefore unknowable implementations (a.k.a. = arbitrary layer violations) is a bit of an oxymoron.

cheers
Dave


>
> You keep talking about using the label stack. = Consider the case:
> - at the end of an LSP, where the forwarding = operation is
> "pop and forward"
> - and where the packets being carried are = IP
> - and there is ECMP on the output paths
>
> How is one supposed to make the ECMP decision = in that case?
> There's only
> one label, so hashing on the label stack will = only choose a
> single path.
>
> And don't say "well, it's ok to look at = the IP packet in that
> case". If
> it's "fundamentally wrong" to look at = the data, as opposed to
> the label(s),
> in the packet to make an ECMP decision in the = middle of the
> LSP, then it's
> "fundamentally wrong" at the = end.
>
> Or is that case acceptable, because the = particular pre-standard
> implementation that you're trying to protect = won't encounter it?
>
> Is it a layer violation for an IP ECMP = implementation to look at the
> TCP/UDP ports when spreading the traffic over = paths? Or to
> look under an
> IPinIP tunnel header? Or for a WFQ = implementation to look at
> any packet
> fields? Maybe, but there can be practical value = in doing so.
>
> For that matter, if we're worrying about layer = violations,
> why is it ok to
> look below the top label (as in "hash the = label stack").
> Isn't that also a
> layer violation?
>
> If your answer is "you know what the = labels are, but you
> don't know that
> what the encapsulated data is" then that's = the whole point of
> this PID
> discussion.
>
> IMO, if you want to make an argument based on = architectural
> purity and
> "layering" then you need to stick = with the top label. In any
> other case
> we've decided what we are,  we're just = arguing over the price.
>
> But, in fact I don't accept that any of these = are layer
> violations. In all
> these cases, the fundamental forwarding = decision is on the outermost
> header. Any examination of underlying data is = simply selecting finer
> granularity of flows.  In most of these = discussions "layer
> violation" is
> simply a debating trick, holding out for OSI = architectural
> purity as when
> all else fails.
>
> As I see it there are two possible = approaches:
>
> 1. Require that an LSP set up for an IP L3PID = or IP FEC carry
> IP packets. 2. Allow non-IP packets on such an = LSP, but
> require that they be
> distinguishable.
>
> The simple facts are:
> - it turns out that [2] has value = operationally, otherwise we
> wouldn't be
> having this discussion
> -  there is a proposal on the table which = provides a backward
> compatible
> way to achieve [2], without affecting any = fielded, standardized,
> implementations.
> -  the only negative impact of the = proposal is on existing
> implementations
> of pre-standard drafts. And we all know the = risks of
> implementing prior to
> standardization. Even there, an operator can = deploy the pre-standard
> implementation, as long as they avoid = [2].
>
> Why isn't this a no-brainer?
>
>
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C2F859.2763DBCE-- From owner-mpls@UU.NET Tue Apr 1 11:43:25 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28168 for ; Tue, 1 Apr 2003 11:43:25 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioh13561 for ; Tue, 1 Apr 2003 16:45:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoioh12483; Tue, 1 Apr 2003 16:45:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiob10597 for mpls-outgoing; Tue, 1 Apr 2003 15:22:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoiob10578 for ; Tue, 1 Apr 2003 15:22:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoiob06835 for ; Tue, 1 Apr 2003 15:21:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiob11627 for ; Tue, 1 Apr 2003 15:21:14 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoiob11539 for ; Tue, 1 Apr 2003 15:21:12 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31FL8MR028117 for ; Tue, 1 Apr 2003 10:21:09 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15858 for ; Tue, 1 Apr 2003 10:21:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31FL8J15362 for mpls@uu.net; Tue, 1 Apr 2003 10:21:08 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoiob10455 for ; Tue, 1 Apr 2003 15:20:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoiob13283 for ; Tue, 1 Apr 2003 15:19:34 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiob06617 for ; Tue, 1 Apr 2003 15:19:31 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoiob06501 for ; Tue, 1 Apr 2003 15:19:29 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31FIgMR027898; Tue, 1 Apr 2003 10:18:42 -0500 (EST) Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-173.cisco.com [161.44.134.173]) by bucket.cisco.com (Mirapoint) with ESMTP id ACW02518; Tue, 1 Apr 2003 10:18:41 -0500 (EST) Message-Id: <5.2.0.9.2.20030401101807.04e94ec8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Apr 2003 10:18:30 -0500 To: Shahram Davari , "'Lloyd Wood'" From: "Thomas D. Nadeau" Subject: RE: [PWE3] MPLS PID Cc: pwe3@ietf.org, mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 02:40 PM 3/31/2003 -0800, Shahram Davari wrote: >I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network >is fundamentally wrong, and is impossible to do for all ECMP >implementations such as the one that I described >in earlier emails in which both the first nibble and the CRC are used to >detect IP. > >The best way to solve this problem is to do ECMP only based on label >stack. Doing so should be >easier than introducing new standard. Sharam, it sounds like you are introducing a new standard by insisting that ECMP only be based on the label stack. --Tom >-Shahram > > > >-----Original Message----- > >From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > >Sent: Sunday, March 30, 2003 6:11 PM > >To: Eric Rosen > >Cc: jeremy.de_clercq@alcatel.be; David Allan; 'Scott W Brim'; > >pwe3@ietf.org; mpls@UU.NET > >Subject: Re: [PWE3] MPLS PID > > > > > >On Thu, 27 Mar 2003, Eric Rosen wrote: > > > >> 1. The only reason for a PID field in MPLS and/or > >PWE3 is to allow > >> intermediate routers to determine whether a particular > >MPLS payload is an > >> IP packet or not. > > > >which is a layer violation, and shouldn't be done. > > > >> There are a number of reasons why this is useful, and > >no one has argued > >> that this is not useful. > > > >not appropriate, more like. > > > >if you're going to sniff for an IP packet (so you can sniff TCP/UDP or > >higher) you might want to ask why you even have any form of mpls > >label stack in there in the first place. > > > >if you're not separating out your ip flows via explicit mpls label, > >why not? > > > >L. > > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From owner-mpls@UU.NET Tue Apr 1 11:48:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28641 for ; Tue, 1 Apr 2003 11:48:51 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioh23029 for ; Tue, 1 Apr 2003 16:51:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoioh22842; Tue, 1 Apr 2003 16:51:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiob10822 for mpls-outgoing; Tue, 1 Apr 2003 15:25:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoiob10811 for ; Tue, 1 Apr 2003 15:25:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoiob09572 for ; Tue, 1 Apr 2003 15:23:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiob18101 for ; Tue, 1 Apr 2003 15:23:37 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQoiob18076 for ; Tue, 1 Apr 2003 15:23:37 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31FNKP27429 for ; Tue, 1 Apr 2003 10:23:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 10:23:20 -0500 Message-ID: From: "David Allan" To: "'mpls@UU.NET'" Subject: RE: Checking MPLS WG Consensus Date: Tue, 1 Apr 2003 10:23:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F862.9EE311C0" 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_01C2F862.9EE311C0 Content-Type: text/plain; charset="iso-8859-1" George/Loa: While I think an IETF requirements statement for OAM is useful, I'd like to understand better the relationship of pursuing this to both the current charter (where my experience is that OAM is out of scope, witness the BOF at IETF 51), and the decision last summer to effectively delegate OAM beyond ping and traceroute to the ITU-T SG13 via publishing RFC 3429. What is to be the scope of MPLS WGs efforts in this space? cheers Dave > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Monday, March 31, 2003 2:09 PM > To: mpls@UU.NET > Subject: Checking MPLS WG Consensus > > > In San Francisco the workgroup showed support for making > > OAM Requirements for MPLS Networks > draft-nadeau-ietf-oam-requirements-01.txt > > an MPLS WG Document. This message is to solicit any further > comments prior to making a final determination. > > Please reply by 4/7 24:00 GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > > ------_=_NextPart_001_01C2F862.9EE311C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Checking MPLS WG Consensus

George/Loa:

While I think an IETF requirements statement for OAM = is useful, I'd like to understand better the relationship of pursuing = this to both the current charter (where my experience is that OAM is = out of scope, witness the BOF at IETF 51), and the decision last summer = to effectively delegate OAM beyond ping and traceroute to the ITU-T = SG13 via publishing RFC 3429.

What is to be the scope of MPLS WGs efforts in this = space?

cheers
Dave



> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Monday, March 31, 2003 2:09 PM
> To: mpls@UU.NET
> Subject: Checking MPLS WG Consensus
>
>
> In San Francisco the workgroup showed support = for making
>
>   OAM Requirements for MPLS = Networks
>     = draft-nadeau-ietf-oam-requirements-01.txt
>
> an MPLS WG Document.  This message is to = solicit any further
> comments prior to making a final = determination.
>
> Please reply by 4/7 24:00 GMT.
>
> ...George
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> George = Swallow          Cisco = Systems           = ;        (978) 936-1398
>          = ;            = ;   250 Apollo Drive
>          = ;            = ;   Chelmsford, Ma 01824
>
>
>
>

------_=_NextPart_001_01C2F862.9EE311C0-- From owner-mpls@UU.NET Tue Apr 1 12:06:18 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29986 for ; Tue, 1 Apr 2003 12:06:18 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioi09826 for ; Tue, 1 Apr 2003 17:08:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoioi08737; Tue, 1 Apr 2003 17:08:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQoioc11713 for mpls-outgoing; Tue, 1 Apr 2003 15:36:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoioc11541 for ; Tue, 1 Apr 2003 15:35:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoioc17856 for ; Tue, 1 Apr 2003 15:34:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioc07598 for ; Tue, 1 Apr 2003 15:34:13 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoioc07564 for ; Tue, 1 Apr 2003 15:34:12 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31FY5MR029418 for ; Tue, 1 Apr 2003 10:34:10 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA16936 for ; Tue, 1 Apr 2003 10:34:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31FY5W17018 for mpls@uu.net; Tue, 1 Apr 2003 10:34:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoioc11418 for ; Tue, 1 Apr 2003 15:32:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoioc13366 for ; Tue, 1 Apr 2003 15:32:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioc03714 for ; Tue, 1 Apr 2003 15:32:30 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [216.241.224.12]) id QQoioc03537 for ; Tue, 1 Apr 2003 15:32:26 GMT Received: (qmail 7953 invoked by uid 104); 1 Apr 2003 15:32:15 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4254. Clear:. Processed in 0.490996 secs); 01 Apr 2003 15:32:15 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.com with SMTP; 1 Apr 2003 15:32:14 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h31FWE901745; Tue, 1 Apr 2003 07:32:14 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 1 Apr 2003 07:32:13 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C86C@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Dan Tappan'" Cc: "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET Subject: RE: [PWE3] MPLS PID Date: Tue, 1 Apr 2003 07:32:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Dan, I know that doing a fine level ECMP is best for load balancing. But it seems that your ONLY goal is to preserve the fine level load balancing, without looking at other aspects which might be negatively affected by doing so. I don't believe people want to do perfect load balancing, at the expense of breaking other properties of MPLS. For example: 1) what would L3PID mean any more in MPLS signaling? would that be deprecated? If not what happens if the L3PID in the signaling does not match the PID in the payload? Who is going to detect that and what error message or actions should be taken? 2) what happens to other proprietary ECMP implementations? should only the implementations checking the first nibble to detect IP be supported or all others too? what if an ECMP implementation checks the checksum to detect IP (which is much more reliable than checking the first nibble)? if the PID is standardized to cater for the first nibble, then should it also cater for the checksum too? In other words should we state that when standardizing a PID, octets 11 and 12 of the payload should not result a valid checksum over the first 20 bytes? 3) How do you solve the ECMP for the case that a reserved label is used is the stack? 4) What does IPv4/v6 null mean in the future if the PID is standardized? will they be irrelevant? if not what happens if the PID and explicit null don't match? Please see specific comments in-line. -Shahram >-----Original Message----- >From: Dan Tappan [mailto:tappan@cisco.com] >Sent: Monday, March 31, 2003 7:42 PM >To: Shahram Davari >Cc: 'Lloyd Wood'; pwe3@ietf.org; mpls@UU.NET >Subject: RE: [PWE3] MPLS PID > > >At 02:40 PM 3/31/2003 -0800, Shahram Davari wrote: >>I agree with Lloyd. Sniffing IP packets in the middle of an >MPLS network >>is fundamentally wrong, and is impossible to do for all ECMP >>implementations such as the one that I described >>in earlier emails in which both the first nibble and the CRC >are used to >>detect IP. >> >>The best way to solve this problem is to do ECMP only based >on label stack. > >You keep talking about using the label stack. Consider the case: >- at the end of an LSP, where the forwarding operation is "pop >and forward" I assume you mean PHP. >- and where the packets being carried are IP If you know that the payload is IP why do you need PID? >- and there is ECMP on the output paths > >How is one supposed to make the ECMP decision in that case? >There's only >one label, so hashing on the label stack will only choose a >single path. You could always use incoming label stack, or even incoming port for ECMP decision. Or if as you said you know the payload is IP the use the IP header (which would be non-standard). > >And don't say "well, it's ok to look at the IP packet in that >case". If >it's "fundamentally wrong" to look at the data, as opposed to >the label(s), >in the packet to make an ECMP decision in the middle of the >LSP, then it's >"fundamentally wrong" at the end. If you know payload is IP use IP header, if you don't know then use label stack. > >Or is that case acceptable, because the particular pre-standard >implementation that you're trying to protect won't encounter it? As opposed to you, I have no implementation and am not protecting anybody's implementation. I am just stating what is the right architectural thing to do. > >Is it a layer violation for an IP ECMP implementation to look at the >TCP/UDP ports when spreading the traffic over paths? Or to >look under an >IPinIP tunnel header? Or for a WFQ implementation to look at >any packet >fields? Maybe, but there can be practical value in doing so. > >For that matter, if we're worrying about layer violations, why >is it ok to >look below the top label (as in "hash the label stack"). Isn't >that also a >layer violation? > >If your answer is "you know what the labels are, but you don't >know that >what the encapsulated data is" then that's the whole point of this PID >discussion. > >IMO, if you want to make an argument based on architectural purity and >"layering" then you need to stick with the top label. In any >other case >we've decided what we are, we're just arguing over the price. > >But, in fact I don't accept that any of these are layer >violations. In all >these cases, the fundamental forwarding decision is on the outermost >header. Any examination of underlying data is simply selecting finer >granularity of flows. In most of these discussions "layer >violation" is >simply a debating trick, holding out for OSI architectural >purity as when >all else fails. > >As I see it there are two possible approaches: > >1. Require that an LSP set up for an IP L3PID or IP FEC carry >IP packets. >2. Allow non-IP packets on such an LSP, but require that they be >distinguishable. > >The simple facts are: >- it turns out that [2] has value operationally, otherwise we >wouldn't be >having this discussion >- there is a proposal on the table which provides a backward >compatible >way to achieve [2], without affecting any fielded, standardized, >implementations. >- the only negative impact of the proposal is on existing >implementations >of pre-standard drafts. And we all know the risks of >implementing prior to >standardization. Even there, an operator can deploy the pre-standard >implementation, as long as they avoid [2]. > >Why isn't this a no-brainer? Because you are trying to be backward compatible with some proprietary implementations but do not want to be backward compatible with pre-standard implementations? Has a proprietary implementation more weight that a pres-standard implementation? Also there are other reasons that I have stated at the beginning of this email. -Shahram > > > From owner-mpls@UU.NET Tue Apr 1 12:06:49 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00028 for ; Tue, 1 Apr 2003 12:06:48 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioi10527 for ; Tue, 1 Apr 2003 17:09:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoioi10225; Tue, 1 Apr 2003 17:09:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQoioc11789 for mpls-outgoing; Tue, 1 Apr 2003 15:37:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoioc11775 for ; Tue, 1 Apr 2003 15:37:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoioc24856 for ; Tue, 1 Apr 2003 15:37:15 GMT From: stefaan.de_cnodder@alcatel.be Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioc12845 for ; Tue, 1 Apr 2003 15:37:15 GMT Received: from relay2.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQoioc12821 for ; Tue, 1 Apr 2003 15:37:14 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h31FbD700916 for ; Tue, 1 Apr 2003 17:37:13 +0200 (MET DST) Received: from alcatel.be ([138.203.197.32]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003040117371181:5627 ; Tue, 1 Apr 2003 17:37:11 +0200 Message-ID: <3E89B224.4E377DAB@alcatel.be> Date: Tue, 01 Apr 2003 17:37:08 +0200 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Nodeid (was Re: Check MPLS WG Consensus) References: <200303311905.OAA05296@bifocal.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 17:37:11, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 17:37:13, Serialize complete at 04/01/2003 17:37:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Why does the PLR have to know whether it is an interface address or a node-id? If the PLR has to select a backup tunnel, it scans the IP addresses in the RRO and compares the IP address in the RRO subobject with the tail-end of the backup tunnel if that IP address in the RRO cannot be converted to a node-id. If the IP address does not match, then the next RRO subobject is taken and then that one will match in case the MP includes an RRO subobject containing the node-id. So I do not see a reason to have to have a flag to indicate that it is a node-id or not. I would also like to see a precise definition of "the backup tunnel's tail-end". Is it the destination address of the bypass tunnel, ... regards, Stefaan George Swallow wrote: > > In San Francisco the workgroup showed support for making > > Definition of an RRO node-id subobject > draft-vasseur-mpls-nodeid-subobject-00.txt > > an MPLS WG Document. This message is to solicit any further comments > prior to making a final determination. > > Please reply by 4/7 24:00 GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 1 12:11:45 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00489 for ; Tue, 1 Apr 2003 12:11:45 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioi01157 for ; Tue, 1 Apr 2003 17:14:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoioi00565; Tue, 1 Apr 2003 17:13:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiod12527 for mpls-outgoing; Tue, 1 Apr 2003 15:45:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoiod12519 for ; Tue, 1 Apr 2003 15:45:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoioc13945 for ; Tue, 1 Apr 2003 15:44:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioc26414 for ; Tue, 1 Apr 2003 15:44:12 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoioc26305 for ; Tue, 1 Apr 2003 15:44:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31Fi3iH003335 for ; Tue, 1 Apr 2003 10:44:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA17768 for ; Tue, 1 Apr 2003 10:44:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31Fi3o18501 for mpls@uu.net; Tue, 1 Apr 2003 10:44:03 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoioc12113 for ; Tue, 1 Apr 2003 15:41:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoioc13931 for ; Tue, 1 Apr 2003 15:40:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioc20056 for ; Tue, 1 Apr 2003 15:40:47 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [216.241.224.12]) id QQoioc20006 for ; Tue, 1 Apr 2003 15:40:46 GMT Received: (qmail 10492 invoked by uid 104); 1 Apr 2003 15:40:45 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4254. Clear:. Processed in 0.457616 secs); 01 Apr 2003 15:40:45 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.com with SMTP; 1 Apr 2003 15:40:44 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h31Fei905125; Tue, 1 Apr 2003 07:40:44 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 1 Apr 2003 07:40:43 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C86D@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" , "'Lloyd Wood'" Cc: pwe3@ietf.org, mpls@UU.NET Subject: RE: [PWE3] MPLS PID Date: Tue, 1 Apr 2003 07:40:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk >>The best way to solve this problem is to do ECMP only based on label >>stack. Doing so should be >>easier than introducing new standard. > > Sharam, it sounds like you are introducing a new standard >by insisting that ECMP only be based on the label stack. > > --Tom > Tom, no I am not standardizing anything. I said, if you are not sure the payload is IP, you could always use the label stack for ECMP? After all isn't this what you do in case the payload is not IP? In other words there is a way around the problem that you are trying to solve. Whether you use it or not is up to you. -Shahram From owner-mpls@UU.NET Tue Apr 1 12:20:18 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01220 for ; Tue, 1 Apr 2003 12:20:18 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioj09223 for ; Tue, 1 Apr 2003 17:22:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoioj07847; Tue, 1 Apr 2003 17:22:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQoioe03120 for mpls-outgoing; Tue, 1 Apr 2003 16:11:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoioe03113 for ; Tue, 1 Apr 2003 16:11:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoioe22444 for ; Tue, 1 Apr 2003 16:11:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioe23604 for ; Tue, 1 Apr 2003 16:11:17 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoioe23494 for ; Tue, 1 Apr 2003 16:11:11 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31GB8iH011105 for ; Tue, 1 Apr 2003 11:11:09 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20043 for ; Tue, 1 Apr 2003 11:11:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31GB8K22675 for mpls@uu.net; Tue, 1 Apr 2003 11:11:08 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoioe02224 for ; Tue, 1 Apr 2003 16:08:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoioe13097 for ; Tue, 1 Apr 2003 16:07:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioe20942 for ; Tue, 1 Apr 2003 16:07:50 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [216.241.224.12]) id QQoioe20927 for ; Tue, 1 Apr 2003 16:07:50 GMT Received: (qmail 19746 invoked by uid 104); 1 Apr 2003 16:07:49 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4254. Clear:. Processed in 1.022591 secs); 01 Apr 2003 16:07:49 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.com with SMTP; 1 Apr 2003 16:07:47 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h31G7l917295; Tue, 1 Apr 2003 08:07:47 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 1 Apr 2003 08:07:47 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C86F@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Lloyd Wood'" Cc: pwe3@ietf.org, mpls@UU.NET Subject: RE: [PWE3] MPLS PID Date: Tue, 1 Apr 2003 08:07:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Lloyd, >-----Original Message----- >From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] >Sent: Tuesday, April 01, 2003 11:03 AM >To: Shahram Davari >Cc: pwe3@ietf.org; mpls@UU.NET >Subject: RE: [PWE3] MPLS PID > > >On Mon, 31 Mar 2003, Shahram Davari wrote: > >> for all ECMP >> implementations such as the one that I described >> in earlier emails in which both the first nibble >> and the CRC are used to detect IP. > >IPv6 doesn't _have_ a header checksum. Yes. The method I said only works for IPV4. >IPv4's header checksum is a pain to work with. !!!! > >Are you describing an existing implementation? It sounds broken. Why is it broken? It works much better than using the first nibble to detect IP. > >If you know from context you're carrying IP, then the intended >identification in the first nibble is enough to identify 4 or 6 or >something else, and you don't need to sniff the packet contents. Sure. But the question was how can you detect that the payload is IP. -Shahram > >L. > > > From owner-mpls@UU.NET Tue Apr 1 12:20:35 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01239 for ; Tue, 1 Apr 2003 12:20:34 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioj26284 for ; Tue, 1 Apr 2003 17:23:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoioj25826; Tue, 1 Apr 2003 17:22:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQoioe03284 for mpls-outgoing; Tue, 1 Apr 2003 16:14:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoioe03265 for ; Tue, 1 Apr 2003 16:14:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoioe28696 for ; Tue, 1 Apr 2003 16:14:16 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioe28267 for ; Tue, 1 Apr 2003 16:14:15 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoioe28256 for ; Tue, 1 Apr 2003 16:14:14 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31GEBMR003600 for ; Tue, 1 Apr 2003 11:14:11 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20277 for ; Tue, 1 Apr 2003 11:14:11 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31GEBj23150 for mpls@uu.net; Tue, 1 Apr 2003 11:14:11 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoioe01169 for ; Tue, 1 Apr 2003 16:04:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoioe26723 for ; Tue, 1 Apr 2003 16:03:42 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioe10957 for ; Tue, 1 Apr 2003 16:03:40 GMT Received: from prue.eim.surrey.ac.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQoioe10916 for ; Tue, 1 Apr 2003 16:03:38 GMT Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 190OED-0005W7-00; Tue, 01 Apr 2003 17:03:13 +0100 Date: Tue, 1 Apr 2003 17:03:11 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Shahram Davari cc: pwe3@ietf.org, "" Subject: RE: [PWE3] MPLS PID In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: References: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-sierra.bc.ca> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-130.8 required=5.5 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SUBJ_ALL_CAPS,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *190OED-0005W7-00*g9YP0XDFns.* (SECM, UniS) Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 31 Mar 2003, Shahram Davari wrote: > for all ECMP > implementations such as the one that I described > in earlier emails in which both the first nibble > and the CRC are used to detect IP. IPv6 doesn't _have_ a header checksum. IPv4's header checksum is a pain to work with. Are you describing an existing implementation? It sounds broken. If you know from context you're carrying IP, then the intended identification in the first nibble is enough to identify 4 or 6 or something else, and you don't need to sniff the packet contents. L. From owner-mpls@UU.NET Tue Apr 1 12:23:57 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01514 for ; Tue, 1 Apr 2003 12:23:57 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiof28585 for ; Tue, 1 Apr 2003 16:29:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiof28270; Tue, 1 Apr 2003 16:28:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiob10372 for mpls-outgoing; Tue, 1 Apr 2003 15:17:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoiob10367 for ; Tue, 1 Apr 2003 15:16:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoiob04451 for ; Tue, 1 Apr 2003 15:15:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiob26395 for ; Tue, 1 Apr 2003 15:15:10 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoiob26385 for ; Tue, 1 Apr 2003 15:15:09 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31FF6iH027232 for ; Tue, 1 Apr 2003 10:15:06 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15387 for ; Tue, 1 Apr 2003 10:15:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31FF6E15063 for mpls@uu.net; Tue, 1 Apr 2003 10:15:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoioa09864 for ; Tue, 1 Apr 2003 15:14:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoioa23416 for ; Tue, 1 Apr 2003 15:11:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioa21114 for ; Tue, 1 Apr 2003 15:11:58 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoioa21101 for ; Tue, 1 Apr 2003 15:11:58 GMT Received: from zaliw2k01 (che-vpn-cluster-1-79.cisco.com [10.86.240.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31FBgiH026673; Tue, 1 Apr 2003 10:11:42 -0500 (EST) From: "zafar ali" To: , Subject: RE: Check MPLS WG Consensus (on nodeid-subobject) Date: Tue, 1 Apr 2003 10:11:41 -0500 Message-ID: <000001c2f861$03f291a0$91053918@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <3E8968C6.8994326B@alcatel.be> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Dimitri.Papadimitriou@alcatel.be > Sent: Tuesday, April 01, 2003 5:24 AM > To: mpls@UU.NET > Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) > > > several points here, first i'd like to know how this > relates to the current polling of inter-area req's to > worked out in the scope of the tewg ? then i thought > that inter-area/inter-as solution development were > within the scope of the ccamp wg (just to be sure that > we also keep some consistence on the work is organised > within the sub-ip area) > Hi Dimitri, I would just like to point out that the ID is applicable to an single area TE case as well. This is for the cases where, either a box may like to avoid peeking into IGP database to find the Merge Point address from the interface addresses, or IGP is not used (a non-practical case). In addition, as the contents/ extension in the drafts are so minor, the WG discussions at the IETF meeting went along the line of moving forward with this as a more generic solution (which is not a 100% tied up with the Inter-AS/ Inter-area discussions). Thanks Regards... Zafar > now independently of the work organisation, this i-d > is valuable when backup tunnels are used and i think > the following i-d "complements" the proposed solution > using detour lsp's for this real problem being "abr > node protection and as border node protection": > http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-protect ion-00.txt thanks, - dimitri. > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > I agree for support of this draft > > JL > > >In San Francisco the workgroup showed support for making > > Definition of an RRO node-id subobject > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > >an MPLS WG Document. This message is to solicit any further comments > > >prior to making a final determination. > > > >Please reply by 4/7 24:00 GMT. > > > >...George > > > >===================================================================== > >= > > >George Swallow Cisco Systems (978) > 936-1398 > > 250 Apollo Drive > > Chelmsford, Ma 01824 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Tue Apr 1 12:30:23 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02014 for ; Tue, 1 Apr 2003 12:30:23 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiok29357 for ; Tue, 1 Apr 2003 17:32:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiok29211; Tue, 1 Apr 2003 17:32:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQoioh07104 for mpls-outgoing; Tue, 1 Apr 2003 16:49:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoioh07060 for ; Tue, 1 Apr 2003 16:48:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoioh19108 for ; Tue, 1 Apr 2003 16:47:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioh27079 for ; Tue, 1 Apr 2003 16:47:10 GMT Received: from mail2.hyperchip.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.hyperchip.com [216.94.112.4]) id QQoioh27007 for ; Tue, 1 Apr 2003 16:47:08 GMT Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 190OuX-0004jw-00; Tue, 01 Apr 2003 11:46:57 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 11:45:53 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E871042EAD17@hermes.hyperchip.com> From: Philip Matthews To: Jean Philippe Vasseur Cc: mpls@UU.NET Subject: Some comments on draft-vasseur-mpls-nodeid-subobject-00.txt Date: Tue, 1 Apr 2003 11:45:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F86E.28BB74E0" 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_01C2F86E.28BB74E0 Content-Type: text/plain; charset="iso-8859-1" Jean Philippe: Here are some comments on your document: draft-vasseur-mpls-nodeid-subobject-00.txt. 1) It wasn't clear to me whether this draft is proposing that a router push both its interface address and its nodeid, or just push its nodeid. I personally feel that both addresses should be included, as the interface address information can be useful for debugging. In particular, interface information is useful when there are parallel links between two routers and the links are not bundled for some reason. (The operator might do this, for example, because he/she wants to be able to explicitly specify which link to take when routing LSPs between the two routers. Or, because the links are in two different SRLGs and the operator wants to expose that fact. Or, because the links run between routers from different vendors, and POS bundling has not yet been standardized). 2) On the assumption that both addresses should be included, then I am not sure that a bit in the Flags field should be used to distinguish the two types of objects. My concern is that an implementation that does NOT understand your new flag might get confused when parsing the RRO. The implementation probably would not break, but if it tries to count the number of routers in the path, or give the operator a more "parsed" view of the path, then it would get the wrong impression. My suggestion is to use a new value in the Type field instead. That way, routers that did not understand this subobject would just skip over it. Hope these comments are clear (and useful) ... - Philip ------_=_NextPart_001_01C2F86E.28BB74E0 Content-Type: text/html; charset="iso-8859-1" Some comments on draft-vasseur-mpls-nodeid-subobject-00.txt

Jean Philippe:

Here are some comments on your document: draft-vasseur-mpls-nodeid-subobject-00.txt.

1) It wasn't clear to me whether this draft is proposing that a router push
   both its interface address and its nodeid, or just push its nodeid.

   I personally feel that both addresses should be included,
   as the interface address information can be useful for debugging.
   In particular, interface information is useful when there are parallel
   links between two routers and the links are not bundled for some reason.
   (The operator might do this, for example, because he/she wants to be able
   to explicitly specify which link to take when routing LSPs between the
   two routers. Or, because the links are in two different SRLGs and the operator
   wants to expose that fact. Or, because the links run between routers from
   different vendors, and POS bundling has not yet been standardized).

2) On the assumption that both addresses should be included, then I am not sure
   that a bit in the Flags field should be used to distinguish the two types
   of objects. My concern is that an implementation that does NOT understand
   your new flag might get confused when parsing the RRO. The implementation
   probably would not break, but if it tries to count the number of routers in
   the path, or give the operator a more "parsed" view of the path, then it
   would get the wrong impression.

   My suggestion is to use a new value in the Type field instead. That way,
   routers that did not understand this subobject would just skip over it.

Hope these comments are clear (and useful) ...

- Philip
  

------_=_NextPart_001_01C2F86E.28BB74E0-- From owner-mpls@UU.NET Tue Apr 1 13:00:23 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04825 for ; Tue, 1 Apr 2003 13:00:23 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiom26108 for ; Tue, 1 Apr 2003 18:02:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiom25062; Tue, 1 Apr 2003 18:02:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiok29685 for mpls-outgoing; Tue, 1 Apr 2003 17:32:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoiok29676 for ; Tue, 1 Apr 2003 17:32:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoiok13177 for ; Tue, 1 Apr 2003 17:32:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiok13169 for ; Tue, 1 Apr 2003 17:32:10 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoiok13156 for ; Tue, 1 Apr 2003 17:32:09 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31HW7MR010991 for ; Tue, 1 Apr 2003 12:32:07 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA26727 for ; Tue, 1 Apr 2003 12:32:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31HW6M08434 for mpls@uu.net; Tue, 1 Apr 2003 12:32:06 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoiok29446 for ; Tue, 1 Apr 2003 17:30:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoioj27452 for ; Tue, 1 Apr 2003 17:28:54 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoioj23715 for ; Tue, 1 Apr 2003 17:28:53 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoioj23705 for ; Tue, 1 Apr 2003 17:28:53 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31HSdiH027865; Tue, 1 Apr 2003 12:28:42 -0500 (EST) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA26432; Tue, 1 Apr 2003 12:28:39 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA15752; Tue, 1 Apr 2003 12:28:39 -0500 (EST) Message-Id: <200304011728.MAA15752@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "David Allan" cc: "'mpls@UU.NET'" , swallow@cisco.com Subject: Re: MPLS WG Consensus on OAM Requirements In-reply-to: Your message of "Tue, 01 Apr 2003 10:23:17 EST." Date: Tue, 01 Apr 2003 12:28:39 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > While I think an IETF requirements statement for OAM is useful, I'd like to > understand better the relationship of pursuing this to both the current > charter (where my experience is that OAM is out of scope, witness the BOF at > IETF 51), and the decision last summer to effectively delegate OAM beyond > ping and traceroute to the ITU-T SG13 via publishing RFC 3429. Since we are both working on part of the problem and delegating another part of the problem, it behooves us to have a clearly articulated requirements document. Since we've already ruled LSP ping in scope, certainly requirements in this area must also be within scope. I also believe to do an effect of job of developing and/or delegating OAM work (whether to the ITU, PPVPN, or PWE3) we should create a framework document to cover the space in general. I will be proposing that we add such to our charter. Whether that would lead to any further protocol work in MPLS or elsewhere remains to be seen. ...George ================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 1 14:15:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08583 for ; Tue, 1 Apr 2003 14:15:34 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoior08779 for ; Tue, 1 Apr 2003 19:18:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoior08459; Tue, 1 Apr 2003 19:17:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiop24836 for mpls-outgoing; Tue, 1 Apr 2003 18:52:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoiop24820 for ; Tue, 1 Apr 2003 18:52:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoiop25418 for ; Tue, 1 Apr 2003 18:51:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiop13800 for ; Tue, 1 Apr 2003 18:51:10 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoiop13785 for ; Tue, 1 Apr 2003 18:51:09 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31Ip6MR020389 for ; Tue, 1 Apr 2003 13:51:07 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA03754 for ; Tue, 1 Apr 2003 13:51:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31Ip6Y15730 for mpls@uu.net; Tue, 1 Apr 2003 13:51:06 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoiop24637 for ; Tue, 1 Apr 2003 18:50:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoiop20057 for ; Tue, 1 Apr 2003 18:49:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiop18047 for ; Tue, 1 Apr 2003 18:49:52 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoiop18039 for ; Tue, 1 Apr 2003 18:49:51 GMT Received: from zaliw2k01 (che-vpn-cluster-1-79.cisco.com [10.86.240.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31InaiH015988; Tue, 1 Apr 2003 13:49:37 -0500 (EST) From: "zafar ali" To: Cc: Subject: RE: Check MPLS WG Consensus (on nodeid-subobject) Date: Tue, 1 Apr 2003 13:49:36 -0500 Message-ID: <001101c2f87f$74aa0630$91053918@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3E89CD9E.36A7640C@alcatel.be> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dimitri, Please see comments in-lined. Thanks Regards... Zafar > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, April 01, 2003 12:34 PM > To: zafar ali > Cc: mpls@UU.NET > Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) > > > hi, > > zafar ali wrote: > > > several points here, first i'd like to know how this > relates to the > > > current polling of inter-area req's to worked out in the scope of > > > the tewg ? then i thought that inter-area/inter-as solution > > > development were within the scope of the ccamp wg (just > to be sure > > > that we also keep some consistence on the work is organised > > > within the sub-ip area) > > > > > > Hi Dimitri, > > > > I would just like to point out that the ID is applicable to > an single > > area TE case as well. This is for the cases where, either a box may > > like to avoid peeking into IGP database to find the Merge Point > > address from the interface addresses, or IGP is not used (a > > non-practical case). > > well what does it mean that you will remove all the content > related to inter-area/inter-as and keep only the two cases > mentioned here above ? ... page 4/5 of this i-d explicitly > mentioned why this solution would make sense in inter-area > cases and for inter-as, i'd like to know how far we can go > in "advertizing" the ospf router-id between as's using rsvp? This will strictly be based on a policy enforced between the ASs. > - it also explains why we don't need it in single area case > i am not sure "avoid a lookup" would justify this - > > > In addition, as the contents/ extension in the drafts are so minor, > > the WG discussions at the IETF meeting went along the line > of moving > > forward with this as a more generic solution (which is not > a 100% tied > > up with the Inter-AS/ Inter-area discussions). > > i am not sure we're on the same line here, do we propose > a solution to a problem, or do we define a "minor object" > and then try to see its applications ? Clearly draft proposes a solution to a practical problem (and I think we agree on that). I am not sure how one can conclude the later part of your statement, from my comments. > ... in fact you > have to spell it out in another way this draft raises a > major issue (in section 5. you may not be an MP so might > be wise to list the implications) > Sorry, can you please elaborate more on the implications that you are referring to? > (*) it is like a newobject in fact not only a flag since > we've to define the processing from the "worst case" view > point when none information was previously available (this > is what you referred as "filtration cases") > > thanks, > - dimitri. > > Thanks > > > > Regards... Zafar > > > > > now independently of the work organisation, this i-d > > > is valuable when backup tunnels are used and i think > > > the following i-d "complements" the proposed solution > > > using detour lsp's for this real problem being "abr > > > node protection and as border node protection": > > > > > > http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-prote > > ct > > ion-00.txt > > > > thanks, > > - dimitri. > > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > > > I agree for support of this draft > > > > > > JL > > > > > > >In San Francisco the workgroup showed support for making > > > > Definition of an RRO node-id subobject > > > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > > > > > >an MPLS WG Document. This message is to solicit any further > > > >comments > > > > > > >prior to making a final determination. > > > > > > > >Please reply by 4/7 24:00 GMT. > > > > > > > >...George > > > > > > > > >=================================================================== > > > >== > > > >= > > > > > > >George Swallow Cisco Systems (978) > > > 936-1398 > > > > 250 Apollo Drive > > > > Chelmsford, Ma 01824 > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 > From owner-mpls@UU.NET Tue Apr 1 14:48:52 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10499 for ; Tue, 1 Apr 2003 14:48:52 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiot02429 for ; Tue, 1 Apr 2003 19:51:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiot02189; Tue, 1 Apr 2003 19:51:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQoior16070 for mpls-outgoing; Tue, 1 Apr 2003 19:23:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoior16056 for ; Tue, 1 Apr 2003 19:23:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoior23057 for ; Tue, 1 Apr 2003 19:23:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoior18171 for ; Tue, 1 Apr 2003 19:23:07 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoior18154 for ; Tue, 1 Apr 2003 19:23:07 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31JN4MR024473 for ; Tue, 1 Apr 2003 14:23:05 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA06687 for ; Tue, 1 Apr 2003 14:23:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31JN4q19249 for mpls@uu.net; Tue, 1 Apr 2003 14:23:04 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoior15868 for ; Tue, 1 Apr 2003 19:21:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoior08667 for ; Tue, 1 Apr 2003 19:21:46 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoior15736 for ; Tue, 1 Apr 2003 19:21:46 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoior15725 for ; Tue, 1 Apr 2003 19:21:46 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31JI6MT023774; Tue, 1 Apr 2003 14:18:09 -0500 (EST) Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-173.cisco.com [161.44.134.173]) by bucket.cisco.com (Mirapoint) with ESMTP id ACW08218; Tue, 1 Apr 2003 14:18:06 -0500 (EST) Message-Id: <5.2.0.9.2.20030401141649.04cc4758@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Apr 2003 14:17:59 -0500 To: Shahram Davari , "'Lloyd Wood'" From: "Thomas D. Nadeau" Subject: RE: [PWE3] MPLS PID Cc: pwe3@ietf.org, mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C86D@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > >>The best way to solve this problem is to do ECMP only based on label > >>stack. Doing so should be > >>easier than introducing new standard. > > > > Sharam, it sounds like you are introducing a new standard > >by insisting that ECMP only be based on the label stack. > > > > --Tom > > > >Tom, no I am not standardizing anything. I said, if you are not sure >the payload is IP, you could always use the label stack for ECMP? >After all isn't this what you do in case the payload is not IP? > >In other words there is a way around the problem that you are trying to solve. >Whether you use it or not is up to you. No, the point is that there are lots of ways around the ECMP problem, as is evident from the fact that most vendors do ECMP differently from everyone else. What seems clear to me is that through the use of a PID in the PWE header we can clearly identify what is in the packet regardless of these mechanisms. --Tom >-Shahram http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X From owner-mpls@UU.NET Tue Apr 1 14:59:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11053 for ; Tue, 1 Apr 2003 14:59:21 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiou26152 for ; Tue, 1 Apr 2003 20:01:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiou25965; Tue, 1 Apr 2003 20:01:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQoios16835 for mpls-outgoing; Tue, 1 Apr 2003 19:33:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoios16825 for ; Tue, 1 Apr 2003 19:33:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoios24245 for ; Tue, 1 Apr 2003 19:33:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoios28050 for ; Tue, 1 Apr 2003 19:33:11 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoios28029 for ; Tue, 1 Apr 2003 19:33:10 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31JX7iH026916 for ; Tue, 1 Apr 2003 14:33:07 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA07689 for ; Tue, 1 Apr 2003 14:33:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31JX6e20391 for mpls@uu.net; Tue, 1 Apr 2003 14:33:06 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoios16764 for ; Tue, 1 Apr 2003 19:32:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoior01087 for ; Tue, 1 Apr 2003 19:27:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoior19193 for ; Tue, 1 Apr 2003 19:27:31 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [216.241.224.12]) id QQoior19183 for ; Tue, 1 Apr 2003 19:27:30 GMT Received: (qmail 27479 invoked by uid 104); 1 Apr 2003 19:27:25 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 (uvscan: v4.1.40/v4254. Clear:. Processed in 1.306449 secs); 01 Apr 2003 19:27:25 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.com with SMTP; 1 Apr 2003 19:27:23 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h31JRN923209; Tue, 1 Apr 2003 11:27:23 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 1 Apr 2003 11:27:22 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C878@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" , "'Lloyd Wood'" Cc: pwe3@ietf.org, mpls@UU.NET Subject: RE: [PWE3] MPLS PID Date: Tue, 1 Apr 2003 11:27:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > No, the point is that there are lots of ways around the ECMP >problem, as is evident from the fact that most vendors do ECMP >differently from everyone else. What seems clear to me is that >through the use of a PID in the PWE header we can clearly >identify what is in the packet regardless of these mechanisms. Are you saying you are OK with a generic PID to be added to the PW even though the value 2 & 4 may be used for other purposes than IPv4/6? If so then I retract my comment, but if not so, then I wonder what "regardless of mechanism" means? -Shahram > > --Tom > > From owner-mpls@UU.NET Tue Apr 1 16:48:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16912 for ; Tue, 1 Apr 2003 16:48:11 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiom07509 for ; Tue, 1 Apr 2003 18:07:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiom07314; Tue, 1 Apr 2003 18:07:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiok00057 for mpls-outgoing; Tue, 1 Apr 2003 17:38:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoiok00049 for ; Tue, 1 Apr 2003 17:38:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoiok20235 for ; Tue, 1 Apr 2003 17:37:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiok04911 for ; Tue, 1 Apr 2003 17:37:16 GMT Received: from bt0g2p.god.bel.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc136.alcatel.be [195.207.101.136]) id QQoiok04580 for ; Tue, 1 Apr 2003 17:37:08 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h31Hb7815445 for ; Tue, 1 Apr 2003 19:37:07 +0200 Received: from alcatel.be ([138.203.67.27]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003040119370484:5782 ; Tue, 1 Apr 2003 19:37:04 +0200 Message-ID: <3E89CD9E.36A7640C@alcatel.be> Date: Tue, 01 Apr 2003 19:34:22 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: network technology and architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: zafar ali CC: mpls@UU.NET Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) References: <000001c2f861$03f291a0$91053918@amer.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 19:37:04, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 19:37:06, Serialize complete at 04/01/2003 19:37:06 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi, zafar ali wrote: > > several points here, first i'd like to know how this > > relates to the current polling of inter-area req's to > > worked out in the scope of the tewg ? then i thought > > that inter-area/inter-as solution development were > > within the scope of the ccamp wg (just to be sure that > > we also keep some consistence on the work is organised > > within the sub-ip area) > > > Hi Dimitri, > > I would just like to point out that the ID is applicable to an single > area TE case as well. This is for the cases where, either a box may like > to avoid peeking into IGP database to find the Merge Point address from > the interface addresses, or IGP is not used (a non-practical case). well what does it mean that you will remove all the content related to inter-area/inter-as and keep only the two cases mentioned here above ? ... page 4/5 of this i-d explicitly mentioned why this solution would make sense in inter-area cases and for inter-as, i'd like to know how far we can go in "advertizing" the ospf router-id between as's using rsvp? - it also explains why we don't need it in single area case i am not sure "avoid a lookup" would justify this - > In addition, as the contents/ extension in the drafts are so minor, the > WG discussions at the IETF meeting went along the line of moving forward > with this as a more generic solution (which is not a 100% tied up with > the Inter-AS/ Inter-area discussions). i am not sure we're on the same line here, do we propose a solution to a problem, or do we define a "minor object" and then try to see its applications ? ... in fact you have to spell it out in another way this draft raises a major issue (in section 5. you may not be an MP so might be wise to list the implications) (*) it is like a newobject in fact not only a flag since we've to define the processing from the "worst case" view point when none information was previously available (this is what you referred as "filtration cases") thanks, - dimitri. > Thanks > > Regards... Zafar > > > now independently of the work organisation, this i-d > > is valuable when backup tunnels are used and i think > > the following i-d "complements" the proposed solution > > using detour lsp's for this real problem being "abr > > node protection and as border node protection": > > > http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-protect > ion-00.txt > > thanks, > - dimitri. > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > I agree for support of this draft > > > > JL > > > > >In San Francisco the workgroup showed support for making > > > Definition of an RRO node-id subobject > > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > > > >an MPLS WG Document. This message is to solicit any further comments > > > > >prior to making a final determination. > > > > > >Please reply by 4/7 24:00 GMT. > > > > > >...George > > > > > >===================================================================== > > >= > > > > >George Swallow Cisco Systems (978) > > 936-1398 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Tue Apr 1 16:57:43 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17181 for ; Tue, 1 Apr 2003 16:57:43 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipc13233 for ; Tue, 1 Apr 2003 22:00:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoipc13040; Tue, 1 Apr 2003 22:00:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQoipa03473 for mpls-outgoing; Tue, 1 Apr 2003 21:34:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoipa03468 for ; Tue, 1 Apr 2003 21:34:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoipa04896 for ; Tue, 1 Apr 2003 21:32:54 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipa16947 for ; Tue, 1 Apr 2003 21:32:53 GMT Received: from ix.eng.level3.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine78.Level3.com [209.244.5.93]) id QQoipa16753 for ; Tue, 1 Apr 2003 21:32:47 GMT Received: from level3.net (localhost.eng.level3.com [127.0.0.1]) by ix.eng.level3.com (8.11.0/8.11.0) with ESMTP id h31LVk429936; Tue, 1 Apr 2003 14:31:46 -0700 Message-ID: <3E8A0542.40603@level3.net> Date: Tue, 01 Apr 2003 14:31:46 -0700 From: Luca Martini Organization: Level3 Communications LLC. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- MIME-Version: 1.0 To: Shahram Davari CC: "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET Subject: Re: [PWE3] MPLS PID References: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network is fundamentally wrong, and is impossible to do for all ECMP implementations such as the one that I described > in earlier emails in which both the first nibble and the CRC are used to detect IP. > Shahram, It might be fundamentally wrong but this is deployed today , and we run our hole network based on this little point. It seems to work fine for a network that transport 90gb/s to 100Gb/s of actual traffic. So if we put the theory, and layer arguments aside , what is the issue with determining that a particular flow is not IP ( assuming IP = 99% of traffic ) ? Luca It might be fundamentally wrong > The best way to solve this problem is to do ECMP only based on label stack. Doing so should be > easier than introducing new standard. > > -Shahram > > > >>-----Original Message----- >>From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] >>Sent: Sunday, March 30, 2003 6:11 PM >>To: Eric Rosen >>Cc: jeremy.de_clercq@alcatel.be; David Allan; 'Scott W Brim'; >>pwe3@ietf.org; mpls@UU.NET >>Subject: Re: [PWE3] MPLS PID >> >> >>On Thu, 27 Mar 2003, Eric Rosen wrote: >> >> >>>1. The only reason for a PID field in MPLS and/or >> >>PWE3 is to allow >> >>> intermediate routers to determine whether a particular >> >>MPLS payload is an >> >>> IP packet or not. >> >>which is a layer violation, and shouldn't be done. >> >> >>> There are a number of reasons why this is useful, and >> >>no one has argued >> >>> that this is not useful. >> >>not appropriate, more like. >> >>if you're going to sniff for an IP packet (so you can sniff TCP/UDP or >>higher) you might want to ask why you even have any form of mpls >>label stack in there in the first place. >> >>if you're not separating out your ip flows via explicit mpls label, >>why not? >> >>L. >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From owner-mpls@UU.NET Tue Apr 1 18:17:04 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21116 for ; Tue, 1 Apr 2003 18:17:04 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiph12788 for ; Tue, 1 Apr 2003 23:19:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiph12664; Tue, 1 Apr 2003 23:19:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQoipf27823 for mpls-outgoing; Tue, 1 Apr 2003 22:54:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoipf27818 for ; Tue, 1 Apr 2003 22:53:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoipf27458 for ; Tue, 1 Apr 2003 22:53:21 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipf27818 for ; Tue, 1 Apr 2003 22:53:21 GMT Received: from bt0g2p.god.bel.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc136.alcatel.be [195.207.101.136]) id QQoipf27812 for ; Tue, 1 Apr 2003 22:53:20 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h31MrJ901306 for ; Wed, 2 Apr 2003 00:53:19 +0200 Received: from alcatel.be ([138.203.67.27]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003040200531786:281 ; Wed, 2 Apr 2003 00:53:17 +0200 Message-ID: <3E8A17B4.A708727E@alcatel.be> Date: Wed, 02 Apr 2003 00:50:28 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: network technology and architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Checking MPLS WG Consensus (ldp-dod) References: <200303311908.OAA05316@bifocal.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2003 00:53:17, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2003 00:53:19, Serialize complete at 04/02/2003 00:53:19 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit in favor. George Swallow wrote: > > In San Francisco the workgroup showed support for making > > LDP DoD Graceful Restart > draft-thomas-mpls-ldp-dod-restart-00.txt > > an MPLS WG Document. This message is to solicit any further comments > prior to making a final determination. > > Please reply by 4/7 24:00 GMT. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Tue Apr 1 18:45:04 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21997 for ; Tue, 1 Apr 2003 18:45:04 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipj02090 for ; Tue, 1 Apr 2003 23:47:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoipj01900; Tue, 1 Apr 2003 23:47:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiph18489 for mpls-outgoing; Tue, 1 Apr 2003 23:22:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoiph18426 for ; Tue, 1 Apr 2003 23:21:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoiph28118 for ; Tue, 1 Apr 2003 23:20:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiph13558 for ; Tue, 1 Apr 2003 23:20:12 GMT Received: from bt0g2p.god.bel.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc136.alcatel.be [195.207.101.136]) id QQoiph13523 for ; Tue, 1 Apr 2003 23:20:11 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h31NJvE06458; Wed, 2 Apr 2003 01:19:57 +0200 Received: from alcatel.be ([138.203.67.27]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003040201195628:339 ; Wed, 2 Apr 2003 01:19:56 +0200 Message-ID: <3E8A1DF1.F40AF5DC@alcatel.be> Date: Wed, 02 Apr 2003 01:17:05 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: network technology and architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: zafar ali CC: mpls@UU.NET Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) References: <001101c2f87f$74aa0630$91053918@amer.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2003 01:19:56, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2003 01:19:56, Serialize complete at 04/02/2003 01:19:56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi see in-line zafar ali wrote: > > Hi Dimitri, > > Please see comments in-lined. > > Thanks > > Regards... Zafar > > > -----Original Message----- > > From: Dimitri.Papadimitriou@alcatel.be > > [mailto:Dimitri.Papadimitriou@alcatel.be] > > Sent: Tuesday, April 01, 2003 12:34 PM > > To: zafar ali > > Cc: mpls@UU.NET > > Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) > > > > > > hi, > > > > zafar ali wrote: > > > > several points here, first i'd like to know how this > > relates to the > > > > current polling of inter-area req's to worked out in the scope of > > > > the tewg ? then i thought that inter-area/inter-as solution > > > > development were within the scope of the ccamp wg (just > > to be sure > > > > that we also keep some consistence on the work is organised > > > > within the sub-ip area) > > > > > > > > > Hi Dimitri, > > > > > > I would just like to point out that the ID is applicable to > > an single > > > area TE case as well. This is for the cases where, either a box may > > > like to avoid peeking into IGP database to find the Merge Point > > > address from the interface addresses, or IGP is not used (a > > > non-practical case). > > > > well what does it mean that you will remove all the content > > related to inter-area/inter-as and keep only the two cases > > mentioned here above ? ... page 4/5 of this i-d explicitly > > mentioned why this solution would make sense in inter-area > > cases and for inter-as, i'd like to know how far we can go > > in "advertizing" the ospf router-id between as's using rsvp? > > This will strictly be based on a policy enforced between the ASs. > > > - it also explains why we don't need it in single area case > > i am not sure "avoid a lookup" would justify this - > > > > > In addition, as the contents/ extension in the drafts are so minor, > > > the WG discussions at the IETF meeting went along the line > > of moving > > > forward with this as a more generic solution (which is not > > a 100% tied > > > up with the Inter-AS/ Inter-area discussions). > > > > i am not sure we're on the same line here, do we propose > > a solution to a problem, or do we define a "minor object" > > and then try to see its applications ? > > Clearly draft proposes a solution to a practical problem (and I think we > agree on that). I am not sure how one can conclude the later part of > your statement, from my comments. that's a detail but when you mention "i can also apply it another contexts" it looks like seeking for app's, turning this in the other way around makes more sense and from this perspective we discuss the solution to this practical problem > > ... in fact you > > have to spell it out in another way this draft raises a > > major issue (in section 5. you may not be an MP so might > > be wise to list the implications) > > > Sorry, can you please elaborate more on the implications that you are > referring to? i've listed here what i have to support to become an MP (using the present proposal): 1) "In addition, any LSR compliant with this draft must systematically include a node-id IPv4 or IPv6 subobject in the RRO object for each protected TE LSP (in addition to the sub-objects required by MPLS TE Fast Reroute as defined in [FAST-REROUTE]). => the MUST here ? i think it still works even if you don't set it even when you support it as long as one of the lsr's (not within the same area/as) sets this value ? thus why do you *mandate* this kind of "discovery process" ... on the other hand taking the policy enforcment mentioned here above it means that even if you'll filter it out you have to include the flag ? further "To remain compatible with the nodes that do not support the RRO IPv4 or IPv6 node-id subobjects, a node can safely ignore these objects. The implication of this limitation will be that these nodes could not be MP in a network with inter-area or inter-AS traffic engineering." => i can safely ignore the object, even if you say could i don't have such limitation in the following case what happens if i push an unnumbered i/f (Type 4) that includes the the Router ID which is recommended to be set to the Router Address (see RFC 3477) is there right ? now how do i combine now the to be "standardized" method you propose here? do i have to push it twice - and this to become compliant ? - i would suggest to refine the scope (**) Router Address being a stable IP address of the advertising router that is always reachable if there is any connectivity to it. > > (*) it is like a newobject in fact not only a flag since > > we've to define the processing from the "worst case" view > > point when none information was previously available (this > > is what you referred as "filtration cases") yes, i think that we have defined here a new subobject being the "half" of the Type 4 subobject available today (keeping only the node_id part); and further work might consider this way of doing - being also my init conclusion on this discussion thanks, - dimitri. > > thanks, > > - dimitri. > > > Thanks > > > > > > Regards... Zafar > > > > > > > now independently of the work organisation, this i-d > > > > is valuable when backup tunnels are used and i think > > > > the following i-d "complements" the proposed solution > > > > using detour lsp's for this real problem being "abr > > > > node protection and as border node protection": > > > > > > > > > http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-prote > > > ct > > > ion-00.txt > > > > > > thanks, > > > - dimitri. > > > > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > > > > > I agree for support of this draft > > > > > > > > JL > > > > > > > > >In San Francisco the workgroup showed support for making > > > > > Definition of an RRO node-id subobject > > > > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > > > > > > > >an MPLS WG Document. This message is to solicit any further > > > > >comments > > > > > > > > >prior to making a final determination. > > > > > > > > > >Please reply by 4/7 24:00 GMT. > > > > > > > > > >...George > > > > > > > > > > > >=================================================================== > > > > >== > > > > >= > > > > > > > > >George Swallow Cisco Systems (978) > > > > 936-1398 > > > > > 250 Apollo Drive > > > > > Chelmsford, Ma 01824 > > > > > > -- > > > Papadimitriou Dimitri > > > E-mail : dimitri.papadimitriou@alcatel.be > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > E-mail : dpapadimitriou@psg.com > > > Public : http://psg.com/~dpapadimitriou/ > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > Phone : +32 3 240-8491 > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Tue Apr 1 19:57:08 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23711 for ; Tue, 1 Apr 2003 19:57:07 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipn10611 for ; Wed, 2 Apr 2003 00:59:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoipn10441; Wed, 2 Apr 2003 00:59:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQoipm12002 for mpls-outgoing; Wed, 2 Apr 2003 00:34:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoipm11977 for ; Wed, 2 Apr 2003 00:33:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoipm29383 for ; Wed, 2 Apr 2003 00:33:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipm08291 for ; Wed, 2 Apr 2003 00:33:06 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoipm08287 for ; Wed, 2 Apr 2003 00:33:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h320X2MR022360 for ; Tue, 1 Apr 2003 19:33:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA01328 for ; Tue, 1 Apr 2003 19:33:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h320X2l11114 for mpls@uu.net; Tue, 1 Apr 2003 19:33:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoipm11938 for ; Wed, 2 Apr 2003 00:32:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoipl03068 for ; Wed, 2 Apr 2003 00:26:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipl02114 for ; Wed, 2 Apr 2003 00:26:13 GMT Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQoipl02081 for ; Wed, 2 Apr 2003 00:26:12 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h320ODQX009327; Wed, 2 Apr 2003 02:24:13 +0200 (MET DST) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn4-232.cisco.com [10.21.80.232]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id CAA05772; Wed, 2 Apr 2003 02:25:55 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030401191430.066adfc0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Apr 2003 19:25:54 -0500 To: Dimitri.Papadimitriou@alcatel.be From: Jean Philippe Vasseur Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) Cc: zafar ali , mpls@UU.NET In-Reply-To: <3E89CD9E.36A7640C@alcatel.be> References: <000001c2f861$03f291a0$91053918@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Dimitri, At 19:34 01/04/2003 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >hi, > >zafar ali wrote: > > > several points here, first i'd like to know how this > > > relates to the current polling of inter-area req's to > > > worked out in the scope of the tewg ? then i thought > > > that inter-area/inter-as solution development were > > > within the scope of the ccamp wg (just to be sure that > > > we also keep some consistence on the work is organised > > > within the sub-ip area) > > > > > > Hi Dimitri, > > > > I would just like to point out that the ID is applicable to an single > > area TE case as well. This is for the cases where, either a box may like > > to avoid peeking into IGP database to find the Merge Point address from > > the interface addresses, or IGP is not used (a non-practical case). > >well what does it mean that you will remove all the content >related to inter-area/inter-as and keep only the two cases >mentioned here above ? ... ... Zafar just wanted to stress the fact that the applicability of the draft was not restricted to multi-area and inter-AS TE, that's it. >page 4/5 of this i-d explicitly >mentioned why this solution would make sense in inter-area >cases and for inter-as, i'd like to know how far we can go >in "advertizing" the ospf router-id between as's using rsvp? not sure to see what you mean by "how far" ... I guess you're referring to some need for hiding the topology of ASx to ASy. If that's the case, in order to use FRR Bypass with NNHOP backup tunnel to protect against an ASBR node failure, this just requires to give the visibility of every ASBR Next hop. >- it also explains why we don't need it in single area case >i am not sure "avoid a lookup" would justify this - > > > In addition, as the contents/ extension in the drafts are so minor, the > > WG discussions at the IETF meeting went along the line of moving forward > > with this as a more generic solution (which is not a 100% tied up with > > the Inter-AS/ Inter-area discussions). > >i am not sure we're on the same line here, do we propose >a solution to a problem, or do we define a "minor object" >and then try to see its applications ? ... Do you think the problem statement was not clear enough ? >in fact you >have to spell it out in another way this draft raises a >major issue (in section 5. you may not be an MP so might >be wise to list the implications) I do not see your point here >(*) it is like a newobject in fact not only a flag since >we've to define the processing from the "worst case" view >point when none information was previously available (this >is what you referred as "filtration cases") idem JP. >thanks, >- dimitri. > > Thanks > > > > Regards... Zafar > > > > > now independently of the work organisation, this i-d > > > is valuable when backup tunnels are used and i think > > > the following i-d "complements" the proposed solution > > > using detour lsp's for this real problem being "abr > > > node protection and as border node protection": > > > > > http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-protect > > ion-00.txt > > > > thanks, > > - dimitri. > > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > > > I agree for support of this draft > > > > > > JL > > > > > > >In San Francisco the workgroup showed support for making > > > > Definition of an RRO node-id subobject > > > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > > > > > >an MPLS WG Document. This message is to solicit any further comments > > > > > > >prior to making a final determination. > > > > > > > >Please reply by 4/7 24:00 GMT. > > > > > > > >...George > > > > > > > >===================================================================== > > > >= > > > > > > >George Swallow Cisco Systems (978) > > > 936-1398 > > > > 250 Apollo Drive > > > > Chelmsford, Ma 01824 > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html >E-mail : dpapadimitriou@psg.com >Public : http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491 From owner-mpls@UU.NET Tue Apr 1 20:45:11 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24641 for ; Tue, 1 Apr 2003 20:45:11 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipr08594 for ; Wed, 2 Apr 2003 01:47:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoipr08255; Wed, 2 Apr 2003 01:47:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoipp04665 for mpls-outgoing; Wed, 2 Apr 2003 01:21:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoipp04572 for ; Wed, 2 Apr 2003 01:20:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoipp05063 for ; Wed, 2 Apr 2003 01:20:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipp07811 for ; Wed, 2 Apr 2003 01:20:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoipp07777 for ; Wed, 2 Apr 2003 01:20:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h321K2iH022857 for ; Tue, 1 Apr 2003 20:20:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA03624 for ; Tue, 1 Apr 2003 20:20:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h321K2A15542 for mpls@uu.net; Tue, 1 Apr 2003 20:20:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoipp04534 for ; Wed, 2 Apr 2003 01:19:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoipp00623 for ; Wed, 2 Apr 2003 01:18:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipp02289 for ; Wed, 2 Apr 2003 01:18:45 GMT Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQoipp02280 for ; Wed, 2 Apr 2003 01:18:44 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h321Gpg7014531; Wed, 2 Apr 2003 03:16:51 +0200 (MET DST) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn4-232.cisco.com [10.21.80.232]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA07735; Wed, 2 Apr 2003 03:18:34 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030401201248.063a7e28@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Apr 2003 20:18:33 -0500 To: stefaan.de_cnodder@alcatel.be From: Jean Philippe Vasseur Subject: Re: Nodeid (was Re: Check MPLS WG Consensus) Cc: mpls@UU.NET In-Reply-To: <3E89B224.4E377DAB@alcatel.be> References: <200303311905.OAA05296@bifocal.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Stefaan, At 17:37 01/04/2003 +0200, stefaan.de_cnodder@alcatel.be wrote: >Hi, > >Why does the PLR have to know whether it is an interface >address or a node-id? If the PLR has to select a backup >tunnel, it scans the IP addresses in the RRO and compares >the IP address in the RRO subobject with the tail-end of the >backup tunnel if that IP address in the RRO cannot be >converted to a node-id. If the IP address does not match, >then the next RRO subobject is taken and then that one will >match in case the MP includes an RRO subobject containing >the node-id. That does not work since the bypass tunnel may terminate on an interface non recorded in the RRO of the protected TE LSP. So what we propose here is just to add the node-id subobject on both TE LSPs, that's as simple as that. If an LSR cannot use the IGP DB, just look at the RRO IPv4 subobjects having the flag set. >So I do not see a reason to have to have a flag >to indicate that it is a node-id or not. >I would also like to see a precise definition of "the backup >tunnel's tail-end". Is it the destination address of the >bypass tunnel, ... Yes. JP. >regards, > >Stefaan > > >George Swallow wrote: > > > > In San Francisco the workgroup showed support for making > > > > Definition of an RRO node-id subobject > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > > an MPLS WG Document. This message is to solicit any further comments > > prior to making a final determination. > > > > Please reply by 4/7 24:00 GMT. > > > > ...George > > > > ====================================================================== > > George Swallow Cisco Systems (978) 936-1398 > > 250 Apollo Drive > > Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Apr 1 20:49:52 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24984 for ; Tue, 1 Apr 2003 20:49:52 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipr15130 for ; Wed, 2 Apr 2003 01:52:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoipr14833; Wed, 2 Apr 2003 01:52:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQoipp04898 for mpls-outgoing; Wed, 2 Apr 2003 01:25:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoipp04889 for ; Wed, 2 Apr 2003 01:25:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoipp11054 for ; Wed, 2 Apr 2003 01:25:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipp14031 for ; Wed, 2 Apr 2003 01:25:10 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoipp14024 for ; Wed, 2 Apr 2003 01:25:09 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h321P6iH023319 for ; Tue, 1 Apr 2003 20:25:07 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA03855 for ; Tue, 1 Apr 2003 20:25:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h321P6B15886 for mpls@uu.net; Tue, 1 Apr 2003 20:25:06 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoipp04807 for ; Wed, 2 Apr 2003 01:23:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoipp12984 for ; Wed, 2 Apr 2003 01:23:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipp06933 for ; Wed, 2 Apr 2003 01:23:32 GMT Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQoipp06927 for ; Wed, 2 Apr 2003 01:23:31 GMT Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h321LC7I014742; Wed, 2 Apr 2003 03:21:12 +0200 (MET DST) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn4-232.cisco.com [10.21.80.232]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA07897; Wed, 2 Apr 2003 03:22:55 +0200 (MET DST) Message-Id: <4.3.2.7.2.20030401192647.066b0398@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Apr 2003 20:22:54 -0500 To: Philip Matthews From: Jean Philippe Vasseur Subject: Re: Some comments on draft-vasseur-mpls-nodeid-subobject-00.txt Cc: mpls@UU.NET In-Reply-To: <8812A03F65CDD511AE98006008F5E871042EAD17@hermes.hyperchip. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_385862651==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_385862651==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Philip, At 11:45 01/04/2003 -0500, Philip Matthews wrote: >Jean Philippe: > >Here are some comments on your document: >draft-vasseur-mpls-nodeid-subobject-00.txt. > >1) It wasn't clear to me whether this draft is proposing that a router push > both its interface address and its nodeid, or just push its nodeid. > > I personally feel that both addresses should be included, > as the interface address information can be useful for debugging. That's perfectly correct. > In particular, interface information is useful when there are parallel > links between two routers and the links are not bundled for some reason. > (The operator might do this, for example, because he/she wants to be able > to explicitly specify which link to take when routing LSPs between the > two routers. Or, because the links are in two different SRLGs and the > operator > wants to expose that fact. Or, because the links run between routers from > different vendors, and POS bundling has not yet been standardized). > >2) On the assumption that both addresses should be included, then I am not >sure > that a bit in the Flags field should be used to distinguish the two types > of objects. My concern is that an implementation that does NOT understand > your new flag might get confused when parsing the RRO. The implementation > probably would not break, but if it tries to count the number of > routers in > the path, or give the operator a more "parsed" view of the path, then it > would get the wrong impression. Well I don't think so, by the way counting the number of RRO IPv4 subobject does not provide any information of the number of hops ... If the RRO is used for debugging purposes, this flag will help in giving a more accurate info. > My suggestion is to use a new value in the Type field instead. That way, > routers that did not understand this subobject would just skip over it. > >Hope these comments are clear (and useful) ... Sure, I just think that we should keep the flag instead of specifying new type. Thanks for your comment. JP. >- Philip > --=====================_385862651==_.ALT Content-Type: text/html; charset="us-ascii" Hi Philip,

At 11:45 01/04/2003 -0500, Philip Matthews wrote:

Jean Philippe:

Here are some comments on your document: draft-vasseur-mpls-nodeid-subobject-00.txt.

1) It wasn't clear to me whether this draft is proposing that a router push
   both its interface address and its nodeid, or just push its nodeid.

   I personally feel that both addresses should be included,
   as the interface address information can be useful for debugging.

That's perfectly correct.

   In particular, interface information is useful when there are parallel
   links between two routers and the links are not bundled for some reason.
   (The operator might do this, for example, because he/she wants to be able
   to explicitly specify which link to take when routing LSPs between the
   two routers. Or, because the links are in two different SRLGs and the operator
   wants to expose that fact. Or, because the links run between routers from
   different vendors, and POS bundling has not yet been standardized).

2) On the assumption that both addresses should be included, then I am not sure
   that a bit in the Flags field should be used to distinguish the two types
   of objects. My concern is that an implementation that does NOT understand
   your new flag might get confused when parsing the RRO. The implementation
   probably would not break, but if it tries to count the number of routers in
   the path, or give the operator a more "parsed" view of the path, then it
   would get the wrong impression.

Well I don't think so, by the way counting the number of RRO IPv4 subobject does not provide any information of the number of hops ...
If the RRO is used for debugging purposes, this flag will help in giving a more accurate info.

   My suggestion is to use a new value in the Type field instead. That way,
   routers that did not understand this subobject would just skip over it.

Hope these comments are clear (and useful) ...

Sure, I just think that we should keep the flag instead of specifying new type.

Thanks for your comment.

JP.

- Philip
  
--=====================_385862651==_.ALT-- From owner-mpls@UU.NET Tue Apr 1 20:57:05 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25132 for ; Tue, 1 Apr 2003 20:57:05 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimx24939 for ; Tue, 1 Apr 2003 07:58:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoimx24590; Tue, 1 Apr 2003 07:58:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQoimv07848 for mpls-outgoing; Tue, 1 Apr 2003 07:26:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoimv07843 for ; Tue, 1 Apr 2003 07:26:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoimv16930 for ; Tue, 1 Apr 2003 07:25:28 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoimv09252 for ; Tue, 1 Apr 2003 07:25:27 GMT Received: from bt0g2p.god.bel.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.207.101.136]) id QQoimv09234 for ; Tue, 1 Apr 2003 07:25:27 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h317OiS04472 for ; Tue, 1 Apr 2003 09:24:44 +0200 Received: from alcatel.be ([138.203.137.2]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003040109244225:1708 ; Tue, 1 Apr 2003 09:24:42 +0200 Message-ID: <3E893E28.71AD0ED7@alcatel.be> Date: Tue, 01 Apr 2003 09:22:16 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Checking MPLS WG Consensus (oam req's) References: <4.3.2.7.2.20030331200353.06f3a248@paris.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 09:24:42, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/01/2003 09:24:43, Serialize complete at 04/01/2003 09:24:43 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit in favor of moving forward. brief comment, this i-d mentions: in the abstract: "This draft specifies OAM requirements for MPLS, as well as for applications of MPLS such as pseudowire voice and VPN services. Those interested in specific issues relating to instrumenting MPLS for OAM purposes are directed to [FRAMEWORK]" in the introduction: "This draft specifies OAM requirements for MPLS, as well as for applications of MPLS such as pseudowire [PWE3FRAME] voice, and VPN services." in the motivations section: "however, the handling of defects and specification of which types of defects are interesting to operational networks may not have been created in concert with those for other applications of MPLS such as L3 VPN." ... imho if there is a need to move forward with "oam techniques" then they should be defined as "generically" as possible (i agree that this may not always feasible); this due to the potential issue to see oam specifics for pseudo- wires and oam specifics for vpn's - another reason is that the requirement 3.7 as mentioned "These actions may be user or operator-specified, or may simply be inherent to the underlying transport technology (i.e.: MPLS Fast-Reroute, graceful restart or high-availability functionality)." can have a broader scope so i would propose to make the scope of this i-d generic enough (**doesn't mean i wanna have an overkill**) and in the future if there is a specific need in having detailed oam techniques usage for vpn's and/or pseudo then let's go for it (ps: this doesn't preclude that in the meanwhile these applications might be used as example in the current version of the document) thanks, - dimitri. Jean Philippe Vasseur wrote: > > in favor > > JP. > > At 14:09 31/03/2003 -0500, George Swallow wrote: > >In San Francisco the workgroup showed support for making > > > > OAM Requirements for MPLS Networks > > draft-nadeau-ietf-oam-requirements-01.txt > > > >an MPLS WG Document. This message is to solicit any further comments > >prior to making a final determination. > > > >Please reply by 4/7 24:00 GMT. > > > >...George > > > >====================================================================== > >George Swallow Cisco Systems (978) 936-1398 > > 250 Apollo Drive > > Chelmsford, Ma 01824 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Wed Apr 2 01:25:54 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01205 for ; Wed, 2 Apr 2003 01:25:53 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiqb20273 for ; Wed, 2 Apr 2003 04:20:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiqb20058; Wed, 2 Apr 2003 04:20:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQoipz23657 for mpls-outgoing; Wed, 2 Apr 2003 03:55:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoipz23635 for ; Wed, 2 Apr 2003 03:54:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoipz17404 for ; Wed, 2 Apr 2003 03:53:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipz17724 for ; Wed, 2 Apr 2003 03:53:10 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoipz17593 for ; Wed, 2 Apr 2003 03:53:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h323r2iH008521 for ; Tue, 1 Apr 2003 22:53:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA09886 for ; Tue, 1 Apr 2003 22:53:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h323r1m26880 for mpls@uu.net; Tue, 1 Apr 2003 22:53:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoipz23539 for ; Wed, 2 Apr 2003 03:51:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoipz26193; Wed, 2 Apr 2003 03:51:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoipz12803; Wed, 2 Apr 2003 03:51:09 GMT Received: from sun.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: host176.triangle.iit.edu [198.37.26.176]) id QQoipz12754; Wed, 2 Apr 2003 03:51:08 GMT Message-ID: From: "Kaylee Williams" To: moncrief@UU.NET, morgan@UU.NET, morgibso@UU.NET, moron@UU.NET, mosentos@UU.NET, mowen@UU.NET, mpatrone@UU.NET, mpls-request@UU.NET, mpls@UU.NET, mr.j@UU.NET Subject: Feel better, lose we1ght, and signs of aging. Date: Wed, 26 Mar 2003 03:47:15 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_483F44AF_45F5AAAE6E041DB2.A25D296F821CCD46" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_483F44AF_45F5AAAE6E041DB2.A25D296F821CCD46 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit ------=_NextPart_000_483F44AF_45F5AAAE6E041DB2.A25D296F821CCD46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit index *As seen on TV*

The health discovery that reverses signs of aging naturally and that is completely safe and effective is on sale for a limited time! Buy a two-month supply of our product and we will give you one month free!

All natural H_G_H Enhancer will help you with all of the following:

- Reduce body fat and build muscle
- Enrich your sex life
- Help remove cellulite and wrinkles
- Sleep better, improve vision and memory
- Restore hair growth and color
- Strengthen your immune system
- Have more energy
- Turn back time on your body's biological clock up to twenty years with just six months of use!

*** IF YOU ARE NOT COMPLETELY SATISFIED WITH OUR PRODUCT WE WILL REFUND YOU YOUR MONEY, NO QUESTIONS ASKED ***

Click here to view our site or paste http://www.betterhealth.bz/human/index.php?show=main&id=284 into your web browser ------=_NextPart_000_483F44AF_45F5AAAE6E041DB2.A25D296F821CCD46-- From owner-mpls@UU.NET Wed Apr 2 04:57:25 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02288 for ; Wed, 2 Apr 2003 04:57:25 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiqx23135 for ; Wed, 2 Apr 2003 09:59:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiqx22992; Wed, 2 Apr 2003 09:59:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQoiqw10406 for mpls-outgoing; Wed, 2 Apr 2003 09:34:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoiqw10401 for ; Wed, 2 Apr 2003 09:34:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoiqw26977 for ; Wed, 2 Apr 2003 09:33:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiqw04189 for ; Wed, 2 Apr 2003 09:33:16 GMT Received: from relay2.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQoiqw04174 for ; Wed, 2 Apr 2003 09:33:16 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h329X3q24614; Wed, 2 Apr 2003 11:33:03 +0200 (MET DST) Received: from alcatel.be ([138.203.67.27]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003040211330120:2593 ; Wed, 2 Apr 2003 11:33:01 +0200 Message-ID: <3E8AADD4.52FA5F60@alcatel.be> Date: Wed, 02 Apr 2003 11:31:00 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: network technology and architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean Philippe Vasseur Cc: zafar ali , mpls@UU.NET Subject: Re: Check MPLS WG Consensus (on nodeid-subobject) References: <000001c2f861$03f291a0$91053918@amer.cisco.com> <4.3.2.7.2.20030401191430.066adfc0@paris.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2003 11:33:01, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/02/2003 11:33:03, Serialize complete at 04/02/2003 11:33:03 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jean-philippe, zafar, i've stressed the question raised, below in the following e-mail: http://cell.onecall.net/mhonarc/mpls/current/msg00025.html thanks, - dimitri. Jean Philippe Vasseur wrote: > > Hi Dimitri, > > At 19:34 01/04/2003 +0200, Dimitri.Papadimitriou@alcatel.be wrote: > >hi, > > > >zafar ali wrote: > > > > several points here, first i'd like to know how this > > > > relates to the current polling of inter-area req's to > > > > worked out in the scope of the tewg ? then i thought > > > > that inter-area/inter-as solution development were > > > > within the scope of the ccamp wg (just to be sure that > > > > we also keep some consistence on the work is organised > > > > within the sub-ip area) > > > > > > > > > Hi Dimitri, > > > > > > I would just like to point out that the ID is applicable to an single > > > area TE case as well. This is for the cases where, either a box may like > > > to avoid peeking into IGP database to find the Merge Point address from > > > the interface addresses, or IGP is not used (a non-practical case). > > > >well what does it mean that you will remove all the content > >related to inter-area/inter-as and keep only the two cases > >mentioned here above ? ... > > ... Zafar just wanted to stress the fact that the applicability of the > draft was not restricted to multi-area and inter-AS TE, that's it. > > >page 4/5 of this i-d explicitly > >mentioned why this solution would make sense in inter-area > >cases and for inter-as, i'd like to know how far we can go > >in "advertizing" the ospf router-id between as's using rsvp? > > not sure to see what you mean by "how far" ... I guess you're referring to > some need for hiding the topology of ASx to ASy. If that's the case, in > order to use FRR Bypass with NNHOP backup tunnel to protect against an ASBR > node failure, this just requires to give the visibility of every ASBR Next hop. > > >- it also explains why we don't need it in single area case > >i am not sure "avoid a lookup" would justify this - > > > > > In addition, as the contents/ extension in the drafts are so minor, the > > > WG discussions at the IETF meeting went along the line of moving forward > > > with this as a more generic solution (which is not a 100% tied up with > > > the Inter-AS/ Inter-area discussions). > > > >i am not sure we're on the same line here, do we propose > >a solution to a problem, or do we define a "minor object" > >and then try to see its applications ? ... > > Do you think the problem statement was not clear enough ? > > >in fact you > >have to spell it out in another way this draft raises a > >major issue (in section 5. you may not be an MP so might > >be wise to list the implications) > > I do not see your point here > > >(*) it is like a newobject in fact not only a flag since > >we've to define the processing from the "worst case" view > >point when none information was previously available (this > >is what you referred as "filtration cases") > > idem > > JP. > > >thanks, > >- dimitri. > > > Thanks > > > > > > Regards... Zafar > > > > > > > now independently of the work organisation, this i-d > > > > is valuable when backup tunnels are used and i think > > > > the following i-d "complements" the proposed solution > > > > using detour lsp's for this real problem being "abr > > > > node protection and as border node protection": > > > > > > > http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-protect > > > ion-00.txt > > > > > > thanks, > > > - dimitri. > > > > > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote: > > > > > > > > I agree for support of this draft > > > > > > > > JL > > > > > > > > >In San Francisco the workgroup showed support for making > > > > > Definition of an RRO node-id subobject > > > > > draft-vasseur-mpls-nodeid-subobject-00.txt > > > > > > > > > >an MPLS WG Document. This message is to solicit any further comments > > > > > > > > >prior to making a final determination. > > > > > > > > > >Please reply by 4/7 24:00 GMT. > > > > > > > > > >...George > > > > > > > > > >===================================================================== > > > > >= > > > > > > > > >George Swallow Cisco Systems (978) > > > > 936-1398 > > > > > 250 Apollo Drive > > > > > Chelmsford, Ma 01824 > > > > > > -- > > > Papadimitriou Dimitri > > > E-mail : dimitri.papadimitriou@alcatel.be > > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > > E-mail : dpapadimitriou@psg.com > > > Public : http://psg.com/~dpapadimitriou/ > > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > > Phone : +32 3 240-8491 > > > >-- > >Papadimitriou Dimitri > >E-mail : dimitri.papadimitriou@alcatel.be > >Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > >E-mail : dpapadimitriou@psg.com > >Public : http://psg.com/~dpapadimitriou/ > >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > >Phone : +32 3 240-8491 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Wed Apr 2 09:03:05 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09608 for ; Wed, 2 Apr 2003 09:03:04 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiro24522 for ; Wed, 2 Apr 2003 14:05:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiro24426; Wed, 2 Apr 2003 14:05:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoirm11583 for mpls-outgoing; Wed, 2 Apr 2003 13:40:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoirm11577 for ; Wed, 2 Apr 2003 13:40:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoirm19882 for ; Wed, 2 Apr 2003 13:40:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirm24492 for ; Wed, 2 Apr 2003 13:40:12 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoirm24478 for ; Wed, 2 Apr 2003 13:40:11 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h32De3iH008345 for ; Wed, 2 Apr 2003 08:40:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA05565 for ; Wed, 2 Apr 2003 08:40:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h32De3k26379 for mpls@uu.net; Wed, 2 Apr 2003 08:40:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoirm11543 for ; Wed, 2 Apr 2003 13:38:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoirm10195 for ; Wed, 2 Apr 2003 13:37:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirm15031 for ; Wed, 2 Apr 2003 13:37:46 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQoirm15011 for ; Wed, 2 Apr 2003 13:37:45 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08885; Wed, 2 Apr 2003 08:35:16 -0500 (EST) Message-Id: <200304021335.IAA08885@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-tc-mib-06.txt Date: Wed, 02 Apr 2003 08:35:15 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Textual for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau, J. Cucchiara Filename : draft-ietf-mpls-tc-mib-06.txt Pages : 22 Date : 2003-4-2 This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Mulitprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-tc-mib-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-tc-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-2085430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-tc-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-tc-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-2085430.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Apr 2 10:04:19 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11659 for ; Wed, 2 Apr 2003 10:04:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirs28735 for ; Wed, 2 Apr 2003 15:06:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoirs28441; Wed, 2 Apr 2003 15:06:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQoirp05345 for mpls-outgoing; Wed, 2 Apr 2003 14:23:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoirp05339 for ; Wed, 2 Apr 2003 14:23:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoirp00883 for ; Wed, 2 Apr 2003 14:22:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirp13300 for ; Wed, 2 Apr 2003 14:22:18 GMT Received: from mail2.hyperchip.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.hyperchip.com [216.94.112.4]) id QQoirp13282 for ; Wed, 2 Apr 2003 14:22:17 GMT Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 190j85-00005R-00 for mpls@UU.NET; Wed, 02 Apr 2003 09:22:17 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 09:21:11 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E871042EAD24@hermes.hyperchip.com> From: Philip Matthews To: mpls@UU.NET Subject: RE: Check MPLS WG Consensus (on nodeid-subobject) Date: Wed, 2 Apr 2003 09:21:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F923.1BF68EB0" 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_01C2F923.1BF68EB0 Content-Type: text/plain; charset="iso-8859-1" I support making this document a WG draft. - Philip >In San Francisco the workgroup showed support for making > Definition of an RRO node-id subobject > draft-vasseur-mpls-nodeid-subobject-00.txt > >an MPLS WG Document. This message is to solicit any further comments >prior to making a final determination. > >Please reply by 4/7 24:00 GMT. > >...George > >====================================================================== >George Swallow Cisco Systems (978) 936-1398 > 250 Apollo Drive > Chelmsford, Ma 01824 ------_=_NextPart_001_01C2F923.1BF68EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Check MPLS WG Consensus (on nodeid-subobject)

I support making this document a WG draft.
- Philip


>In San Francisco the workgroup showed support for = making
>   Definition of an RRO node-id = subobject
>     = draft-vasseur-mpls-nodeid-subobject-00.txt
>
>an MPLS WG Document.  This message is to = solicit any further comments
>prior to making a final determination.
>
>Please reply by 4/7 24:00 GMT.
>
>...George
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
>George = Swallow          Cisco = Systems           = ;        (978) 936-1398
>          = ;            = ;   250 Apollo Drive
>          = ;            = ;   Chelmsford, Ma 01824

------_=_NextPart_001_01C2F923.1BF68EB0-- From owner-mpls@UU.NET Wed Apr 2 10:04:21 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11676 for ; Wed, 2 Apr 2003 10:04:21 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirs28763 for ; Wed, 2 Apr 2003 15:06:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoirs28483; Wed, 2 Apr 2003 15:06:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQoirp05351 for mpls-outgoing; Wed, 2 Apr 2003 14:23:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoirp05340 for ; Wed, 2 Apr 2003 14:23:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoirp00884 for ; Wed, 2 Apr 2003 14:22:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirp13301 for ; Wed, 2 Apr 2003 14:22:18 GMT Received: from mail2.hyperchip.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.hyperchip.com [216.94.112.4]) id QQoirp13283 for ; Wed, 2 Apr 2003 14:22:18 GMT Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 190j85-0004ZN-00 for mpls@UU.NET; Wed, 02 Apr 2003 09:22:17 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 09:21:11 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E871042EAD23@hermes.hyperchip.com> From: Philip Matthews To: mpls@UU.NET Subject: RE: Checking MPLS WG Consensus Date: Wed, 2 Apr 2003 09:21:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F923.1BDC4FF0" 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_01C2F923.1BDC4FF0 Content-Type: text/plain; charset="iso-8859-1" I am in favor of making this a WG document. - Philip -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] Sent: 2003-Mar-31 14:09 To: mpls@UU.NET Subject: Checking MPLS WG Consensus In San Francisco the workgroup showed support for making OAM Requirements for MPLS Networks draft-nadeau-ietf-oam-requirements-01.txt an MPLS WG Document. This message is to solicit any further comments prior to making a final determination. Please reply by 4/7 24:00 GMT. ...George ====================================================================== George Swallow Cisco Systems (978) 936-1398 250 Apollo Drive Chelmsford, Ma 01824 ------_=_NextPart_001_01C2F923.1BDC4FF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Checking MPLS WG Consensus

I am in favor of making this a WG document.
- Philip

-----Original Message-----
From: George Swallow [mailto:swallow@cisco.com]
Sent: 2003-Mar-31 14:09
To: mpls@UU.NET
Subject: Checking MPLS WG Consensus


In San Francisco the workgroup showed support for = making

  OAM Requirements for MPLS Networks
    = draft-nadeau-ietf-oam-requirements-01.txt

an MPLS WG Document.  This message is to solicit = any further comments
prior to making a final determination.

Please reply by 4/7 24:00 GMT.

...George

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
George = Swallow          Cisco = Systems           = ;        (978) 936-1398
          &nb= sp;           &nb= sp; 250 Apollo Drive
          &nb= sp;           &nb= sp; Chelmsford, Ma 01824



------_=_NextPart_001_01C2F923.1BDC4FF0-- From owner-mpls@UU.NET Wed Apr 2 10:11:52 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12712 for ; Wed, 2 Apr 2003 10:11:51 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirs22230 for ; Wed, 2 Apr 2003 15:14:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoirs21960; Wed, 2 Apr 2003 15:14:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQoirq05793 for mpls-outgoing; Wed, 2 Apr 2003 14:30:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoirq05788 for ; Wed, 2 Apr 2003 14:30:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoirp28105 for ; Wed, 2 Apr 2003 14:29:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirp22591 for ; Wed, 2 Apr 2003 14:29:10 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoirp22524 for ; Wed, 2 Apr 2003 14:29:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h32ET4iH016948 for ; Wed, 2 Apr 2003 09:29:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA08536 for ; Wed, 2 Apr 2003 09:29:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h32ET3s00762 for mpls@uu.net; Wed, 2 Apr 2003 09:29:03 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoirp05723 for ; Wed, 2 Apr 2003 14:28:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoirp09284 for ; Wed, 2 Apr 2003 14:27:24 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirp20307 for ; Wed, 2 Apr 2003 14:27:23 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoirp20289 for ; Wed, 2 Apr 2003 14:27:23 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA60493; Wed, 2 Apr 2003 09:26:07 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200304021426.JAA60493@workhorse.fictitious.org> To: "David Allan" cc: "'Dan Tappan'" , Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: [PWE3] MPLS PID In-reply-to: Your message of "Tue, 01 Apr 2003 09:15:31 EST." Date: Wed, 02 Apr 2003 09:26:07 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , " David Allan" writes: > > If the goal is that ECMP trumps the MPLS architecture, we have a few things > to fix, not just the PID. If the goal is that MPLS must be backwards > compliant with deployed or may be deployed ECMP gear making PW 1st nybbles > == 0 is only a start. Dave, I never knew that MPLS architecture was a religion. I always thought MPLS was deployed and because it solved real world practical problems. Requiring the martinni control word would seem like a no brainer. However maybe we don't buy into that for some **technical** reason, perhaps overhead on the control word in the edge of the network makes a difference. If so, then the control word must be added along the way if the traffic type is known. The only truly deterministic way to know the traffic type is if L3PID tells you. The two common values are IPv4 and MPLS. MPLS essentially means "don't know". The issue comes up when hierarchical LSPs contain more than one LSP of different type and currently the only choice is MPLS. If we add L3PID types of "IP or PWE3 contains control word" or "PWE3 without control word" a control word of "unknown type" can be added at the PSC tunnel ingress and stripped at the PSC tunnel egress. This adding and removing a control word would be a painful solution to swallow but it would be the cleanest solution and would provide *both* low overhead on the edge *and* load split (ECMP) in the core without reordering non-IP flows. Some people want to depricate L3PID but this issue is proving that it may be worth keeping it. This whole argument is predicated on there being a sound reason to make the control word optional. By far the simplest solution is to make implementing the control word a requirement but make enabling the control word optional. This would give the provider the option of lower overhead near the edges *or* ECMP in the core but not both (without risking reordering). Curtis From owner-mpls@UU.NET Wed Apr 2 10:20:26 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13389 for ; Wed, 2 Apr 2003 10:20:25 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirt21714 for ; Wed, 2 Apr 2003 15:22:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoirt21532; Wed, 2 Apr 2003 15:22:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQoirq06662 for mpls-outgoing; Wed, 2 Apr 2003 14:41:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoirq06638 for ; Wed, 2 Apr 2003 14:41:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoirq13182 for ; Wed, 2 Apr 2003 14:39:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirq05144 for ; Wed, 2 Apr 2003 14:39:08 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoirq05128 for ; Wed, 2 Apr 2003 14:39:07 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h32Ed5iH019053 for ; Wed, 2 Apr 2003 09:39:05 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09177 for ; Wed, 2 Apr 2003 09:39:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h32Ed4X01672 for mpls@uu.net; Wed, 2 Apr 2003 09:39:04 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoirq06370 for ; Wed, 2 Apr 2003 14:38:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoirq03856 for ; Wed, 2 Apr 2003 14:35:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirq29802 for ; Wed, 2 Apr 2003 14:35:04 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoirq29780 for ; Wed, 2 Apr 2003 14:35:03 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA60534; Wed, 2 Apr 2003 09:34:06 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200304021434.JAA60534@workhorse.fictitious.org> To: Luca Martini cc: Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: [PWE3] MPLS PID In-reply-to: Your message of "Tue, 01 Apr 2003 14:31:46 MST." <3E8A0542.40603@level3.net> Date: Wed, 02 Apr 2003 09:34:06 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E8A0542.40603@level3.net>, Luca Martini writes: > > > Shahram Davari wrote: > > I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network is > fundamentally wrong, and is impossible to do for all ECMP implementations su > ch as the one that I described > > in earlier emails in which both the first nibble and the CRC are used to de > tect IP. > > > Shahram, > It might be fundamentally wrong but this is deployed today , and we run our > hole network based on this little point. It seems to work fine for a network > that transport 90gb/s to 100Gb/s of actual traffic. > > So if we put the theory, and layer arguments aside , what is the issue with > determining that a particular flow is not IP ( assuming IP = 99% of traffic ) > ? > > Luca > > It might be fundamentally wrong > > > > The best way to solve this problem is to do ECMP only based on label stack. > Doing so should be > > easier than introducing new standard. > > > > -Shahram Solving real world problems is never fundamentally wrong. If all traffic is know to be either IP or contain a control word then there is no chance of reorder so its not wrong at all. Curtis From owner-mpls@UU.NET Wed Apr 2 10:36:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14159 for ; Wed, 2 Apr 2003 10:36:18 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoiru28516 for ; Wed, 2 Apr 2003 15:38:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoiru28418; Wed, 2 Apr 2003 15:38:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQoirs27038 for mpls-outgoing; Wed, 2 Apr 2003 15:06:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoirs27017 for ; Wed, 2 Apr 2003 15:06:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoirs08422 for ; Wed, 2 Apr 2003 15:05:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirs27062 for ; Wed, 2 Apr 2003 15:05:47 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoirs27046 for ; Wed, 2 Apr 2003 15:05:46 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h32F5iMR015064 for ; Wed, 2 Apr 2003 10:05:44 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA11157 for ; Wed, 2 Apr 2003 10:05:43 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h32F5hG05773 for mpls@uu.net; Wed, 2 Apr 2003 10:05:43 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoirs21283 for ; Wed, 2 Apr 2003 15:04:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoirs08701 for ; Wed, 2 Apr 2003 15:02:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirs05850 for ; Wed, 2 Apr 2003 15:02:35 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoirs05841 for ; Wed, 2 Apr 2003 15:02:34 GMT Received: from pilgrim.cisco.com (pilgrim.cisco.com [161.44.168.94]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h32F1jiH024036; Wed, 2 Apr 2003 10:01:46 -0500 (EST) Received: from tappan-w2k01.cisco.com (tappan-frame1.cisco.com [10.83.99.138]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA15348; Wed, 2 Apr 2003 10:01:44 -0500 (EST) Message-Id: <4.3.2.7.2.20030402093708.09931ca8@pilgrim.cisco.com> X-Sender: tappan@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Apr 2003 10:01:43 -0500 To: "David Allan" From: Dan Tappan Subject: RE: [PWE3] MPLS PID Cc: Shahram Davari , "'Lloyd Wood'" , pwe3@ietf.org, mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:15 AM 4/1/2003 -0500, David Allan wrote: >1) are we going to permanently break the paradigm where labels are PIDs?, >because that's where we're headed. IMHO that's fairly fundamental. MPLS >cannot just carry "anything" via signalled convention, because >intermediate boxes are making their own assumptions as to what the payload is. I believe that I addressed this point: I wrote: > As I see it there are two possible approaches: > >1. Require that an LSP set up for an IP L3PID or IP FEC carry IP packets. >2. Allow non-IP packets on such an LSP, but require that they >be distinguishable. The immediate situation is that we have cases where a TE LSP is signalled using L3PID==IP, or an LDP LSP is setup for an IP FEC, but the encapsulated data (under a multi-level label stack) is not IP. You seem to be arguing in favor of [1] - requiring a strict interpretation of the L3PID, which means those packets should never be injected into that LSP. That's an internally consistent model, and it's the one which was used during the arguments which removed the L3PID from the original MPLS encapsulation. Unfortunately it seems to fail the reality test - if there were not operational benefit in violating [1] then we would not be having this discussion. >2) if we codify snooping the first nybble, it still does not fix ECMP >hashing of reserved labels, we're still in the woods. We also hang out to >dry work in PWE3 and other SDOs that are not compliant with this "new" >convention. Either I'm missing your point or this is a red herring. Fundamentally, any ECMP algorithm needs to be designed to avoid misordering flows. If someone implements an algorithm that uses a hash of the label stack then it needs to avoid fields which are not constant for a flow. IF we codify standards which require arbitrarily inserting additional labels into a stack then it can certainly impact an ECMP algorithm which depends on the contents of the stack. So we can have a whole separate argument about whether that is a good idea. BUT, that is all orthogonal to the issue of whether it should-be/needs-to-be possible to distinguish an IP from a non-IP packet on an IP LSP. From owner-mpls@UU.NET Wed Apr 2 10:44:49 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14463 for ; Wed, 2 Apr 2003 10:44:49 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirv26872 for ; Wed, 2 Apr 2003 15:47:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoirv26619; Wed, 2 Apr 2003 15:47:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQoirt29077 for mpls-outgoing; Wed, 2 Apr 2003 15:17:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoirt29062 for ; Wed, 2 Apr 2003 15:17:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoirt03012 for ; Wed, 2 Apr 2003 15:17:00 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoirt14305 for ; Wed, 2 Apr 2003 15:16:59 GMT Received: from mail2.hyperchip.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.hyperchip.com [216.94.112.4]) id QQoirt14286 for ; Wed, 2 Apr 2003 15:16:59 GMT Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 190jyg-0003Px-00; Wed, 02 Apr 2003 10:16:38 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 10:15:32 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E87104DC11D6@hermes.hyperchip.com> From: Philip Matthews To: "'Jean Philippe Vasseur'" Cc: mpls@UU.NET Subject: RE: Some comments on draft-vasseur-mpls-nodeid-subobject-00.txt Date: Wed, 2 Apr 2003 10:15:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F92A.B33B8440" 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_01C2F92A.B33B8440 Content-Type: text/plain; charset="iso-8859-1" Hi Jean Philippe: > Hi Philip, > > At 11:45 01/04/2003 -0500, Philip Matthews wrote: > > > Jean Philippe: > > Here are some comments on your document: draft-vasseur-mpls-nodeid-subobject-00.txt. > > 1) It wasn't clear to me whether this draft is proposing that a router push > both its interface address and its nodeid, or just push its nodeid. > > I personally feel that both addresses should be included, > as the interface address information can be useful for debugging. > > That's perfectly correct. From your comment, I take it that the intent is to push BOTH the interface address AND the node id. What is the order of the various subobjects? The draft says: "The node-id subobject is added into the RECORD_ROUTE object after the Label Record subobject. " Does this mean: (a) a router pushes first a Label subobject, then a nodeid subobject, and then finally a interface address subobject (so the order in the RRO is