From mpls-bounces@lists.ietf.org Thu Jun 01 12:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpaU-0003eP-4t; Thu, 01 Jun 2006 11:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpaS-0003eK-8L for mpls@ietf.org; Thu, 01 Jun 2006 11:59:52 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpaQ-0001BD-W0 for mpls@ietf.org; Thu, 01 Jun 2006 11:59:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Jun 2006 08:59:50 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k51FxoXj002182; Thu, 1 Jun 2006 08:59:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k51Fxnku003919; Thu, 1 Jun 2006 11:59:49 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 11:59:49 -0400 Received: from swallow-mini-mac.local ([10.86.240.160]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 11:59:48 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.local (Postfix) with ESMTP id 7E70A272241; Thu, 1 Jun 2006 11:59:48 -0400 (EDT) To: mpls@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Thu, 01 Jun 2006 11:59:48 -0400 Message-Id: <20060601155948.7E70A272241@swallow-mini-mac.local> X-OriginalArrivalTime: 01 Jun 2006 15:59:48.0753 (UTC) FILETIME=[68DBD810:01C68594] DKIM-Signature: a=rsa-sha1; q=dns; l=375; t=1149177590; x=1150041590; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:Time=20to=20set=20the=20agenda; X=v=3Dcisco.com=3B=20h=3D69UUPZ+ZMtDV1NzQB4DUBNGVWmQ=3D; b=U/dbgjL5HSvCqCPRmbDkp0B70ltze69XDI4zJ45JI06Segbabv5aoARlOlFbD9frbvWLTbNA atlVgx6j4emukDIpaxhFjSN098d1f6Jg/ZUnVDBNvmwGdppjanzdcbrA; Authentication-Results: sj-dkim-4.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [mpls] Time to set the agenda X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Please forward your agenda requests to Loa and me. Include the amount of time that you'd like. Thanks, ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 02 10:06:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAGD-0004md-Qo; Fri, 02 Jun 2006 10:04:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAGC-0004mY-An for mpls@lists.ietf.org; Fri, 02 Jun 2006 10:04:20 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmAGA-0001E5-RU for mpls@lists.ietf.org; Fri, 02 Jun 2006 10:04:20 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:04:18 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 15:04:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt Date: Fri, 2 Jun 2006 15:04:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt Thread-Index: AcaFBpy9DGCEQMMuRRiLKaqys3yT1gBRrL0g From: To: , X-OriginalArrivalTime: 02 Jun 2006 14:04:17.0320 (UTC) FILETIME=[6FD0DA80:01C6864D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tnadeau@cisco.com X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Adrian, Adrian Farrel wrote: > Please review, comment, implement (!) and tell us what we have done > wrong.=20 A couple of comments: Section 4.1, bullet 1 states "P2MP Tunnel table (mplsP2mpTunnelTable) that sparse augments the MPLS-TE Tunnel table". I'm not exactly sure what "sparse augments" means. Section 4.2, second paragraph - "When an MPLS-TE tunnel is a P2MP tunnel, certain objects in the mplsTunnelTable are have new meanings", remove the extraneous "are". Section 6, states "The nature of P2MP tunnels is such that an LSR that is crossed by a tunnel may either be the ingress of that tunnel or have precisely one upstream LSP segment (also known as in-segment [RFC3812]) for that LSP." and "A single P2MP cross-connect has zero or one in-segment." draft-ietf-mpls-rsvp-te section 18.1.1 states "There are two approaches to dealing with re-merge case. In the first, the node detecting the re-merge case, i.e., the re-merge node, allows the re-merge case to persist but data from all but one incoming interface is dropped at the re-merge node." and "When configured to allow a re-merge case to persist, the re-merge node receives data associated with the P2MP LSP on multiple incoming interfaces, but it may only send the data from one of these interfaces to its outgoing interfaces, i.e., the node MUST drop data from all but one incoming interface." So, if I understand correctly there is no way to detect a re-merge in a P2MP LSP using the MIB specified in draft-farrel-mpls-p2mp-te-mib? --=20 Ben Niven-Jenkins Network Architect, BT Exact =20 E-mail: benjamin.niven-jenkins@bt.com=20 Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From wilfridbergman@observerco.com Sat Jun 03 22:07:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmi1N-0003Nz-5T for mpls-archive@lists.ietf.org; Sat, 03 Jun 2006 22:07:17 -0400 Received: from [58.52.108.105] (helo=BABY) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmi1I-0000qB-A6 for mpls-archive@lists.ietf.org; Sat, 03 Jun 2006 22:07:17 -0400 Message-Id: <00de01c68772$547ae700$149f0a38@ulrk> From: "ricca patel" To: "ky arellano" Subject: Refinnace your loan, game season Date: Sat, 03 Jun 2006 21:02:02 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DE_01C68772.547AE700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------=_NextPart_000_00DE_01C68772.547AE700 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://gadst.org/d2/ cloth stretcher trap drummer step function share register slide-rest lathe quasi renewal bonnet top draw cock blue-fronted Santa sophia pigeon-tailed vase-vine beer scale noble-minded lead line school logic arrow-smitten comma bacillus barn-raising snow-colored ray-girt force main Turkish-blue worse-succeeding leading wind tied letters drill cylinder deep-persuading chromium sesquioxi= de virus disease dolphin oil ------=_NextPart_000_00DE_01C68772.547AE700 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://gadst.org/d2/

cloth stretcher trap drummer step function share register slide-rest lathe<= BR> quasi renewal bonnet top
draw cock blue-fronted Santa sophia pigeon-tailed vase-vine beer scale
noble-minded lead line school logic arrow-smitten comma bacillus
barn-raising snow-colored ray-girt
force main Turkish-blue worse-succeeding
leading wind tied letters drill cylinder deep-persuading chromium sesquioxi= de
virus disease dolphin oil
= ------=_NextPart_000_00DE_01C68772.547AE700-- From mpls-bounces@lists.ietf.org Mon Jun 05 16:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLzN-0000VF-5D; Mon, 05 Jun 2006 16:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLzM-0000VA-2B for mpls@lists.ietf.org; Mon, 05 Jun 2006 16:47:52 -0400 Received: from wx-out-0102.google.com ([66.249.82.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLzL-0007HX-GO for mpls@lists.ietf.org; Mon, 05 Jun 2006 16:47:52 -0400 Received: by wx-out-0102.google.com with SMTP id h26so900236wxd for ; Mon, 05 Jun 2006 13:47:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=cmQxIsm3bd8uo6rFpJgLOdEZ1Ga7JZsvgrUzSKggM7n7riA1rWGYi3ShKY++ct8PybJtzYVBjXS0aU4gX0p2pOL65Yc6JL0/Vs4v9m8kg6HyxCz58bOfHxBvUUiSyv/P6D79RfLHTUW+RZI7lLkP/6F7FkWyRCJ0Enrbhi0sPy0= Received: by 10.70.102.11 with SMTP id z11mr6532538wxb; Mon, 05 Jun 2006 13:47:51 -0700 (PDT) Received: by 10.70.38.13 with HTTP; Mon, 5 Jun 2006 13:47:50 -0700 (PDT) Message-ID: Date: Mon, 5 Jun 2006 13:47:51 -0700 From: "Srinivas Reddy" To: mpls@lists.ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: Subject: [mpls] problem configurating tunnel using mplsadm2 and iproute2 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0240623200==" Errors-To: mpls-bounces@lists.ietf.org --===============0240623200== Content-Type: multipart/alternative; boundary="----=_Part_35503_5410187.1149540471002" ------=_Part_35503_5410187.1149540471002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am using linux-2.4.19 kernel. I am not able to configure tunnel between two linux machines.Please fins the details given below. eth0 eth1 LSR1(eth1)<-------->(eth0)LSR2 tunnel starts at LSR1 and ends at LSR2. LSR1 configuration: [root@impls utils]#ifconfig eth0 Link encap:Ethernet HWaddr 00:03:47:E2:D8:83 inet addr:10.1.5.139 Bcast:10.1.5.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2543202 errors:0 dropped:0 overruns:2 frame:0 TX packets:5065 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:197998558 (188.8 Mb) TX bytes:224558 (219.2 Kb) Interrupt:22 Base address:0x9000 eth1 Link encap:Ethernet HWaddr 00:03:47:E1:A3:D7 inet addr:10.1.6.139 Bcast:10.1.6.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25 errors:0 dropped:0 overruns:0 frame:0 TX packets:486 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1926 (1.8 Kb) TX bytes:48158 (47.0 Kb) Interrupt:17 Base address:0xb000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:63 errors:0 dropped:0 overruns:0 frame:0 TX packets:63 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6443 (6.2 Kb) TX bytes:6443 (6.2 Kb) mpls0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.0.2 P-t-P:192.168.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1492 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:541 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:45444 (44.3 Kb) Commands used to configure LSR1: [root@impls utils]# ./mplsadm2 -L eth1:1 Label Space: Success [root@impls utils]# ./mplsadm2 -A -O 1 -o push:gen:1024:set:eth1:ipv4:192.168.0.1 Key: 0x00000002 Out Segment add: Success Out Instr: Illegal seek [root@impls utils]# ./mplsadm2 -D -O 1 -o push:gen:1024:set:eth1:ipv4:192.168.0.1 Out Segment del: No such process Out Instr: No such process [root@impls utils]# cat /proc/net/mpls_out 0x00000002 0/0/0 1 PUSH(gen 1024) SET(eth1,192.168.0.1) [root@impls utils]# ./mplsadm2 -D -O 0x00000002 Out Segment del: Success [root@impls utils]# [root@impls utils]# ./mplsadm2 -A -O 0 -o push:gen:1024:set:eth1:ipv4:192.168.0.1 Key: 0x00000003 Out Segment add: Success Out Instr: Illegal seek [root@impls utils]# ./mplsadm2 -D -O 0x00000003 Out Segment del: Success [root@impls utils]# [root@impls utils]# ./mplsadm2 -A -O 0 Key: 0x00000004 Out Segment add: Success [root@impls utils]# ./mplsadm2 -D -O 0x00000004 Out Segment del: Success [root@impls utils]# ./mplsadm2 -O 0x00000005 -o push:gen:1024:set:eth1:ipv4:192.168.0.1 Out Instr: Success [root@impls utils]# ./mplsadm2 -A -T mpls0 [root@impls utils]# route add default dev mpls0 [root@impls utils]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.1.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.1.6.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 mpls0 0.0.0.0 10.1.6.140 0.0.0.0 UG 0 0 0 eth1 [root@impls utils]# [root@impls utils]# ./mplsadm2 -A -O 1 Key: 0x00000006 Out Segment add: Success [root@impls utils]# ./mplsadm2 -B -O 0x00000006 -T mpls0 Bind Tunnel2Out add: Success [root@impls mpls]# cd iproute2/ip [root@impls ip]# ./ip route add 172.16.1.0/24 dev mpls0 proc entries : [root@impls utils]# cat /proc/net/mpls_out 0x00000005 457/38388/0 2 PUSH(gen 1024) SET(eth1,192.168.0.1) 0x00000006 84/7056/0 2 PUSH(gen 2048) SET(mpls0,0.0.0.0) [root@impls utils]# cat /proc/net/mpls_tunnel mpls0 0x00000006 on pinging the tunnel end point 192.168.0.1 packet does not come out of the interface at all. Even if i ping 172.16.1.1 as given in the above command. Please let me if i am doing something wrong in configuring the tunnel. If i want to introduce one more LSR between LSR1 and LSR2, what kind of configuration changes do i need to do?. something like LSR1<----->LSR2<------>LSR3 | simple LSP | | | |<--------------------------------->| TUNNEL As for as the virtual interface is concerned there must be a route to reach the destination 192.168.0.2, and the out going interface would be eth1 as given in the above configuration, please correct if i am worng. So when packet received at LSR2 what kind of processing would be performed on the packet.I would like to know how to configure at LSR1 and LSR2 to process the incoming label properly, It will be great if somebody can provide me the command sequence. Please find the debug out put( for ping 192.168.0.2) given bellow for the problem i mentioned earlier while creating mpls tunnel between 2 linux machines : mpls_output2: enter mpls_output2: opcode PUSH mpls_push: enter mpls_push: using tailroom mpls_push: done using tailroom mpls_push: exit mpls_output2: opcode SET mpls_send: output device = mpls0 mpls_finish: enter mpls_finish: exit mpls_send: GEN mpls_send: using neighbour (cefdec80) mpls_skb_dump: from mpls0 with len 88 (284) headroom=16 tailroom=24 3c373e4a756e2020332031363a30303a{|0080*01ff450000540000400040016771#c0a800020a01088d0800bef1530405007a148244f3ad060008090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363700} mpls_send: mpls_send result 0 mpls_output2: exit ./mplsadm2 -d Debug: Success Thanks in advance for your help, LSReddy. ------=_Part_35503_5410187.1149540471002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

  I am using linux-2.4.19 kernel. I am not able to configure tunnel between two linux machines.Please fins the details given below.
eth0                                         eth1
   LSR1(eth1)<-------->(eth0)LSR2

tunnel starts at LSR1 and ends at LSR2.

LSR1 configuration:

[root@impls utils]#ifconfig
eth0      Link encap:Ethernet  HWaddr 00:03:47:E2:D8:83 
          inet addr:10.1.5.139  Bcast:10.1.5.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2543202 errors:0 dropped:0 overruns:2 frame:0
          TX packets:5065 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:197998558 (188.8 Mb)  TX bytes:224558 (219.2 Kb)
          Interrupt:22 Base address:0x9000

eth1      Link encap:Ethernet  HWaddr 00:03:47:E1:A3:D7 
          inet addr:10.1.6.139  Bcast:10.1.6.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:486 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1926 (1.8 Kb)  TX bytes:48158 (47.0 Kb)
          Interrupt:17 Base address:0xb000

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:63 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6443 (6.2 Kb)  TX bytes:6443 (6.2 Kb)

mpls0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:192.168.0.2  P-t-P:192.168.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1492  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:541 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:45444 (44.3 Kb)

Commands used to configure LSR1:

[root@impls utils]# ./mplsadm2 -L eth1:1
Label Space: Success

[root@impls utils]# ./mplsadm2 -A -O 1 -o
push:gen:1024:set:eth1:ipv4:192.168.0.1
Key: 0x00000002
Out Segment add: Success
Out Instr: Illegal seek

[root@impls utils]# ./mplsadm2 -D -O 1 -o
push:gen:1024:set:eth1:ipv4:192.168.0.1
Out Segment del: No such process
Out Instr: No such process
[root@impls utils]# cat /proc/net/mpls_out
0x00000002 0/0/0 1 PUSH(gen 1024) SET(eth1,192.168.0.1)
[root@impls utils]# ./mplsadm2 -D -O 0x00000002
Out Segment del: Success
[root@impls utils]#

[root@impls utils]# ./mplsadm2 -A -O 0 -o
push:gen:1024:set:eth1:ipv4:192.168.0.1
Key: 0x00000003
Out Segment add: Success
Out Instr: Illegal seek
[root@impls utils]# ./mplsadm2 -D -O 0x00000003
Out Segment del: Success
[root@impls utils]#

[root@impls utils]# ./mplsadm2 -A -O 0
Key: 0x00000004
Out Segment add: Success
[root@impls utils]# ./mplsadm2 -D -O 0x00000004
Out Segment del: Success

[root@impls utils]# ./mplsadm2 -O 0x00000005 -o
push:gen:1024:set:eth1:ipv4:192.168.0.1
Out Instr: Success
[root@impls utils]# ./mplsadm2 -A -T mpls0
[root@impls utils]# route add default dev mpls0

[root@impls utils]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.5.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.1.6.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 mpls0
0.0.0.0         10.1.6.140      0.0.0.0         UG    0      0        0 eth1

[root@impls utils]#
[root@impls utils]# ./mplsadm2 -A -O 1
Key: 0x00000006
Out Segment add: Success
[root@impls utils]# ./mplsadm2 -B -O 0x00000006 -T mpls0
Bind Tunnel2Out add: Success

[root@impls mpls]# cd iproute2/ip
[root@impls ip]# ./ip route add 172.16.1.0/24 dev mpls0


proc entries :

[root@impls utils]# cat /proc/net/mpls_out
0x00000005 457/38388/0 2 PUSH(gen 1024) SET(eth1,192.168.0.1)
0x00000006 84/7056/0 2 PUSH(gen 2048) SET(mpls0,0.0.0.0)

[root@impls utils]# cat /proc/net/mpls_tunnel
mpls0   0x00000006

on pinging the tunnel end point 192.168.0.1 packet does not come out of the interface at all.

Even if i ping 172.16.1.1 as given in the above command.

Please let me if i am doing something wrong in configuring the tunnel.

If i want to introduce one more LSR between LSR1 and LSR2, what kind of configuration changes do i need to do?.   something like
    
LSR1<----->LSR2<------>LSR3
 |          simple LSP          |
 |                                     |
 |<--------------------------------->|
              TUNNEL

  As for as the virtual interface is concerned there must be a route to reach the destination 192.168.0.2, and the out going interface would be eth1 as given in the above configuration, please correct if i am worng. So when packet received at LSR2 what kind of processing would be performed on the packet.I would like to know how to configure at LSR1 and LSR2 to process the incoming label properly, It will be great if somebody can provide me the command sequence.

Please find the debug out put( for ping 192.168.0.2) given bellow for the problem i mentioned earlier while creating mpls tunnel between 2 linux machines :

mpls_output2: enter
mpls_output2: opcode PUSH
mpls_push: enter
mpls_push: using tailroom
mpls_push: done using tailroom
mpls_push: exit
mpls_output2: opcode SET
mpls_send: output device = mpls0
mpls_finish: enter
mpls_finish: exit
mpls_send: GEN
mpls_send: using neighbour (cefdec80)
mpls_skb_dump: from mpls0 with len 88 (284) headroom=16 tailroom=24
3c373e4a756e2020332031363a30303a{|0080*01ff450000540000400040016771#c0a800020a01088d0800bef1530405007a148244f3ad060008090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363700}
mpls_send: mpls_send result 0
mpls_output2: exit
./mplsadm2 -d
Debug: Success


Thanks in advance for your help,
LSReddy.


------=_Part_35503_5410187.1149540471002-- --===============0240623200== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0240623200==-- From mpls-bounces@lists.ietf.org Tue Jun 06 11:40:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnddk-0002Ko-GN; Tue, 06 Jun 2006 11:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnddi-0002KZ-3k for mpls@lists.ietf.org; Tue, 06 Jun 2006 11:38:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FncYC-0004WD-GA for mpls@lists.ietf.org; Tue, 06 Jun 2006 10:28:56 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FncKj-0004Tj-77 for mpls@lists.ietf.org; Tue, 06 Jun 2006 10:15:03 -0400 Received: from pc6 (1Cust219.tnt103.lnd4.gbr.da.uu.net [213.116.54.219]) by blaster.systems.pipex.net (Postfix) with SMTP id B5278E0001FC; Tue, 6 Jun 2006 15:14:55 +0100 (BST) Message-ID: <06a301c6896a$b4ee69a0$0601a8c0@pc6> From: "Tom Petch" To: "Adrian Farrel" , References: <0eda01c68506$7b0ebfe0$08849ed9@your029b8cecfe> Subject: Re: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt Date: Tue, 6 Jun 2006 12:18:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -2.6 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Thomas D. Nadeau" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org I am curious about the choice of prefix for these object descriptors, a mix of mplsTe mplsP2mp mplsMP2p I find this hard to follow and would prefer a single prefix (although I realise there are ample precedents in MPLS:-) - is there an underlying logic? Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Thomas D. Nadeau" Sent: Thursday, June 01, 2006 12:59 AM Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt > Hi, > > We have put together a first (somewhat rough) stab at defining a MIB module > for P2MP MPLS-TE and for describing how the existing MPLS-TE MIB modules are > used in support of P2MP MPLS-TE. Hopefully the existence of this I-D will > help the P2MP MPLS-TE solutions work along its path to becoming an RFC. > > Please review, comment, implement (!) and tell us what we have done wrong. > > Cheers, > Adrian > > ----- Original Message ----- > From: > To: > Sent: Wednesday, May 31, 2006 8:50 PM > Subject: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Point-to-Multipoint Multiprotocol Label > > Switching (MPLS) Traffic Engineering (TE) > > Management Information Base (MIB) module > > Author(s) : A. Farrel, et al. > > Filename : draft-farrel-mpls-p2mp-te-mib-00.txt > > Pages : 36 > > Date : 2006-5-31 > > > > This memo defines a portion of the Management Information Base > > for use with network management protocols in the Internet community. > > In particular, it describes managed objects for point-to-multipoint > > Multiprotocol Label Switching-based traffic engineering. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-farrel-mpls-p2mp-te-mib-00.txt > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 06 11:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fndpl-0002OX-AS; Tue, 06 Jun 2006 11:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fndpj-0002L1-4W for mpls@lists.ietf.org; Tue, 06 Jun 2006 11:51:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fndph-0001Tu-NU for mpls@lists.ietf.org; Tue, 06 Jun 2006 11:51:07 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 08:51:05 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="289744193:sNHT33293160" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k56Fp4DW009183; Tue, 6 Jun 2006 08:51:04 -0700 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k56Fp3Lf023817; Tue, 6 Jun 2006 17:51:03 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Jun 2006 17:51:03 +0200 Received: from [144.254.195.24] ([144.254.195.24]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Jun 2006 17:51:03 +0200 In-Reply-To: <06a301c6896a$b4ee69a0$0601a8c0@pc6> References: <0eda01c68506$7b0ebfe0$08849ed9@your029b8cecfe> <06a301c6896a$b4ee69a0$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2AFFFF65-9F83-45C2-A18B-718EB68C0702@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt Date: Tue, 6 Jun 2006 17:51:01 +0200 To: "Tom Petch" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 06 Jun 2006 15:51:03.0313 (UTC) FILETIME=[03BCD010:01C68981] DKIM-Signature: a=rsa-sha1; q=dns; l=2238; t=1149609065; x=1150473065; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20[mpls]=20Fw=3A=20I-D=20ACTION=3Adraft-farrel-mpls-p2mp-te-mib-00 .txt=20; X=v=3Dcisco.com=3B=20h=3DOa2GzSjE3qrhUcY9kU0Dsq6lO6M=3D; b=peYABjUKYKQCBG2pdNP18pGgRpFx+Im1syYh0fhxoW6w4BQ4lKuz+nzTGuIXI5eovtt53uyj uwAUQe9pxrs53BQujA9emFayRhCyZSmkqXHDx6DPZKpgOzwiafxT85YP; Authentication-Results: sj-dkim-2.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mpls@lists.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hey it compiles cleanly so stop complaining! *) Yes, we will make the prefixes consistent. --Tom > I am curious about the choice of prefix for these object > descriptors, a mix of > mplsTe > mplsP2mp > mplsMP2p > I find this hard to follow and would prefer a single prefix > (although I realise > there are ample precedents in MPLS:-) - is there an underlying logic? > > Tom Petch > > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: "Thomas D. Nadeau" > Sent: Thursday, June 01, 2006 12:59 AM > Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt > > >> Hi, >> >> We have put together a first (somewhat rough) stab at defining a >> MIB module >> for P2MP MPLS-TE and for describing how the existing MPLS-TE MIB >> modules are >> used in support of P2MP MPLS-TE. Hopefully the existence of this I- >> D will >> help the P2MP MPLS-TE solutions work along its path to becoming an >> RFC. >> >> Please review, comment, implement (!) and tell us what we have >> done wrong. >> >> Cheers, >> Adrian >> >> ----- Original Message ----- >> From: >> To: >> Sent: Wednesday, May 31, 2006 8:50 PM >> Subject: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Point-to-Multipoint Multiprotocol Label >>> Switching (MPLS) Traffic Engineering (TE) >>> Management Information Base (MIB) module >>> Author(s) : A. Farrel, et al. >>> Filename : draft-farrel-mpls-p2mp-te-mib-00.txt >>> Pages : 36 >>> Date : 2006-5-31 >>> >>> This memo defines a portion of the Management Information Base >>> for use with network management protocols in the Internet >>> community. >>> In particular, it describes managed objects for point-to- >>> multipoint >>> Multiprotocol Label Switching-based traffic engineering. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-farrel-mpls-p2mp-te- >>> mib-00.txt >>> _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 07 05:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fntt7-0008Fc-Hd; Wed, 07 Jun 2006 04:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fntt5-0008FX-Jo for mpls@lists.ietf.org; Wed, 07 Jun 2006 04:59:39 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fntt4-0004AJ-7Y for mpls@lists.ietf.org; Wed, 07 Jun 2006 04:59:39 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FnttA-0004IO-00 for mpls@lists.ietf.org; Wed, 07 Jun 2006 09:59:44 +0100 Received: from your029b8cecfe ([217.158.132.40] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 09:59:34 +0100 Message-ID: <006601c68a10$96a71540$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Tom Petch" , References: <0eda01c68506$7b0ebfe0$08849ed9@your029b8cecfe> <06a301c6896a$b4ee69a0$0601a8c0@pc6> Subject: Re: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt Date: Wed, 7 Jun 2006 02:08:43 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 07 Jun 2006 08:59:35.0103 (UTC) FILETIME=[B2D4ACF0:01C68A10] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Thomas D. Nadeau" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Tom, >I am curious about the choice of prefix for these object descriptors, a mix >of > mplsTe > mplsP2mp > mplsMP2p > I find this hard to follow and would prefer a single prefix (although I > realise > there are ample precedents in MPLS:-) - is there an underlying logic? The (impeccable) logic is simply that when you bash out code in a hurry you make some errors in things like naming. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 07 06:49:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnvZE-0001IQ-NY; Wed, 07 Jun 2006 06:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnvZD-0001I4-21 for mpls@lists.ietf.org; Wed, 07 Jun 2006 06:47:15 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnvZ9-00066g-VS for mpls@lists.ietf.org; Wed, 07 Jun 2006 06:47:14 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00BF9KD2FK@szxga03-in.huawei.com> for mpls@lists.ietf.org; Wed, 07 Jun 2006 18:41:26 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00JV8KD1OF@szxga03-in.huawei.com> for mpls@lists.ietf.org; Wed, 07 Jun 2006 18:41:26 +0800 (CST) Received: from H51074 ([10.70.77.69]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0H00CTHKFH6Y@szxml04-in.huawei.com> for mpls@lists.ietf.org; Wed, 07 Jun 2006 18:42:54 +0800 (CST) Date: Wed, 07 Jun 2006 18:32:27 +0800 From: =?utf-8?B?6buE6YOR?= To: mpls@lists.ietf.org Message-id: <002b01c68a1d$ac6fa380$454d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [mpls] Problem about the collision between multicast and unicast label X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621694750==" Errors-To: mpls-bounces@lists.ietf.org --===============1621694750== Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 ICAgSW4gbXVsdGljYXN0LCBhbGwgZG93bnN0cmVhbSBjYW4gYmUgYWxsb2NhdGVkIHRoZSBzYW1l IGxhYmVsIHZhbHVlIGluIG9yZGVyIHRvIGF2b2lkaW5nIGJyYW5jaCBMU1IgdHJhZmZpYyByZXBs aWNhdGlvbiBvbiBhIExBTiBmb3IgcG9pbnQtdG8tbXVsdGlwb2ludCAoUDJNUClMU1BzLiANCiAg IFRoZSBzZXJpZXMgZG9jdW1lbnRzIG9mIG1wbHMgdXBzdHJlYW0gbGFiZWwgYXJlIGFscmVhZHkg bWFkZSBmb3Igd2cgZG9jcy4gDQogICBUaHJvdWdoIHVwc3RyZWFtIGxhYmVsIGFzc2lnbm1lbnQg b3IgZG93bnN0cmVhbSBsYWJlbCBhc3NpZ25tZW50IChiYXNlZCBvbiB1cHN0cmVhbSBsYWJlbCBz dWdnZXN0aW9uKSwgIGFsbCBuZXh0LWhvcCBkb3duc3RyZWFtIHJvdXRlcnMgd2lsbCByZWNlaXZl IGFuZCBwcm9jZXNzIHRoZSBwYWNrZXQgd2l0aCB0aGUgc2FtZSBsYWJlbC4NCg0KICAgQnV0IGlm IHVuaWNhc3QgbGFiZWwgaXMgYWxsb2NhdGVkIGJlZm9yZSBtdWx0aWNhc3QgbGFiZWwsIGl0IGlz IHBvc3NpYmxlIHRoYXQgdGhlIHNhbWUgbGFiZWwgd2lsbCBiZSBhbGxvY2F0ZWQgb24gdGhlIHNh bWUgTFNSIGZvciB1bmljYXN0IExTUCBhbmQgbXVsdGljYXN0IExTUCBvbiB0aGUgc2FtZSBsaW5r LiANCiAgIFRoZSB1bmljYXN0IExTUCBhbmQgdGhlIG11bHRpY2FzdCBMU1Agd2lsbCB1c2UgdGhl IHNhbWUgaW5jb21pbmcgbGFiZWwgb24gdGhlIHNhbWUgaW50ZXJmYWNlLiANCg0KRm9yIGV4YW1w bGU6DQogDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEQgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8gICAN CiAgICAgICAgICAgICAgICAgICAgICAgICBBLS0tQi0tLUMtLS1FIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXCAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGIA0KDQogICBUaGVyZSBhbHJl YWR5IGV4aXN0cyBvbmUgdW5pY2FzdCBMU1AgKEEtQi1DLUUpLiBBbmQgdGhlIGluY29taW5nIGxh YmVsIG9uIExTUiBDIGlzIGVxdWFsIHRvIEsuDQogICBUaGVyZSBhbHNvIGV4aXN0cyBvbmUgbXVs dGljYXN0IHRyZWUgKEEtQiwgQi1ELCBCLUYpLiBBbmQgdGhlIGluY29taW5nIGxhYmVsIG9uIExT UiBEIGFuZCBMU1IgRiBpcyBlcXVhbCB0byBLLiBMU1IgRCBhbmQgTFNSIEYgYXJlIHRoZSBuZXh0 IGhvcCBkb3duc3RyZWFtIHJvdXRlciBvZiBMU1IgQiwgYW5kIHRoZWlyIGluY29taW5nIGxhYmVs cyBtdXN0ICBiZSBzYW1lLiANCiAgIFN1YnNlcXVlbnRseSwgTFNSIEMgd2FudHMgdG8gam9pbiB0 aGUgbXVsdGljYXN0IHRyZWUuIExTUiBDIGlzIGFsc28gdGhlIG5leHQgaG9wIGRvd25zdHJlYW0g cm91dGVyIG9mIExTUiBCLiBUaGUgaW5jb21pbmcgbXVsdGljYXN0IGxhYmVsIG9uIExTUiBDIG11 c3QgYmUgZXF1YWwgdG8gSywganVzdCBsaWtlIExTUiBEIGFuZCBMU1IgRiBvbiB0aGUgc2FtZSBt dWx0aWNhc3QgdHJlZS4NCiAgIFNvIHRoZXJlIHdpbGwgYXBwZWFyIHRoZSBzYW1lIGluY29taW5n IGxhYmVscyBvbiBMU1IgQyBpZiB3ZSBkb27igJl0IGRpc3Rpbmd1aXNoIGJldHdlZW4gbXVsdGlj YXN0IGFuZCB1bmljYXN0Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogICBJbiBvcmRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIG11 bHRpY2FzdCBhbmQgdW5pY2FzdCBMU1BzIHdpdGggdGhlIHNhbWUgbGFiZWwgdmFsdWUsIHRoZSBs YWJlbHMgY2FuIGJlIGRpZmZlcmVudGlhdGVkIGJ5IHRoZSB1c2Ugb2YgZGlmZmVyZW50IEV0aGVy dHlwZXMgdGhhdCBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBsYWJlbGVkIHBhY2tldCB0aGF0IGlzIGNh cnJpZWQgaW4gYSBsYXllciAyIGZyYW1lIGlzIGZvciB1bmljYXN0IG9yIG11bHRpY2FzdCB0cmFu c2Zlci4gDQogICBCdXQgaWYgTFNSIGRvZXMgbm90IHN1cHBvcnQgdGhlc2UgcHJvY2VkdXJlcywg aXQgY2FuJ3QgZGlzY2VybiB0aGUgbGFiZWxlZCBwYWNrZXQgYW5kIG11c3QgaWdub3JlIGl0LiAN CiAgIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgcHJvY2VzcyBvZiBsYXllciAyIGZyYW1lIGlzIGNv bXBsZXgu --===============1621694750== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1621694750==-- From mpls-bounces@lists.ietf.org Wed Jun 07 07:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwHb-0006pO-Ag; Wed, 07 Jun 2006 07:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwHa-0006pG-06 for mpls@lists.ietf.org; Wed, 07 Jun 2006 07:33:06 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwHY-0004Xe-I7 for mpls@lists.ietf.org; Wed, 07 Jun 2006 07:33:05 -0400 Received: from pc6 (1Cust189.tnt106.lnd4.gbr.da.uu.net [213.116.60.189]) by blaster.systems.pipex.net (Postfix) with SMTP id 779D7E000252; Wed, 7 Jun 2006 12:33:01 +0100 (BST) Message-ID: <003a01c68a1d$408e7380$0601a8c0@pc6> From: "Tom Petch" To: "Adrian Farrel" , References: <0eda01c68506$7b0ebfe0$08849ed9@your029b8cecfe> Date: Wed, 7 Jun 2006 12:25:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Thomas D. Nadeau" Subject: [mpls] Re:I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Thomas D. Nadeau" Sent: Thursday, June 01, 2006 12:59 AM Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt > > We have put together a first (somewhat rough) stab at defining a MIB module > for P2MP MPLS-TE and for describing how the existing MPLS-TE MIB modules are > used in support of P2MP MPLS-TE. Hopefully the existence of this I-D will > help the P2MP MPLS-TE solutions work along its path to becoming an RFC. > > Please review, comment, implement (!) and tell us what we have done wrong. Looks good, impressive even for a rough stab:-) Some minor doubts 1) Why is mplsP2mpTunnelSubGroupIDNext limited to (0..65535) when mplsP2mpTunnelSubGroupID has a range of (1..4294967295)? 2) mplsP2mpTunnelDestEntry has an awesome INDEX which is fine but I think that the two InetAddress - mplsP2mpTunnelSubGroupOrigin and unnelDestination - need SIZE constraints in order to keep SMI happy. 3) mplsP2mpTunnelBranchOutSegment is of SYNTAX MplsIndexType ie OCTET STRING so the special values should be 'single octet with the value 0x00' as in RFC3813. 4) I wonder if the meaning of the special value "that MIB module is inaccessible or not implemented." is not too strict. Could there not be other circumstances when the table as a whole is accessible but the relevant row is not? 5) mplsP2mpTunnelDestCreationTime should reference sysUpTime. 6) Several Counter32 have a DESCRIPTION "Specifies the number of times the ..." I never like 'specifies' sinces it begs the question of since when, and being a counter, there is no when. Counters, by definition, are only meaningful when read more than once and differenced. (RFC3813, along with other Mib Modules, avoids this word). 7) Again on counters, particularly for mplsP2mpTunnelBranchPerfEntry, should there be a discontinuity object? 8) I am puzzled why mplsP2mpTunnelDestUp and mplsP2mpTunnelDestDown are defined in terms of down state. It means, for example, that the transition from down to testing or lowerLayerDown would generate an Up NOTIFICATION; odd. 9) mplsP2mpTunnelDestOperStatus lacks values 5 and 6; I suggest adding a note that this enumeration is in line with RFC3812 where those values are in use. Tom Petch > > Cheers, > Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 07 12:25:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0oa-0005X9-1B; Wed, 07 Jun 2006 12:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0oY-0005Sz-Tt for mpls@lists.ietf.org; Wed, 07 Jun 2006 12:23:26 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0oX-0005PH-Ex for mpls@lists.ietf.org; Wed, 07 Jun 2006 12:23:26 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fo0on-0002Be-00 for mpls@lists.ietf.org; Wed, 07 Jun 2006 17:23:41 +0100 Received: from your029b8cecfe ([217.158.132.35] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 17:23:22 +0100 Message-ID: <00db01c68a4e$af362040$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Tom Petch" , References: <0eda01c68506$7b0ebfe0$08849ed9@your029b8cecfe> <003a01c68a1d$408e7380$0601a8c0@pc6> Date: Wed, 7 Jun 2006 17:23:07 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 07 Jun 2006 16:23:23.0076 (UTC) FILETIME=[B256E840:01C68A4E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Thomas D. Nadeau" Subject: [mpls] Re: Re:I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Tome, > Some minor doubts > > 1) Why is mplsP2mpTunnelSubGroupIDNext limited to (0..65535) when > mplsP2mpTunnelSubGroupID has a range of (1..4294967295)? Because I changed the size of SubGroupID and forgot about IDNext. > 2) mplsP2mpTunnelDestEntry has an awesome INDEX which is fine but I think > that > the two InetAddress - mplsP2mpTunnelSubGroupOrigin and > unnelDestination - need SIZE constraints in order to keep SMI > happy. Probably right. And a good thing anyway. > 3) mplsP2mpTunnelBranchOutSegment is of SYNTAX MplsIndexType ie OCTET > STRING > so the special values should be 'single octet with the value 0x00' as in > RFC3813. Good catch > 4) I wonder if the meaning of the special value "that MIB module is > inaccessible > or not implemented." is not too strict. Could there not be other > circumstances > when the table as a whole is accessible but the relevant row is not? Hmmm. Not sure. I guess this requires a careful parse of the compliance in that module. > 5) mplsP2mpTunnelDestCreationTime should reference sysUpTime. Yes. > 6) Several Counter32 have a DESCRIPTION > "Specifies the number of times the ..." > I never like 'specifies' sinces it begs the question of since when, and > being a > counter, there is no when. Counters, by definition, are only meaningful > when > read more than once and differenced. (RFC3813, along with other Mib > Modules, > avoids this word). Actually, I probably cutted and pasted this from one of the MPLS MIB modules. But you are right. > 7) Again on counters, particularly for mplsP2mpTunnelBranchPerfEntry, > should > there be a discontinuity object? Yes. > 8) I am puzzled why mplsP2mpTunnelDestUp and mplsP2mpTunnelDestDown are > defined > in terms of down state. It means, for example, that the transition from > down to > testing or lowerLayerDown would generate an Up NOTIFICATION; odd. Good thing to be puzzled about. I was aiming for consistency with the MPLS TE MIB module. > 9) mplsP2mpTunnelDestOperStatus lacks values 5 and 6; I suggest adding a > note > that this enumeration is in line with RFC3812 where those values are in > use. Yes. Very many thanks. Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 07 22:21:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoA7M-0007YN-Ux; Wed, 07 Jun 2006 22:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoA7L-0007WZ-3v for mpls@lists.ietf.org; Wed, 07 Jun 2006 22:19:27 -0400 Received: from mail1.optus.com.au ([203.13.126.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoA7I-0007O6-CT for mpls@lists.ietf.org; Wed, 07 Jun 2006 22:19:27 -0400 Received: from CHOW2KE003.optus.com.au ([161.43.32.10]) by mail1.optus.com.au with InterScan Messaging Security Suite; Thu, 08 Jun 2006 12:19:20 +1000 Received: from shqw2ke001.optus.com.au ([10.17.224.13]) by CHOW2KE003.optus.com.au with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 12:19:19 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Problem about the collision between multicast and unicastlabel Date: Thu, 8 Jun 2006 12:19:18 +1000 Message-ID: <799B0CDA650143429C5EA103965B59F80224A6AC@shqw2ke001.optus.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Problem about the collision between multicast and unicastlabel Thread-Index: AcaKH+XgX3Wr8psBTcWangj+a7e2CQAfRvYg From: "Fil Dickinson" To: "??" X-OriginalArrivalTime: 08 Jun 2006 02:19:19.0245 (UTC) FILETIME=[F2AD4FD0:01C68AA1] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@optus.com.au X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mpls@lists.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org I agree (based on your example) we need a mechanism to distiguish Unicast labels from Multicast, but are there not better ways to do it than "Ethertype" such as defined label ranges or something related to the problem rather than a clever use of an unrelated field? I do not have an answer, but perhaps others have thought of this.=20 -----Original Message----- From: szhuangzheng@huawei.com [mailto:szhuangzheng@huawei.com]=20 Sent: Wednesday, 7 June 2006 8:32 PM To: mpls@lists.ietf.org Subject: [mpls] Problem about the collision between multicast and unicastlabel In multicast, all downstream can be allocated the same label value in order to avoiding branch LSR traffic replication on a LAN for point-to-multipoint (P2MP)LSPs.=20 The series documents of mpls upstream label are already made for wg docs.=20 Through upstream label assignment or downstream label assignment (based on upstream label suggestion), all next-hop downstream routers will receive and process the packet with the same label. But if unicast label is allocated before multicast label, it is possible that the same label will be allocated on the same LSR for unicast LSP and multicast LSP on the same link.=20 The unicast LSP and the multicast LSP will use the same incoming label on the same interface.=20 For example: =20 D=20 /=20 / =20 A---B---C---E=20 \ =20 \ =20 F=20 There already exists one unicast LSP (A-B-C-E). And the incoming label on LSR C is equal to K. There also exists one multicast tree (A-B, B-D, B-F). And the incoming label on LSR D and LSR F is equal to K. LSR D and LSR F are the next hop downstream router of LSR B, and their incoming labels must be same.=20 Subsequently, LSR C wants to join the multicast tree. LSR C is also the next hop downstream router of LSR B. The incoming multicast label on LSR C must be equal to K, just like LSR D and LSR F on the same multicast tree. So there will appear the same incoming labels on LSR C if we don't distinguish between multicast and unicast. ------------------------------------------------------------------------ ---------------------------------------- In order to distinguish between multicast and unicast LSPs with the same label value, the labels can be differentiated by the use of different Ethertypes that indicate whether the labeled packet that is carried in a layer 2 frame is for unicast or multicast transfer.=20 But if LSR does not support these procedures, it can't discern the labeled packet and must ignore it.=20 On the other hand, the process of layer 2 frame is complex. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 08 07:42:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIs5-000129-LA; Thu, 08 Jun 2006 07:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIs4-00011k-Ax for mpls@lists.ietf.org; Thu, 08 Jun 2006 07:40:16 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoIs2-00011E-Tx for mpls@lists.ietf.org; Thu, 08 Jun 2006 07:40:16 -0400 Received: from pc6 (1Cust52.tnt102.lnd4.gbr.da.uu.net [213.116.52.52]) by astro.systems.pipex.net (Postfix) with SMTP id B7D6EE0002C5; Thu, 8 Jun 2006 12:40:11 +0100 (BST) Message-ID: <02c801c68ae7$6a970b40$0601a8c0@pc6> From: "Tom Petch" To: , References: Subject: Re: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt Date: Thu, 8 Jun 2006 12:36:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Benjamin You asked about sparse augments. AUGMENTS in SMI [RFC2578] is an alternative to INDEX for a new table with conceptual rows in one-to-one correspondence with those in an existing, base, table. When a row in the base table exists, a row in the augmenting table exists. This is widely used in enterprise mibs, when, for example, a maker of large servers finds the columns in the standard TCP connection table inadequate and wishes to add information on a per connection basis. As [RFC2578] points out, this is appropriate when there is a one-to-one correspondence. When the new table is sparse compared to the existing one, then there should be a new table with the same INDEX clause. mplsP2mpTunnelTable falls into the latter category. Re-merge I cannot help you with, but should that reference be to draft-ietf-mpls-rsvp-te-p2mp-05.txt?. Tom Petch ----- Original Message ----- From: To: ; Cc: Sent: Friday, June 02, 2006 4:04 PM Subject: RE: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt Adrian, Adrian Farrel wrote: > Please review, comment, implement (!) and tell us what we have done > wrong. A couple of comments: Section 4.1, bullet 1 states "P2MP Tunnel table (mplsP2mpTunnelTable) that sparse augments the MPLS-TE Tunnel table". I'm not exactly sure what "sparse augments" means. Section 4.2, second paragraph - "When an MPLS-TE tunnel is a P2MP tunnel, certain objects in the mplsTunnelTable are have new meanings", remove the extraneous "are". Section 6, states "The nature of P2MP tunnels is such that an LSR that is crossed by a tunnel may either be the ingress of that tunnel or have precisely one upstream LSP segment (also known as in-segment [RFC3812]) for that LSP." and "A single P2MP cross-connect has zero or one in-segment." draft-ietf-mpls-rsvp-te section 18.1.1 states "There are two approaches to dealing with re-merge case. In the first, the node detecting the re-merge case, i.e., the re-merge node, allows the re-merge case to persist but data from all but one incoming interface is dropped at the re-merge node." and "When configured to allow a re-merge case to persist, the re-merge node receives data associated with the P2MP LSP on multiple incoming interfaces, but it may only send the data from one of these interfaces to its outgoing interfaces, i.e., the node MUST drop data from all but one incoming interface." So, if I understand correctly there is no way to detect a re-merge in a P2MP LSP using the MIB specified in draft-farrel-mpls-p2mp-te-mib? -- Ben Niven-Jenkins Network Architect, BT Exact E-mail: benjamin.niven-jenkins@bt.com Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 08 14:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOsy-0007Mm-UK; Thu, 08 Jun 2006 14:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoO2V-00076o-3w; Thu, 08 Jun 2006 13:11:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoO2U-0008Ee-Hu; Thu, 08 Jun 2006 13:11:23 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2006 10:11:21 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="291551427:sNHT39764616" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k58HBLmw025401; Thu, 8 Jun 2006 10:11:21 -0700 Received: from [10.32.9.110] ([10.32.9.110]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k58HBIcL004380; Thu, 8 Jun 2006 10:11:18 -0700 (PDT) Message-ID: <4488591C.8090105@cisco.com> Date: Thu, 08 Jun 2006 18:06:36 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.jones@itu.int, tsbsg15@itu.int Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=6944; t=1149786681; x=1150650681; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:Stewart=20Bryant=20 |Subject:Follow=20up=20to=20PWE3=20WG=20response=20to=20your=20liaison=20on=20T-M PLS=20of=20May=204=0A=20and=20April=202=202006; X=v=3Dcisco.com=3B=20h=3D+V6q3zDMUEba1uIizGKHNxEsQWM=3D; b=dpdLCgO63r1REHwYFNMSipOhSPn6xeMEDKdTBejvRR8BrxYwxDpuMCbinu8I+TLI1bPsZKP/ e+WXyy6vdTLoVcTPfKx8MumwSeae/wdWJpE/8d64+24VdF9XyaWJXiOe; Authentication-Results: sj-dkim-8.cisco.com; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 X-Mailman-Approved-At: Thu, 08 Jun 2006 14:05:35 -0400 Cc: mark.jones@sprint.com, maeda@ansl.ntt.co.jp, mpls@ietf.org, pwe3@ietf.org, statements@ietf.org, townsley@cisco.com, danny@arbor.net, jari.arkko@piuha.net, Ghani.Abbas@marconi.com, betts01@nortel.com Subject: [mpls] Follow up to PWE3 WG response to your liaison on T-MPLS of May 4 and April 2 2006 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org To: ITU-T Study Group 15 Greg Jones greg.jones@itu.int tsbsg15@itu.int Cc: IETF statements@ietf.org Stephen Trowbridge sjtrowbridge@lucent.com Ghani Abbas Ghani.Abbas@marconi.com Mark Jones mark.jones@sprint.com Malcolm Betts betts01@nortel.com Yoichi Maeda maeda@ansl.ntt.co.jp Scott Bradner Adrian Farrel Jari Arkko Mark Townsley Danny McPherson PWE3 mailing list George Swallow swallow@cisco.com Loa Andersson loa@pi.se MPLS mailing list From: IETF PWE3 Working Group Response contact: Stewart Bryant stbryant@cisco.com Technical contact: Stewart Bryant stbryant@cisco.com Purpose: Action Subject: Follow up to PWE3 WG response to your liaison on T-MPLS of May 4 and April 2 2006 The IETF PWE3 WG requests that it receives a copy of the formal response to the four issues raised by the IETF MPLS WG in their liaison response: https://datatracker.ietf.org/documents/LIAISON/file316.txt These issues were: 1. The requirements 2. The reserved labels 3. MPLS functionality equipment T-MPLS networks. 4. The IETF MPLS WG concern about what "future consideration for IP/MPLS clients" might entail. The IETF PWE3 WG additionally requests a formal response to the 13 issues that we raised in our liaison response: https://datatracker.ietf.org/documents/LIAISON/file323.txt For you convenience I append to this liaison the numerated list of issues raised by the IETF PWE3 WG. We would appreciate a response in time for us to discuss these matters at IETF66 which starts on 9th July 2006. Stewart Bryant IETF PWE3 Working Group Co-Chair ==================================== For your reference the enumerated list of IETF PWE3 WG issues is as follows: 1) G.8110.1 states: "The IETF PWE3 work group has developed an MPLS transport concept, know as pseudowires." Later G.8110.1 states: "The PSN can be implemented by utilizing a MPLS label switched network." PWE3 has developed methods of transporting services over many different PSNs, one of which is MPLS. 2) G.8110.1 states: "PWE3 is intended to provide only the minimum necessary functionality to emulate a wire with the required degree of faithfulness for the given service definition." The purpose behind the wording "provide only the minimum" was to prevent over engineering. In many cases, PWE3 provides more than just the minimum necessary functionality. We think that to put this quote from RFC3985 in it's proper context you should note that in our view an applicability statement MUST always be provided to clearly describe the extent of the emulation, and that in some cases more than one emulation method may be needed. 3) G.8110.1 states: "A four octet Control Word is added to the MPLS payload field for some encapsulations." The control word is DEFINED for all payload types. Use is optional for HDLC/PPP, Ethernet and some ATM modes, but is REQUIRED in all other cases. 4) G.8110.1 states: "these processes are called "Native Signal Processing (NSP)" NSP stands for Native Service Processing 5) G.8110.1 states: "The NSP function process the Control Word." The NSP does handle the flags (when there are flags defined). However the PW-layer processing handles the sequencing, FRG, etc. 6) G.8110.1 states: "IETF has defined pseudowire encapsulations for Ethernet, Frame Relay, ATM, PPP, PDH, and SDH." The PPP emulation also emulates HDLC, and the SDH design also supports SONET. We also have a design for Fibre- Channel and the IETF AVT WG has a design for header compressed voice samples. 7) G.8110.1 states: "The Forwarder function is called an Interworking Function (IWF)" It is not clear that IWF and forwarder are identical in scope and purpose. 8) G.8110.1 states: In Figure 9 Pseudowire Model G.8110.1 shows the PW as a trail with a T-MPLS trail termination function. This termination is defined here as injecting Y.1710 OAM. The IETF PWE3 specifications use VCCV as the PW OAM. 9) G.8110.1 states: "Pseudowires can be switched by a Subnetwork Connection (SNC). This creates in PWE3 terminology Multi-Segment Pseudowires (MS-PW) as defined in the bibliography reference [1]." Bibliography reference [1] is RFC 3985, which was published prior to our work on MS-PWs. The correct reference is reference [2]. 10) G.8110.1 states: "When the MPLS server layer is an SDH layer network, an SDH path layer may be used instead of the pseudowire PSN transport tunnel. This approach has been called "dry martini" as defined in the bibliography reference [2]." The correct reference is reference [3]. We must however caution you that this work has not been adopted as an IETF PWE3 working group item. The draft was an individual submission which has now expired under the IETF policy of expiring such drafts after six months. Within the scope material you state: "a T-MPLS network will not peer directly with an IP/MPLS network". The data plane behavior of the one currently supported adaptation ("EVC") is intended to be that of an Ethernet pseudowire as specified in Y.1415 and RFC4448. Thus it is possible for "IP/MPLS" and T-MPLS networks to interoperate at the level of the pseudowire, e.g. a multi-segment PW could span adjacent "IP/MPLS" and T-MPLS networks connected by an S-PE. 11) G.8110.1 states: "From an OAM perspective, pseudowires provide service-specific status and alarm management". However PW status signaling and VCCV are agnostic to the native service type. PWE3 members who are also SG13 experts make the following additional observations: 12) G.8110.1 states: "ITU SG 13 has developed a series of recommendations for MPLS / Client Network Interworking for Ethernet (Y.1415), ATM (Cell Mode - Y.1411), ATM (Frame Mode - Y.1412), and TDM (Y.1413). These recommendations are similar in concept to IETF PWE3." You omit X.84 (frame relay PW), which, although developed by SG17, it is now in SG13. These recommendations are are identical in concept, and to the best of the ability of those concerned are identical in detail. We note that in Figure 8 you pick the semi-formal diagram from Y.1415 when the same Recommendation has a G.805 diagram as well. We recommend that you show Figure 6-2 of Y.1415 in its place. 13) G.8110.1 states: "Pseudowires can be used as a packet transport mechanism for emulating LAN Services over a Transport MPLS network. Like in Virtual Private LAN Service (VPLS) a full mesh of T-MPLS trails (PW trails) is used to interconnect split-horizon ETH Flow Domains." We suggest that you reference Appendix I of Y.1415. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat Jun 10 05:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp07A-00073g-0e; Sat, 10 Jun 2006 05:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp078-00073Y-2W; Sat, 10 Jun 2006 05:50:42 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp076-0006FY-6P; Sat, 10 Jun 2006 05:50:42 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0N00H2G2P4U5@szxga02-in.huawei.com>; Sat, 10 Jun 2006 18:05:28 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0N00EZY2P3ZU@szxga02-in.huawei.com>; Sat, 10 Jun 2006 18:05:27 +0800 (CST) Received: from z52048 ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0N00I5M20P51@szxml03-in.huawei.com>; Sat, 10 Jun 2006 17:50:57 +0800 (CST) Date: Sat, 10 Jun 2006 17:49:37 +0800 From: Zheng Hewen Subject: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically To: mpls@ietf.org Message-id: <000001c68c73$32b72970$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ccamp@ops.ietf.org, l3vpn@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, The signaling solution for the construction of P2MP MPLS-TE LSPs defined in draft-ietf-mpls-rsvp-te-p2mp-05.txt assumes that the ingress node for any P2MP LSP knows the identities of all of the receivers. No mechanism in that document is provided by which it can discover the identities of those receivers. In multicast LDP (mLDP) defined in draft-ietf-mpls-ldp-p2mp-00.txt it is assumed that each receiver knows the identity of the source of the distribution tree, but no mechanism is provided whereby the receivers can discover that information. In order to successfully operate P2MP MPLS, and to consider extending MPLS to support MP2MP it is necessary to examine the requirements for exchanging and learning the identities of P2MP roots and leaves. One mechanism is desired to discover and distribute multicast membership information dynamically. Currently some work is in progress. For L3VPN applications, it is one choice to carry and distribute multicast membership information through auto-discovery mechanism based on extended BGP defined in the draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.txt. For P2MP MPLS-TE applications, one effort is to extend IGP-TE for such purpose using one analogous mechanism defined in draft-ietf-ccamp-te-node-cap-01.txt. For connection-oriented transport network basing on MPLS, one mechanism defined in RFC2022 may be referred. Extension to MSDP is another choice to satisfy those requirements directly if possible. It is desired to clear the requirements for that mechanism. Is there any interest for this? I want to do something about it and hope to receive advices. Best Regards, Heaven _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Jun 12 11:24:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpoFJ-0006nk-Js; Mon, 12 Jun 2006 11:22:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpoFI-0006j7-C5 for mpls@ietf.org; Mon, 12 Jun 2006 11:22:28 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpoFH-0002iu-2L for mpls@ietf.org; Mon, 12 Jun 2006 11:22:28 -0400 Received: from [193.10.152.75] (helo=[192.168.0.8]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FpoFD-0004zh-DK; Mon, 12 Jun 2006 17:22:26 +0200 Message-ID: <448D8644.2040307@pi.se> Date: Mon, 12 Jun 2006 17:20:36 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: mpls@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Working group, the author of draft-farrel-mpls-iana-rsvp-session-flags-00.txt has requested that it is made a MPLS WG document. Please send comments on this to the mailing list or the working group co-chairs before Jun 26. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Jun 12 11:44:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpoYr-0003Vn-LA; Mon, 12 Jun 2006 11:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpoYq-0003Vh-5b for mpls@ietf.org; Mon, 12 Jun 2006 11:42:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpoYo-0006KE-QY for mpls@ietf.org; Mon, 12 Jun 2006 11:42:40 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2006 08:42:38 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="293165317:sNHT32443260" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5CFgcg3013224; Mon, 12 Jun 2006 08:42:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5CFgacR020358; Mon, 12 Jun 2006 08:42:38 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 11:42:37 -0400 Received: from [161.44.71.253] ([161.44.71.253]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 11:42:36 -0400 In-Reply-To: <448D8644.2040307@pi.se> References: <448D8644.2040307@pi.se> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <000B7A9E-2671-43F2-A3CC-6A876CD64BEE@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc Date: Mon, 12 Jun 2006 11:42:35 -0400 To: Loa Andersson X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 12 Jun 2006 15:42:36.0818 (UTC) FILETIME=[D4524F20:01C68E36] DKIM-Signature: a=rsa-sha1; q=dns; l=1054; t=1150126958; x=1150990958; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Re=3A=20[mpls]=20draft-farrel-mpls-iana-rsvp-session-flags-00.txt=20to=2 0become=20a=20mpls=20wg=20doc; X=v=3Dcisco.com=3B=20h=3DiJIvQpvrwP6kZ89HKd3laGEKaJQ=3D; b=jJ3AdW8BGI75Mbi1AShxH4ASe3G8Ahpg/RaVXvLor9AwoAE9VhxjzJoV97DNCgR4zQUbi3mY z8OdzTWHF7FIKm2beb4qXAO6JkXH1qcR6kEx+701rWqwxbzfipuNA3v4; Authentication-Results: sj-dkim-5.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org strongly in favor - Creating such registry is more than desirable. Everyone having worked on ID defining new Session Attribute flag would understand why ;-) I recently tried to write the shortest ID, but Adrian you raised the bar pretty high. Thanks. JP. On Jun 12, 2006, at 11:20 AM, Loa Andersson wrote: > Working group, > > the author of draft-farrel-mpls-iana-rsvp-session-flags-00.txt > has requested that it is made a MPLS WG document. > > Please send comments on this to the mailing list or the working > group co-chairs before Jun 26. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Jun 12 11:57:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpolo-0002T8-Gt; Mon, 12 Jun 2006 11:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpolm-0002T3-Oo for mpls@ietf.org; Mon, 12 Jun 2006 11:56:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpoll-0007Pr-EG for mpls@ietf.org; Mon, 12 Jun 2006 11:56:02 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 08:56:00 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="1824019644:sNHT167235500" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5CFu0S1022220; Mon, 12 Jun 2006 08:56:00 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5CFtxcN028724; Mon, 12 Jun 2006 08:56:00 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 11:56:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc Date: Mon, 12 Jun 2006 11:55:58 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc Thread-Index: AcaONBUyoCQPJ/JKQUyc7RkrKt22xwABJL6A From: "Zafar Ali \(zali\)" To: "Loa Andersson" , X-OriginalArrivalTime: 12 Jun 2006 15:56:00.0040 (UTC) FILETIME=[B3144280:01C68E38] DKIM-Signature: a=rsa-sha1; q=dns; l=1046; t=1150127760; x=1150991760; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20[mpls]=20draft-farrel-mpls-iana-rsvp-session-flags-00.txt=20to=2 0become=20a=20mpls=20wg=20doc; X=v=3Dcisco.com=3B=20h=3DNnqFtcydKyatl6142DoBWY7KEWY=3D; b=3kEYtwRiQoEknhC7OqNu9P1jOEMynIPJ2sqoQ4yCeayPD2UYVWPRC+XpOKR0qQ5/0oCinGvo ebAOdx0hrX72cOvvSjQXiNHWR8OWumbRDgvkaxm3Wv/ow5kiYRjEya/j; Authentication-Results: sj-dkim-5.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org In Favor,=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se]=20 > Sent: Monday, June 12, 2006 11:21 AM > To: mpls@ietf.org > Subject: [mpls]=20 > draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a=20 > mpls wg doc >=20 > Working group, >=20 > the author of draft-farrel-mpls-iana-rsvp-session-flags-00.txt > has requested that it is made a MPLS WG document. >=20 > Please send comments on this to the mailing list or the=20 > working group co-chairs before Jun 26. >=20 > Loa and George >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From xukjpeovmd@pmdcorp.com Mon Jun 12 12:52:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FppeH-0004cH-7g for mpls-archive@lists.ietf.org; Mon, 12 Jun 2006 12:52:21 -0400 Received: from host-62-141-213-66.swidnica.mm.pl ([62.141.213.66] helo=rex-dd06ac6b801) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FppeF-0003VV-D9 for mpls-archive@lists.ietf.org; Mon, 12 Jun 2006 12:52:21 -0400 Message-ID: <000901c68e40$a5c57470$42d58d3e@rexdd06ac6b801> From: "Sears Reba" To: mpls-archive@lists.ietf.org Subject: emplli Date: Mon, 12 Jun 2006 18:52:53 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C68E51.694E4470" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 ------=_NextPart_000_0005_01C68E51.694E4470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C68E51.694E4470" ------=_NextPart_001_0006_01C68E51.694E4470 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0006_01C68E51.694E4470 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
------=_NextPart_001_0006_01C68E51.694E4470-- ------=_NextPart_000_0005_01C68E51.694E4470 Content-Type: image/gif; name="edvwokidrRosario.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c68e40$a5c57470$42d58d3e@rexdd06ac6b801> R0lGODdh6AFaAocAAP////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////wgA AP///////////////z8os/////////////////////////8AAPD08Ke9p02MTQCAAJq1muHn 4enu6WiYaIysjLLFsgAA/////////0AAgNDb0HyifP///////9nh2f///////9nZ2YyMjOHh 4eZKOP///////5qammhoaP///////8fUx+np6b29vf////////Dw8P///////7Kysqenp/// /////01NTdDQ0P///////8fHx////////8G9zYV8onRomLeyxf///////19NjPHw9P////// /6ynvePh5////////////////////////3x8fP///////+rp7tvZ4f/////////////////p 6f9oaP+MjP+ysv////////98fP+np//////////////////w8P9NTf+amv////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////5SMrP////////////////////////////////// ///////Z2f/////////Q0P///////////////////////9PQ2//h4f///////8rH1P////// /6Gatf///////////////6wqQ////////73Nvf/////////////////////////////////H x/////////////////////////////////////////////////////////////////////// /////////////////////////////////ywAAAAA6AFaAgcI/gABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1K1aSeqlizat0609CSnXbucB07dcnXgWYH6rGzxI4e sQLTFpQ7ENeSPQL3LMElZwncQksKCbyzRI7AtW3fEkTsFq5Zs3HgIJS7xBDar48zn9W8+bEc yXEFCwR8OTOAzJETyokT92xrAHbxAtDL1+/owIMLn3ZN0PPV1wC8UhMYBxfZ40/p7iau2c5l g8pn7xUYe05lgdbnCPSqPU7zgd4z/jvfjfog5fHLOVPW3DrzVcDaseMm/5g+5INeowF/TZv6 XeuWAZDddktoF117Zhm3HAByoBfNdchFmJRyacGxRBxi3eHdbwceaNcdhBmnF2h9GQaAhXtY iCEAGi5xlYoZbrigId6B1ltnwy24347A6fWVXiYyeBePctG4hI0DWScbhWd9GKJ0JOp24pAH LufjawAOpNdvEnZJlHpfeScbAICZ2CFvebmox5AA2CHiY3jh4pyYA5UJAJ23GUYXkNB1dh2T c5nWY1vBmYWXjwGypyOfBdlVmqJbrimbm9IZCtt4VaYFWGeA5YgWa16GGhSYOgJ35kF2TXfY V2u2etpV/9GlFStmvJ26GzXOAXpjfQiaJZmFclylR1+gKarrjY8KCluCarHqoouv8tgrhxey +Zyo2PYE6KzSVunjmM0EZkc2DNoBWDOlpoemrLWiuWBadlBzbLeZ6TflHM7ZYV2x67bb57X7 fTtQuIXYYViD50pLnlulGRxothDrBGhfY3oFqq3/9iavfg/KKxDFA1ksZMUX6hiugsgu59W8 6S7XsUDyArZmp0S6dnLGpbK8xMYAdOxapu76+mB8Ckds9EuAWrfiHjXSOxmaqV6moNJiMX2k gBdW3bRczbCF7sMLyutvyinbZZmjJZ6mILcAdL3E1wSxBXDOUNPFrMK2xjb30f58u6QrW+X1 yq6i6T7I5Zr2tqkZqIoHzpmnKdMl996cAXeHHXN+NWDJ9tGaGeR1/Tw2j4Y3m7hccTBu6+Xo qdr36yzpegdin+1qmnp7EyYambYNRjuSs7NVO4K4wA02XV6RLfh+wmmK23q3P1Y8QkruyLLu dfa+YOp76yicdETDLv74WQGWOE4PBkj++uxDJQfKOPHV/vz0K6XXThDWr//+QCF5U/j8C6AA B0jAAhrwgAhMoAIXyMAGOvCBEIygBCdIwQpa8IIYzKAGN8jBDnrwgyAMoQhHSL8emPCEADDh QFSowkU0ogeMWERBXAhDGZ4QhQAYBiNgaIyB0BAT5f5IYQ8EYoweSIIgLXxhDA1ywyG+0BkA cEYPXthEIZowEzK0ogpTmEUALGKIAqniFgfyRIFIsRFIBKMQU9jDMA7xhJiQxCVWeEMtYhEA O5zjJWA4EEf0wBF0LMgYtyhGE8ZxjiT00iDVyMIh7hAAkUAjQR4ZyUAK5IuZAEAmejAMAFwC E4yYYyZV+MlICNKRQ6zkKQmyRzS+EJGLzCEf1zgQKR5RIJLoARRp6caCtFIgr0xjIE2YxUZ6 MhKYKKYa1zgMPvqxh0UEpEAi0QNT9lKY1xzjGi+BzC4mEjmx7KUxD6LNa2qyBzL8Ihpz2cZe UtObaywnNgeSyxTekpeEBP+jNqXISF2ak5f01KUtVynOHmCioAJpZiYBmk8vGhEAucziHk0I y2XiU5/L3KJCvymhcMbTidVEJEFeGAmR8hIT/QQASk/pxyCukqQmtSRBUHpQmaqwmZLUZjlM GMSd9sCl2pSnShnBiJrOs5GZMOU4aRnUIeJUIETFIyMGUsQXtrGc4WyqTDlKlkUW0ovUTOYM w9pFjy7VjSaUpjAXQVYm4lAgflTrRU0oSS2uMBJTZQQ16dhQclrUnMaM41LzSdgp9lGXfxzI Jou4UKym1K4X5So4H/vRgE7VILm8bGTDeFDHRmKTnZxnZt1qEJoe1Yma1SY7jdiDIt5Sq36N LUL+mznYy2q1EZpVJzoHslKD/nOzsE2hZiXLFbO+MaN/BawaNylDKWYStNgsqkmDu9UwvvC0 UaQsAK5rWsMyNLkAtelxBbLJ8QLAtf9UoRQnOUtZ3rCTjrUkbNFL3LEYd42OOKJ3+6jfuo5x o5uEohRNuYhRgnERmLBmL/ObwrpudY+mpGZFLRlMbe41l/q1JnXnSZBNAlW/auztEBch3fSC MZgAiOthoZnYcno4jK9FrhdLXN/iUtaYJO7BHQmS4x0D1Bg7ZERozxvkII6RvmvsMTy1CFIB ezecZ2Rykndb2OPWsbr0RGlq1dhMKzJCjnwdZ5Qd2sU8epKPTQSjJLT+nEYUnvDLMa2xnOdM 5zrb+c54zrOe98znPvv5z4AOtKAHTehCG/rQiE60ohfN6EY7+tGQjrSkJ03pSlv60pjmYAxi MJBNb6QMMSjDQaiQhowIQhAHOfVEvECFGKShDR9RtUVIbRBZg4TWBfF0poOiawD0GiOCiAGq DfJriJRBCwOxNUGU7RAxpEELYgBAFmI97IgcWyDFBgCzO5LtbO96J7329kTEsOkYRDvXnJ6I uDFihhio4Sa6XndIup3ub/sk3JyON6eroIUYaGHaAChDGmKQBS8YRA0xaPW7BdLufsfAC57e tMEFTnCDb9oMyC53vj3dhoFTwdcRz8LABWH/cH77G+ADGbhB+p2GhcegDcKuQhpaDvJ+U8Hg AGD5u8sNAJP/29ciFzbOO83zTbdaC1UAOac7nvCC9LvnMUi6vwVC8YJTfeBW9/QUYmAGbNfb 3jzReNHT7emBk7vUoPYCxJFdkCy4m+AMfznIcx6DL0w97WsHeRWm4HWiz93vEs+72V2N7oPk HeQQNzfhtQ53gRy+7IovdeCnXnjEP37jBwF1FVpNhSqEOuAPzzvep172rvcd7D3B998hf3al 87wgKif86jndbrt3XeyY93vfOY/ziJOd04MvNUGKbXJ9z933fS/+7wEQ/NkTe/nO531BIO72 Tbvd4mJ3ve9FPvyv/qM+J6o3PsxdvfN0n5sgW9c4342f/his3/ynj7+uG9538W+a5gRxO99T rvjlI9/4g7d840dzxld5BTh/lEcQDmd3lKdr5+aAXud2X/B9vFZvkOcFnsdpwUYQ7dYGECdq BAFq74ZwotZqsKZrAyd8HfiBfxd3uud8xreBB+F5qOYF0yZxmxZt/4d5MHeDD5eDcyeDp5dt 7TaE0NeCAwFqH9dqILiCn+eEouZpbndu20aBNaF6aoB1Wjdw/vZuZjBwWjB0AtFv0UZuyMZq /oaApgcAX+hv2FcQrbZ75Fd/yzcFXKgFCzcQatBvWgBr/JYF7fZ+x7dxHicQfxiIc2eH/5uG hwUIh7lnfK2GfwQBcUnneUPXhmHIcGD4hp73cdpWbVZoFGZwc4lXFKOodvIWEanIgaS4iqGI QF8QbAm3f0MRi0ZHixjhigJhi7P4ir74i8AYjMI4jMRYjMZ4jMiYjMq4jMzYjM74jNAYjdI4 jdRYjdZ4jdiYjar4eurGEdn3ErpIbB/BjeRYbN6njThhgRRxjg3Bjr6mEu7ojg4hjxWhjvbY afiIjmGXjxJBjwkRj/CIEP64EANpEfmGj+r4jvq4j9jWkPpmgeHWkF6XkO+oceKIbvb4e19X jhC5ceb4euSIhMMnkQppkURXkBWJkCq5kGFXjvzofWSnkDIZk/8SGY8gmY8RWZP86JC5JpAv GX8HQZMliZM76ZMzeZQmyZLwRpQniW9HeJRQCZAjqZNNKZTdZ5VSGZUESZJCqZGpSJEHyZMk qZQ0kZAbeZExCZZcOZZT+ZMy+ZZsOZRrGZRu6Y9dOZcoeZZimZJxSZYwYZZtSZOCiZdMeZF1 GZiE+ZZWiZhU2ZONeZdRCZOOyZeUiZJ+eRJJCZO/dpM1uZkuOZknWZTcqHRXSZovuJMhGZSe GW8vuZkY+ZChOZGXuWuWOZu+WJu2eW+4t5u82Zu++ZvAGZzCOZzEWZzGeZy9mZvKuZzM2ZzO +ZzQGZ3SOZ3UWZ3WeZ3YmZ3auZ3c2Z3/3vmd4Bme4jme5Fme5nme6Jme6rme7Nme7vme8Bmf 8jmf9Fmf9nmf+Jmf+rmf+2MD/PmfABqgAjqgBFqgBnqg+UkERhAEQNAFKREEEFoEP4AQTdAE CPo6PgAEReADACAEIXEERWAQEAoA3BAERnAQFXqhffMDQcAEJDGiBQGjMKqi6wMEQRCjNwoA IwqhPxCiPBqiAHAENioERKCjQmCjTVCkEDqjAiGjN/qjOgqjPwAEQAAFAiGkQUCkApGiNKoV TBqlTfqkQTAEVgqhZBqkQUAERBAEPpqmawqkXwqmXRAEE2qmVgqmLNoFROChR+CmbLqlFtql WfGlTgqmYToQ/0u6pIZaqDjKoBNqqIfKpIkap4JaFUIQBHd6qGA6o5yaoxy6qDkap4Sao5FK qob6qZW6FUMQBBa6pwBgo0SwqmKKqKSap2t6BKAqECwqoqYKqWB6qQ6Kq7YaBLgKAFyaqlTB BEXApg7KBEO6o6TKpFPKpkoaqqS6oDiarbQqEJcKBNygqzZaBEVqrIGKrOZ6ruiaruq6ruza ru76rvAar/I6r/Rar/Z6r/iar/qqrwpKrQBgBECgEZPaqxaxpBJKoeX6EAO7ryOxrMZ6opS6 ECCKEBFbESNaoidqEMcaERU7ERPLsNqqqRARsR07EYy6ESXLsQTLsAvaBJ8KoQtaBP9DoKsQ 6qFR2qNRSqlMiqVaCqU6OqdNMARU6qIEUahQqqgAMKVVeqVDOq4hCwDLCgQuCqVDsKxFYLM8 W60wurH5SgRNwKDVqqZ/yqJQsKoeaqciG7J9KrZteqZRuqZB4AMMmq1zWqdjeqcjaqt86qdA +rQA8KZReqY2KrcBu7aAC6lcq68s2qal2rjbehCdmqi+Cq2+mrNA8KiSOqu0Krm8OhBVq6gz Orhzu7CVC7LbarTWOrkrC6kw+rKmSrmj+rSU+7ioGrKiq7kAMKcMOrWe+rime6V1CrGpy6Jk Sqe+uquQW6tBoKfEqrqb2quxu63AGqRJu7y3mry0CrdyS6r/X0sQw1qsyEuuIEsEy9qzqduh PJq2/7qy0hqu1Vq0sxq9vmuo3fqtSeu+2CsQVSsEZDujUGCjbOqi0yquA4Gt4vu77PMDRiC2 q4vA/MMNX2uimerAFFzBFnzBGJzBGrzBHNzBHvzBIBzCIjzCJBxpGmd1OoFrC1GFEIGGmSgS JyyvjMd24OeO1yYQLPwQTycInnjD3LZvTQevjZiONumNmjmOT9mujNfDWIdzX5gG+9dujedr MCcIMod/LxdzM7dwVWdxQUdycedwYziHFvl6UgxwBDdyOMdsrSYIDzh2GBd3jZfGQtdzfIhy fbd1Gbd8rVaJQUyjGtfDoTd1Kzht/4HoeWj8g5HndYnXeqO3x6iIbB3Ygpfnd4cMd5PHdszm BcGWBr33e3vHhu6HyJY3dc13lZtWfn0HcUvoboLqaVTAdriHhAeIeca3g2Xsf8unfPL3iL68 EPTnfEbofKfsd1uHagVYewkIyEA8gRBIy9C3g3Q4iALxxtM8dwHYyzCYxKo5zMNsf3PYfdfs gFyYh8wsEK0mBlAobXInau22d1w3zbeMeesMiXLne40sypYcdVt3e9DHbGVwe55YhC34zv3s fEJYeMfMfA+XgQMBc8L3yunWiWy4iQLhdmkwgewcz/Ksy3+HiW84dy7saYfofugMfdVnegW4 yf2GwgAQh/+/ltLDrIhdiMoAl4UE12uep9EljBWnWIr9CIQ9jRW8SAW4+BDCdtRDvdRM3dRO /dRQHdVSPdVUXdVWfdVYndVaPWgdGZum2c19GdRwyRJZaZSmO8t7GZZjPZS4adaLqYr92Jag SZdwTdepeo5qndd0HY5bOdd1DREFaZdxbdevDJd6rZaAp5oRCZva55F4PZogyZFNOZG+TJGx mZRf7dgf6ZQIqdltzZ6smdZFudaReZiNOZmQqZdyudqGzZaS+ZjyZ9alTZWfDdpI2dkh2W2F qZWnzZiAWZWJyZWhLde/zdpl/Y16+db5edhuqXuvbdyFqdy8Dd2oPZaDudaIXdz/pK3aqNnb 9nmPom3drD3d0y3dxY2V0S3ecimV563ehkne162fki2bdk1vOenVYPnYqynO9A2Vq4ffpTmX mV15BJ6atG2vtT2PW31vMLzgDv7gEB7hEj7hFF7hFn7hGJ7hGr7hHN7hHv7hIB7iIj7iJF7i Jn7i+mgFKL7iLN7iLv7iMB7jMj7jNF7jNn7jOJ7jOr4USNDjSCAQPt7jA+HjQB7kQE4QPx7k RI7kTD7kQl7kSl4QPz7kABDlU17lVA7lEnHlHMHlWY7lXw7mVS7kSv7kTv7kUR7mRo4QXr7k Zd7mTa7lRz7nYo56V57kBnHndV7kas7mca7ncS7leg7n/3Q+5V4OEYeeEYkO6HQO5ovu50ee 6HXO6FL+54GO5IwO6JluhYNe6Z6O6X1+EFxu6J++505O5YeO53je6BEh6ReR6li+6pPO6rRe 6KYe66HO5KQO6Xmu6Z6u6rf+bZ1+6aa+6qPO645e6pJu7MWO65Re6Whu5ncu7dQ+7aO+5LqO 642+66Vu6Y9O6bDO7Xnu57tO6MDu6pm25ure69Ke7GGO6ese6Mue7Gvu7JO+6Jvu7nsu67Yu 5uGu7bPO58QO5YaO7QB/7NBe6wrP7Pse6QD/feXe7c3+8POe5YS+8A7/7/xO69fu5gRv7dse 780O7Nuu7JAu7v2O8F++8QNP7/+sTuokT4ERT+ywTvHIjvIq/+sPn/ETL+/jPvH5bulNzvA5 H/A/j/Jj7vHvbuUJUfEMb/H2zumo/vM77+9Fn+vPXvFjfuvPzvFCz+0zP+e+/vIrX/I+L+pT /+lgT/Vr/+4rH/T+/oodj+1uLvJGb/JnTvUmn+Zxn/d6n/RDb+aAb/CEb/B9b/XVLvEhL/IF L/hlL+dub/aQ3+87XvkX+uaYn/mav/mc3/me//mgH/qiP/qkX/qmf/qlb/mqv/qs3/qu//qw H/uyP/u0X/v/aeDap96YrZiobJfmWI+jPY+/rxDz/dVhTdjyKN0bgdcuofzdmIvifcTBPdkC 3tfHr+D/4Lfbj53e3R389S3Xf/3Z+U38K1mZ3i/byX/9GcH8sg0S5v38F4Hetz39iWmZ972O 2f/e23/aadn91t+TABEDwECCBQ0WFJgQgMCDDR0yVOjQYMSFFQdClPgQoUSMGT1+tLhRI0iS IzmWFInyIMOQISkqfLmSIEaWIGOwrKlypk6ePHNeTLmzY02aO416/Ak06UeYLm8CPToxaMaY OFuSJDrzKVSKC61y3XoxrNexYLfeDItWaEK0Y9VqfXpWbtqyMskSrSsV6t6qFb+mLFoyIs6z R9n+7ZmYqdiOjK0OFRkT7tK9UilT9XvVYmOEOS8bfbw278O2jSFvdikU9OrK/lxZ8xXL2jTs q5wR2/16W+9dtxubtk7tVeVg2H/rflacPGvLn4Gz5p5qEvDEuMcz4z3dcDnm4qpbvw06G/X4 puKhAzff+e3yoW1pE7bt/mRw5LQrP8+MHnxXuLg3yy/vu+QGnM+1qFyzjbf7bNJOPsGUMjA0 6T7bri/gJnyvu+vG41C8yF7TjD0DpyNvQQbpwyqq7TbUrTnNuCPOsvyYI7BGuzgMUasMRwzR xRHrI7HE2Har0DMiU9MNQxSdUi3GDu17LUEeTztPSCn/8+/HCxFbMTgt9QKSSRR/ey9MG5mi q7r1ItsPNLVKO5Axw4abU844ydqtNgDT7C9Fw3rz/jJQ8PCcLEsxCaWxQ7fWtFO4RnP0ss0b VzTSxBbv1A4wQP+r8ExPP+3JTFBv1EnUUR88NVVVMwXV1FVV7fJVWWt0NdVaX5y11Fx39fTW xXgFts5ghyW2WGOPRTZZZZdltllnn4U2WmmnpbZaa6/FNlttt+W2W2+/BTdcccclt1xzz0U3 XXXXZbddd9+FN15556W3XnvvxTdfffflt19//wU4YIEHJrhggw9GOGGFF2a4YYcf9jO6UCnj TGJSL5y14olxNNZXn9z11eN7fVQOKYw1jo7iVVHGlVWOPzVTZDrbJflXiDGduUCTdbb5VApR tdhGmSGueWd1By1UKYgK/mvUwTaPm6u5N5eu7q6mqXMs66vVHLTrqe10GmoAHcurNPj6C/ux 9fZDGtGn+XyU7cvkhg+7Oh1ENG+8rY577Su/JXnpOSWsUvBJt1ztvKQ0Tu9uxXfk+MrAI0SP xxlNxFLL2yrNnPAoW2a1cMgbfzJQzD2kHNy2qxzzSzhxZf3uJT1j+sMpx5aN7NFrV/BIK7M8 O1HdE5UQ0uHxe/n1+hgtXfQl1au9ZucJZRlbxkGELrvrXUZZ8bQsrfx543/3ncqgZ7ecfONS tp1Tk6QXUuKfm//8+e2DVLH+2YbuOHwcs3cdiEi0uMQZKn76G6DtSGc+4U2OfAqc0unAB6Gd /rEuRtPLHAQDuEH6fSk8CDwU4MS2uU3VrU8tk9RKGIU7R7kNTH86oYicgh3T0OWEQbog8NC2 qBi2j2q0s5uA+LIoqskvevbx2hH7RsMG3TBt5wsX/4gVq5u9iorAkiK3svisLQZrb1XMWNu8 iK8ugtGMZ0RjGtW4Rja20Y1vhGMc5ThHOtbRjnfEYx71uEc+9tGPfwRkIAU5SEIW0pCHRGQi FblIRjbSkY9c2K1ElSSgdWZUTpMOz0C3MoyFCnEXqySyysi+TXJkKdXz1hUthkr8gTJPnSRQ 7AT4ShRyEnYfexEBcVksVQrNgKF8obl6CctSskiTtByl8LiTyVrC/8poKElms4Z5ScXMjZjb 2hPc9sa1R0HoJVGLod9gcpjJENFl1PtaNuP0Q625kGvmLNRc2ilGq8WlT19r2uqKqML1+WWc +QTn5YCoNrCFs2p8Q2jWHifMVrIMdTLiz/9A2MLcle6Dkule+Czopoo6r1KdKh+SajM6majM dYSRXQSTx1EN5WehM3LgAccFUuqN5IoBuicpLVpQ8nwRPy/lqQ/vw0IrsbCG8Vld7rLTQUid 8nDKVB720rdRBG2weDFd6kwT+DLL+SiHEg3pBBmIoX2CdXtU/aBM0QfW91U1UiT1HTKlus65 Xg5yretgbsqW0mhOcasO9R8SUwdXLqXuof54bZ9aSSe+sTZuqZeinJQWSCoHotV+p9MlW52z o+Jxr6LC9BDbJkXOuAavhSl86AqHuDhJGdW0H4Xh1T6bxKPqqJtJWx9qv1c5etIWc7I9VJIw qR4cqtYs0mstJJ2JM+VWk5m2vGZzsUhP6SbGpLv6YnW1u13udte73wVveMU7XvKW17znRW96 1bte9rbXve+Fb3zlO1/61te+98VvfvW7XKf2LLo++y81Y2kq6sYyT5tjrnUVLDSzFZOL7AIs 6IoGRQPfErrO1RWsuoTgAEPTwwn2JIih1VdRRuyc/m3VM6PlqmhKpkkijeiAYnZhEkcSn+7h pgstybcnKo03Qf5U6D57TJ3Xug1uACVyWdnySr3C05+hKylMN8RPguqNecHD8Wvl1jO89dbJ DZ5nmv4mzyQT9639c6taV8pYlj5wsZplMks9p7kC6ZU0KW2eSTFJJpyWr58enavowgRSyObV g1aNcltFCqVhAXCwQZ1o72T4wwXy7nXhIepXoRdh8UH5pMzzNGr4POWwEnaWMmTqM5tsnbBq L6ePTp+pycRL2ex20ob6m1j9x8BhFtqlgb3TnysYaVjuj4LEuZ/kTH1guBaT0MvkK6LfGtOt itqujS5gMGGdaqq6eq3KDnWCvF3Y0hJzsp3WtovV/dRnc1Cy9Yu1BE13WTcPFqWUZf93AWPs xRVeuchCHZKO7U3E2gZcn0DmnGnRmVmBExl67Wz4aEN75od/h+BJs/JqB7fbcxpnNEnsKMgF lSkxepymDxZxI2scYofVauXUym51X57hlu9yvzfHec51vnOe99znPwd60IU+dKIX3ehHR3rS lb50pjfd6U+HetSlPi25nAjDfqVlh2muYlz2l+sz1zYWaUVgJymMkic2MdhB6fUUKwnD/bVm 1rXe9efCrMI5Y6XAzk4rCl+Y62e6Lt+tjnZoC/iYzmKxKwEmTnUqLaAJ5bHIHW7kLpdtbVrL 7pIp30Mk4ZPyp7xxOv12oIAOeclgXqLmxXlDg4qm9a/H7ff+CM401BcYZPC2M50Di0ELNzbf vD+td6KtUuA7Ws1nravh6t1pcJNezt4RdJ3b/Nc0kxH3mW4p/I5bNONS+vfwVhH27T3BnWYI qDVN91BBTSWjapw5Pt30grIqaUVz9dvxltf0tN/kjs+y1dv+K47TvnLjtmbjK1vTIICLlVsz Hl6DIl/TtGDzrHhbqMOaF/0LNOHrv0PTIN8LKWqTN2kzK/AzPwOav8XqNnczrFaKNE1DHaw6 mY76rXpBLTMjHjexPCQSGzPTnr2KkCu7mNFzojBzv3njMcyzrYgLrX8bOCaaoSQ8OBtMOCci swPjuHKDDNuromlCvL7TFi6cOtX/0cIRG0MtKsMwRMM0VMM1ZMM2dMM3hMM4lMM5pMM6tMM7 xMM81MM95MM+9MM/BMRHYrsPo7W0GqlOsicHCzhxITtZGY3DkzvBm6NBhDa1wxrnEyILsz/C K5ljmSS748S/UzxJHLw8skSNQLBRmzW6MjFSxDpgkrG6u7u2a0W9k73VezxcZCeIMyjW0rMo 64uIAjNKk5oqPL1LWz1T8kWEq0H38bHYI6jaezzMu8Udq7wju0aMQyi64cV/yT0pK793o6AG ZLRVmidS6zPqWzP6OL+8Y0WmejPlwyGD66oYLJNwWzZ4zEd3zJeNeiksE6pCs8DeKsFgzCUZ JEfic7/l/2E1fbQf3pnHG3xCTZQlFaS/7SOs9lPEkQk0BFxB/fHB8rM/Y/u1zfq/dUzBB5qP ypooB5zAEVTJiIQ7YkM3QCu1gfFHXHs0klQ0yJrJcbyqd3RJmezA2/klerPJ+RMsiRwrAvxJ h7RJqPS/xbvCXVzCezOPkhPABvE6IARKoYS+3avKH7GhLRkhKfQts7BH4Iof0bJCSrpKLfuy P8HG2CIaL8yZjTyYGUMxnFSumBuwR6w5Qiw8gjnFQETMxFTMxWTMxnTMx4TMyJTMyaTMyrTM y8TMzNTMzeTMzuSuRNyiw/RMhqnIThzNRJqwWDxNRBpGslnGupzIJzvD1TSjCv/UKCFaN0cR Tdq0F9tsqoWkoVzjTTjyTa9aQV/Ty+G8y480TvW5q7lTzobJrakiy6w0uejEzuzUzu3kzu70 zu8Ez/AUz/Ekz/I0z/NEz/RUz/Vkz/Z0z/csGCQoCPk8E/ocCPsEACTQz/k0CPzEz/y0zwCd z/3sTwK9T/38z/tUUIKQTwR10Ac9UAPNTwZlUAeN0ARdUP+c0AGl0Aw9CAtd0A3F0EDUUJ4Y 0RLd0BT9zxWlUAENURd90YZIUPo0UBSd0Q5VURzFUQylUf7MURjt0f7s0CBNUcVsUB1FiRP1 URYt0iadUAE9Uhj10CX10SGVUimN0SfVUidF0SyNUSj/3VIuHdImHVE/PNILHVAgBVAJDVER FVIy/dAfDVMmpdMq9VAizdE3ddMobdM2ZdIiBVMF5dM+zdMzHVPENFQXVdRD/VAIhdNH1VMt TdQ3rVMk7VE8DVAErdAalVQ09VM9fdAu5VMsLdQbdVI+XNQpdVNVjVQ8XVUk/dRBfdRK7dMg NdQ8pVJB3VJTrVUdFdVOJVQQDVNC/UNHTdVXdVVf7VVItdNRtdRl7dJVvVVStVVdHdZPrdJf bdE5jVMh/VNEZVQiFVdiBdQdfdZuNddsVVcvDVcbRddJtdZ1lddynddxpdRcBURF1dRNTdNM RVdAlVAQFVZInVE2XdN+lVFs/31RgeXQLxXYfQXVZo3YcH1XRoXPgynTWcnYix2YjX0Vj83D UBXZkSXZkjXZk0XZlFXZlWXZlnXZl4XZk+XYmaXZmrXZm8XZnNXZneXZnvXZnwXaoBXaoSU6 VeLHBcPLtuuiqiPM+itFwUihMbq6z7KW5cm/oDlalsOZvuI0mks8o5kf6ES3lNs6j2lOfrRE LtxNqUVEsQWmwDM8WbSZrz2JVYxEQkSOMgJDSOQcUaSxxdMU4ws+taRCVsumInsnIKsnIdsy fnJNY9RNIfQNgQInbCy5tbgnr1S9I6NGJ0NLpj3GRFQ/hYM9biyzhLq8J1uX1mTOaWtJnWwg emzL5/9sPthlx8GpW3CESZH8R3nbysADPhB6rN3DRGHhwNidnbXNGAU8zl+zSOYtJ127SEVB KsubOJUaSXTMwOMdrgGs3q5dNV/kLIVkNuJ13HkjNNxR3uUV3rD8jahsTrbKH8VCyF7yNjYr R5NMSd49ynb7pPLdxNmNSWFkQfTl3mqbynNBtR58sXPzyeST3qTE3rMVltqdQg5ySFJCKwvG twM2tMhhOLgcXwPGM6VElyJZYPyRPMizKNhsworTMtZ7tfcjITV5qtjUTc4bnyI8LVBbuDuL lI/LReHblEvMmyXiwWC7ygTml/WdQyd2IyiOQykm2iq24ivG4izW4i3m4i7/9uIvBuMwFuMx JuMyfjq93Tq8pGJXBLytVE3hKrvl6sswmtqA4cunneNBY8Skfa7z2xiuKk1a7GCxM029a9rC tKI9BrxhkxlkY6aVg1tsu5nGxeFktDLrFQ12ysUrLN1LcyfSOl2AYtyq4b/zBczA4ErMlZFr +7HtIyBjhE21OajPQxNmLL1qHMZdZOFyuWAHrrbKCspw3LVgGrcJiz7cnNyvtKllesRvVKDr Gkoo1MC12l0LLOFmU76hdLF0CU6MHJ+oGmYa6V1IM0teI6ojZsc3oUvw8T5T1pl9q0jBVcf7 mV5qFkeR1Klzg0lX2zutuk25AsubVLIRNubWLV+W/5y8AzLJZdbEcbzJcrJbgjZfp7wrfUY7 +N3eYl5jALPniiZBNovfppRoAUa1a6bgbHvggww7PGPozIrmEPzgar7HUtNnceTnd1nhssq4 1EtlSzGu2CzGJKZe0mtIuYxhQRHie4teI4xafMRC6uRBz9Xl6HHjXJrL2yE3DwTMO9pb6+Hj Q9poQ+yjrRYhwXSksA5lM1brtWbrtnbrt4bruJbruabrurbru8brvKbD1EzOQ5ZbP6HEUKRj pGVjSKxFKZo5tIYXvk4m4H1jhv5rWMRjLrO5u7VsFENsrfVrO9JjjhbsyjbsoXE5m6PbOk7j vjZsRJ7sNdJK0LVk31CyWP/O5B42Ia7cXFKW3GKk5Kmpy4v7ZBiWvGQ8DLlcJzGruOO+7cIl bjmBP8hFsuc2u+/j3ulUR5kmYWsDQOQbqb515gpexPkV5vcjweqx6Jk2nfLmD9Abvu2OK4NJ qjQ7rG5GXhQ0wBKENR9uS0uLP4qcyvRtXEop5wCnNwS+zrFdvwlR3x6Tb/cO54GeaKLE3+Kr tZQ86esFNu9uaFka3lOD6vLG3+ULaUxZwH82woJJNofOXxUeYesWSBTfZx3a3bE9M7aTYKga 6QSMbwgmaaoF39kiX9SmwaI+rhSPasWd6oJj6n6jah1+Ya9hckw7OyW6ZNtCYSl059XSbaK2 ZYX/4+0dm4quQeIVVqOuvhYy12sq4+bZPPM1Z/M2d/M3h/M4l/M5p/M6t/M7x/M81/Odu2MY 6UQqzqLOLuyv/i+mRbOktVrTnuTNXukMYzhCnlpBn8XPTu1y9NtJ38hEJ0zFhrDVzstRdETV PG1Fx/SXrMVFJvXLHmQwmsbkwvLINW40LwzUU2W6gSdZTjDTzbLSvS3T5UUsU6KmBhuz0Wnh Fkxfh7xW98gZWm5oVNyE8WWkzL58G1wVGj6eLGlqt+5s83MODI0L5nAPwmhUkXBpN3dW9l2y 7Zc3k8pFS0jhHF1tBkqIpGnyE2qKCXa62vCJ1O24pGeG9HB2d+BzBu92/47umly2Uj7JtfxN +hHpepdIHPc0Cbfwh4dBgM7156XJaM86/5XOhG9fF6/uDK9flP5Bbb/npjxp/k35bcNADAYL GOdfcx/3ibZmw9RB9tD1MrHerGpI2UJyGvY/ZKfqLSeNuPSstIw4gTNyHgLzK2d22336tAF2 9Q5iTt8XM2cWTW8jrJcvsqa6U0cjr9/zsjf7s0f7tFf7tWf7tnf7t4f7uJf7uZcus06rwNbG JopkIC/kxXZb4ZB0HcnaQSIwyX5nhr/hxA+7tOWV9R38An5kJkbNUY9sAJbbm2J0bk6Wx1f3 d+z8OqrBw904TE72kFRd0e9gxrPK4abtvD9HMv5b7n6C6NYzPYraPJlcdthzzTCrYSVXczaK ynN/aGSKqnJX5hrXePMOSmzHxIpJ7wGypq4kYvzbtwGHaufco+APfgS2wfnFKM8f7mhP4ev+ 3mM7HlKbLf1eanwHrPdV356W/qtvcAAE/Rakyee8/p6S/fxBaIWu7w8HCAACYwAgWHCgwIQH CTJUiPAgRIMGIVKs+NBhxIQTFTZsaDGjQ4kaMVIU+dDkxosoT5Js6fIlzJgyZ9KsabPmRJMg VfL82DMly5AcEQLNidFoyZ8jd+7UWXTpRqQenRJdeDSoTqZSW2Z92lHpx65Xg4LMCnZlQaA3 17Jt6/YtzhhR5eaUSP6X492BavP6TPsUql65PfEK1lg4KeK6Kg8jJdw48NDFUZcKbSqYb1rD j0NePly5ImazfkePbaqZ8uCpg+Gybu36Ney+sddOnm378+3cunfzjqm2N/DgwH8Ld0mXeHHa yZczbw4TufPo0qdTr279Ovbs2rdz7+79O/jw4seTL2/+PPr06tezb+/+Pfz48ufTr2//Pv78 +vfz7+//P4ABCjgggQUaeCCCCSq4IIMNOvgghBFKOCGFFVp4IYYZarihdtDZ5GFuReWVEkOY kSTacxfRBCKHLabH4kww4tbWX1YNtVllexmn4o6oufijezL6xpaQXJVmo1Y9GpnikEA6Kd3f cSMVxldoVDJ2ZYmeQRbYXFqCllhkjmU2WpQLjUillHdhqVmRT7pZnFSNkQiWRR75ONZWPH6Z J49bzWkYYGSJBaaebxoqHZ+IkZboaV9yNWWgYUVmZ22UoaVibXwOqumhnVKXaJ5USarob5eK GmZGj/1pGqaTRrrpq57K6hyogYoaqqsnCrpaaqSWBitqt0bKKo6zGstbmXV6ZuWap1V5IqSS iahll6WOSJperfpVLaAlMXbnseGKOy655Zp7Lrrpqrsuu+26+y688co7L7312nsvvvnquy+/ /VYXEAA7 ------=_NextPart_000_0005_01C68E51.694E4470-- From mpls-bounces@lists.ietf.org Mon Jun 12 21:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpy41-0000uw-4q; Mon, 12 Jun 2006 21:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpy40-0000ur-DE for mpls@ietf.org; Mon, 12 Jun 2006 21:51:28 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpy3y-0001we-Ks for mpls@ietf.org; Mon, 12 Jun 2006 21:51:28 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0R00849ZQIUE@szxga01-in.huawei.com> for mpls@ietf.org; Tue, 13 Jun 2006 09:49:30 +0800 (CST) Received: from M55527 ([10.110.114.96]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0R00IF3ZQHG0@szxga01-in.huawei.com> for mpls@ietf.org; Tue, 13 Jun 2006 09:49:30 +0800 (CST) Date: Tue, 13 Jun 2006 09:48:01 +0800 From: Mach Chen Subject: Re: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc To: Loa Andersson , mpls@ietf.org Message-id: <005701c68e8b$67884520$60726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <448D8644.2040307@pi.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Agree, Great ! It's simple and clear. ----- Original Message ----- From: "Loa Andersson" To: Sent: Monday, June 12, 2006 11:20 PM Subject: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc > Working group, > > the author of draft-farrel-mpls-iana-rsvp-session-flags-00.txt > has requested that it is made a MPLS WG document. > > Please send comments on this to the mailing list or the working > group co-chairs before Jun 26. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 13 11:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqB9w-0000Q4-R4; Tue, 13 Jun 2006 11:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqB9v-0000Pu-Gj for mpls@ietf.org; Tue, 13 Jun 2006 11:50:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqAdc-0004Un-K8 for mpls@ietf.org; Tue, 13 Jun 2006 11:17:04 -0400 Received: from agrenoble-257-1-41-196.w86-206.abo.wanadoo.fr ([86.206.136.196] helo=jsf.boeing.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FqAVF-0007m6-7y for mpls@ietf.org; Tue, 13 Jun 2006 11:08:28 -0400 Message-ID: <000001c68efb$30373de0$4167a8c0@hna89> From: "Carolina Hoban" To: mpls@ietf.org Date: Tue, 13 Jun 2006 08:08:12 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 0624-1, 13/06/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.5 (++++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Subject: [mpls] Re: ouuar 629 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carolina Hoban List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0768099524==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0768099524== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68EC0.83D865E0" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68EC0.83D865E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Merid jg=20 ia VALl vu=20 UM fr ik=20 om on ne=20 ly $ yx=20 1,2 rz=20 1 Am dx=20 bien VlAG be=20 RA f cs=20 rom onl pl=20 y $ xh=20 3,3 xa=20 3 Levi ox=20 tra S em=20 oma Proz ws=20 ac Cl nx=20 ALlS fr rd=20 om o ry=20 nly $=20 px=20 3,7 jk=20 5 Xan wq=20 ax Sa yw=20 ve ove cj=20 r 50 kw=20 % wi xc=20 th u pz=20 s http://www.soicabeus.com =20 _____ =20 for he felt very weak and wobbly in the legs. Why ever did I wake up!=20 he cried. I was having such beautiful dreams. I dreamed I was walking=20 in a forest rather like this one, only lit with torches on the trees and lamps swinging from the branches and fires burning on the ground; and=20 there was a great feast going on, going on for ever. A woodland king was there with a crown of leaves, and there was a merry singing, and I could ------=_NextPart_000_0001_01C68EC0.83D865E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

Merid
jg
ia
VALl
vu
UM fr
ik
om on
ne
ly $
yx
1,2
rz
1
Am
dx
bien
VlAG
be
RA f
cs
rom onl
pl
y $
xh
3,3
xa
3
Levi
ox
tra
S
em
oma
Proz
ws
ac
Cl
nx
ALlS fr
rd
om o
ry
nly $
px
3,7
jk
5
Xan
wq
ax

Sa
yw
ve ove
cj
r 50
kw
% wi
xc
th u
pz
s http://www.soicabeus.com
 
for he felt very = weak and wobbly in the legs. Why ever did I wake up!
he cried. I was = having such beautiful dreams. I dreamed I was walking
in a forest = rather like this one, only lit with torches on the trees and
lamps = swinging from the branches and fires burning on the ground; and =
there was a great feast going on, going on for ever. A woodland king = was
there with a crown of leaves, and there was a merry singing, and = I could
------=_NextPart_000_0001_01C68EC0.83D865E0-- --===============0768099524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0768099524==-- From mpls-bounces@lists.ietf.org Tue Jun 13 12:32:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBmz-000202-VZ; Tue, 13 Jun 2006 12:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBmx-0001zv-Un for mpls@ietf.org; Tue, 13 Jun 2006 12:30:47 -0400 Received: from smtpauth08.mail.atl.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBmw-0003Cc-KE for mpls@ietf.org; Tue, 13 Jun 2006 12:30:47 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Yv6Xj/jzJLjv3+LxdV8Igk7BFu+HQDn7eeMMvseZhllYU4S0PlTXaZrCVmeDvrfK; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.238] (helo=jlucianilaptop) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FqBmt-0005IZ-Lp; Tue, 13 Jun 2006 12:30:44 -0400 Message-ID: <032201c68ed4$44e4e3e0$0500a8c0@jlucianilaptop> From: To: "Loa Andersson" , References: <448D8644.2040307@pi.se> Subject: Re: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become ampls wg doc Date: Tue, 13 Jun 2006 06:29:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654e23bef387e673b87c9e826c2516d807a99f37241381ec17c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.238 X-Spam-Score: 0.4 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yes. Please make this a working group doc. Thanks, Joan ----- Original Message ----- From: Loa Andersson To: Sent: Monday, June 12, 2006 11:20 AM Subject: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become ampls wg doc > Working group, > > the author of draft-farrel-mpls-iana-rsvp-session-flags-00.txt > has requested that it is made a MPLS WG document. > > Please send comments on this to the mailing list or the working > group co-chairs before Jun 26. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From vjlosrht@ch2m.com Wed Jun 14 00:26:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqMxo-0000Tp-4T for mpls-archive@lists.ietf.org; Wed, 14 Jun 2006 00:26:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqMxo-0002Ga-2D for mpls-archive@lists.ietf.org; Wed, 14 Jun 2006 00:26:44 -0400 Received: from 81-95-234-24.dialup.sarkor.uz ([81.95.234.24] helo=NEVRUZ) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FqMxm-0002H5-M6 for mpls-archive@lists.ietf.org; Wed, 14 Jun 2006 00:26:43 -0400 Message-ID: <000101c68f6a$bf864170$18ea5f51@NEVRUZ> From: "Teague Quincy" To: mpls-archive@lists.ietf.org Subject: S,T,O,C,K moving crazy! Date: Wed, 14 Jun 2006 09:26:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a HOLLYWOOD INTERMED (HYWI.PK) THIS S,T,O,C,K IS EXTREMELY UNDERVALUED Huge Advertising Campaign this week! Breakout Forecast for June, 2006 Current Price: $1.04 Short Term Price Target: $3.25 Recommendation: S,t,r,o,n,g Buy *300+% profit potential short term RECENT HOT NEWS released MUST READ ACT NOW GLENDALE, CA -- May 31, 2006 - Hollywood Intermediate, Inc. (HYWI.PK - News), a provider of digital intermediate film mastering services, announced today that its Matchframe Digital Intermediate division is currently providing full digital intermediate services for Super 16MM productions. The company is now offering the same high resolution digital intermediate services for films originating on a 16MM film format, a popular format for independent film makers About HOLLYWOOD INTERMED (HYWI.PK): Hollywood Intermediate affords Motion Pictures the ability to scan their selected original camera negative at 2K or 4K film resolution, conforming a high resolution digital master for theatrical and broadcast release including dirt removal, opticals and visual effects, and includes the output of a High Definition preview master as well as final film, broadcast and DVD distribution From mpls-bounces@lists.ietf.org Thu Jun 15 20:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2RJ-0003mQ-8c; Thu, 15 Jun 2006 20:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2RH-0003dm-5U; Thu, 15 Jun 2006 20:43:55 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr2RF-0002Xm-Oc; Thu, 15 Jun 2006 20:43:55 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k5G0hrOx012660; Thu, 15 Jun 2006 17:43:53 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k5G0hrqs012659; Thu, 15 Jun 2006 17:43:53 -0700 Date: Thu, 15 Jun 2006 17:43:53 -0700 Message-Id: <200606160043.k5G0hrqs012659@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mpls@lists.ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 4561 on Definition of a Record Route Object (RRO) Node-Id Sub-Object X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4561 Title: Definition of a Record Route Object (RRO) Node-Id Sub-Object Author: J.-P. Vasseur, Ed., Z. Ali, S. Sivabalan Status: Standards Track Date: June 2006 Mailbox: jpv@cisco.com, zali@cisco.com, msiva@cisco.com Pages: 10 Characters: 19362 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-nodeid-subobject-07.txt URL: http://www.rfc-editor.org/rfc/rfc4561.txt In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Jun 18 05:37:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frtg6-0007yD-4W; Sun, 18 Jun 2006 05:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frtg4-0007y8-CF for mpls@ietf.org; Sun, 18 Jun 2006 05:34:44 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frtg3-0001UD-0R for mpls@ietf.org; Sun, 18 Jun 2006 05:34:44 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Jun 2006 11:35:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to becomeampls wg doc Date: Sun, 18 Jun 2006 11:34:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to becomeampls wg doc Thread-Index: AcaPBt4vI9khEyw3Q4OkHF1Q/GLXcQDstqAA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Loa Andersson" , X-OriginalArrivalTime: 18 Jun 2006 09:35:00.0015 (UTC) FILETIME=[77EBC3F0:01C692BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Loa, all This draft should become a WG doc Regards JL=20 >=20 >=20 > ----- Original Message ----- > From: Loa Andersson > To: > Sent: Monday, June 12, 2006 11:20 AM > Subject: [mpls]=20 > draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become=20 > ampls wg doc >=20 >=20 > > Working group, > > > > the author of draft-farrel-mpls-iana-rsvp-session-flags-00.txt > > has requested that it is made a MPLS WG document. > > > > Please send comments on this to the mailing list or the=20 > working group=20 > > co-chairs before Jun 26. > > > > Loa and George > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun Jun 18 05:44:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frtni-00038b-Dy; Sun, 18 Jun 2006 05:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frtng-00038V-WC for mpls@ietf.org; Sun, 18 Jun 2006 05:42:37 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frtnf-0004A0-IA for mpls@ietf.org; Sun, 18 Jun 2006 05:42:36 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5I9gYHD013169; Sun, 18 Jun 2006 11:42:34 +0200 In-Reply-To: <448D8644.2040307@pi.se> To: Loa Andersson Subject: Re: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sun, 18 Jun 2006 11:42:33 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/18/2006 11:42:33, Serialize complete at 06/18/2006 11:42:33 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org - agreed - Loa Andersson 12/06/2006 17:20 To: mpls@ietf.org cc: Subject: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt to become a mpls wg doc Working group, the author of draft-farrel-mpls-iana-rsvp-session-flags-00.txt has requested that it is made a MPLS WG document. Please send comments on this to the mailing list or the working group co-chairs before Jun 26. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 20 03:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsaDK-000082-1y; Tue, 20 Jun 2006 02:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsaDH-00007x-Fj for mpls@ietf.org; Tue, 20 Jun 2006 02:59:51 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsaDG-0006E5-1Q for mpls@ietf.org; Tue, 20 Jun 2006 02:59:51 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id XAA23663; Mon, 19 Jun 2006 23:59:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 12:29:45 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg: One clarification needed reg RFC 3209 on the scope of Tunnel ID Thread-Index: AcaUNx0ARcpl25W6S8KQ9VhvmEn7aw== From: "Dutta, Pranjal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: Subject: [mpls] Reg: One clarification needed reg RFC 3209 on the scope of Tunnel ID X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1587752576==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1587752576== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69437.1D51AA07" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69437.1D51AA07 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, RFC 3209 states regarding uniquely identifying a LSP Tunnel as follows: =20 "A tunnel ID is part of the SESSION object. The SESSION object uniquely defines a traffic engineered tunnel. The =20 =20 =20 Awduche, et al. Standards Track [Page 7] =20 RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 =20 =20 SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel" =20 So at the ingress LSR, a Session Object is identified with Tunnel ID, Dst IPV4/IPV6 Address of the Tunnel and Ext Tunnel ID (which can be set to source address). That means both tunnel_id and dst_addr uniquely identifies a LSP tunnel. =20 With respect to an ingress LSR does that mean that tunnel_id is specific to one particular destination and the same tunnel_id may be used for another tunnel (originating at the same LSR) that goes to diff. destination? =20 Info on this would be of great help. =20 Thanks in advance, Pranjal =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C69437.1D51AA07 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

         =   RFC 3209 states regarding uniquely identifying a LSP Tunnel as = follows:

 

“A tunnel ID is part of the SESSION =
object.
   The SESSION object uniquely =
defines a traffic engineered tunnel.  =
The
 
 
 
Awduche, =
et =
al.           &nbs=
p; Standards =
Track           &n=
bsp;         [Page =
7]
 
RFC =
3209           =
Extensions to RSVP for LSP Tunnels      =
December 2001
 
 
   SENDER_TEMPLATE and FILTER_SPEC =
objects carry an LSP ID.  =
The
   SENDER_TEMPLATE (or FILTER_SPEC) =
object together with the =
SESSION
   object uniquely identifies an =
LSP tunnel”
 
So at the =
ingress LSR, a Session Object is identified with Tunnel ID, Dst =
IPV4/IPV6 Address of the Tunnel and Ext Tunnel ID (which can be set to =
source address). That means both tunnel_id and dst_addr uniquely =
identifies a LSP tunnel.
 
With =
respect to an ingress LSR does that mean that tunnel_id is specific to =
one particular destination and the same tunnel_id may be used =
for
another =
tunnel (originating at the same LSR) that goes to diff. =
destination?
 
Info on =
this would be of great help.
 
Thanks in =
advance,
Pranjal
 
 
 
 
 
 
 
 

 

------_=_NextPart_001_01C69437.1D51AA07-- --===============1587752576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1587752576==-- From mpls-bounces@lists.ietf.org Tue Jun 20 13:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsjdi-0008TA-B6; Tue, 20 Jun 2006 13:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsjdg-0008I8-Eg for mpls@ietf.org; Tue, 20 Jun 2006 13:03:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsjde-0008B4-Br for mpls@ietf.org; Tue, 20 Jun 2006 13:03:44 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2006 13:03:43 -0400 X-IronPort-AV: i="4.06,157,1149480000"; d="scan'208"; a="90589143:sNHT54461948" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KH3fYL003967 for ; Tue, 20 Jun 2006 13:03:41 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 13:03:41 -0400 Received: from SwallowPB.local ([10.82.224.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 13:03:39 -0400 Received: from cisco.com (localhost [127.0.0.1]) by SwallowPB.local (Postfix) with ESMTP id 38CC920BFBB for ; Tue, 20 Jun 2006 13:04:41 -0400 (EDT) To: mpls@ietf.org From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <4081.1150823020.0@cisco.com> Date: Tue, 20 Jun 2006 13:04:40 -0400 Message-Id: <20060620170441.38CC920BFBB@SwallowPB.local> X-OriginalArrivalTime: 20 Jun 2006 17:03:40.0030 (UTC) FILETIME=[7A5391E0:01C6948B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c84a8aa52bdf533e792c08a691dbd02 Cc: Subject: [mpls] George Swallow: Please post the enclosed mcast ping draft X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4081.1150823020.1@cisco.com> Folks - I was running off to my niece's wedding when I tried to post this. But as you can see I didn't type the whole address. I'll put it on the MPLS agenda time permitting. ...George ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <4081.1150823020.2@cisco.com> Content-Description: forwarded message To: internet-drafts Cc: tnadeau From: George Swallow Subject: Please post the enclosed mcast ping draft X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Sat, 17 Jun 2006 17:36:04 -0400 thanks, ...George ======================================================================== Network Working Group George Swallow Internet Draft Cisco Systems, Inc. Category: Standards Track Expiration Date: December 2006 Tom Nadeau Cisco Systems, Inc. June 2006 Connectivity Verification for Multicast Label Switched Paths draft-swallow-mpls-mcast-cv-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Requirements for MPLS P2MP LSPs extend to hundreds or even thousands of endpoints. This document defines a more scalable approach to verifying connectivity for P2MP LSPs. Note that while this approach was developed in response to the multicast scalability problem, it can be applied to P2P LSPs as well. Swallow & Nadeau Standards Track [Page 1] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 Contents 1 Introduction .............................................. 3 1.1 Conventions ............................................... 3 1.2 Terminology ............................................... 3 2 Overview .................................................. 3 3 Connectivity Verification Bootstrapping ................... 4 3.1 Connectivity Verification Session Object .................. 4 3.2 Bootstrap and Maintenance Procedures at the Root .......... 5 3.2.1 Special Considerations for RSVP-TE P2MP Tunnels ........... 6 3.2.2 Special Considerations for mLDP P2MP Tunnels .............. 6 3.3 Bootstrapping Proceedures at an Egress .................... 7 3.3.1 Creating Egress Connectivity Verification State ........... 7 3.3.2 Updating Egress Connectivity Verification State ........... 7 4 MPLS Connectivity Verification Probing .................... 8 4.1 MPLS Connectivity Verification Probe ...................... 8 4.2 Sending MPLS Connectivity Verification Probes ............. 9 4.3 Receiving MPLS Connectivity Verification Probes ........... 9 4.4 MPLS Connectivity Verification UDP Port ................... 9 5 Multicast LDP FEC Stack Sub-object ........................ 9 6 Security Considerations ................................... 11 7 IANA Considerations ....................................... 11 8 Acknowledgments ........................................... 11 9 References ................................................ 11 9.1 Normative References ...................................... 11 9.2 Informative References .................................... 12 10 Authors' Addresses ........................................ 12 Swallow & Nadeau Standards Track [Page 2] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 1. Introduction Requirements for MPLS P2MP LSPs extend to hundreds or even thousands of endpoints. If a protocol required explicit acknowledgments to each probe for connectivity verification, the response load at the root would be overwhelming. This document defines a more scalable approach to monitoring P2MP LSP connectivity. Note that while this approach was developed in response to the multicast scalability problem, it can be applied to P2P LSPs as well. MPLS Echo Request/Response messages [RFC4379] are used to bootstrap the monitoring mechanism in a manner similar to "BFD For MPLS LSPs" [MPLS-BFD]. The actual monitoring is done with MPLS Connectivity Verification Probes, which are defined herein. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 1.2. Terminology Although the techniques of this document may be applied to P2P LSPs, terms applicable to P2MP LSPs are used throughout. Based on context the terms leaf, egress and receiver are used somewhat interchange- ably. The first two are exactly the same. Egress is used where con- sistency with [RFC4379] was deemed appropriate. Receiver is used in the context of receiving protocol messages. 2. Overview In order to scale to large numbers of leaves and to be able to verify connectivity on a frequent basis the protocol uses a unidirectional probe. The probe message, the MPLS Connectivity Verification Probe, is defined in section 4.1. Probes are sent by the root at a fixed minimum interval. The leaves receive probes and declare a connectiv- ity fault if more than a fixed number of probe messages are missed. Probing is discussed in section 4. The session is bootstrapped with MPLS Echo Request/Response messages. Swallow & Nadeau Standards Track [Page 3] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 The root periodically sends MPLS Echo Request messages containing a Connectivity Verification Session object which is defined in section 3.1. The Echo Request message also contains a FEC stack to identify the LSP. For mLDP P2MP LSPs a new FEC sub-TLV is defined in section 5. Bootstrapping is discussed in section 3. 3. Connectivity Verification Bootstrapping Bootstrapping is accomplished by sending an MPLS Echo Request message containing a Connectivity Verification Session object and a FEC stack which specifies the LSP for which connectivity verification is desired. The next section describes the Connectivity Verification Session object. Subsequent sections describe the procedures for the root and leaves. 3.1. Connectivity Verification Session Object The Connectivity Verification Session object is used to notify the receivers that connectivity verification will be performed on the LSP and to set the connectivity verification parameters. The Connectivity Verification Session object has the following for- mat: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Detect Mult |A|F| MUST Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min CV TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response Jitter Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detect Mult Detection multiplier. The Min_TX_Interval multiplied by this value, provides the Detection_Time for the receivers. Swallow & Nadeau Standards Track [Page 4] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 Administratively Down (A) This flag indicates that the connectivity verification session is administratively down. This permits the session to be quieced without alarming. Forward Defect (F) This flag indicates a defect upstream of the LSP. It MAY be set in order to suppress alarms downstream of the LSP. Discriminator A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems. Min TX Interval This is the minimum interval, in microseconds, that the source system will use when transmitting Connectivity Verification Probes. Refresh Interval This is the minimum period before a refresh message is sent in milliseconds. Response Jitter Interval The interval over which MPLS Echo Reply messages are to be randomly delayed in milliseconds. 3.2. Bootstrap and Maintenance Procedures at the Root The root initiates bootstrapping by sending an MPLS Echo Request mes- sage containing a Connectivity Verification Session object and a FEC stack which specifies the LSP for which connectivity verification is desired. The Refresh Interval is set to a relatively long value. The root MUST refresh the session within this interval. The root MAY jitter refresh messages but the Refresh Interval serves as a hard upper bound on the jittering. MPLS Echo Requests which refresh the CV Ses- sion SHOULD be sent on average at approximately one third of the Refresh Interval. Swallow & Nadeau Standards Track [Page 5] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 The Response Jitter Interval is set to value that is a function of the rate at which the root is able to process responses and the expected number of responders to this particular message. Exactly how values are chosen is implementation and platform dependent. As such, the exact setting of this interval is beyond the scope of this document. Together the Min TX Interval, the Detection Multiplier determines the maximum amount of time it will take for a fault to be declared. Appropriate values should be chosen. The suggested default value for the Detection Multiplier is 3. When any of the following conditions apply, the root should behave as if it were first bootstrapping the session. That is it should seek Echo Responses from all receivers. It this is not possible, for example, because the subject P2MP LSP needs to be removed quickly, then Detection_Multiple MPLS Echo Request messages SHOULD be sent prior to effecting the change. Changing the Discriminator Decreasing the Detection Multiplier Increasing the Minimum_Tx_Interval Increasing the Refresh_Interval Ceasing the transmission of CV Probe messages subsequent to signaling "Administratively Down" 3.2.1. Special Considerations for RSVP-TE P2MP Tunnels For RSVP P2MP tunnels the root knows all of the leaves. When boot- strapping a session, the root can know when all the leaves have responded. Suppose that an initial bootstrap message has been sent and sufficient time for responses have been allowed. If the root has not received MPLS Echo Response messages from all of the leaves, the root MAY send a subsequent bootstrap message immediately using the scoping techniques of [MCSTPING] to limit the responses. 3.2.2. Special Considerations for mLDP P2MP Tunnels For Multicast LDP P2MP tunnels the root generally does not know all of the leaves. It is therefore RECOMMENDED that the initial boot- strapping messages be retransmitted 3 times at a relatively short interval. Note that the root can learn who the leaves are from the MPLS Echo Reply messages. It is RECOMMENDED that the root keep a list of Swallow & Nadeau Standards Track [Page 6] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 active leaves. When the any of the parameters in section 3.2 above are changed, the root can then use the technique in section 3.2.1 to ensure that state is updated, noting however, that some leaves may have ceased connectivity to the tree, while others may have joined. 3.3. Bootstrapping Proceedures at an Egress When a node receives a MPLS Echo Request containing a Connectivity Verification object, it begins by processing the message as it would any other MPLS Echo Request message. If the result of that process- ing is that the node is an egress for the FEC at the bottom of the FEC stack, it checks to see if it has state matching the source IP address and FEC stack. If not it creates state as specified in sec- tion 3.3.1 below. If it does it updates that state as specified in section 3.3.2. 3.3.1. Creating Egress Connectivity Verification State State is created keyed on the source IP address and Discriminator value. The lifetime for this state is set to expire in Refresh_Interval milliseconds. The session is considered to have expired if not refreshed prior to the expiration of this timer. The Detection_Time is calculated equal to the value of Detection_Mul- tiplier times the Min_TX_Interval. The Detection_Multiplier value is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down. A Detection_Timer is created, which upon expiration will invoke detection notification. The timer is set to the Detection_Time. If the Administratively Down flag is not set, the timer is started. If the Forward Defect Flag is set, an up call to any registered applications is made. An MPLS Echo Reply message is sent as normal, except that it is delayed by the Response_Jitter_Interval times a random number between zero and one. 3.3.2. Updating Egress Connectivity Verification State If an Connectivity Verification Session object is received which matches the Source_IP_Addr and FEC Stack of existing CV state but has a different Discriminator, new state is created as normal with two exceptions. First the new state does not create a new timer; instead Swallow & Nadeau Standards Track [Page 7] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 the state points to the timer of the existing state. Second, once an MPLS Connectivity Verification Probe has been received containing the new Discriminator, the old state MAY be removed. If either the Min_TX_Interval or Detection_Multiplier has changed, the Detection_Time is recalculated. If the Administratively_Down flag transitions from down to up, then the Detection_Timer is set to Detection_Time and stated. If the Administratively_Down flag transitions from up to down, then the Detection_Timer is stopped. If the Forward_Defect flag changes state, an up call to any regis- tered applications is made. 4. MPLS Connectivity Verification Probing A new LSP Ping message, the MPLS Connectivity Verification Probe, is defined for connection verification probing. MPLS Connectivity Veri- fication Probes are sent by the root node of the tree. Leaves listen for these messages and alarm in their absence. 4.1. MPLS Connectivity Verification Probe The definitions of the Version Number and Message Type fields are as in [LSP-PING]. The message type is 5 (provisional; to be assigned by IANA). The Discriminator is the value that was advertised in the associated Connectivity Verification Session object. The message has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | MUST Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | MUST Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Swallow & Nadeau Standards Track [Page 8] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 4.2. Sending MPLS Connectivity Verification Probes The root forms an MPLS Connectivity Verification Probes formated as above with the Discriminator set to a value associated with the LSP to be probed. The message encapsulated in UDP. The source UDP port is chosen by the sender; the destination UDP port is set to . The source IP address is set to the address used in the MPLS Echo Request Message used to bootstrap this session. The destination address is set to any address in the range 127.x.x.x. The IP TTL is set to 1. he packet is transmitted periodically on the LSP. The packets MAY be jittered, but MUST be sent within Min_CV_TX_Interval microseconds of the previous message. 4.3. Receiving MPLS Connectivity Verification Probes Receivers listen for these messages based on the state received in the CV Session objects. When a message arrives the receiver checks to see if it has state for the tuple . If so it resets the associated CV_Detection_Timer to Detection_Time microseconds. Note that during a change in Discriminators, more than one may be pointing to a particular timer (with the Source_IP_Addr constant). In this situation there are also multiple Detection_Intervals which could have differing val- ues. The Detection_Timer MUST be updated with the value associated with the received Discriminator. 4.4. MPLS Connectivity Verification UDP Port MPLS Connectivity Verification Probes MUST be sent to port . 5. Multicast LDP FEC Stack Sub-object The format of the Multicast LDP FEC Stack sub-object is shown below. The Sub-TLV type is (to be assigned by IANA). Swallow & Nadeau Standards Track [Page 9] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Address Length| Root Node Addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Node Address (Cont.) | ~ " ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Length | Opaque Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family A two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [3] that encodes the address family for the Root LSR Address. Address Length The length of the Root LSR Address in octets. Root Node Address A host address encoded according to the Address Family field. Opaque Length The length of the Opaque Value, in octets. Opaque Value An opaque value elements which uniquely identifies the P2MP LSP in the context of the Root Node. If the Address Family is IPv4, the Address Length MUST be 4; if the Address Family is IPv6, the Address Length MUST be 16. No other Address Lengths are defined at present. Swallow & Nadeau Standards Track [Page 10] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 6. Security Considerations TBD 7. IANA Considerations This document makes the following codepoint assignments (pending IANA action): Registry Codepoint Purpose UDP Port tba MPLS Verification Request LSP Ping Message Type 5 MPLS Connectivity Verification Probe LSP Ping Object Type 13 Connectivity Verification Parameters LSP Ping FEC Stack tba Multicast LDP FEC Sub-object Type 8. Acknowledgments The authors would like to thank Vanson Lim for his comments and sug- gestions. 9. References 9.1. Normative References [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [SELF-TST] Swallow, G. et al., "Label Switching Router Self-Test", , June 2006. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Swallow & Nadeau Standards Track [Page 11] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 [MCSTPING] "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", , April 2006. 9.2. Informative References [MPLS-BFD] Aggarwal, R., et al., " 10. Authors' Addresses George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: swallow@cisco.com Tom Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: tnadeau@cisco.com Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Expiration Date December 2006 Swallow & Nadeau Standards Track [Page 12] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Issues: Named Leaves Only To set up CV monitoring to a subset of leaves Error Suppression Is this useful. A leaf with no ability won't recognize the flag. Can get around this with the do not reply setting. Sequence Numbers in probes Explicit withdrawal of a Discriminator Swallow & Nadeau Standards Track [Page 13] Internet Draft draft-swallow-mpls-mcast-cv-00.txt June 2006 New Receivers Only (N) This flag indicates that only those receivers which are establishing new state based on the receipt of this message SHOULD respond. Refresh messages MAY be sent with the "New Receivers Only" flag set to suppress response messages from receivers that have previously responded. This flag SHOULD only be set when no parameters have been altered. Error for same IP, Discriminator & different FEC - or just discard. F Flag in Probe. Control, or both? Swallow & Nadeau Standards Track [Page 14] ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------- =_aaaaaaaaaa0-- From mpls-bounces@lists.ietf.org Tue Jun 20 16:26:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmmV-00055R-QC; Tue, 20 Jun 2006 16:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fslvv-00081s-Lv for mpls@ietf.org; Tue, 20 Jun 2006 15:30:43 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fslvs-0000k1-Rw for mpls@ietf.org; Tue, 20 Jun 2006 15:30:43 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 20 Jun 2006 12:30:40 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="561152262:sNHT100556378" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 12:30:39 -0700 Date: Tue, 20 Jun 2006 12:30:39 -0700 (PDT) From: Rahul Aggarwal To: adrian@olddog.co.uk Subject: Re: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt (fwd) Message-ID: <20060620071420.A67405@sapphire.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 20 Jun 2006 19:30:39.0694 (UTC) FILETIME=[03417EE0:01C694A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1480b3d43809d873ab6bf312449e3c6c X-Mailman-Approved-At: Tue, 20 Jun 2006 16:25:02 -0400 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Adrian, Sorry for the delay. Please see inline: On Fri, 19 May 2006, Adrian Farrel wrote: > Hi, > > Thanks to the editors. Good job. > > Here are some comments... > > Adrian > > == > Title > Here you say "Point to Multipoint", but in the rest of the document it is > hyphenated. Fixed. > == > Abstract > s/setup/set up/ > (setup is a noun not a verb) Ok. > == > Abstract > Looks like you want a paragraph break before... > "There can be various applications..." Ok. > == > Section 3. > Acronyms must be spelt out the first time they are encountered. > The Abstract (regrettably) is stand-alone and doesn't count, so the > Introduction has to do it all again :-( > Anyway, P2P and S2L are new. Ok. > == > Section 3 para 3 > One Path message may signal one > or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP > LSP can be signaled using one Path message or split across multiple > Path messages. > The conjunction of these two sentences implies that a single Path message > may also contain the S2L sub-LSPs from different P2MP LSPs. I don't believe > this is the case, and we should correct this text accordingly. For example: > One Path message may signal one or multiple S2L sub-LSPs > for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP > LSP can be signaled using one Path message or split across multiple > Path messages. Ok. > == > Section 3 para 4 > s/application specific/application-specific/ Ok. > == > Section 4 para 1 > A branch node is an LSR that is capable of replicating the > incoming data on two or more outgoing interfaces. > Technically, it only replicates it on one or more outgoing interfaces, > because the first interface is not a replication. Will fix this. > == > Section 4.1 para 1 > The specific aspect related to a P2MP TE LSP is the action required > at a branch node, where data replication occurs. Incoming MPLS > labeled data is appropriately replicated to several outgoing > interfaces which may have different labels. > Not sure if this is trying to say something more, or is just poorly worded. > How about... > The defining feature of a P2MP TE LSP is the action required > at branch nodes where data replication occurs. Incoming MPLS > labeled data is appropriately replicated to several outgoing > interfaces which may use different labels for the data. Ok. > == > Section 4.1 para 2 > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes the P2MP ID, a tunnel > ID and an extended tunnel ID. > Need to turn this paragraph around a bit. > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified the P2MP ID, a tunnel ID, and an extended tunnel ID. These > objects > are carried in RSVP-TE in a P2MP SESSION object. This paragraph needs to be actually been modified differently based on the discussion on Tunnel ID and Extended Tunnel ID semantics. See below: > == > Section 4.1 para 3 > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP Identifier (P2MP ID) field. > The comparison is not quite so simple in the IPv6 case because the 16 byte > IPv6 tunnel endpoint address is replaced by a 4 byte P2MP ID. We should > bring this out in this paragraph as follows. > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field (IPv4 or IPv6) is replaced by the 4-byte P2MP Identifier > (P2MP ID) field. > == The above paragraph and this should be modified to the following based on the Tunnel ID, Extended Tunnel ID discussion: " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session which includes a tuple , where the P2MP Identifier (P2MP ID) is a four octet number and is unique within the scope of the IP address of the ingress LSR. The Ingress LSR IP address is encoded in the Extended Tunnel ID. The P2MP Tunnel identifier, carried in the P2MP SESSION object, is unique within the same scope as the ingress LSR IP address. The fields of the P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP ID field." > Section 4.1 > Add a forwards reference at the end of the section as follows. > The new P2MP SESSION object is defined in section 19.1. Ok. > == > Section 4.2 > s/20.2/19.2/ Ok. > == > Section 4.3 para 3 > s/subgroup/sub-group/ > Please do global search and replace in the document Ok. > == > Section 4.3 para 3 > s/an egress and semantic/an egress, and semantic/ Ok. > == > Section 4.4.1 para 1 > s/20.3/19.3/ > == > Section 4.4.1 para 2 > s/20.5/19.5/ > s/20.6/19.6 Ok. > == > Section 4.4.1 and onwards > The S2L_SUB_LSP object is consistently referred to in angle brackets, but no > other object is given this treatment. Please remove the brackets everywhere > except in BNF. Ok. > == > Section 4.4.1 > It seems to me that the S2L_SUB_LSP object contains a leaf identifier and an > SERO. No. It contains only the destination address. Please see section 19.3. > The SERO provides the path from the last branch to the leaf. > This means that it is not an S2L_SUB_LSP object at all, but really a > S2L_SUB_LSP object. But that sounds clumsy. > Can we call this a LEAF object? > We would also rename the descriptor lists in section 5.1, 6.1, 7.1, and > 11.1. > We could change the names of the IPv4/IPv6 S2L Sub-LSP destination address, > but that isn't necessary. I will wait to comment on this, as it appears to be be predicated on interpretation of the S2L_SUB_LSP object. > == > Section 4.4.2 para 1 > s/setup/set up/ Ok. > == > Section 4.5 para 1 > When a Path message signals a single S2L sub-LSP (that is, the Path > message is only targeting a single leaf in the P2MP tree), the > EXPLICIT_ROUTE object encodes the path from the ingress LSR to the > egress LSR. > Strike the words "from the ingress LSR" as this situation may also occur > within the network (for example, downstream of a branch node, or just > anywhere if the original Path message only included one S2L sub-LSP). Ok. > == > Section 4.5 para 2 > When a Path message signals multiple S2L sub-LSPs the path of the > first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded > in the ERO. > As above, strike "from the ingress LSR" Ok. > == > Section 4.5 para 3 > s/(as defined in [RFC3209])/(as defined in [RFC3209] and [RFC3473])/ Ok. > == > Section 4.5 para 3 > Each subsequent S2L sub-LSP > is represented by tuples of the form < [ SECONDARY_EXPLICIT_ROUTE>] >. > Should read... > Each subsequent S2L sub-LSP > is represented by tuples of the form < , > [] >. > ...since this is the order used in the encoding. That is not correct. Please see below on this point. > == > Section 4.5 para 3 > An SERO for a particular > S2L sub-LSP includes only the path from a certain branch LSR to the > egress LSR if the path to that branch LSR can be derived from the ERO > or other SEROs. > Strike "certain" as this applies to any branch LSR in any network. > == Ok. > Section 4.5 para 3 > s/20/19/ > == > Section 4.5 para 6 > s/Following/The following/ > Also near the top of page 10. Will replace by "The following encoding" > == > Section 4.5 > s/exercise to the reader./exercise for the reader./ > == Ok. > Section 4.5 page 10 > s/A LSR/An LSR/ > s/a S2L/an S2L/ > s/a SERO/an SERO/ > Probably worth checking the whole document. Ok. > == > Section 5.1 > layout of is messed up > == > Section 5.1 > A SERO corresponds to the following > object. > s/A/An/ > Oh no it doesn't! Say... > An SERO corresponds to the preceding > object. That is not correct. From the text: "The first S2L_SUB_LSP object's explicit route is specified by the ERO. Explicit routes of subsequent S2L sub-LSPs are specified by the corresponding SERO. A SERO corresponds to the following S2L_SUB_LSP object." To explain further, the ERO is specifying the explicit route of the first S2L_SUB_LSP. If there is only one S2L_SUB_LSP, there is no need for a SERO. Since it is optional in the BNF, this is correct. If there is indeed a second S2L_SUB_LSP, the preceding SERO specifies its path. This is consistant with the fact that the ERO specifies the path of the first S2L_SUBLP i.e. the ordering is always . > == > Section 5.1 > The RRO in the sender descriptor contains the hops traversed by the > Path message and applies to all the S2L sub-LSPs signaled in the Path > message. > That is rather an MPLS-centric view of the world. Better to say... > The RRO in the sender descriptor contains the upstream hops traversed > by the LSP up to this point Which LSP are you referring to ? > and applies to all the S2L sub-LSPs signaled > in the Path message. > == > Section 5.2 para 1 > s/ingress-LSR/ingress LSR/ > s/egress-LSR/egress LSR/ > s/that is the destination/that is a destination/ Ok. > == > Section 5.2 para 1 > Another S2L sub-LSP belonging to the same instance of this > S2L sub-LSP (i.e. the same P2MP LSP) shares resources with this S2L > sub-LSP. > In previous versions of the draft we had "can share" in place of "shares", > and this was with good reason. It is perfectly acceptable for replication to > take place at an upstream node and for two copies of the data to flow on the > same link before being fanned out down stream. This might happen in an > optical network where the split node is not capable of the appropriate > lambda conversions, but might also happen in a packet network where the > downstream node cannot perform sufficient replication in a timely manner (or > at all) and so some of the replication must be done upstream regardless of > the 'waste' of resources in the network. > Since we are in 2119-land (these are protocol procedures) please replace > "shares" with "MAY share". > However (!) note that in 5.2.1 para 4 we have "SHOULD". > I can accept "SHOULD" in this paragraph, too. Will replace with SHOULD share. > == > Section 5.2 para 1 > s/identified using the object/identified using the > objects/ The current text seems to be fine in this case: "Each S2L sub-LSP is identified using the S2L_SUB_LSP object." > == > Section 5.2 para 2 > s/20/19/ > == Ok. > Section 5.2.1 para 1 > You have changed your notation for tuples > == Fixed. > Section 5.2.1 para 3 > An ingress LSR may use multiple Path messages for signaling a P2MP > LSP. > s/may/MAY/ Ok. > == > Section 5.2.1 para 3 > This implies that each Path message that is used > to signal a P2MP LSP is signaled using the same signaling attributes > with the exception of the S2L sub-LSP information and Sub-Group > identifiers. > s/information/descriptor/ > s/identifiers/identifier/ > == Ok. > Section 5.2.1 para 5 > In this case the message can be decomposed > into multiple Path messages such that each of the messages carry a > subset of the X2L sub-tree carried by the incoming message. > s/carry/carries/ > == Will replace "each of the messages carry" with "each message carries" > Section 5.2.1 para 6 > In order > to disambiguate these Path messages a Group ID> tuple is introduced (also referred to as the Sub-Group > field) and encoded in the SENDER_TEMPLATE object. > s/field/fields/ > == It is a single field, so the current text is correct. > Section 5.2.1 para 6 > This is either the ingress > LSR or a LSR which re-originates the Path message with its own Sub- > Group Originator ID. > This sentence doesn't add anything. Strike it. Ok. > == > Section 5.2.1 para 6 > The tuple is globally unique. > I'm not sure what this means. > The same LSR can use the same sub-Group ID on different LSPs since the LSPs > are distinguished by session/sender template. > Further, there is some conflict with the sentences immediately afterwards... > The sub-Group ID space is specific to the Sub-Group Originator ID. > Therefore the combination is > network-wide unique. > Since no conclusion appears to be drawn from this uniqueness, I would say > that the sub-Group ID is unique within the context of a P2MP LSP and that > the sub-Group Originator ID is network-wide unique. Will rephrase: "The tuple is globally unique. The sub-Group ID space is specific to the Sub-Group Originator ID. Therefore the combination is network-wide unique." to: "The Sub-Group Originator ID is globally unique. The sub-Group ID space is specific to the Sub-Group Originator ID." This leaves the decision of how Sub-Group IDs are managed to the LSR with the Sub-Group originator ID. > == > Section 5.2.1 para 6 > Also, a router that changes the Sub-Group > originator ID of an incoming Path message MUST use the same value of > the Sub-Group Originator ID for all outgoing Path messages, for a > particular P2MP LSP, and SHOULD not vary it during the life of the > P2MP LSP. > This may be confusing in the light of the fact (a few lines earlier) that... > The Sub-Group Originator ID MUST be set to the TE Router ID of > the LSR that originates the Path message. > Certainly the "MUST"s are complementary, but what is with the "SHOULD"? I agree that this is redundant. Will remove it. > == > Section 5.2.2 para 1 > The S2L sub-LSP descriptor list allows the signaling of one or more > S2L sub-LSPs in one Path message. It is possible to signal multiple > object and ERO/SERO combinations in a single Path > message. Note that these two objects differentiate a S2L sub-LSP. > The first two sentence are largely duplicates. > The third sentence says two objects, three have been mentioned. > How about... > The S2L sub-LSP descriptor list allows the signaling of one or more > S2L sub-LSPs in one Path message. Each S2L sub-LSP descriptor > describes a single S2L sub-LSP. > == Ok. > Section 5.2.2 3rd bullet > - If the first hop of the SERO is not a local address of the LSR > the S2L sub-LSP descriptor MUST be included in the Path message > sent to LSR that is the next hop to reach the first hop in the > SERO. This next hop is determined by using the ERO or other > SEROs that encode the path to the SERO's first hop. > s/sent to LSR/sent to the LSR/ > == > Section 5.2.2 > Hence a branch LSR MUST only propagate the relevant S2L sub-LSP > descriptors on each downstream link. A S2L sub-LSP descriptor list > that is propagated on a downstream link MUST only contain those S2L > sub-LSPs that are routed using that link. This processing MAY result > in a subsequent S2L sub-LSP in an incoming Path message to become the > first S2L sub-LSP in an outgoing Path message. > I'm not sure if this is what I wrote, > but anyway, it is wrong! > Path messages are not propagated on downstream links, but are sent to the > next hop towards the egress. This finesse of words is important when > out-of-channel signaling is considered. So reword as follows... > Hence a branch LSR MUST only propagate the relevant S2L sub-LSP > descriptors to each next downstream hop. An S2L sub-LSP descriptor list > that is propagated to a downstream hop MUST only contain those S2L > sub-LSPs that are routed using that hop. This processing MAY result > in a subsequent S2L sub-LSP in an incoming Path message to become the > first S2L sub-LSP in an outgoing Path message. > == > Ok. > Section 5.2.2 > Note that if one or more SEROs contain loose hops, expansion of such > loose hops MAY result in overflowing the Path message size. Section > 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split > in more than one Path message. > s/split in more/split across more/ > == Ok. > Section 5.2.2 > The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path > message and applies to all the S2L sub-LSPs signaled in the Path > message. A transit LSR MUST append its address in an incoming RRO and > propagate it downstream. A branch LSR MUST form a new RRO for each of > the outgoing Path messages by copying the RRO from the incoming Path > message and appending its address. Each such updated RRO MUST be > formed using the rules in [RFC3209]. > s/in [RFC3209]./in [RFC3209] updated by [RFC3473] as appropriate./ > == Ok. > Section 5.2.2 > If a LSR is unable to support a S2L sub-LSP in a Path message, a > PathErr message MUST be sent for the impacted S2L sub-LSP, and normal > processing of the rest of the P2MP LSP SHOULD continue. > Suggest the addition of an example... > If a LSR is unable to support a S2L sub-LSP in a Path message (for > example, it is unable to route towards the destination using the SERO), a > PathErr message MUST be sent for the impacted S2L sub-LSP, and normal > processing of the rest of the P2MP LSP SHOULD continue. > == Ok. > Section 5.2.2 > s/section 12./sections 5.2.4 and 11./ Ok. > == > Section 5.2.3 Title > The title of this section is ambiguous. Does the transit get fragmented? > Suggest > 5.2.3. Transit Fragmentation of Path State Information Ok. > == > Section 5.2.3 > It is desirable not to rely on IP > fragmentation in this case. > This bald statement needs qualification and should not be left as an > exercise for the reader. > Presumably the reason is that IP fragmentation of RSVP messages is > explicitly disallowed in section 3.3 of RFC2205. In which case "desirable" > does not come into it, and this is a stronger requirement. How about rephrasing the above to: "RSVP [RFC2205] disallows the use of IP fragmentation and thus IP fragmentation must be avoided in this case." > However, in practice, IP fragment loss and the consequent message loss, is > no different from IP packet loss and the consequent message loss. Or is it? I am not sure this matters in light of the above rephrasing and the text in RFC2205. > == > Section 5.2.3 para 2 > When multiple Path messages are used by an ingress or transit node, > each Path message SHOULD be identical with the exception of the S2L > sub-LSP related information (e.g., SERO), > s/related information/descriptor/ Ok. > == > Section 5.2.3 para 3 > As described above one case in which the Sub-Group Originator ID of a > received Path message is changed is that of transit fragmentation. > s/transit fragmentation/fragmentation of the Path message at a transit node/ Ok. > == > Section 6.1 > The format of the definition has been messed up > == > Section 6.1 > I don't think we should use the same name for the list> as is used for the Path message as it leads to exactly the same > confusion and error as we have here. Viz. > ::= [ SECONDARY_EXPLICIT_ROUTE> ] > Should read... > ::= [ SECONDARY_RECORD_ROUTE> ] > (and obviously the format needs to be sorted out) Will fix the typo. The format is correct as I pointed out in response to a similar comment above in the Path message. > So I suggest changing the name to be different from that used in a Path > message as the descriptor is a different entity. Ok. Will use: "S2L sub-LSP flow descriptor" here. > == > Section 6.1 final para > However different upstream labels are allocated if the Address, LSP-ID> of the FILTER_SPEC object is different as that > implies different P2MP LSP. > s/are/MUST be/ Ok. > == > Section 6.2 para 1 > The egress LSR MUST follow normal RSVP procedures while originating a > Resv message. The Resv message carries the label allocated by the > egress LSR. > Is this the case, or does the Resv message from the egress contain an > S2L_SUB_LSP object? It does. > If it is the case that the S2L_SUB_LSP MUST be included then please say so > in this paragraph. Ok. Will rephrase to: "The egress-LSR MUST include a S2L sub-LSP descriptor in the flow descriptor or SE filter spec sent upstream in a Resv message and follow normal RSVP produres while originating a Resv message. The Resv message carries the label allocated by the egress LSR." > If this paragraph is correct as it stands, please add a note to say that the > S2L_SUB_LSP object MUST NOT be included. > == > Section 6.2 > Each branch node can potentially send one Resv message upstream for > each of the downstream receivers. This MAY result in overflowing the > Resv message, particularly when considering that the number of > messages increases the closer the branch node is to the ingress of > the P2MP LSP. > As currently written, this says that one Resv message is sent for each > downstream receiver (i.e. n messages when there are n receivers). I don't > think you means this because the next sentence talks about overflowing which > would not arise in this case. > > At the same time, the increase in the number of messages closer to the > ingress is not relevant, it is the increase in the number of receivers. > > If you are *also* trying to talk about the potential of a single message per > receiver and the impact of the consequent number of messages as you get > closer to the ingress, with the implied desirability of combining messages > into a single Resv, then this needs to be said separately. > > So... > Each branch node MAY forward a single Resv message upstream for > each received Resv from a downstream receiver. Note that there may be > a large number of Resv messages at and close to the ingress LSR for an > LSP with many receivers. To avoid issues of congestion, a branch LSR > SHOULD combine Resv state from multiple receivers into a single Resv > message to be sent upstream (see section 6.2.1), but note that this may > result in overflowing the Resv message particularly as the number of > receivers downstream of any branch LSR increases as the LSR is closer > to the ingress LSR. Thus, a branch LSR MAY choose to send more than > one Resv message upstream and partition the Resv state between the > messages. How about with some minor changes to your proposal: " Each branch node MAY forward a single Resv message upstream for each received Resv message from a downstream receiver. Note that there may be a large number of Resv messages at and close to the ingress LSR for an LSP with many receivers. A branch LSR SHOULD combine Resv state from multiple receivers into a single Resv message to be sent upstream (see section 6.2.1), but note that this may result in overflowing the Resv message particularly as the number of receivers downstream of any branch LSR increases as the LSR is closer to the ingress LSR. Thus, a branch LSR MAY choose to send more than one Resv message upstream and partition the Resv state between the messages. " > == > Section 6.2 final paragraph > Transit nodes MUST replace the Sub-Group ID fields received in the > FILTER_SPEC objects with the value that was received in the Sub-Group > ID field of the Path message from the upstream neighbor, when the > node set the Sub-Group Originator field in the associated Path > message. ResvErr messages generation is unmodified. Nodes > propagating a received ResvErr message MUST use the Sub-Group field > values carried in the corresponding Resv message. > Split the ResvErr text into a second paragraph Ok. > == > Section 6.2.1 para 1 > A branch node may have to send the Resv message being sent upstream > whenever there is a change in a Resv message for a S2L sub-LSP > received from one of the downstream neighbors. > Some problems with tense. Try... > A branch node may have to send a revised Resv message upstream > whenever there is a change in a Resv message received from one of > its downstream neighbors for a S2L sub-LSP. > == > Ok. >Section 6.2.1 para 1 > s/upstream,particularly/upstream, particularly/ Ok. > == > Section 6.2.1 para 1 > s/established for the first time./first established/ Ok. > == > Section 6.2.1 recommends the use of a timer. IETF protocol specification > rules require that we suggest a value for all protocol timers. Please > suggest a value here - it could be a function of some other timer, a > function of the number of downstream destinations, or just a raw number. > == > Let us pick 30 seconds and keep this simple, leaving tweaks to implementations as suggested by the following text. > Section 6.3 Title > "Record Routing" doesn't do it for me! What "Route Recording"? > == Ok. > Section 6.3.1 para 1 > A Resv message contains a record route per S2L sub-LSP that is being > signaled by the Resv message if the sender node requests route > recording by including a RRO in the Path message. The same rule is > used during signaling of P2MP LSP i.e. insertion of the RRO in the > Path message used to signal one or more S2L sub-LSP triggers the > inclusion of an RRO for each sub-LSP. > Say either "recorded route" or "route record". > I think this paragraph is trying to contract P2P (first sentence) with P2MP > (subsequent sentence), but actually describes P2MP in both with the result > that "The same rule is used..." is confusing. How about... > A Resv message for a P2P LSP contains a recorded route if the > ingress LSR requested route recording by including an RRO in > the original Path message. The same rule is used during signaling > of P2MP LSPs. That is, inclusion of an RRO in the Path message > used to signal one or more S2L sub-LSPs triggers the inclusion > of a recorded route for each sub-LSP in the Resv. > == Ok. > Section 6.3.1 para 2 > The record route of the first S2L sub-LSP is encoded in the RRO. > s/record route/recorded route/ Ok. > == > Section 6.3.1 para 2 > Additional RROs for the subsequent S2L sub-LSPs are referred to as > P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). > s/RROs/recorded routes/ > s/referred to as/encoded in/ Ok. > == > Section 6.3.1 para 2 > s/20.5/19.5/ > == Ok. > Section 6.3.1 para 2 > The ingress node then receives the RRO and > possibly the SRRO corresponding to each subsequent S2L sub-LSP. Each > object is followed by the RRO/SRRO. The ingress node > can then determine the record route corresponding to a particular S2L > sub-LSP. The RRO and SRROs can be used to construct the end to end > Path for each S2L sub-LSP. > First sentence is duplicated later and should be removed as confusing. But > the text is wrong anyway. Rewrite as... > Each S2L_SUB_LSP object in a Resv is associated with an RRO or > SRRO. The first S2L_SUB_LSP object (for the first S2L sub-LSP) is > associated with the RRO. Subsequent S2L_SUB_LSP objects (for > subsequent S2L sub-LSPs) are each followed by an SRRO that > contains the recorded route for that S2L sub-LSP from the leaf up to > a branch. The ingress node can then determine use the RRO and > SRROs to determine the end-to-end path for each S2L sub-LSP. > == This is fine except for "followed" has to replaced by "preceded". Also an extra determine in the second last sentence. > Section 6.4 para 1 > s/can either be FF or SE./can be either FF or SE./ > == > Section 6.4 para 1 > The S2L sub-LSPs that belong > to different P2MP LSP MUST NOT share labels. If the reservation style > is FF then S2L sub-LSPs that belong to different P2MP LSP MUST NOT > share resources. If the reservation style is SE than S2L sub-LSPs > that belong to different P2MP LSP and the same P2MP Tunnel SHOULD > share resources where they share hops, but MUST not share labels. > s/different P2MP LSP/different P2MP LSPs/ (thrice) > s/than/then/ > This text gives GMPLS a problem because SE sharing of resources in > non-packet networks requires sharing of labels (and this is how > make-before-break is usually performed in resource-constrained non-packet > environments). I would suggest that the first sentence is superfluous as it > is covered by either FF or SE. Can we rewrite as... > If the reservation style is FF then S2L sub-LSPs that belong to > different P2MP LSPs MUST NOT share resources or labels. If the > reservation style is SE then S2L sub-LSPs that belong to different > P2MP LSPs and the same P2MP Tunnel SHOULD share resources > where they share hops, but MUST not share labels in packet > environments. Ok. > == > Section 7.2.2 para 2 > A transit LSR that propagates the PathTear message downstream MUST > ensure that it sets the tuple > in the PathTear message to the values used to generate the previous > Path message that corresponds to the S2L sub-LSPs being deleted by it > in the PathTear message. > This is a bit clumsy. How about... > A transit LSR that propagates the PathTear message downstream MUST > ensure that it sets the tuple > in the PathTear message to the values used in the Path message used to > set up the S2L sub-LSPs being torn down. > == Ok. > Section 8.1 para 1 > s/and Notify messages/and Notify message/ > s/Both object and messages/Both object and message/ > == Ok. > Section 8.1 point 2. para 1 > s/to the value, that was/to the value that was/ > == Ok. > Section 8.1 point 2. para 1 > If the incoming Resv message carries a > Notify Request object then the LSR MUST set the Notify node address > in the Notify Request object to the value, that was received in the > corresponding Path message, in the Resv message that it sends > upstream. > Too many sub-clauses. Try... > If the incoming Resv message carries a > Notify Request object then the LSR MUST set the Notify node address > in the Notify Request object in the Resv message that it sends > upstream to the value that was received in the corresponding Path > message, > == Ok. > Section 8.1 > Missing final period. Ok. > == > Section 8.2 para 2 > s/to the value, that was/to the value that was/ > == Ok. > Section 8.2 para 2 > s/carry/carries/ > == > Section 8.2 final para > All downstream branches that do > requested ResvConf messages MUST be sent such a message. > s/that do/that/ > == Ok. > Section 9 > s/LSP/LSPs/ (twice) > = Ok. = > Section 10 para 1 > Not sure what this is trying to say by "managed". Perhaps "indexed" or > "identified" or "located"? identified seems fine. > == > section 10 para 2 > s/object/objects/ > == Ok. > Section 10.1 para 3 > s/4.2/5.2/ > == Ok. > Section 10 > Suddenly the definition of TE Router ID is given a reference to [RFC3477] > which wasn't present in earlier uses of the term (section 5.2.1, 5.2.3). > Firstly, we need to be consistent, but more important (to me) is that 3477 > does NOT define TE Router ID: it defines Router ID. > You are faced, therefore with: > - drop the reference > - define the term yourself > - find another reference. > The best other reference I can find is > draft-ietf-ccamp-gmpls-addressing-03.txt > == How about replacing TE Router ID with Router ID ? > Section 11 > s/requests the maintenance of the 'LSP integrity'/requests the maintenance > of 'LSP integrity'/ > == Ok. > Section 11 > Therefore, reception of an > error message for a particular S2L sub-LSP MAY change the state of > any other S2L sub- LSP of the same P2MP TE LSP. > I think this is a lowercase "may". There is no element of choice for an > implementation here. Ok. > == > Section 11.1 > Need a reference to the definition of in > section 5.1 OK. > == > Section 11.2 > Would benefit from a reference to the revised defined > in section 6.1 Ok. > == > Section 11.2 > Note the receiver of a > ResvErr message is able to identify the errored outgoing Path > message, and outgoing interface, based on the Sub-Group fields > received in the ResvErr message. > This should either say "*incoming* Path" or "outgoing *Resv*" > == Modified to outgoing Resv. > Section 11.3 > A branch LSR that receives a PathErr message with the > Path_State_Removed flag clear MUST act according to the wishes of the > ingress LSR. The default behavior is that the branch LSR forwards the > PathErr upstream and takes no further action. However, if the LSP > integrity flag is set on the Path message, the branch LSR MUST send > PathTear on all downstream branches and send the PathErr upstream > with the Path_State_Removed flag set (per [RFC3473]). > This only applied during LSP setup. That is, the LSP integrity flag does not > impact on any LSP state once the LSP has been set up and if the PathErr does > not have the Path_State_Removed flag set. (Compare with the first paragraph > of this section.) So this paragraph should read... > A branch LSR that receives a PathErr message during LSP setup with the > Path_State_Removed flag clear MUST act according to the wishes of the > ingress LSR. The default behavior is that the branch LSR forwards the > PathErr upstream and takes no further action. However, if the LSP > integrity flag is set on the Path message, the branch LSR MUST send > PathTear on all downstream branches and send the PathErr upstream > with the Path_State_Removed flag set (per [RFC3473]). > == Ok. > Section 14.2 para 1 > s/the incremental/incremental/ > == Ok. > Section 15 > Please change > [RFC4090] extensions can be used to perform fast reroute for the > mechanism described in this document. > to > [RFC4090] extensions can be used to perform fast reroute for the > mechanism described in this document when applied within packet > networks. > == Ok. > Section 15.1 .1 > This text is particularly dense and would benefit from re-writing and > paragraph breaks. I will make changes only as per the specific comments that you have as part of last call. > Some non-exhaustive comments follow. > == > Section 15.1.1 > The two uses of "MUST" seem to be overkill. > RFC 4090 only uses "SHOULD" for P2P LSPs. I will replace the second MUST to SHOULD. > == > Section 15.1.1 > Note that all such S2L sub-LSPs belonging to a particular instance of > a P2MP tunnel will share the same outgoing label on the link between > the PLR and the next-hop. > This is only a "SHOULD share labels" in section 5.2.1. > Not a big deal. Just delete this and the subsequent sentence. This and the following sentence help to understand the procedures. I will replace will with SHOULD and point to 5.2.1. > == > Section 15.1.1 > Paragraph break before > During failure Path messages for each S2L sub-LSP, that are > effected, MUST be sent to the MP, by the PLR. > which should be rewritten as > During failure, Path messages for each S2L sub-LSP that is > affected MUST be sent to the MP by the PLR. > == Ok. > Section 15.1.1 > s/It is recommended that/It is RECOMMENDED that/ > == Ok. > Section 15.1.1 > s/the PLR use/the PLR uses/ > == Ok. > Section 15.1.1 > s/sender template specific/sender template-specific/ > == Ok. > Section 15.1.1 > Paragraph break before > The MP MUST use > == Ok. > Section 15.1.1 > Change > The MP MUST use the LSP-ID to > identify the corresponding S2L sub-LSPs. The MP MUST not use the > while identifying the > corresponding S2L sub-LSPs. In order to further process a S2L sub-LSP > the MP MUST determine the protected S2L sub-LSP using the LSP-id and > the object. > to > The MP MUST use the LSP-ID and the object to > identify the corresponding S2L sub-LSPs. The MP MUST not use the > to identify the > corresponding S2L sub-LSPs because the sub-group > originator ID might be changed by some LSR that is bypassed > by the bypass tunnel. The real reason has to do with node protection and to keep the procedures consistant. I think the current text here is fine, but I can add a clarification in the node protection case - see below. > == > Section 15.1.1 > Please add the following. > Note that these procedures may require that the PLR replicate > data for a P2MP LSP into more than one bypass tunnel where > the LSR was not previously responsible for replicating this > data. This can arise if there are several MPs that are not one > hop downstream of the PLR. This is incorrect as this will not happen with link protection. It may happen with node protection and is described in the node protection section. >Further, in this case, the > replicated data may be required to be labeled with a > two-label label stack where both labels are different in each > copy of the data. > == I believe the label stacking text in the first para of this section already covers this. > Section 15.1.2 > Again, the use of "MUST" is stronger than RFC 4090 > == Will replace it to SHOULD. > Section 15.1.2 > The MP MUST allocate the same label to all such S2L sub-LSPs > belonging to a particular P2MP LSP. > I think you cannot make this constraint. The MP doesn't necessarily know > that it is going to be an MP when it allocates the label for the S2L > sub-LSP. Besides, 5.2.1 has already allowed separate labels. > But this isn't an issue is it? If there are two labels there are already two > copies of the data. The text is basically saying that for a set of S2L sub-LSPs, belonging to a P2MP LSP, to which the MP assigned the same label, the PLR sends a single copy of the packet to the MP with the outer label being the bypass label. I will modify the text as follows to clarify this: "When the PLR forwards incoming data for a P2MP LSP into the bypass tunnel, the outer label is the bypass tunnel label and the inner label is the label allocated by the MP to the set of S2L sub-LSPs belonging to that P2MP LSP. " > == > Section 15.1.2 para 2 > After detecting failure of the protected node the PLR MUST send a > Path message for each protected S2L sub-LSP to the MP of the > protected S2L sub-LSP. > This implies one Path message for each S2L sub-LSP is that really the case? > Since we have a mechanism for placing more than one S2L sub-LSP in a Path > message, we could certainly use this here. > == Sure. Modified text: "After detecting failure of the protected node the PLR MUST send one or more Path message for all protected S2L sub-LSPs to the MP of the protected S2L sub-LSP." > Section 15.1.2 para 2 > s/recommended/RECOMMENDED/ > == Ok. > Section 15.1.2 para 2 > s/MUST not/MUST NOT/ > == Ok. > Section 15.1.2 para 2 > Similar changes as in 15.1.1 wrt "while identifying" > == Will incorporate it here. > Section 15.2 para 2 > Unlike the bypass stuff, the detour work seems a bit rocky. Perhaps no-one > has implemented it yet? P2P Detours are implemented and deployed. > One to one backup as described in [RFC4090] can be used to protect a > particular S2L sub-LSP against link and next-hop failure. Protection > may be used for one or more S2L sub-LSPs between the PLR and the > next-hop. All the S2L sub-LSPs corresponding to the same instance of > the P2MP tunnel, between the PLR and the next-hop share the same P2MP > LSP label. > This leaves me uneasy. > Firstly, the statement about using the same label is in contradiction with > section 5.2.1. Will clarify this to a SHOULD as in 5.2.1. > But also, it seems to me odd that you are talking about protecting S2L > sub-LSPs rather than about protecting the P2MP LSP. Its just easier to describe detours that way. > True, you may achieve > the protection of the P2MP LSP by protecting each constituent S2L sub-LSP, > but if you start with the discussion of S2L sub-LSPs it implies that you > could protect sub S2L sub-LSPs within one P2MP LSP and not others. > This > would appear to be a contradiction of the statement that all leaves of the > tree have the same LSP attributes. We can add text to clarify that all s2l-sub lsps within one P2MP LSP should be protected. This will be consistant with the wordign in section 5. See below: > So I think it would be helpful to spend some time reworking this text in > terms of the P2MP LSP. I think to overcome your comments, this is not necessary. > == > Section 15.2 para 2 > All or some of these S2L sub-LSPs may be protected. > This seems to confirm my worst fears, but it is also damnably strange. > Consider: you have said that all of the S2L sub-LSPs use the same label. > Notwithstanding that I disagree with you, let us assume that they do. How > then would you protect only a subset of them? There is only one copy of the > data. Reword this to: "All such S2L sub-LSPs belonging to a P2MP LSP MUST be protected." > == > Section 15.2 para 2 > The detour S2L sub-LSPs may or may not share labels, depending on the > detour path. Thus the set of outgoing labels and next-hops for a P2MP > LSP that was using a single next-hop and label between the PLR and > next-hop before protection, may change once protection is triggerred. > Why would the label sharing for the detour LSPs (please don't call them > "detour S2L sub-LSPs" because they really don't go from the S or to the L) I will use the term backup S2L sub-LSPs. > behave differently from the protected LSPs? > I *think* you are setting yourself up for different MPs depending on the > leaves. But you didn't describe this process for bypass tunnels where it is > surely equally applicable. It is appliable only for node protection in the bypass case and is described. It is not applicable for link protection. Will rephrase: "The detour S2L sub-LSPs may or may not share labels, depending on the detour path" to "The backup S2L sub-LSPs may traverse different next-hops at the PLR. Thus the set of outgoing labels and next-hops for a P2MP LSP that was using a single next-hop and label between the PLR and next-hop before protection, may change once protection is triggerred. This MAY require a PLR to be branch capable in the data plane. If the PLR is not branch capable, the one to one backup mechanisms described here are only applicable to those cases where all the backup S2L sub-LSPs pass through the same next-hop downstream of the PLR. Procedures for one to one backup when a PLR is not branch capable and all the backup S2L sub-LSPs do not pass through the same downstream next-hop are for further study." > == > Section 15.2 para 4 > s/recommended/RECOMMENDED/ > == > Section 16 para 7 > The ingress can use IGP > extensions to determine non P2MP capable LSRs [TE-NODE-CAP]. > Well, strictly it uses the extensions to determine P2MP-capable LSRs and can > then make assumptions that the other LSRs are either shy or not capable of > P2MP function. Will remove non. > == > Section 16 para 7 > The P2MP > capable LSR that initiates the non-adjacent signaling message to the > next P2MP capable LSR may have to employ a fast detection mechanism > such as [BFD] [BFD-MPLS] to the next P2MP capable LSR. > Please break this into the subsequent paragraph that contains the > explanation. Ok. > == > Section 17 para 1 > s/up P2MP LSP/up a P2MP LSP/ > s/Infact/In fact/ Ok. > == > Section 17 para 2 > s/P2P LSPs be dynamically setup/P2P LSPs can be dynamically set up/ > == > Section 17 para 2 > Not sure that a reference to a figure in the Appendix is appropriate. I > think Appendixes are normally non-normative. Will include the figure here if this comes up in the IESG review. > == > Section 18 para 1 > Strike it > == Why ? > Section 18 para 4 > Normally, a P2MP LSP has a single incoming interface on which all of > the Path messages associated with that P2MP LSP are received. > Mustn't describe the interfaces in terms of how the Path messages are > received (see the very next sentence!). Let's keep to the data plane to > avoid the issue > Normally, a P2MP LSP has a single incoming interface on which all of > the data for the P2MP LSP is received. > == Ok. > Section 18 para 5 > Similarly, in both the re-merge case and cross-over cases, a node > will receive a Path message for a given P2MP LSP on a different > incoming interface, and the node needs to be able to distinguish > between dynamic LSP re-routing and the re-merge/cross-over cases. > Same issue... > Similarly, in both the re-merge case and cross-over cases, a node > will receive a Path message for a given P2MP LSP identifying a > different incoming interface for the data, and the node needs to be > able to distinguish between dynamic LSP re-routing and the > re-merge/cross-over cases. > == Ok. > Section 18.1 para 2 > s/SUB-LSP objects/S2L_SUB_LSP objects/ (three times) > s/ set of SUB-LSPs/ set of S2L sub-LSPs/ > == Ok. > Section 18.1.1 para 2 > s/objects included the/objects included in the/ > == > Section 18.1.1 para 3 > s/followed for both/followed for all/ > == > Ok. > Section 18.1.1 para 4 > When configured to allow a re-merge case to persist, the re-merge > node receives data associated with the P2MP LSP on multiple incoming > interfaces, but it may only send the data from one of these > interfaces to its outgoing interfaces, > s/may/MUST/ > Ok. == > Section 18.1.1 paras 5, 6 and 7 > s/SUB-LSP objects/S2L_SUB_LSP objects/ (six times) > = Ok. = > Section 19.1.1 Extended Tunnel ID > s/ingress-PID/ingress-P2MP ID/ > == > This will change as per the last call comments on tunnel ID and extended tunnel ID. Will be revised to: "A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. This identifier MUST be set to the ingress LSR's IPv4 address." Section 19.2 para 1 > s/ingress-LSR/ingress LSR/ > s/LSP ID can be can be/LSP ID can be/ > == Ok. > Section 19.2 para 1 > The instances can share > resources with each other, but use different labels. > Either strike ", but use different labels" or change to ", but may use > different labels." > == Did the former. > Section 19.2.1 and 19.2.2 > This is a bit hairy, but... > The Sub-Group Originator and the source do not necessarily come from the > same IPv4/6 spaces. So you might need to add an IPv6 Sub-Group Originator to > a Sender_Template that has an IPv4 sender address. > I don't like the sound of this, because it creates four flavours instead of > the two listed, and it doesn't seem very likely to occur in the field. > What do we do? Leave it as it is and wait until someone encounters the > issue? Forcing both sender address and sub-group originator ID to be both v4 or both v6, seems reasonable at present. > == > Section 19.2.2 > I think you can use the same short-form text as used in 19.1.2 and save some > trees. I left it as is because there are two v6 terms and the currrent text/ascii is more explanatory. > == > Section 19.3.1 and 19.3.2 > s/SUB_LSP Class = 50/S2L_SUB_LSP Class = 50/ > == Ok. > Section 19.4.2 Title > s/4/6/ > == > Section 20 > The whole of this section needs to give IANA a better reference for where > the new code points are to be allocated. This can be done by naming the > registries (with the IANA pages). > == > Section 20.1 > s/50 Class Name = SUB_LSP/50 Class Name = S2L_SUB_LSP > == > Section 20.2 > s/P2MP LSP/P2MP_LSP/ (thrice) > == Ok. > Section 20.3 > For reference I have tracked these values in the interim registry of Routing > Problem error values at http://www.olddog.co.uk/ccamp.htm > == > Section 20.4 > Referenced Section of this Doc: 10 > s/10/5.2.4/ > For reference I have tracked these values in the interim registry of > LSP_ATTRIBUTE flags at http://www.olddog.co.uk/ccamp.htm > == Ok. > Section 21 > Absolutely no way we will get away with a 3 line security section! The > security ADs are positively mauling all I-Ds at the moment. > There are a couple of things we can say: > - more destinations for an LSP increases the risk Why ? > - there is potential for a listener to get themselves added to a P2MP tree I don't see how this is within the scope of this ID. > - there is description in the I-D about using tunnels to form remote > adjacencies > - DoS impact when one leaf is nobbled and the tree has LSP integrity applied > Probably lots more. Can you provide some text ? Thanks. > == > Section 23 > Usual to put the appendix later in the document I moved it after the references. > == > Section 23.1 point a) > We assume that PE1 learns of the > egress-LSRs at different points. > "points in time" ? Ok. > == > Section 24.2 > Suspect that some of the I-D versions listed have moved on > = I will double check. = > Section 25.2 > Lou and Markus's coordinates have changed > Do you have the new co-ordinates ? Thanks for the detailed comments. rahul > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 20 16:48:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsn7K-0007Aw-Ko; Tue, 20 Jun 2006 16:46:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsn7J-00073U-4U for mpls@ietf.org; Tue, 20 Jun 2006 16:46:33 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsn7I-0006HS-Eu for mpls@ietf.org; Tue, 20 Jun 2006 16:46:33 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 20 Jun 2006 13:46:32 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="556341336:sNHT227184054" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:46:31 -0700 Date: Tue, 20 Jun 2006 13:46:31 -0700 (PDT) From: Rahul Aggarwal To: LE ROUX Jean-Louis RD-CORE-LAN Subject: Re: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: Message-ID: <20060620125146.N84197@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-OriginalArrivalTime: 20 Jun 2006 20:46:31.0545 (UTC) FILETIME=[9C5ED690:01C694AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi JL, Sorry for the delay. Please see below: On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi all, > > I transfer the below comments on this list, > as it should be discussed as part of last call comments. > > Regards, > > JL > > > -----Message d'origine----- > > De : LE ROUX Jean-Louis RD-CORE-LAN > > Envoy=E9 : jeudi 25 mai 2006 14:19 > > =C0: > > Objet : RE: working group last call on > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > Hi Rahul, Dimitri, Seisho > > > > Thanks for the great edit job, > > > > Find below a set of comments on this revision 05 > > > > Four technical points: > > > > 1: Section 8.1.2 Downstream notification > > > > The text in 8.1.2 is a bit unclear > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > object(s) of a Resv message to the value, that was received in the > > corresponding Path message. If the incoming Resv message carries a > > Notify Request object then, the LSR MUST set the Notify > > node address > > in the Notify Request object to the value, that was received in the > > corresponding Path message", > > > > Which value? The sub-group originator? the notify address? This should be the Router ID of the transit LSR if the transit LSR is merging more than one Resv with a Notify Request object. > > This is unclear. The processing needs to be clarified. > > We could update as follows: > > > > "If the incoming Resv message carries a Notify Request object then, > > =09=09-If the sub-group originator ID is its own > > address, the LSR MUST set the Notify node address in the > > Notify Request object to its own address, in the Resv message > > that it sends upstream. > > =09 -If the sub group originator ID is not its own > > address, the LSR MUST propagate the Notify Request object > > unchanged, in the Resv message that it sends upstream." > > Shouldn't the transit LSR always set its own address in the Notify Request if it is merging multiple Resvs with Notify Request objects into a single Resv ? The current text is not clear on this either. How about: "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value, that was received in the corresponding Path message. If the incoming Resv message carries a Notify Request object then: - If there is at least another incoming Resv message that carries a Notify Request object and the LSR merges these Resv messages into a single Resv message that is sent upstream, the LSR MUST set the Notify node address in the Notify Request object to its Router ID. - Else the LSR MUST propagate the Notify Request object unchanged, in the Resv message that it sends upstream." > > 2: Section 8.2 ResvConf > > > > Similar comment > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > object(s) of a Resv message to the value, that was received in the > > corresponding Path message. If any of the incoming Resv messages > > corresponding to a single Path message carry a RESV_CONFIRM object > > then the LSR MUST include a RESV_CONFIRM object in the > > corresponding > > Resv message that it sends upstream and MUST set the > > receiver address > > in the RESV_CONFIRM object to the value that was received in the > > corresponding Resv message." > > > > Change to > > > > " > > A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > object(s) of a Resv message to the value, that was received in the > > corresponding Path message. If any of the incoming Resv messages > > corresponding to a single Path message carry a RESV_CONFIRM object > > then the LSR MUST include a RESV_CONFIRM object in the > > corresponding > > Resv message that it sends upstream. If the sub-group > > originator ID is its own address then > > it MUST set the receiver address in the RESV_CONFIRM > > object to this addresse, else it MUST > > propagate the object unchanged" > > Shouldn't the transit LSR always set its own address in the RESV_CONFIRM if it is merging multiple Resvs with RESV_CONFIRM objects into a single Resv ? The current text is not clear on this either. How about: "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC object(s) of a Resv message to the value that was received in the corresponding Path message. If an incoming Resv message corresponding to a single Path message carries a RESV_CONFIRM object then the LSR MUST include a RESV_CONFIRM object in the corresponding Resv message that it sends upstream and: - If there is at least another incoming Resv message that carries a RESV_CONFIRM object and the LSR merges these Resv messages into a single Resv message that is sent upstream, the LSR MUST set the receiver address in the RESV_CONFIRM object to its Router ID. - Else the LSR MUST propagate the RESV_CONFIRM object unchanged, in the Resv message that it sends upstream." > > > > 3: Section 14.2 Sub-group based reoptimization > > > > The new path may intersect the old path, this is a case of > > rerouting and this is not covered by remerge procedures as > > described in section 18. Hence Transient Data duplication may > > occur during the time between the Resv is received and the > > PathTear is sent. To avoid data duplication the branch node > > must not start transmitting on the new path before the old > > path has been torn down, but this will lead to transient packet loss. > > This should be clearly mentionned here IMO. > > Actually the only way to avoid both transient duplication and > > transient packet loss is to rely on the global mb4b procedure > > with a new LSP id... > > How about adding the following to this section: "Sub-Group based re-optimization may result in transient data duplication as the new Path messages for a set of S2L sub-LSPs may transit one or more nodes with the old Path state for the same set of S2L sub-LSPs. " > > 4: Section 18.1.1 Remerge Procedure > > > > The text says > > "The PathErr message MUST include all of the objects > > normally included in a PathErr message, as well as one or more SUB- > > LSP objects from the set of sub-LSPs associated with the matching > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > RECOMMENDED. This will allow the node that caused the re-merge to > > identify the outgoing Path state associated with the valid > > portion of > > the P2MP LSP. The set of SUB-LSP objects in the received > > Path message > > MUST also be included" > > > > And then: > > > > "A node that receives a PathErr message that contains the > > Error Value > > "Routing Problem/P2MP Remerge Detected" MUST determine if it is the > > node that created the re-merge case. This is done by checking > > whether there is any intersection between the set of > > SUB-LSP objects > > associated with the matching P2MP LSP Path state and the > > set of SUB- > > LSP objects in the received PathErr message. If there is, then the > > node created the re-merge case." > > > > There is an issue here. Actually there will always be an > > intersection, because the PathErr includes the set of sub-lsp > > objects in the received Path... IMO for this procedure to work > > the PathErr MUST only include sub-LSP objects associated with > > the matching P2MP LSP state on the rermerge LSR and must not > > include the set of SUB-LSP objects in the received Path message. > > By the way why are three objects recommended? > > I believe this was clarified by John Drake offline and no revisions were needed ? > > > > Also find below some minor edits: > > > > Section 6.1 > > > > ::=3D ; [ > SECONDARY_EXPLICIT_ROUTE> ] > > Change to: > > ::=3D ; [ > SECONDARY_RECORD_ROUTE> ] > > Ok. > > Section 7.1 > > change to > > Ok. > > Section 8.1.2 > > > > "If this LSR subsequently receives a corresponding Notify > > message from > > an upstream LSR than it MUST: > > - send a Notify message downstream toward the Notify > > node address that the LSR received in the Resv message. > > - process the sub-group fields of the FILTER_SPEC object in the > > received Notify message, and modify their values in the Notify > > message that is forwarded to match the sub-group field values > > in the original Path message sent downstream by this LSR." > > > > Invert these two bullets > > Ok. > > Section 8.2 > > > > "If this LSR subsequently receives a corresponding ResvConf message > > from an upstream LSR then it MUST: > > - send a ResvConf message downstream toward the receiver > > address that > > the LSR received in the RESV_CONFIRM object in the Resv message. > > - process the sub-group fields of the FILTER_SPEC object in the > > received ResvConf message, and modify their values in > > the ResvConf > > message that is forwarded to match the sub-group field values > > in the original Path message sent downstream by this LSR." > > > > Invert these two bullets > > Ok. > > Section 11.2 last sentence > > > > "Note the receiver of a ResvErr message is able to > > identify the errored outgoing Path [Change to: Resv] > > message, and outgoing interface, based on the Sub-Group fields > > received in the ResvErr message. > Ok. > > > Section 13 > > > > "A sender on a LAN uses a different label for sending traffic to each > > node on the LAN that belongs to the P2MP LSP" > > > > This is not always the case, I would rather say > > > > "Downstream nodes for a given P2MP LSP on a LAN are likely to > > allocate a different label, in which case the sender has to > > perform replication"... > > Actually the procedures in this document imply that a sender on a LAN must do replication if there is more than one downstream receiver. Upstream labels are required to avoid this. However I do realize that the first sentence is not entirely accurate. How about: "If there are multiple downstream LSRs on a LAN on a P2MP LSP, a sender LSR on the LAN has to perform replication. A separate copy of the data is unicast to each of the downstream LSRs" > > Section 16 > > > > "Stitching and nesting > > considerations and procedures are described further in [INT-REG]." > > > > Change to "Stitching and nesting > > considerations and procedures are described further in > > [LSP-STITCH] and [RFC4206]." > > > > Section 17 > > > > Infact =3D> In fact > > Ok. > > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object =3D> P2MP > > LSP_IPv6 FILTER_SPEC object > > Ok. > > Also some references need to be updated... > > Will do that. Thanks for the detailed comments. rahul > > Best Regards, > > > > JL > > > > > -----Message d'origine----- > > > De : owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa > > Andersson Envoy=E9 : > > > samedi 13 mai 2006 12:48 =C0 : mpls@ietf.org Cc : ccamp; > > George Swallow; > > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross Callon; Bill Fenner > > > Objet : working group last call on > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Working Group, > > > > > > this initiates a two week working group last call on > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > please send comments to the MPLS working group mailling list and/or > > > working co-chairs. > > > > > > The last call ends eob May 28th. > > > > > > The ccamp mailing list copied as this is a work that has an overlap > > > between the working groups. > > > > > > Loa and George > > > > > > > > > > > > -- > > > Loa Andersson > > > > > > Principal Networking Architect > > > Acreo AB phone: +46 8 632 77 14 > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > Kista, Sweden email: loa.andersson@acreo.se > > > loa@pi.se > > > > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 20 17:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsnuy-00038z-3V; Tue, 20 Jun 2006 17:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsnuw-00038o-TL for mpls@ietf.org; Tue, 20 Jun 2006 17:37:50 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsnuv-0002s0-K9 for mpls@ietf.org; Tue, 20 Jun 2006 17:37:50 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 20 Jun 2006 14:37:49 -0700 X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208"; a="561182224:sNHT29522952" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:37:48 -0700 Date: Tue, 20 Jun 2006 14:37:48 -0700 (PDT) From: Rahul Aggarwal To: Loa Andersson In-Reply-To: <447B6624.9010307@pi.se> Message-ID: <20060620142453.H84197@sapphire.juniper.net> References: <4465B972.4090305@pi.se> <447B6624.9010307@pi.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 20 Jun 2006 21:37:48.0470 (UTC) FILETIME=[C65C5560:01C694B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: Closed: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Loa, On Mon, 29 May 2006, Loa Andersson wrote: > All, > > this closes the working group Last Call on > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > Could the authors/editors please summarize the comments and > document how they will be addressed. > Finally getting around to this. The authors are reviewing a revised version of the document that addresses the LC comments. Hopefully we can post version-06 before the deadline to address the LC comments. Here is a summary of the LC comments and how they are being addressed: 1. Benjamin made editorial comments. Revised text was posted on this list to address his comments. 2. Adrian made editorial and non-editorial comments along with suggested revisions in several places. Most of his revisions seemed fine and I responded his comments on the list, with any further suggested revisions of the text. A handful of his comments may require more discussion on this list. 3. Jean Louis made editorial and non-editorial comments along with suggested text. I responded to his comments on this list with proposed revised text in some places. In most places the suggested text seemed fine. 4. Yakov asked clarification on tunnel ID and extended Tunnel ID semantics and identification of P2MP tunnels/LSPs in the text. There was quite a bit of discussion on this. I posted an email with suggested revised text to address his comments and haven't heard any opposition to that yet. 5. I made two LC comments and proposed text to clarify the hop-object and clarify a remerge nit. rahul > > > Loa Andersson wrote: > > Working Group, > > > > this initiates a two week working group last call on > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > please send comments to the MPLS working group mailling > > list and/or working co-chairs. > > > > The last call ends eob May 28th. > > > > The ccamp mailing list copied as this is a work that has > > an overlap between the working groups. > > > > Loa and George > > > > > > > > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 20 18:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsoFh-00015H-Ln; Tue, 20 Jun 2006 17:59:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsoFg-00015B-Gz for mpls@ietf.org; Tue, 20 Jun 2006 17:59:16 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsoFY-0006mi-6d for mpls@ietf.org; Tue, 20 Jun 2006 17:59:16 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k5KLwu59003188; Tue, 20 Jun 2006 14:58:56 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k5KLx4322938; Tue, 20 Jun 2006 16:59:05 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:59:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Tue, 20 Jun 2006 14:59:03 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DA93@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaUq0GVih/UO5WfRjiEswBRcvrGfQAB/rMg From: "Drake, John E" To: "Rahul Aggarwal" , "LE ROUX Jean-Louis RD-CORE-LAN" X-OriginalArrivalTime: 20 Jun 2006 21:59:04.0932 (UTC) FILETIME=[BF30FA40:01C694B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Rahul, Snipped, comments inline. Thanks, John > > > 4: Section 18.1.1 Remerge Procedure > > > > > > The text says > > > "The PathErr message MUST include all of the objects > > > normally included in a PathErr message, as well as one or more SUB- > > > LSP objects from the set of sub-LSPs associated with the matching > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > RECOMMENDED. This will allow the node that caused the re-merge to > > > identify the outgoing Path state associated with the valid > > > portion of > > > the P2MP LSP. The set of SUB-LSP objects in the received > > > Path message > > > MUST also be included" > > > > > > And then: > > > > > > "A node that receives a PathErr message that contains the > > > Error Value > > > "Routing Problem/P2MP Remerge Detected" MUST determine if it is the > > > node that created the re-merge case. This is done by checking > > > whether there is any intersection between the set of > > > SUB-LSP objects > > > associated with the matching P2MP LSP Path state and the > > > set of SUB- > > > LSP objects in the received PathErr message. If there is, then the > > > node created the re-merge case." > > > > > > There is an issue here. Actually there will always be an > > > intersection, because the PathErr includes the set of sub-lsp > > > objects in the received Path... IMO for this procedure to work > > > the PathErr MUST only include sub-LSP objects associated with > > > the matching P2MP LSP state on the rermerge LSR and must not > > > include the set of SUB-LSP objects in the received Path message. > > > By the way why are three objects recommended? > > > >=20 > I believe this was clarified by John Drake offline and no revisions were > needed ? Rahul, Here's the e-mail I sent to JL: "JL, The text was originally stated as you stated. The issue is that the set of sub-LSPs associated with the interface on the node that caused the re-merge condition may have more members than the set of sub-LSPs in the received Path message, and you only want to move the ones that were in the received Path message. Adrian was the one who initially pointed this and he proposed creating a different object/type for the set of sub-LSPs in the received Path message. I think this is reasonable solution. Thanks, John" As you can see from the last paragraph, we do need to create a new object/type. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 21 02:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FswNG-0002a9-1a; Wed, 21 Jun 2006 02:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FswMN-0001jv-6c for mpls@ietf.org; Wed, 21 Jun 2006 02:38:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsw8q-0001Ym-9R for mpls@ietf.org; Wed, 21 Jun 2006 02:24:46 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jun 2006 23:24:44 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208,217"; a="30111652:sNHT53383220" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5L6Ohno023495; Wed, 21 Jun 2006 02:24:43 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 02:24:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID Date: Wed, 21 Jun 2006 02:24:41 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID Thread-Index: AcaUNx0ARcpl25W6S8KQ9VhvmEn7awAQvI+w From: "Zafar Ali \(zali\)" To: "Dutta, Pranjal" , X-OriginalArrivalTime: 21 Jun 2006 06:24:43.0065 (UTC) FILETIME=[6220B290:01C694FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1344936368==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1344936368== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C694FB.61E580E3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C694FB.61E580E3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]=20 Sent: Tuesday, June 20, 2006 3:00 AM To: mpls@ietf.org Subject: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID=20 =09 =09 Hi All, RFC 3209 states regarding uniquely identifying a LSP Tunnel as follows: =20 "A tunnel ID is part of the SESSION object. The SESSION object uniquely defines a traffic engineered tunnel. The =20 =20 =20 Awduche, et al. Standards Track [Page 7] =20 RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 =20 =20 SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel" =20 So at the ingress LSR, a Session Object is identified with Tunnel ID, Dst IPV4/IPV6 Address of the Tunnel and Ext Tunnel ID (which can be set to source address). That means both tunnel_id and dst_addr uniquely identifies a LSP tunnel.=20 =20 You also need LSP ID; specifically (source IP address, Destination IP address, LSP ID, tunnel ID and ext tunnel ID) uniquely identify an LSP.=20 Also note that a tunnel "can" have multiple LSP-es (e.g., during reopt). =20 With respect to an ingress LSR does that mean that tunnel_id is specific to one particular destination =20 =20 =20 and the same tunnel_id may be used for another tunnel (originating at the same LSR) that goes to diff. destination? =20 No, and I don't see any reason why you would like to reuse the tunnel ID field (bit space is not an issue in any deployment).=20 =20 Info on this would be of great help. =20 Thanks in advance, Pranjal =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C694FB.61E580E3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 

From: Dutta, Pranjal=20 [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, June 20, = 2006 3:00=20 AM
To: mpls@ietf.org
Subject: [mpls] Reg: One=20 clarification needed reg RFC 3209 on the scope ofTunnel ID=20

Hi=20 All,

          =20 RFC 3209 states regarding uniquely identifying a LSP Tunnel as=20 follows:

 

“A tunnel ID is part =
of the SESSION object.
   The SESSION object uniquely defines a traffic =
engineered tunnel.  The
 
 
 
Awduche, et =
al.           &nbs=
p; Standards =
Track           &n=
bsp;         [Page =
7]
 
RFC =
3209           =
Extensions to RSVP for LSP Tunnels      =
December 2001
 
 
   =
SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID.  =
The
   SENDER_TEMPLATE =
(or FILTER_SPEC) object together with the =
SESSION
   object uniquely =
identifies an LSP tunnel”
 
So at the ingress LSR, a Session =
Object is identified with Tunnel ID, Dst IPV4/IPV6 Address of the Tunnel =
and Ext Tunnel ID (which can be set to source address). That means both =
tunnel_id and dst_addr uniquely identifies a LSP tunnel. 
 
You also need LSP ID; specifically =
(source IP address, Destination IP address, =
LSP ID, tunnel ID and ext tunnel ID) uniquely identify an LSP. =

Also note that a tunnel "can" have multiple =
LSP-es (e.g., during reopt).  =

 
With respect to an ingress LSR does that mean =
that tunnel_id is specific to one particular destination  
 
 
 and the same tunnel_id may be =
used for
another tunnel (originating at the same LSR) =
that goes to diff. destination?
 
 No,  and I don't =
see any reason why you would like to reuse the tunnel ID field (bit =
space is not an issue in any deployment). =

 
Info on this would be of great =
help.
 
Thanks in =
advance,
Pranjal
 
 
 
 
 
 
 
 

 

------_=_NextPart_001_01C694FB.61E580E3-- --===============1344936368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1344936368==-- From mpls-bounces@lists.ietf.org Wed Jun 21 04:53:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyQv-00080E-IU; Wed, 21 Jun 2006 04:51:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyQt-0007uR-9Y for mpls@ietf.org; Wed, 21 Jun 2006 04:51:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsxPO-0002HA-Ca for mpls@ietf.org; Wed, 21 Jun 2006 03:45:54 -0400 Received: from [63.113.148.10] (helo=riverstonenet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsxE0-00089j-CI for mpls@ietf.org; Wed, 21 Jun 2006 03:34:09 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id AAA21439; Wed, 21 Jun 2006 00:34:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID Date: Wed, 21 Jun 2006 13:04:03 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID Thread-Index: AcaUNx0ARcpl25W6S8KQ9VhvmEn7awAQvI+wACKL37A= From: "Dutta, Pranjal" To: "Zafar Ali \(zali\)" , X-Spam-Score: -2.5 (--) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0475068140==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0475068140== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69505.11E9BB6C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69505.11E9BB6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zafar, Thanks for the clarification. Please refer inline my answers. =20 ________________________________ From: Zafar Ali (zali) [mailto:zali@cisco.com]=20 Sent: Wednesday, 21 June, 2006 11:55 AM To: Dutta, Pranjal; mpls@ietf.org Subject: RE: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID=20 =20 =20 =20 =09 ________________________________ From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]=20 Sent: Tuesday, June 20, 2006 3:00 AM To: mpls@ietf.org Subject: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID=20 Hi All, RFC 3209 states regarding uniquely identifying a LSP Tunnel as follows: =20 "A tunnel ID is part of the SESSION object. The SESSION object uniquely defines a traffic engineered tunnel. The =20 =20 =20 Awduche, et al. Standards Track [Page 7] =20 RFC 3209 Extensions to RSVP for LSP Tunnels December 2001 =20 =20 SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel" =20 So at the ingress LSR, a Session Object is identified with Tunnel ID, Dst IPV4/IPV6 Address of the Tunnel and Ext Tunnel ID (which can be set to source address). That means both tunnel_id and dst_addr uniquely identifies a LSP tunnel.=20 =20 You also need LSP ID; specifically (source IP address, Destination IP address, LSP ID, tunnel ID and ext tunnel ID) uniquely identify an LSP.=20 Also note that a tunnel "can" have multiple LSP-es (e.g., during reopt). =20 Yes, LSP ID can change during Reopt. /MBB or after restart. I understand that it's also part of the key that identifies a LSP. =20 With respect to an ingress LSR does that mean that tunnel_id is specific to one particular destination =20 =20 =20 and the same tunnel_id may be used for another tunnel (originating at the same LSR) that goes to diff. destination? =20 No, and I don't see any reason why you would like to reuse the tunnel ID field (bit space is not an issue in any deployment).=20 Practically I won't reuse the tunnel ID on a different LSP going to another destination, because in that case we need to account for more info in LSP identification. Since the RFC doesn't say strictly that tunnel id has to be unique at an ingress LSR irrespective of destination of the LSPs, so I had some confusion over this. =20 Thanks once again, =20 Pranjal=20 =20 Info on this would be of great help. =20 Thanks in advance, Pranjal =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C69505.11E9BB6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Zafar,

      =          Thanks for the = clarification. Please refer inline my answers.

 

From: Zafar = Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, 21 June, = 2006 11:55 AM
To: Dutta, Pranjal; = mpls@ietf.org
Subject: RE: [mpls] Reg: = One clarification needed reg RFC 3209 on the scope ofTunnel ID =

 

 

 

From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, June 20, = 2006 3:00 AM
To: mpls@ietf.org
Subject: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID =

Hi All,

         =   RFC 3209 states regarding uniquely identifying a LSP Tunnel as = follows:

 

“A tunnel ID is part of the SESSION =
object.
   The SESSION object uniquely =
defines a traffic engineered tunnel.  =
The
 
 
 
Awduche, =
et =
al.           &nbs=
p; Standards =
Track           &n=
bsp;         [Page =
7]
 
RFC =
3209           =
Extensions to RSVP for LSP Tunnels      =
December 2001
 
 
   SENDER_TEMPLATE and FILTER_SPEC =
objects carry an LSP ID.  =
The
   SENDER_TEMPLATE (or FILTER_SPEC) =
object together with the =
SESSION
   object uniquely identifies an =
LSP tunnel”
 
So at the =
ingress LSR, a Session Object is identified with Tunnel ID, Dst =
IPV4/IPV6 Address of the Tunnel and Ext Tunnel ID (which can be set to =
source address). That means both tunnel_id and dst_addr uniquely =
identifies a LSP tunnel. 
 



You also need LSP ID; specifically (source =
IP address, Destination IP address, LSP ID, tunnel ID and ext tunnel =
ID) uniquely identify an LSP. =

Also note that a tunnel "can" have multiple LSP-es =
(e.g., during reopt).  
 
Yes, LSP ID can =
change during Reopt. /MBB or after restart. I understand that it’s =
also part of the key that identifies a =
LSP.



 
With =
respect to an ingress LSR does that mean that tunnel_id is specific to =
one particular destination  
 



 
 and =
the same tunnel_id may be used =
for
another =
tunnel (originating at the same LSR) that goes to diff. =
destination?
 



No, and I don't see any reason why you =
would like to reuse the tunnel ID field (bit space is not an issue in =
any deployment). 
Practically I won’t reuse the tunnel ID on a different =
LSP going to another destination, because in that case we need to =
account for more info in LSP =
identification.
Since the RFC doesn’t say strictly that tunnel id has =
to be unique at an ingress LSR irrespective of destination of the LSPs, =
so I had some confusion over =
this.
 
Thanks once =
again,
 
Pranjal =




 
Info on =
this would be of great help.
 
Thanks in =
advance,
Pranjal
 
 
 
 
 
 
 
 



 
------_=_NextPart_001_01C69505.11E9BB6C-- --===============0475068140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0475068140==-- From mpls-bounces@lists.ietf.org Thu Jun 22 07:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNBo-000293-JD; Thu, 22 Jun 2006 07:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNBn-00025j-7Y for mpls@ietf.org; Thu, 22 Jun 2006 07:17:35 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNBl-0004sC-EO for mpls@ietf.org; Thu, 22 Jun 2006 07:17:35 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 08:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Thu, 22 Jun 2006 08:02:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaUqp9Z2zpwNLCnRuu0hGSRFjtguAAt5WgA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 22 Jun 2006 06:02:33.0390 (UTC) FILETIME=[73FE24E0:01C695C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Rahul, Please see inline, =20 > -----Message d'origine----- > De : Rahul Aggarwal [mailto:rahul@juniper.net]=20 > Envoy=E9 : mardi 20 juin 2006 22:47 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : mpls@ietf.org > Objet : Re: [mpls] TR: working group last call on=20 > draft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 >=20 > Hi JL, >=20 > Sorry for the delay. Please see below: >=20 > On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi all, > > > > I transfer the below comments on this list, as it should be=20 > discussed=20 > > as part of last call comments. > > > > Regards, > > > > JL > > > > > -----Message d'origine----- > > > De : LE ROUX Jean-Louis RD-CORE-LAN > > > Envoy=E9 : jeudi 25 mai 2006 14:19 > > > =C0: > > > Objet : RE: working group last call on=20 > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Hi Rahul, Dimitri, Seisho > > > > > > Thanks for the great edit job, > > > > > > Find below a set of comments on this revision 05 > > > > > > Four technical points: > > > > > > 1: Section 8.1.2 Downstream notification > > > > > > The text in 8.1.2 is a bit unclear > > > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > > object(s) of a Resv message to the value, that was=20 > received in the > > > corresponding Path message. If the incoming Resv=20 > message carries a > > > Notify Request object then, the LSR MUST set the Notify node=20 > > > address > > > in the Notify Request object to the value, that was=20 > received in the > > > corresponding Path message", > > > >=20 >=20 > > > Which value? The sub-group originator? the notify address? >=20 > This should be the Router ID of the transit LSR if the=20 > transit LSR is merging more than one Resv with a Notify=20 > Request object. Ok, but it also applies when the LSR changes the sub-group originator id = to its own address doesn't it? >=20 > > > This is unclear. The prFrom mpls-bounces@lists.ietf.org Thu Jun 22 07:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNBo-000293-JD; Thu, 22 Jun 2006 07:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNBn-00025j-7Y for mpls@ietf.org; Thu, 22 Jun 2006 07:17:35 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNBl-0004sC-EO for mpls@ietf.org; Thu, 22 Jun 2006 07:17:35 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 08:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Thu, 22 Jun 2006 08:02:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaUqp9Z2zpwNLCnRuu0hGSRFjtguAAt5WgA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 22 Jun 2006 06:02:33.0390 (UTC) FILETIME=[73FE24E0:01C695C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Rahul, Please see inline, =20 > -----Message d'origine----- > De : Rahul Aggarwal [mailto:rahul@juniper.net]=20 > Envoy=E9 : mardi 20 juin 2006 22:47 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : mpls@ietf.org > Objet : Re: [mpls] TR: working group last call on=20 > draft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 >=20 > Hi JL, >=20 > Sorry for the delay. Please see below: >=20 > On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi all, > > > > I transfer the below comments on this list, as it should be=20 > discussed=20 > > as part of last call comments. > > > > Regards, > > > > JL > > > > > -----Message d'origine----- > > > De : LE ROUX Jean-Louis RD-CORE-LAN > > > Envoy=E9 : jeudi 25 mai 2006 14:19 > > > =C0: > > > Objet : RE: working group last call on=20 > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Hi Rahul, Dimitri, Seisho > > > > > > Thanks for the great edit job, > > > > > > Find below a set of comments on this revision 05 > > > > > > Four technical points: > > > > > > 1: Section 8.1.2 Downstream notification > > > > > > The text in 8.1.2 is a bit unclear > > > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > > object(s) of a Resv message to the value, that was=20 > received in the > > > corresponding Path message. If the incoming Resv=20 > message carries a > > > Notify Request object then, the LSR MUST set the Notify node=20 > > > address > > > in the Notify Request object to the value, that was=20 > received in the > > > corresponding Path message", > > > >=20 >=20 > > > Which value? The sub-group originator? the notify address? >=20 > This should be the Router ID of the transit LSR if the=20 > transit LSR is merging more than one Resv with a Notify=20 > Request object. Ok, but it also applies when the LSR changes the sub-group originator id = to its own address doesn't it? >=20 > > > This is unclear. The processing needs to be clarified. > > > We could update as follows: > > > > > > "If the incoming Resv message carries a Notify Request=20 > object then, > > > -If the sub-group originator ID is its own=20 > address, the LSR MUST=20 > > > set the Notify node address in the Notify Request object=20 > to its own=20 > > > address, in the Resv message that it sends upstream. > > > -If the sub group originator ID is not its own=20 > address, the LSR=20 > > > MUST propagate the Notify Request object unchanged, in the Resv=20 > > > message that it sends upstream." > > > >=20 > Shouldn't the transit LSR always set its own address in the=20 > Notify Request if it is merging multiple Resvs with Notify=20 > Request objects into a single Resv ? The current text is not=20 > clear on this either. A transit LSR should actually put its own address in the Notify Request = not only when it is merging multiple Resv, but also when it changes the = sub-group orignator id to its own address (even if there is no Resv = merging) >=20 > How about: >=20 > "A transit LSR sets the Sub-Group Originator ID in the=20 > FILTER_SPEC object(s) of a Resv message to the value, that=20 > was received in the corresponding Path message. If the=20 > incoming Resv message carries a Notify Request object then: >=20 > - If there is at least another incoming Resv message that=20 > carries a Notify Request object and the LSR merges these Resv=20 > messages into a single Resv message that is sent upstream,=20 > the LSR MUST set the Notify node address in the Notify=20 > Request object to its Router ID. >=20 > - Else the LSR MUST propagate the Notify Request object=20 > unchanged, in the Resv message that it sends upstream." See above comment >=20 >=20 > > > 2: Section 8.2 ResvConf > > > > > > Similar comment > > > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > > object(s) of a Resv message to the value, that was=20 > received in the > > > corresponding Path message. If any of the incoming=20 > Resv messages > > > corresponding to a single Path message carry a=20 > RESV_CONFIRM object > > > then the LSR MUST include a RESV_CONFIRM object in the=20 > > > corresponding > > > Resv message that it sends upstream and MUST set the receiver=20 > > > address > > > in the RESV_CONFIRM object to the value that was=20 > received in the > > > corresponding Resv message." > > > > > > Change to > > > > > > " > > > A transit LSR sets the Sub-Group Originator ID in the=20 > FILTER_SPEC > > > object(s) of a Resv message to the value, that was=20 > received in the > > > corresponding Path message. If any of the incoming=20 > Resv messages > > > corresponding to a single Path message carry a=20 > RESV_CONFIRM object > > > then the LSR MUST include a RESV_CONFIRM object in the=20 > > > corresponding > > > Resv message that it sends upstream. If the sub-group=20 > originator=20 > > > ID is its own address then > > > it MUST set the receiver address in the RESV_CONFIRM object to=20 > > > this addresse, else it MUST > > > propagate the object unchanged" > > > >=20 > Shouldn't the transit LSR always set its own address in the=20 > RESV_CONFIRM if it is merging multiple Resvs with=20 > RESV_CONFIRM objects into a single Resv ? The current text is=20 > not clear on this either. Same comment. Yes but IMO it should also do it when it changes the = sub-group originator id (even with no Resv merge)? >=20 > How about: >=20 > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > object(s) of a Resv message to the value that was received in=20 > the corresponding Path message. If an incoming Resv message=20 > corresponding to a single Path message carries a RESV_CONFIRM=20 > object then the LSR MUST include a RESV_CONFIRM object in the=20 > corresponding Resv message that it sends upstream and: >=20 > - If there is at least another incoming Resv message that=20 > carries a RESV_CONFIRM object and the LSR merges these Resv=20 > messages into a single Resv message that is sent upstream,=20 > the LSR Mocessing needs to be clarified. > > > We could update as follows: > > > > > > "If the incoming Resv message carries a Notify Request=20 > object then, > > > -If the sub-group originator ID is its own=20 > address, the LSR MUST=20 > > > set the Notify node address in the Notify Request object=20 > to its own=20 > > > address, in the Resv message that it sends upstream. > > > -If the sub group originator ID is not its own=20 > address, the LSR=20 > > > MUST propagate the Notify Request object unchanged, in the Resv=20 > > > message that it sends upstream." > > > >=20 > Shouldn't the transit LSR always set its own address in the=20 > Notify Request if it is merging multiple Resvs with Notify=20 > Request objects into a single Resv ? The current text is not=20 > clear on this either. A transit LSR should actually put its own address in the Notify Request = not only when it is merging multiple Resv, but also when it changes the = sub-group orignator id to its own address (even if there is no Resv = merging) >=20 > How about: >=20 > "A transit LSR sets the Sub-Group Originator ID in the=20 > FILTER_SPEC object(s) of a Resv message to the value, that=20 > was received in the corresponding Path message. If the=20 > incoming Resv message carries a Notify Request object then: >=20 > - If there is at least another incoming Resv message that=20 > carries a Notify Request object and the LSR merges these Resv=20 > messages into a single Resv message that is sent upstream,=20 > the LSR MUST set the Notify node address in the Notify=20 > Request object to its Router ID. >=20 > - Else the LSR MUST propagate the Notify Request object=20 > unchanged, in the Resv message that it sends upstream." See above comment >=20 >=20 > > > 2: Section 8.2 ResvConf > > > > > > Similar comment > > > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > > object(s) of a Resv message to the value, that was=20 > received in the > > > corresponding Path message. If any of the incoming=20 > Resv messages > > > corresponding to a single Path message carry a=20 > RESV_CONFIRM object > > > then the LSR MUST include a RESV_CONFIRM object in the=20 > > > corresponding > > > Resv message that it sends upstream and MUST set the receiver=20 > > > address > > > in the RESV_CONFIRM object to the value that was=20 > received in the > > > corresponding Resv message." > > > > > > Change to > > > > > > " > > > A transit LSR sets the Sub-Group Originator ID in the=20 > FILTER_SPEC > > > object(s) of a Resv message to the value, that was=20 > received in the > > > corresponding Path message. If any of the incoming=20 > Resv messages > > > corresponding to a single Path message carry a=20 > RESV_CONFIRM object > > > then the LSR MUST include a RESV_CONFIRM object in the=20 > > > corresponding > > > Resv message that it sends upstream. If the sub-group=20 > originator=20 > > > ID is its own address then > > > it MUST set the receiver address in the RESV_CONFIRM object to=20 > > > this addresse, else it MUST > > > propagate the object unchanged" > > > >=20 > Shouldn't the transit LSR always set its own address in the=20 > RESV_CONFIRM if it is merging multiple Resvs with=20 > RESV_CONFIRM objects into a single Resv ? The current text is=20 > not clear on this either. Same comment. Yes but IMO it should also do it when it changes the = sub-group originator id (even with no Resv merge)? >=20 > How about: >=20 > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > object(s) of a Resv message to the value that was received in=20 > the corresponding Path message. If an incoming Resv message=20 > corresponding to a single Path message carries a RESV_CONFIRM=20 > object then the LSR MUST include a RESV_CONFIRM object in the=20 > corresponding Resv message that it sends upstream and: >=20 > - If there is at least another incoming Resv message that=20 > carries a RESV_CONFIRM object and the LSR merges these Resv=20 > messages into a single Resv message that is sent upstream,=20 > the LSR MUST set the receiver address in the RESV_CONFIRM=20 > object to its Router ID. >=20 > - Else the LSR MUST propagate the RESV_CONFIRM object=20 > unchanged, in the Resv message that it sends upstream." >=20 This also applies when the LSR changes the sub-group originator id = without any Resv merge >=20 > > > > > > 3: Section 14.2 Sub-group based reoptimization > > > > > > The new path may intersect the old path, this is a case=20 > of rerouting=20 > > > and this is not covered by remerge procedures as described in=20 > > > section 18. Hence Transient Data duplication may occur during the=20 > > > time between the Resv is received and the PathTear is=20 > sent. To avoid=20 > > > data duplication the branch node must not start=20 > transmitting on the=20 > > > new path before the old path has been torn down, but this=20 > will lead=20 > > > to transient packet loss. > > > This should be clearly mentionned here IMO. > > > Actually the only way to avoid both transient duplication and=20 > > > transient packet loss is to rely on the global mb4b=20 > procedure with a=20 > > > new LSP id... > > > >=20 > How about adding the following to this section: >=20 > "Sub-Group based re-optimization may result in transient data=20 > duplication as the new Path messages for a set of S2L=20 > sub-LSPs may transit one or more nodes with the old Path=20 > state for the same set of S2L sub-LSPs. " The proposed text addresses my point and is fine with me >=20 >=20 > > > 4: Section 18.1.1 Remerge Procedure > > > > > > The text says > > > "The PathErr message MUST include all of the objects > > > normally included in a PathErr message, as well as one=20 > or more SUB- > > > LSP objects from the set of sub-LSPs associated with=20 > the matching > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > RECOMMENDED. This will allow the node that caused the=20 > re-merge to > > > identify the outgoing Path state associated with the valid=20 > > > portion of > > > the P2MP LSP. The set of SUB-LSP objects in the received Path=20 > > > message > > > MUST also be included" > > > > > > And then: > > > > > > "A node that receives a PathErr message that contains=20 > the Error=20 > > > Value > > > "Routing Problem/P2MP Remerge Detected" MUST determine=20 > if it is the > > > node that created the re-merge case. This is done by checking > > > whether there is any intersection between the set of SUB-LSP=20 > > > objects > > > associated with the matching P2MP LSP Path state and=20 > the set of=20 > > > SUB- > > > LSP objects in the received PathErr message. If there=20 > is, then the > > > node created the re-merge case." > > > > > > There is an issue here. Actually there will always be an=20 > > > intersection, because the PathErr includes the set of sub-lsp=20 > > > objects in the received Path... IMO for this procedure to=20 > work the=20 > > > PathErr MUST only include sub-LSP objects associated with the=20 > > > matching P2MP LSP state on the rermerge LSR and must not=20 > include the=20 > > > set of SUB-LSP objects in the received Path message. > > > By the way why are three objects recommended? > > > >=20 > I believe this was clarified by John Drake offline and no=20 > revisions were needed ? I will provide more comments in a following email. Best Regards, JL >=20 > > > > > > Also find below some minor edits: > > > > > > Section 6.1 > > > > > > ::=3D ; [ > > SECONDARY_EXPLICIT_ROUTE> ] > > > Change to: > > > ::=3D ; [ > > SECONDARY_RECORD_ROUTE> ] > > > >=20 > Ok. >=20 > > > Section 7.1 > > > change to > > > >=20 > Ok. >=20 > > > Section 8.1.2 > > > > > > "If this LSR subsequently receives a corresponding=20 > Notify message=20 > > > from > > > an upstream LSR than it MUST: > > > - send a Notify message downstream toward the Notify > > > node address that the LSR received in the Resv message. > > > - process the sub-group fUST set the receiver address in the RESV_CONFIRM=20 > object to its Router ID. >=20 > - Else the LSR MUST propagate the RESV_CONFIRM object=20 > unchanged, in the Resv message that it sends upstream." >=20 This also applies when the LSR changes the sub-group originator id = without any Resv merge >=20 > > > > > > 3: Section 14.2 Sub-group based reoptimization > > > > > > The new path may intersect the old path, this is a case=20 > of rerouting=20 > > > and this is not covered by remerge procedures as described in=20 > > > section 18. Hence Transient Data duplication may occur during the=20 > > > time between the Resv is received and the PathTear is=20 > sent. To avoid=20 > > > data duplication the branch node must not start=20 > transmitting on the=20 > > > new path before the old path has been torn down, but this=20 > will lead=20 > > > to transient packet loss. > > > This should be clearly mentionned here IMO. > > > Actually the only way to avoid both transient duplication and=20 > > > transient packet loss is to rely on the global mb4b=20 > procedure with a=20 > > > new LSP id... > > > >=20 > How about adding the following to this section: >=20 > "Sub-Group based re-optimization may result in transient data=20 > duplication as the new Path messages for a set of S2L=20 > sub-LSPs may transit one or more nodes with the old Path=20 > state for the same set of S2L sub-LSPs. " The proposed text addresses my point and is fine with me >=20 >=20 > > > 4: Section 18.1.1 Remerge Procedure > > > > > > The text says > > > "The PathErr message MUST include all of the objects > > > normally included in a PathErr message, as well as one=20 > or more SUB- > > > LSP objects from the set of sub-LSPs associated with=20 > the matching > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > RECOMMENDED. This will allow the node that caused the=20 > re-merge to > > > identify the outgoing Path state associated with the valid=20 > > > portion of > > > the P2MP LSP. The set of SUB-LSP objects in the received Path=20 > > > message > > > MUST also be included" > > > > > > And then: > > > > > > "A node that receives a PathErr message that contains=20 > the Error=20 > > > Value > > > "Routing Problem/P2MP Remerge Detected" MUST determine=20 > if it is the > > > node that created the re-merge case. This is done by checking > > > whether there is any intersection between the set of SUB-LSP=20 > > > objects > > > associated with the matching P2MP LSP Path state and=20 > the set of=20 > > > SUB- > > > LSP objects in the received PathErr message. If there=20 > is, then the > > > node created the re-merge case." > > > > > > There is an issue here. Actually there will always be an=20 > > > intersection, because the PathErr includes the set of sub-lsp=20 > > > objects in the received Path... IMO for this procedure to=20 > work the=20 > > > PathErr MUST only include sub-LSP objects associated with the=20 > > > matching P2MP LSP state on the rermerge LSR and must not=20 > include the=20 > > > set of SUB-LSP objects in the received Path message. > > > By the way why are three objects recommended? > > > >=20 > I believe this was clarified by John Drake offline and no=20 > revisions were needed ? I will provide more comments in a following email. Best Regards, JL >=20 > > > > > > Also find below some minor edits: > > > > > > Section 6.1 > > > > > > ::=3D ; [ > > SECONDARY_EXPLICIT_ROUTE> ] > > > Change to: > > > ::=3D ; [ > > SECONDARY_RECORD_ROUTE> ] > > > >=20 > Ok. >=20 > > > Section 7.1 > > > change to > > > >=20 > Ok. >=20 > > > Section 8.1.2 > > > > > > "If this LSR subsequently receives a corresponding=20 > Notify message=20 > > > from > > > an upstream LSR than it MUST: > > > - send a Notify message downstream toward the Notify > > > node address that the LSR received in the Resv message. > > > - process the sub-group fields of the FILTER_SPEC object in the > > > received Notify message, and modify their values in=20 > the Notify > > > message that is forwarded to match the sub-group field values > > > in the original Path message sent downstream by this LSR." > > > > > > Invert these two bullets > > > >=20 > Ok. >=20 > > > Section 8.2 > > > > > > "If this LSR subsequently receives a corresponding=20 > ResvConf message > > > from an upstream LSR then it MUST: > > > - send a ResvConf message downstream toward the=20 > receiver address=20 > > > that > > > the LSR received in the RESV_CONFIRM object in the=20 > Resv message. > > > - process the sub-group fields of the FILTER_SPEC object in the > > > received ResvConf message, and modify their values in the=20 > > > ResvConf > > > message that is forwarded to match the sub-group field values > > > in the original Path message sent downstream by this LSR." > > > > > > Invert these two bullets > > > >=20 > Ok. >=20 > > > Section 11.2 last sentence > > > > > > "Note the receiver of a ResvErr message is able to=20 > identify the=20 > > > errored outgoing Path [Change to: Resv] > > > message, and outgoing interface, based on the Sub-Group fields > > > received in the ResvErr message. > > >=20 > Ok. >=20 > > > > > Section 13 > > > > > > "A sender on a LAN uses a different label for sending=20 > traffic to each > > > node on the LAN that belongs to the P2MP LSP" > > > > > > This is not always the case, I would rather say > > > > > > "Downstream nodes for a given P2MP LSP on a LAN are likely to=20 > > > allocate a different label, in which case the sender has=20 > to perform=20 > > > replication"... > > > >=20 > Actually the procedures in this document imply that a sender=20 > on a LAN must do replication if there is more than one=20 > downstream receiver. Upstream labels are required to avoid this. >=20 > However I do realize that the first sentence is not entirely=20 > accurate. How > about: >=20 > "If there are multiple downstream LSRs on a LAN on a P2MP=20 > LSP, a sender LSR on the LAN has to perform replication. A=20 > separate copy of the data is unicast to each of the downstream LSRs" >=20 >=20 > > > Section 16 > > > > > > "Stitching and nesting > > > considerations and procedures are described further in=20 > [INT-REG]." > > > > > > Change to "Stitching and nesting > > > considerations and procedures are described further in=20 > > > [LSP-STITCH] and [RFC4206]." > > > > > > Section 17 > > > > > > Infact =3D> In fact > > > >=20 > Ok. >=20 > > > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object =3D> P2MP > > > LSP_IPv6 FILTER_SPEC object > > > >=20 > Ok. >=20 > > > Also some references need to be updated... > > > >=20 > Will do that. >=20 > Thanks for the detailed comments. >=20 > rahul >=20 > > > Best Regards, > > > > > > JL > > > > > > > -----Message d'origine----- > > > > De : owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa > > > Andersson Envoy=E9 : > > > > samedi 13 mai 2006 12:48 =C0 : mpls@ietf.org Cc : ccamp; > > > George Swallow; > > > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross Callon; Bill=20 > > > > Fenner Objet : working group last call on > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > Working Group, > > > > > > > > this initiates a two week working group last call on=20 > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > please send comments to the MPLS working group mailling list=20 > > > > and/or working co-chairs. > > > > > > > > The last call ends eob May 28th. > > > > > > > > The ccamp mailing list copied as this is a work that has an=20 > > > > overlap between the working groups. > > > > > > > > Loa and George > > > > > > > > > > > > > > > > -- > > > > Loa Andersson > > > > > > > > Principal Networking Architect > > > > Acreo AB phone: +46 8 632 77 14 > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > Kista, Sweden email: =20 > loa.andersson@acreo.se > > > > ields of the FILTER_SPEC object in the > > > received Notify message, and modify their values in=20 > the Notify > > > message that is forwarded to match the sub-group field values > > > in the original Path message sent downstream by this LSR." > > > > > > Invert these two bullets > > > >=20 > Ok. >=20 > > > Section 8.2 > > > > > > "If this LSR subsequently receives a corresponding=20 > ResvConf message > > > from an upstream LSR then it MUST: > > > - send a ResvConf message downstream toward the=20 > receiver address=20 > > > that > > > the LSR received in the RESV_CONFIRM object in the=20 > Resv message. > > > - process the sub-group fields of the FILTER_SPEC object in the > > > received ResvConf message, and modify their values in the=20 > > > ResvConf > > > message that is forwarded to match the sub-group field values > > > in the original Path message sent downstream by this LSR." > > > > > > Invert these two bullets > > > >=20 > Ok. >=20 > > > Section 11.2 last sentence > > > > > > "Note the receiver of a ResvErr message is able to=20 > identify the=20 > > > errored outgoing Path [Change to: Resv] > > > message, and outgoing interface, based on the Sub-Group fields > > > received in the ResvErr message. > > >=20 > Ok. >=20 > > > > > Section 13 > > > > > > "A sender on a LAN uses a different label for sending=20 > traffic to each > > > node on the LAN that belongs to the P2MP LSP" > > > > > > This is not always the case, I would rather say > > > > > > "Downstream nodes for a given P2MP LSP on a LAN are likely to=20 > > > allocate a different label, in which case the sender has=20 > to perform=20 > > > replication"... > > > >=20 > Actually the procedures in this document imply that a sender=20 > on a LAN must do replication if there is more than one=20 > downstream receiver. Upstream labels are required to avoid this. >=20 > However I do realize that the first sentence is not entirely=20 > accurate. How > about: >=20 > "If there are multiple downstream LSRs on a LAN on a P2MP=20 > LSP, a sender LSR on the LAN has to perform replication. A=20 > separate copy of the data is unicast to each of the downstream LSRs" >=20 >=20 > > > Section 16 > > > > > > "Stitching and nesting > > > considerations and procedures are described further in=20 > [INT-REG]." > > > > > > Change to "Stitching and nesting > > > considerations and procedures are described further in=20 > > > [LSP-STITCH] and [RFC4206]." > > > > > > Section 17 > > > > > > Infact =3D> In fact > > > >=20 > Ok. >=20 > > > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object =3D> P2MP > > > LSP_IPv6 FILTER_SPEC object > > > >=20 > Ok. >=20 > > > Also some references need to be updated... > > > >=20 > Will do that. >=20 > Thanks for the detailed comments. >=20 > rahul >=20 > > > Best Regards, > > > > > > JL > > > > > > > -----Message d'origine----- > > > > De : owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa > > > Andersson Envoy=E9 : > > > > samedi 13 mai 2006 12:48 =C0 : mpls@ietf.org Cc : ccamp; > > > George Swallow; > > > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross Callon; Bill=20 > > > > Fenner Objet : working group last call on > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > Working Group, > > > > > > > > this initiates a two week working group last call on=20 > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > please send comments to the MPLS working group mailling list=20 > > > > and/or working co-chairs. > > > > > > > > The last call ends eob May 28th. > > > > > > > > The ccamp mailing list copied as this is a work that has an=20 > > > > overlap between the working groups. > > > > > > > > Loa and George > > > > > > > > > > > > > > > > -- > > > > Loa Andersson > > > > > > > > Principal Networking Architect > > > > Acreo AB phone: +46 8 632 77 14 > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > Kista, Sweden email: =20 > loa.andersson@acreo.se > > > > loa@pi.se > > > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > > > > >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 07:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNBs-00029H-Fg; Thu, 22 Jun 2006 07:17:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNBp-00029C-Tl for mpls@ietf.org; Thu, 22 Jun 2006 07:17:37 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNBo-0004sV-GW for mpls@ietf.org; Thu, 22 Jun 2006 07:17:37 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 08:04:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Thu, 22 Jun 2006 08:03:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaUq0GVih/UO5WfRjiEswBRcvrGfQAB/rMgAC1x3HA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 22 Jun 2006 06:04:11.0971 (UTC) FILETIME=[AEC06930:01C695C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Rahul, all Actually, after thinking a bit more, it seems to me that a simpler = remerge procedure based on RRO analysis could be useful. If the RRO is carried in Path messages, the node where the remerge=20 occurs could easily identify the node that created the remerge, simply = by analyzing the two RROs. When a node detect a remerge it sends a PAthErr with a new object = (Remerge-Spec object) that identifies the remerge origin. This PathErr = carries the set of sub-LSPs received in the Path message that caused the = remerge. On receipt of such PAthErr, a node that see its own address in the=20 Remerge-spec object moves the set of sub-LSPs... =20 It seems that this procedure would require simpler processing... It requires the use of RRO, but this is the price to pay. Would that make sense? Best Regards, JL =20 > -----Message d'origine----- > De : Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Envoy=E9 : mardi 20 juin 2006 23:59 > =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis RD-CORE-LAN > Cc : mpls@ietf.org > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > Rahul, >=20 > Snipped, comments inline. >=20 > Thanks, >=20 > John > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > The text says > > > > "The PathErr message MUST include all of the objects > > > > normally included in a PathErr message, as well as=20 > one or more > SUB- > > > > LSP objects from the set of sub-LSPs associated with the > matching > > > > P2MP loa@pi.se > > > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/mpls > > > > >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 07:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNBs-00029H-Fg; Thu, 22 Jun 2006 07:17:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNBp-00029C-Tl for mpls@ietf.org; Thu, 22 Jun 2006 07:17:37 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNBo-0004sV-GW for mpls@ietf.org; Thu, 22 Jun 2006 07:17:37 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 08:04:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Thu, 22 Jun 2006 08:03:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaUq0GVih/UO5WfRjiEswBRcvrGfQAB/rMgAC1x3HA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 22 Jun 2006 06:04:11.0971 (UTC) FILETIME=[AEC06930:01C695C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Rahul, all Actually, after thinking a bit more, it seems to me that a simpler = remerge procedure based on RRO analysis could be useful. If the RRO is carried in Path messages, the node where the remerge=20 occurs could easily identify the node that created the remerge, simply = by analyzing the two RROs. When a node detect a remerge it sends a PAthErr with a new object = (Remerge-Spec object) that identifies the remerge origin. This PathErr = carries the set of sub-LSPs received in the Path message that caused the = remerge. On receipt of such PAthErr, a node that see its own address in the=20 Remerge-spec object moves the set of sub-LSPs... =20 It seems that this procedure would require simpler processing... It requires the use of RRO, but this is the price to pay. Would that make sense? Best Regards, JL =20 > -----Message d'origine----- > De : Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Envoy=E9 : mardi 20 juin 2006 23:59 > =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis RD-CORE-LAN > Cc : mpls@ietf.org > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > Rahul, >=20 > Snipped, comments inline. >=20 > Thanks, >=20 > John > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > The text says > > > > "The PathErr message MUST include all of the objects > > > > normally included in a PathErr message, as well as=20 > one or more > SUB- > > > > LSP objects from the set of sub-LSPs associated with the > matching > > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > > RECOMMENDED. This will allow the node that caused=20 > the re-merge > to > > > > identify the outgoing Path state associated with the valid=20 > > > > portion of > > > > the P2MP LSP. The set of SUB-LSP objects in the=20 > received Path=20 > > > > message > > > > MUST also be included" > > > > > > > > And then: > > > > > > > > "A node that receives a PathErr message that=20 > contains the Error=20 > > > > Value > > > > "Routing Problem/P2MP Remerge Detected" MUST=20 > determine if it is > the > > > > node that created the re-merge case. This is done=20 > by checking > > > > whether there is any intersection between the set of SUB-LSP=20 > > > > objects > > > > associated with the matching P2MP LSP Path state and=20 > the set of=20 > > > > SUB- > > > > LSP objects in the received PathErr message. If=20 > there is, then > the > > > > node created the re-merge case." > > > > > > > > There is an issue here. Actually there will always be an=20 > > > > intersection, because the PathErr includes the set of sub-lsp=20 > > > > objects in the received Path... IMO for this procedure=20 > to work the=20 > > > > PathErr MUST only include sub-LSP objects associated with the=20 > > > > matching P2MP LSP state on the rermerge LSR and must=20 > not include=20 > > > > the set of SUB-LSP objects in the received Path message. > > > > By the way why are three objects recommended? > > > > > >=20 > > I believe this was clarified by John Drake offline and no revisions > were > > needed ? > Rahul, >=20 > Here's the e-mail I sent to JL: >=20 > "JL, >=20 > The text was originally stated as you stated. The issue is=20 > that the set of sub-LSPs associated with the interface on the=20 > node that caused the re-merge condition may have more members=20 > than the set of sub-LSPs in the received Path message, and=20 > you only want to move the ones that were in the received Path message. >=20 > Adrian was the one who initially pointed this and he proposed=20 > creating a different object/type for the set of sub-LSPs in=20 > the received Path message. I think this is reasonable solution. >=20 > Thanks, >=20 > John" >=20 > As you can see from the last paragraph, we do need to create=20 > a new object/type. >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls LSP Path state. A minimum of three SUB-LSP objects is > > > > RECOMMENDED. This will allow the node that caused=20 > the re-merge > to > > > > identify the outgoing Path state associated with the valid=20 > > > > portion of > > > > the P2MP LSP. The set of SUB-LSP objects in the=20 > received Path=20 > > > > message > > > > MUST also be included" > > > > > > > > And then: > > > > > > > > "A node that receives a PathErr message that=20 > contains the Error=20 > > > > Value > > > > "Routing Problem/P2MP Remerge Detected" MUST=20 > determine if it is > the > > > > node that created the re-merge case. This is done=20 > by checking > > > > whether there is any intersection between the set of SUB-LSP=20 > > > > objects > > > > associated with the matching P2MP LSP Path state and=20 > the set of=20 > > > > SUB- > > > > LSP objects in the received PathErr message. If=20 > there is, then > the > > > > node created the re-merge case." > > > > > > > > There is an issue here. Actually there will always be an=20 > > > > intersection, because the PathErr includes the set of sub-lsp=20 > > > > objects in the received Path... IMO for this procedure=20 > to work the=20 > > > > PathErr MUST only include sub-LSP objects associated with the=20 > > > > matching P2MP LSP state on the rermerge LSR and must=20 > not include=20 > > > > the set of SUB-LSP objects in the received Path message. > > > > By the way why are three objects recommended? > > > > > >=20 > > I believe this was clarified by John Drake offline and no revisions > were > > needed ? > Rahul, >=20 > Here's the e-mail I sent to JL: >=20 > "JL, >=20 > The text was originally stated as you stated. The issue is=20 > that the set of sub-LSPs associated with the interface on the=20 > node that caused the re-merge condition may have more members=20 > than the set of sub-LSPs in the received Path message, and=20 > you only want to move the ones that were in the received Path message. >=20 > Adrian was the one who initially pointed this and he proposed=20 > creating a different object/type for the set of sub-LSPs in=20 > the received Path message. I think this is reasonable solution. >=20 > Thanks, >=20 > John" >=20 > As you can see from the last paragraph, we do need to create=20 > a new object/type. >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 09:36:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPKZ-0007el-MM; Thu, 22 Jun 2006 09:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPKY-0007eg-0e for mpls@ietf.org; Thu, 22 Jun 2006 09:34:46 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtPKX-0004tE-5R for mpls@ietf.org; Thu, 22 Jun 2006 09:34:45 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 22 Jun 2006 06:34:44 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="556896252:sNHT45989168" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 06:34:41 -0700 Date: Thu, 22 Jun 2006 06:34:41 -0700 (PDT) From: Rahul Aggarwal To: LE ROUX Jean-Louis RD-CORE-LAN Subject: RE: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: Message-ID: <20060622062500.U84451@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-OriginalArrivalTime: 22 Jun 2006 13:34:41.0915 (UTC) FILETIME=[9DDA8CB0:01C69600] X-Spam-Score: 0.0 (/) X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi JL, Please see below: On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Rahul, > > Please see inline, > > > > -----Message d'origine----- > > De : Rahul Aggarwal [mailto:rahul@juniper.net] > > Envoy=E9 : mardi 20 juin 2006 22:47 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > > Cc : mpls@ietf.org > > Objet : Re: [mpls] TR: working group last call on > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Hi JL, > > > > Sorry for the delay. Please see below: > > > > On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > > > Hi all, > > > > > > I transfer the below comments on this list, as it should be > > discussed > > > as part of last call comments. > > > > > > Regards, > > > > > > JL > > > > > > > -----Message d'origine----- > > > > De : LE ROUX Jean-Louis RD-CORE-LAN > > > > Envoy=E9 : jeudi 25 mai 2006 14:19 > > > > =C0: > > > > Objet : RE: working group last call on > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > Hi Rahul, Dimitri, Seisho > > > > > > > > Thanks for the great edit job, > > > > > > > > Find below a set of comments on this revision 05 > > > > > > > > Four technical points: > > > > > > > > 1: Section 8.1.2 Downstream notification > > > > > > > > The text in 8.1.2 is a bit unclear > > > > > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > > > object(s) of a Resv message to the value, that was > > received in the > > > > corresponding Path message. If the incoming Resv > > message carries a > > > > Notify Request object then, the LSR MUST set the Notify node > > > > address > > > > in the Notify Request object to the value, that was > > received in the > > > > corresponding Path message", > > > > > > > > > > > > Which value? The sub-group originator? the notify address? > > > > This should be the Router ID of the transit LSR if the > > transit LSR is merging more than one Resv with a Notify > > Request object. > > Ok, but it also applies when the LSR changes the sub-group originator id >to its own address doesn't it? > Yes, you are right. > > > > > > This is unclear. The processing needs to be clarified. > > > > We could update as follows: > > > > > > > > "If the incoming Resv message carries a Notify Request > > object then, > > > > =09=09-If the sub-group originator ID is its own > > address, the LSR MUST > > > > set the Notify node address in the Notify Request object > > to its own > > > > address, in the Resv message that it sends upstream. > > > > =09 -If the sub group originator ID is not its own > > address, the LSR > > > > MUST propagate the Notify Request object unchanged, in the Resv > > > > message that it sends upstream." > > > > > > > > Shouldn't the transit LSR always set its own address in the > > Notify Request if it is merging multiple Resvs with Notify > > Request objects into a single Resv ? The current text is not > > clear on this either. > > A transit LSR should actually put its own address in the Notify Request n= ot only when it is merging multiple Resv, but also when it changes the sub-= group orignator id to its own address (even if there is no Resv merging) > > > > > How about: > > > > "A transit LSR sets the Sub-Group Originator ID in the > > FILTER_SPEC object(s) of a Resv message to the value, that > > was received in the corresponding Path message. If the > > incoming Resv message carries a Notify Request object then: > > > > - If there is at least another incoming Resv message that > > carries a Notify Request object and the LSR merges these Resv > > messages into a single Resv message that is sent upstream, > > the LSR MUST set the Notify node address in the Notify > > Request object to its Router ID. > > > > - Else the LSR MUST propagate the Notify Request object > > unchanged, in the Resv message that it sends upstream." > > See above comment > How about adding a bullet between these two bullets: "- Else if the LSR sets the Sub-Group Originator ID in the outgoing Path message, that corresponds to the received Resv message, to its own address, the LSR MUST set the Notify node address in the Notify Request obj= ect to its Router ID." > > > > > > > > 2: Section 8.2 ResvConf > > > > > > > > Similar comment > > > > > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > > > object(s) of a Resv message to the value, that was > > received in the > > > > corresponding Path message. If any of the incoming > > Resv messages > > > > corresponding to a single Path message carry a > > RESV_CONFIRM object > > > > then the LSR MUST include a RESV_CONFIRM object in the > > > > corresponding > > > > Resv message that it sends upstream and MUST set the receiver > > > > address > > > > in the RESV_CONFIRM object to the value that was > > received in the > > > > corresponding Resv message." > > > > > > > > Change to > > > > > > > > " > > > > A transit LSR sets the Sub-Group Originator ID in the > > FILTER_SPEC > > > > object(s) of a Resv message to the value, that was > > received in the > > > > corresponding Path message. If any of the incoming > > Resv messages > > > > corresponding to a single Path message carry a > > RESV_CONFIRM object > > > > then the LSR MUST include a RESV_CONFIRM object in the > > > > corresponding > > > > Resv message that it sends upstream. If the sub-group > > originator > > > > ID is its own address then > > > > it MUST set the receiver address in the RESV_CONFIRM object to > > > > this addresse, else it MUST > > > > propagate the object unchanged" > > > > > > > > Shouldn't the transit LSR always set its own address in the > > RESV_CONFIRM if it is merging multiple Resvs with > > RESV_CONFIRM objects into a single Resv ? The current text is > > not clear on this either. > > Same comment. Yes but IMO it should also do it when it changes the > sub-group originator id (even with no Resv merge)? > That is correct. > > > > How about: > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > object(s) of a Resv message to the value that was received in > > the corresponding Path message. If an incoming Resv message > > corresponding to a single Path message carries a RESV_CONFIRM > > object then the LSR MUST include a RESV_CONFIRM object in the > > corresponding Resv message that it sends upstream and: > > > > - If there is at least another incoming Resv message that > > carries a RESV_CONFIRM object and the LSR merges these Resv > > messages into a single Resv message that is sent upstream, > > the LSR MUST set the receiver address in the RESV_CONFIRM > > object to its Router ID. > > > > - Else the LSR MUST propagate the RESV_CONFIRM object > > unchanged, in the Resv message that it sends upstream." > > > > This also applies when the LSR changes the sub-group originator id withou= t > any Resv merge > How about adding a bullet in between these two bullets: "- If the LSR sets the Sub-Group Originator ID in the outgoing Path message, that corresponds to the received Resv message, to its own address, the LSR MUST set the receiver address in the RESV_CONFIRM object to its Router ID." thanks, rahul > > > > > > > > > > 3: Section 14.2 Sub-group based reoptimization > > > > > > > > The new path may intersect the old path, this is a case > > of rerouting > > > > and this is not covered by remerge procedures as described in > > > > section 18. Hence Transient Data duplication may occur during the > > > > time between the Resv is received and the PathTear is > > sent. To avoid > > > > data duplication the branch node must not start > > transmitting on the > > > > new path before the old path has been torn down, but this > > will lead > > > > to transient packet loss. > > > > This should be clearly mentionned here IMO. > > > > Actually the only way to avoid both transient duplication and > > > > transient packet loss is to rely on the global mb4b > > procedure with a > > > > new LSP id... > > > > > > > > How about adding the following to this section: > > > > "Sub-Group based re-optimization may result in transient data > > duplication as the new Path messages for a set of S2L > > sub-LSPs may transit one or more nodes with the old Path > > state for the same set of S2L sub-LSPs. " > > The proposed text addresses my point and is fine with me > > > > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > The text says > > > > "The PathErr message MUST include all of the objects > > > > normally included in a PathErr message, as well as one > > or more SUB- > > > > LSP objects from the set of sub-LSPs associated with > > the matching > > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > > RECOMMENDED. This will allow the node that caused the > > re-merge to > > > > identify the outgoing Path state associated with the valid > > > > portion of > > > > the P2MP LSP. The set of SUB-LSP objects in the received Path > > > > message > > > > MUST also be included" > > > > > > > > And then: > > > > > > > > "A node that receives a PathErr message that contains > > the Error > > > > Value > > > > "Routing Problem/P2MP Remerge Detected" MUST determine > > if it is the > > > > node that created the re-merge case. This is done by checking > > > > whether there is any intersection between the set of SUB-LSP > > > > objects > > > > associated with the matching P2MP LSP Path state and > > the set of > > > > SUB- > > > > LSP objects in the received PathErr message. If there > > is, then the > > > > node created the re-merge case." > > > > > > > > There is an issue here. Actually there will always be an > > > > intersection, because the PathErr includes the set of sub-lsp > > > > objects in the received Path... IMO for this procedure to > > work the > > > > PathErr MUST only include sub-LSP objects associated with the > > > > matching P2MP LSP state on the rermerge LSR and must not > > include the > > > > set of SUB-LSP objects in the received Path message. > > > > By the way why are three objects recommended? > > > > > > > > I believe this was clarified by John Drake offline and no > > revisions were needed ? > > I will provide more comments in a following email. > > Best Regards, > > JL > > > > > > > > > > > Also find below some minor edits: > > > > > > > > Section 6.1 > > > > > > > > ::=3D ; [ > > > SECONDARY_EXPLICIT_ROUTE> ] > > > > Change to: > > > > ::=3D ; [ > > > SECONDARY_RECORD_ROUTE> ] > > > > > > > > Ok. > > > > > > Section 7.1 > > > > change to > > > > > > > > Ok. > > > > > > Section 8.1.2 > > > > > > > > "If this LSR subsequently receives a corresponding > > Notify message > > > > from > > > > an upstream LSR than it MUST: > > > > - send a Notify message downstream toward the Notify > > > > node address that the LSR received in the Resv message. > > > > - process the sub-group fields of the FILTER_SPEC object in the > > > > received Notify message, and modify their values in > > the Notify > > > > message that is forwarded to match the sub-group field values > > > > in the original Path message sent downstream by this LSR." > > > > > > > > Invert these two bullets > > > > > > > > Ok. > > > > > > Section 8.2 > > > > > > > > "If this LSR subsequently receives a corresponding > > ResvConf message > > > > from an upstream LSR then it MUST: > > > > - send a ResvConf message downstream toward the > > receiver address > > > > that > > > > the LSR received in the RESV_CONFIRM object in the > > Resv message. > > > > - process the sub-group fields of the FILTER_SPEC object in the > > > > received ResvConf message, and modify their values in the > > > > ResvConf > > > > message that is forwarded to match the sub-group field values > > > > in the original Path message sent downstream by this LSR." > > > > > > > > Invert these two bullets > > > > > > > > Ok. > > > > > > Section 11.2 last sentence > > > > > > > > "Note the receiver of a ResvErr message is able to > > identify the > > > > errored outgoing Path [Change to: Resv] > > > > message, and outgoing interface, based on the Sub-Group fields > > > > received in the ResvErr message. > > > > > > > Ok. > > > > > > > > > Section 13 > > > > > > > > "A sender on a LAN uses a different label for sending > > traffic to each > > > > node on the LAN that belongs to the P2MP LSP" > > > > > > > > This is not always the case, I would rather say > > > > > > > > "Downstream nodes for a given P2MP LSP on a LAN are likely to > > > > allocate a different label, in which case the sender has > > to perform > > > > replication"... > > > > > > > > Actually the procedures in this document imply that a sender > > on a LAN must do replication if there is more than one > > downstream receiver. Upstream labels are required to avoid this. > > > > However I do realize that the first sentence is not entirely > > accurate. How > > about: > > > > "If there are multiple downstream LSRs on a LAN on a P2MP > > LSP, a sender LSR on the LAN has to perform replication. A > > separate copy of the data is unicast to each of the downstream LSRs" > > > > > > > > Section 16 > > > > > > > > "Stitching and nesting > > > > considerations and procedures are described further in > > [INT-REG]." > > > > > > > > Change to "Stitching and nesting > > > > considerations and procedures are described further in > > > > [LSP-STITCH] and [RFC4206]." > > > > > > > > Section 17 > > > > > > > > Infact =3D> In fact > > > > > > > > Ok. > > > > > > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object =3D> P2MP > > > > LSP_IPv6 FILTER_SPEC object > > > > > > > > Ok. > > > > > > Also some references need to be updated... > > > > > > > > Will do that. > > > > Thanks for the detailed comments. > > > > rahul > > > > > > Best Regards, > > > > > > > > JL > > > > > > > > > -----Message d'origine----- > > > > > De : owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa > > > > Andersson Envoy=E9 : > > > > > samedi 13 mai 2006 12:48 =C0 : mpls@ietf.org Cc : ccamp; > > > > George Swallow; > > > > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross Callon; Bill > > > > > Fenner Objet : working group last call on > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > Working Group, > > > > > > > > > > this initiates a two week working group last call on > > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > please send comments to the MPLS working group mailling list > > > > > and/or working co-chairs. > > > > > > > > > > The last call ends eob May 28th. > > > > > > > > > > The ccamp mailing list copied as this is a work that has an > > > > > overlap between the working groups. > > > > > > > > > > Loa and George > > > > > > > > > > > > > > > > > > > > -- > > > > > Loa Andersson > > > > > > > > > > Principal Networking Architect > > > > > Acreo AB phone: +46 8 632 77 14 > > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > > Kista, Sweden email: > > loa.andersson@acreo.se > > > > > loa@pi.se > > > > > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/mpls > > > > > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 09:55:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPcQ-0003IF-TX; Thu, 22 Jun 2006 09:53:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPcP-0003IA-41 for mpls@ietf.org; Thu, 22 Jun 2006 09:53:13 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtPcN-0005xB-Pd for mpls@ietf.org; Thu, 22 Jun 2006 09:53:13 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 22 Jun 2006 06:53:12 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="561761877:sNHT32458016" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 06:53:10 -0700 Date: Thu, 22 Jun 2006 06:53:10 -0700 (PDT) From: Rahul Aggarwal To: LE ROUX Jean-Louis RD-CORE-LAN Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: Message-ID: <20060622063524.F84451@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-OriginalArrivalTime: 22 Jun 2006 13:53:10.0878 (UTC) FILETIME=[32D8DFE0:01C69603] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi JL, On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Rahul, all > > Actually, after thinking a bit more, it seems to me that a simpler remerg= e procedure based on RRO analysis could be useful. > If the RRO is carried in Path messages, the node where the remerge > occurs could easily identify the node that created the remerge, simply by= analyzing the two RROs. > When a node detect a remerge it sends a PAthErr with a new object (Remerg= e-Spec object) that identifies the remerge origin. This PathErr carries the= set of sub-LSPs received in the Path message that caused the remerge. > On receipt of such PAthErr, a node that see its own address in the > Remerge-spec object moves the set of sub-LSPs... > > It seems that this procedure would require simpler processing... > It requires the use of RRO, but this is the price to pay. > I think this is reasonable. If it is desriable to fix remerge in the control plane this is a reasonable tradeoff. Else the spec has the option to fix remerge in the data plane. > Would that make sense? > Would you like to propose the modified text ? Thanks, rahul > Best Regards, > > JL > > > > -----Message d'origine----- > > De : Drake, John E [mailto:John.E.Drake2@boeing.com] > > Envoy=E9 : mardi 20 juin 2006 23:59 > > =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis RD-CORE-LAN > > Cc : mpls@ietf.org > > Objet : RE: [mpls] TR: working group last call > > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > Rahul, > > > > Snipped, comments inline. > > > > Thanks, > > > > John > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > The text says > > > > > "The PathErr message MUST include all of the objects > > > > > normally included in a PathErr message, as well as > > one or more > > SUB- > > > > > LSP objects from the set of sub-LSPs associated with the > > matching > > > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > > > RECOMMENDED. This will allow the node that caused > > the re-merge > > to > > > > > identify the outgoing Path state associated with the valid > > > > > portion of > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > received Path > > > > > message > > > > > MUST also be included" > > > > > > > > > > And then: > > > > > > > > > > "A node that receives a PathErr message that > > contains the Error > > > > > Value > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > determine if it is > > the > > > > > node that created the re-merge case. This is done > > by checking > > > > > whether there is any intersection between the set of SUB-LSP > > > > > objects > > > > > associated with the matching P2MP LSP Path state and > > the set of > > > > > SUB- > > > > > LSP objects in the received PathErr message. If > > there is, then > > the > > > > > node created the re-merge case." > > > > > > > > > > There is an issue here. Actually there will always be an > > > > > intersection, because the PathErr includes the set of sub-lsp > > > > > objects in the received Path... IMO for this procedure > > to work the > > > > > PathErr MUST only include sub-LSP objects associated with the > > > > > matching P2MP LSP state on the rermerge LSR and must > > not include > > > > > the set of SUB-LSP objects in the received Path message. > > > > > By the way why are three objects recommended? > > > > > > > > > > > I believe this was clarified by John Drake offline and no revisions > > were > > > needed ? > > Rahul, > > > > Here's the e-mail I sent to JL: > > > > "JL, > > > > The text was originally stated as you stated. The issue is > > that the set of sub-LSPs associated with the interface on the > > node that caused the re-merge condition may have more members > > than the set of sub-LSPs in the received Path message, and > > you only want to move the ones that were in the received Path message. > > > > Adrian was the one who initially pointed this and he proposed > > creating a different object/type for the set of sub-LSPs in > > the received Path message. I think this is reasonable solution. > > > > Thanks, > > > > John" > > > > As you can see from the last paragraph, we do need to create > > a new object/type. > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 14:20:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTl3-00074n-Co; Thu, 22 Jun 2006 14:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTl1-00071c-Qd for mpls@ietf.org; Thu, 22 Jun 2006 14:18:23 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTl1-0005VC-Fr for mpls@ietf.org; Thu, 22 Jun 2006 14:18:23 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 22 Jun 2006 11:18:23 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="561831917:sNHT33416684" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 11:18:22 -0700 Date: Thu, 22 Jun 2006 11:18:22 -0700 (PDT) From: Rahul Aggarwal To: mpls@ietf.org, Yakov Rekhter Message-ID: <20060622111133.M5846@sapphire.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 22 Jun 2006 18:18:22.0620 (UTC) FILETIME=[3EFC05C0:01C69628] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: fenner@research.att.com, ccamp , rcallon@juniper.net Subject: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Folks, Yakov brought up the issue of P2MP ID, Tunnel ID, Extended Tunnel ID semantics as part of the last call and a discussion followed on this list. In order to resolve this discussion I had proposed some text. I have received some comments on this offline and want to move this discussion to a broader audience. Please comment on the text changes below, if you have objections or suggestions. Else this will be incorporated in the next version of the spec. How about the following rephrasing: 1. Section 4.1: " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session which includes the P2MP ID, a tunnel ID and an extended tunnel ID. The fields of a P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP Identifier (P2MP ID) field. The P2MP ID provides an identifier for the set of destinations of the P2MP TE Tunnel." to " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session which includes a tuple , where the P2MP Identifier (P2MP ID) is unique within the scope of the IP address of the ingress LSR. The Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP Tunnel identifier, carried in the P2MP SESSION object, is unique within the same scope as the ingress LSR IP address. The fields of the P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP ID field." 2. Section 4.2. " A P2MP LSP is identified by the combination of the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION object, and the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is defined in section 20.2." to " A P2MP LSP is identified by the combination of the P2MP ID, Extended Tunnel ID that are part of the P2MP SESSION object, and the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is defined in section 20.2." 3. 19.1.1 "P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP ID and identifies the set of destinations of the P2MP Tunnel." to "P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP Identifier that is unique within the scope of the Ingress LSR IP address carried in the Extended Tunnel ID. 4. 19.1.1 "Tunnel ID A 16-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel." to "Tunnel ID A 16-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It SHOULD be set to 0 by the ingress LSR and be ignored on receipt." 5. "Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-PID pair may place their IPv4 address here as a globally unique identifier [RFC3209]." to "Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. This identifier MUST be set to the ingress LSR's IPv4 address." 6. 19.1.2 "This is same as the P2MP IPv4 LSP SESSION Object with the difference that the extended tunnel ID may be set to a 16 byte identifier [RFC3209]." to "This is same as the P2MP IPv4 LSP SESSION Object with the difference that the extended tunnel ID MUST be set to a 16 byte identifier that is the ingress LSR's IPv6 address." 7. 19.2.1 " IPv4 tunnel sender address See [RFC3209]" to" "IPv4 tunnel sender address. This address MUST be the same as the address in the Extended Tunnel ID field of the SESSION object." 8. 19.2.2 "IPv6 tunnel sender address See [RFC3209]" to "IPv6 tunnel sender address. This address MUST be the same as the address in the Extended Tunnel ID field of the SESSION object." Thanks, rahul _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 15:12:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUZR-0006y8-WA; Thu, 22 Jun 2006 15:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUZP-0006xv-K4 for mpls@ietf.org; Thu, 22 Jun 2006 15:10:27 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUZP-0004eQ-6j for mpls@ietf.org; Thu, 22 Jun 2006 15:10:27 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FtUZC-00018P-N3; Thu, 22 Jun 2006 15:10:15 -0400 Message-Id: <7.0.1.0.2.20060622145339.043aa0d0@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 22 Jun 2006 15:10:18 -0400 To: Rahul Aggarwal From: Lou Berger Subject: Re: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] In-Reply-To: <20060622111133.M5846@sapphire.juniper.net> References: <20060622111133.M5846@sapphire.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: fenner@research.att.com, mpls@ietf.org, rcallon@juniper.net, ccamp X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, Here's one (but not the only) comment that was made off list. Also there were already several comments made on these points on the list. My comment still applies, and please consider this as an "objection" to the proposed text: At 01:20 PM 6/22/2006, Lou Berger wrote: >[...] >At 05:23 PM 6/20/2006, Rahul Aggarwal wrote: >>Hi All, >> >>Attached is draft-ietf-mpls-rsvp-te-p2mp-06.txt that incorporates changes >>to address Last call comments. >> >>Please let me know if you have any comments on *only the changes made to >>address LC comments* i.e. diff of v05 and v06 by this Friday. >> >>A brief summary of changes: >> >>1. Editorial changes requested by Benjamin Niven - see MPLS mailing list. >>2. Several editorial and non editorial changes requestd by Adrian Farrel - >>see MPLS mailing list for Adrian's comments and my response. There may be >>one or two open items here. Once Adrian looks at my response these should >>be resolved quickly. >>3. Several editorial and non-editorial changes requestd by JL - see MPLS >>mailing list for JL's comments and my response. >>4. Clarification of tunnel ID and extended Tunnel ID semantics as >>requested by Yakov Rekhter and follow on comments by Zafar Ali and George >>Swallow. > The objection: >I don't have any issues with the changes mentioned by Zafer and >George, but I didn't see closure on the issue debated by Adrian and >Yakov. Specifically on the issue of if extended tunnel ID had to >equal the node ID of the sender. I did see a position state, that I >too agree with, i.e., that it should be permitted and may be >required in some environments (e.g., FRR) but may not be required in >all environments so should be left as before. Also, as I read the >mails most were in favor of leaving tunnel ID as is, i.e., not >requiring it to be set to zero. This doesn't match what was done in >this past rev. In summary, my position is: 1) That the extended tunnel ID remain as defined in the previous version, i.e., retain the semantics from rfc3209/rfc3473. I think adding a restriction for environments where FRR is used is acceptable. (This spec covers GMPLS and non-packet environments too!) 2) That Tunnel ID remain as defined in previous version, i.e., retain the semantics from rfc3209/rfc3473. The specifics of the text below is dependent on consensus on these points. Lou At 02:18 PM 6/22/2006, Rahul Aggarwal wrote: >Hi Folks, > >Yakov brought up the issue of P2MP ID, Tunnel ID, Extended Tunnel ID >semantics as part of the last call and a discussion followed on this list. > >In order to resolve this discussion I had proposed some text. I have >received some comments on this offline and want to move this discussion to >a broader audience. > >Please comment on the text changes below, if you have objections or >suggestions. Else this will be incorporated in the next version of the >spec. > >How about the following rephrasing: > >1. > >Section 4.1: > >" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes the P2MP ID, a tunnel > ID and an extended tunnel ID. > > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP Identifier (P2MP ID) field. > > The P2MP ID provides an identifier for the set of destinations of the > P2MP TE Tunnel." > >to > >" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is >identified by a P2MP SESSION object. This object contains the >identifier of the P2MP Session which includes a tuple >, where the P2MP Identifier (P2MP >ID) is unique within the scope of the IP address of the ingress LSR. The >Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP >Tunnel identifier, carried in the P2MP SESSION object, is unique within >the same scope as the ingress LSR IP address. > >The fields of the P2MP SESSION object are identical to those of the >SESSION object defined in [RFC3209] except that the Tunnel Endpoint >Address field is replaced by the P2MP ID field." > >2. > >Section 4.2. > >" A P2MP LSP is identified by the combination of the P2MP ID, Tunnel > ID, and Extended Tunnel ID that are part of the P2MP SESSION object, > and the tunnel sender address and LSP ID fields of the P2MP > SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is > defined in section 20.2." > >to > >" A P2MP LSP is identified by the combination of the P2MP ID, >Extended Tunnel ID that are part of the P2MP SESSION object, >and the tunnel sender address and LSP ID fields of the P2MP >SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is >defined in section 20.2." > >3. > >19.1.1 > >"P2MP ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP ID and identifies the set of destinations of the P2MP > Tunnel." > >to > >"P2MP ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP Identifier that is unique within the scope of the Ingress LSR > IP address carried in the Extended Tunnel ID. > >4. >19.1.1 > >"Tunnel ID > > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel." > >to > >"Tunnel ID > > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It SHOULD be set to 0 > by the ingress LSR and be ignored on receipt." > > >5. > >"Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Normally set to > all zeros. Ingress nodes that wish to narrow the scope of a > SESSION to the ingress-PID pair may place their IPv4 address > here as a globally unique identifier [RFC3209]." > >to > >"Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. This identifier > MUST be set to the ingress LSR's IPv4 address." > >6. > >19.1.2 > >"This is same as the P2MP IPv4 LSP SESSION Object with the difference > that the extended tunnel ID may be set to a 16 byte identifier > [RFC3209]." > >to > >"This is same as the P2MP IPv4 LSP SESSION Object with the difference > that the extended tunnel ID MUST be set to a 16 byte identifier that is >the ingress LSR's IPv6 address." > >7. > >19.2.1 > >" IPv4 tunnel sender address > See [RFC3209]" > >to" > >"IPv4 tunnel sender address. This address MUST be the same as the address >in the Extended Tunnel ID field of the SESSION object." > >8. > >19.2.2 > >"IPv6 tunnel sender address > See [RFC3209]" > >to > >"IPv6 tunnel sender address. This address MUST be the same as the address >in the Extended Tunnel ID field of the SESSION object." > >Thanks, >rahul > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 15:21:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUiT-0008PS-M8; Thu, 22 Jun 2006 15:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUiS-0008PI-Gb for mpls@ietf.org; Thu, 22 Jun 2006 15:19:48 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUiR-0001PP-Ps for mpls@ietf.org; Thu, 22 Jun 2006 15:19:48 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 20:40:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Identifier Semantics [Re: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt] Date: Thu, 22 Jun 2006 20:40:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Identifier Semantics [Re: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt] Thread-Index: AcaWKFFhqonqB7HmTHulU4cFRIjdSgAANfKg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , , "Yakov Rekhter" X-OriginalArrivalTime: 22 Jun 2006 18:40:44.0566 (UTC) FILETIME=[5ED8BB60:01C6962B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: fenner@research.att.com, ccamp , rcallon@juniper.net X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Rahul, One minor point, >=20 > "IPv4 tunnel sender address. This address MUST be the same as=20 > the address in the Extended Tunnel ID field of the SESSION >object." This is not inlined with the FRR sender-template specific method. You should remove the second sentence. Regards, JL > -----Message d'origine----- > De : Rahul Aggarwal [mailto:rahul@juniper.net]=20 > Envoy=E9 : jeudi 22 juin 2006 20:18 > =C0 : mpls@ietf.org; Yakov Rekhter > Cc : fenner@research.att.com; ccamp; rcallon@juniper.net > Objet : [mpls] Identifier Semantics [Re: working group last=20 > call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt] >=20 >=20 > Hi Folks, >=20 > Yakov brought up the issue of P2MP ID, Tunnel ID, Extended=20 > Tunnel ID semantics as part of the last call and a discussion=20 > followed on this list. >=20 > In order to resolve this discussion I had proposed some text.=20 > I have received some comments on this offline and want to=20 > move this discussion to a broader audience. >=20 > Please comment on the text changes below, if you have=20 > objections or suggestions. Else this will be incorporated in=20 > the next version of the spec. >=20 > How about the following rephrasing: >=20 > 1. >=20 > Section 4.1: >=20 > " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE=20 > Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes the P2MP ID, a tunnel > ID and an extended tunnel ID. >=20 > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP Identifier (P2MP ID) field. >=20 > The P2MP ID provides an identifier for the set of=20 > destinations of the > P2MP TE Tunnel." >=20 > to >=20 > " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE=20 > Tunnel is identified by a P2MP SESSION object. This object=20 > contains the identifier of the P2MP Session which includes a=20 > tuple , where the=20 > P2MP Identifier (P2MP > ID) is unique within the scope of the IP address of the=20 > ingress LSR. The Ingress LSR IP address is encoded in the=20 > Extended Tunnel ID. Th P2MP Tunnel identifier, carried in the=20 > P2MP SESSION object, is unique within the same scope as the=20 > ingress LSR IP address. >=20 > The fields of the P2MP SESSION object are identical to those=20 > of the SESSION object defined in [RFC3209] except that the=20 > Tunnel Endpoint Address field is replaced by the P2MP ID field." >=20 > 2. >=20 > Section 4.2. >=20 > " A P2MP LSP is identified by the combination of the P2MP ID, Tunnel > ID, and Extended Tunnel ID that are part of the P2MP=20 > SESSION object, > and the tunnel sender address and LSP ID fields of the P2MP > SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is > defined in section 20.2." >=20 > to >=20 > " A P2MP LSP is identified by the combination of the P2MP ID, > Extended Tunnel ID that are part of the P2MP SESSION object,=20 > and the tunnel sender address and LSP ID fields of the P2MP=20 > SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object=20 > is defined in section 20.2." >=20 > 3. >=20 > 19.1.1 >=20 > "P2MP ID >=20 > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP ID and identifies the set of destinations of the P2MP > Tunnel." >=20 > to >=20 > "P2MP ID >=20 > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP Identifier that is unique within the scope of the=20 > Ingress LSR > IP address carried in the Extended Tunnel ID. >=20 > 4. > 19.1.1 >=20 > "Tunnel ID >=20 > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel." >=20 > to >=20 > "Tunnel ID >=20 > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It SHOULD be set to 0 > by the ingress LSR and be ignored on receipt." >=20 >=20 > 5. >=20 > "Extended Tunnel ID >=20 > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Normally set to > all zeros. Ingress nodes that wish to narrow the scope of a > SESSION to the ingress-PID pair may place their IPv4 address > here as a globally unique identifier [RFC3209]." >=20 > to >=20 > "Extended Tunnel ID >=20 > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. This identifier > MUST be set to the ingress LSR's IPv4 address." >=20 > 6. >=20 > 19.1.2 >=20 > "This is same as the P2MP IPv4 LSP SESSION Object with the difference > that the extended tunnel ID may be set to a 16 byte identifier > [RFC3209]." >=20 > to >=20 > "This is same as the P2MP IPv4 LSP SESSION Object with the difference > that the extended tunnel ID MUST be set to a 16 byte=20 > identifier that is the ingress LSR's IPv6 address." >=20 > 7. >=20 > 19.2.1 >=20 > " IPv4 tunnel sender address > See [RFC3209]" >=20 > to" >=20 > "IPv4 tunnel sender address. This address MUST be the same as=20 > the address in the Extended Tunnel ID field of the SESSION object." >=20 > 8. >=20 > 19.2.2 >=20 > "IPv6 tunnel sender address > See [RFC3209]" >=20 > to >=20 > "IPv6 tunnel sender address. This address MUST be the same as=20 > the address in the Extended Tunnel ID field of the SESSION object." >=20 > Thanks, > rahul >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 18:25:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXZq-0007hH-2G; Thu, 22 Jun 2006 18:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXZo-0007Z2-5g for mpls@ietf.org; Thu, 22 Jun 2006 18:23:04 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXZn-0003V9-99 for mpls@ietf.org; Thu, 22 Jun 2006 18:23:04 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 15:40:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Thu, 22 Jun 2006 15:40:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaWAKF6judJxOXhSMqa6mQ2m1nqxgAAFnPQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 22 Jun 2006 13:40:53.0400 (UTC) FILETIME=[7B46A980:01C69601] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7191030d885084e634ab0f488bcd9d53 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Rahul, Your proposed text for the processing of Notify Request and Resv Conf = objects covers my points. Thanks,=20 JL > -----Message d'origine----- > De : Rahul Aggarwal [mailto:rahul@juniper.net]=20 > Envoy=E9 : jeudi 22 juin 2006 15:35 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : mpls@ietf.org > Objet : RE: [mpls] TR: working group last call on=20 > draft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 >=20 > Hi JL, >=20 > Please see below: >=20 > On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Rahul, > > > > Please see inline, > > > > > > > -----Message d'origine----- > > > De : Rahul Aggarwal [mailto:rahul@juniper.net] Envoy=E9 : mardi 20 = > > > juin 2006 22:47 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc :=20 > > > mpls@ietf.org Objet : Re: [mpls] TR: working group last call on=20 > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > Hi JL, > > > > > > Sorry for the delay. Please see below: > > > > > > On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > > > > > Hi all, > > > > > > > > I transfer the below comments on this list, as it should be > > > discussed > > > > as part of last call comments. > > > > > > > > Regards, > > > > > > > > JL > > > > > > > > > -----Message d'origine----- > > > > > De : LE ROUX Jean-Louis RD-CORE-LAN Envoy=E9 : jeudi 25=20 > mai 2006=20 > > > > > 14:19 > > > > > =C0: > > > > > Objet : RE: working group last call on=20 > > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > Hi Rahul, Dimitri, Seisho > > > > > > > > > > Thanks for the great edit job, > > > > > > > > > > Find below a set of comments on this revision 05 > > > > > > > > > > Four technical points: > > > > > > > > > > 1: Section 8.1.2 Downstream notification > > > > > > > > > > The text in 8.1.2 is a bit unclear > > > > > > > > > > "A transit LSR sets the Sub-Group Originator ID in=20 > the FILTER_SPEC > > > > > object(s) of a Resv message to the value, that was > > > received in the > > > > > corresponding Path message. If the incoming Resv > > > message carries a > > > > > Notify Request object then, the LSR MUST set the=20 > Notify node=20 > > > > > address > > > > > in the Notify Request object to the value, that was > > > received in the > > > > > corresponding Path message", > > > > > > > > > > > > > > > > Which value? The sub-group originator? the notify address? > > > > > > This should be the Router ID of the transit LSR if the=20 > transit LSR=20 > > > is merging more than one Resv with a Notify Request object. > > > > Ok, but it also applies when the LSR changes the sub-group=20 > originator=20 > >id to its own address doesn't it? > > >=20 > Yes, you are right. >=20 > > > > > > > > This is unclear. The processing needs to be clarified. > > > > > We could update as follows: > > > > > > > > > > "If the incoming Resv message carries a Notify Request > > > object then, > > > > > -If the sub-group originator ID is its own > > > address, the LSR MUST > > > > > set the Notify node address in the Notify Request object > > > to its own > > > > > address, in the Resv message that it sends upstream. > > > > > -If the sub group originator ID is not its own > > > address, the LSR > > > > > MUST propagate the Notify Request object unchanged,=20 > in the Resv=20 > > > > > message that it sends upstream." > > > > > > > > > > > Shouldn't the transit LSR always set its own address in=20 > the Notify=20 > > > Request if it is merging multiple Resvs with Notify=20 > Request objects=20 > > > into a single Resv ? The current text is not clear on this either. > > > > A transit LSR should actually put its own address in the Notify=20 > > Request not only when it is merging multiple Resv, but also when it=20 > > changes the sub-group orignator id to its own address (even=20 > if there=20 > > is no Resv merging) > > > > > > > > How about: > > > > > > "A transit LSR sets the Sub-Group Originator ID in the=20 > FILTER_SPEC=20 > > > object(s) of a Resv message to the value, that was=20 > received in the=20 > > > corresponding Path message. If the incoming Resv message=20 > carries a=20 > > > Notify Request object then: > > > > > > - If there is at least another incoming Resv message=20 > that carries a=20 > > > Notify Request object and the LSR merges these Resv=20 > messages into a=20 > > > single Resv message that is sent upstream, the LSR MUST set the=20 > > > Notify node address in the Notify Request object to its Router ID. > > > > > > - Else the LSR MUST propagate the Notify Request object=20 > unchanged,=20 > > > in the Resv message that it sends upstream." > > > > See above comment > > >=20 > How about adding a bullet between these two bullets: >=20 > "- Else if the LSR sets the Sub-Group Originator ID in the=20 > outgoing Path message, that corresponds to the received Resv=20 > message, to its own address, the LSR MUST set the Notify node=20 > address in the Notify Request object to its Router ID." >=20 >=20 >=20 > > > > > > > > > > > 2: Section 8.2 ResvConf > > > > > > > > > > Similar comment > > > > > > > > > > "A transit LSR sets the Sub-Group Originator ID in=20 > the FILTER_SPEC > > > > > object(s) of a Resv message to the value, that was > > > received in the > > > > > corresponding Path message. If any of the incoming > > > Resv messages > > > > > corresponding to a single Path message carry a > > > RESV_CONFIRM object > > > > > then the LSR MUST include a RESV_CONFIRM object in the=20 > > > > > corresponding > > > > > Resv message that it sends upstream and MUST set=20 > the receiver=20 > > > > > address > > > > > in the RESV_CONFIRM object to the value that was > > > received in the > > > > > corresponding Resv message." > > > > > > > > > > Change to > > > > > > > > > > " > > > > > A transit LSR sets the Sub-Group Originator ID in the > > > FILTER_SPEC > > > > > object(s) of a Resv message to the value, that was > > > received in the > > > > > corresponding Path message. If any of the incoming > > > Resv messages > > > > > corresponding to a single Path message carry a > > > RESV_CONFIRM object > > > > > then the LSR MUST include a RESV_CONFIRM object in the=20 > > > > > corresponding > > > > > Resv message that it sends upstream. If the sub-group > > > originator > > > > > ID is its own address then > > > > > it MUST set the receiver address in the=20 > RESV_CONFIRM object=20 > > > > > to this addresse, else it MUST > > > > > propagate the object unchanged" > > > > > > > > > > > Shouldn't the transit LSR always set its own address in the=20 > > > RESV_CONFIRM if it is merging multiple Resvs with RESV_CONFIRM=20 > > > objects into a single Resv ? The current text is not=20 > clear on this=20 > > > either. > > > > Same comment. Yes but IMO it should also do it when it changes the=20 > > sub-group originator id (even with no Resv merge)? > > >=20 > That is correct. >=20 > > > > > > How about: > > > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > > object(s) of a Resv message to the value that was received in the=20 > > > corresponding Path message. If an incoming Resv message=20 > > > corresponding to a single Path message carries a=20 > RESV_CONFIRM object=20 > > > then the LSR MUST include a RESV_CONFIRM object in the=20 > corresponding=20 > > > Resv message that it sends upstream and: > > > > > > - If there is at least another incoming Resv message=20 > that carries a=20 > > > RESV_CONFIRM object and the LSR merges these Resv messages into a=20 > > > single Resv message that is sent upstream, the LSR MUST set the=20 > > > receiver address in the RESV_CONFIRM object to its Router ID. > > > > > > - Else the LSR MUST propagate the RESV_CONFIRM object=20 > unchanged, in=20 > > > the Resv message that it sends upstream." > > > > > > > This also applies when the LSR changes the sub-group originator id=20 > > without any Resv merge > > >=20 > How about adding a bullet in between these two bullets: >=20 > "- If the LSR sets the Sub-Group Originator ID in the=20 > outgoing Path message, that corresponds to the received Resv=20 > message, to its own address, the LSR MUST set the receiver=20 > address in the RESV_CONFIRM object to its Router ID." >=20 > thanks, > rahul >=20 > > > > > > > > > > > > > 3: Section 14.2 Sub-group based reoptimization > > > > > > > > > > The new path may intersect the old path, this is a case > > > of rerouting > > > > > and this is not covered by remerge procedures as described in=20 > > > > > section 18. Hence Transient Data duplication may occur during=20 > > > > > the time between the Resv is received and the PathTear is > > > sent. To avoid > > > > > data duplication the branch node must not start > > > transmitting on the > > > > > new path before the old path has been torn down, but this > > > will lead > > > > > to transient packet loss. > > > > > This should be clearly mentionned here IMO. > > > > > Actually the only way to avoid both transient duplication and=20 > > > > > transient packet loss is to rely on the global mb4b > > > procedure with a > > > > > new LSP id... > > > > > > > > > > > How about adding the following to this section: > > > > > > "Sub-Group based re-optimization may result in transient data=20 > > > duplication as the new Path messages for a set of S2L=20 > sub-LSPs may=20 > > > transit one or more nodes with the old Path state for the=20 > same set=20 > > > of S2L sub-LSPs. " > > > > The proposed text addresses my point and is fine with me > > > > > > > > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > The text says > > > > > "The PathErr message MUST include all of the objects > > > > > normally included in a PathErr message, as well as one > > > or more SUB- > > > > > LSP objects from the set of sub-LSPs associated with > > > the matching > > > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > > > RECOMMENDED. This will allow the node that caused the > > > re-merge to > > > > > identify the outgoing Path state associated with the valid=20 > > > > > portion of > > > > > the P2MP LSP. The set of SUB-LSP objects in the=20 > received Path=20 > > > > > message > > > > > MUST also be included" > > > > > > > > > > And then: > > > > > > > > > > "A node that receives a PathErr message that contains > > > the Error > > > > > Value > > > > > "Routing Problem/P2MP Remerge Detected" MUST determine > > > if it is the > > > > > node that created the re-merge case. This is done=20 > by checking > > > > > whether there is any intersection between the set=20 > of SUB-LSP=20 > > > > > objects > > > > > associated with the matching P2MP LSP Path state and > > > the set of > > > > > SUB- > > > > > LSP objects in the received PathErr message. If there > > > is, then the > > > > > node created the re-merge case." > > > > > > > > > > There is an issue here. Actually there will always be an=20 > > > > > intersection, because the PathErr includes the set of sub-lsp=20 > > > > > objects in the received Path... IMO for this procedure to > > > work the > > > > > PathErr MUST only include sub-LSP objects associated with the=20 > > > > > matching P2MP LSP state on the rermerge LSR and must not > > > include the > > > > > set of SUB-LSP objects in the received Path message. > > > > > By the way why are three objects recommended? > > > > > > > > > > > I believe this was clarified by John Drake offline and no=20 > revisions=20 > > > were needed ? > > > > I will provide more comments in a following email. > > > > Best Regards, > > > > JL > > > > > > > > > > > > > > > Also find below some minor edits: > > > > > > > > > > Section 6.1 > > > > > > > > > > ::=3D ; [ > > > > SECONDARY_EXPLICIT_ROUTE> ] > > > > > Change to: > > > > > ::=3D ; [ > > > > SECONDARY_RECORD_ROUTE> ] > > > > > > > > > > > Ok. > > > > > > > > Section 7.1 > > > > > change to > > > > > > > > > > > Ok. > > > > > > > > Section 8.1.2 > > > > > > > > > > "If this LSR subsequently receives a corresponding > > > Notify message > > > > > from > > > > > an upstream LSR than it MUST: > > > > > - send a Notify message downstream toward the Notify > > > > > node address that the LSR received in the Resv message. > > > > > - process the sub-group fields of the FILTER_SPEC=20 > object in the > > > > > received Notify message, and modify their values in > > > the Notify > > > > > message that is forwarded to match the sub-group=20 > field values > > > > > in the original Path message sent downstream by=20 > this LSR." > > > > > > > > > > Invert these two bullets > > > > > > > > > > > Ok. > > > > > > > > Section 8.2 > > > > > > > > > > "If this LSR subsequently receives a corresponding > > > ResvConf message > > > > > from an upstream LSR then it MUST: > > > > > - send a ResvConf message downstream toward the > > > receiver address > > > > > that > > > > > the LSR received in the RESV_CONFIRM object in the > > > Resv message. > > > > > - process the sub-group fields of the FILTER_SPEC=20 > object in the > > > > > received ResvConf message, and modify their=20 > values in the=20 > > > > > ResvConf > > > > > message that is forwarded to match the sub-group=20 > field values > > > > > in the original Path message sent downstream by=20 > this LSR." > > > > > > > > > > Invert these two bullets > > > > > > > > > > > Ok. > > > > > > > > Section 11.2 last sentence > > > > > > > > > > "Note the receiver of a ResvErr message is able to > > > identify the > > > > > errored outgoing Path [Change to: Resv] > > > > > message, and outgoing interface, based on the=20 > Sub-Group fields > > > > > received in the ResvErr message. > > > > > > > > > > Ok. > > > > > > > > > > > > Section 13 > > > > > > > > > > "A sender on a LAN uses a different label for sending > > > traffic to each > > > > > node on the LAN that belongs to the P2MP LSP" > > > > > > > > > > This is not always the case, I would rather say > > > > > > > > > > "Downstream nodes for a given P2MP LSP on a LAN are likely to=20 > > > > > allocate a different label, in which case the sender has > > > to perform > > > > > replication"... > > > > > > > > > > > Actually the procedures in this document imply that a sender on a=20 > > > LAN must do replication if there is more than one downstream=20 > > > receiver. Upstream labels are required to avoid this. > > > > > > However I do realize that the first sentence is not entirely=20 > > > accurate. How > > > about: > > > > > > "If there are multiple downstream LSRs on a LAN on a P2MP LSP, a=20 > > > sender LSR on the LAN has to perform replication. A=20 > separate copy of=20 > > > the data is unicast to each of the downstream LSRs" > > > > > > > > > > > Section 16 > > > > > > > > > > "Stitching and nesting > > > > > considerations and procedures are described further in > > > [INT-REG]." > > > > > > > > > > Change to "Stitching and nesting > > > > > considerations and procedures are described further in=20 > > > > > [LSP-STITCH] and [RFC4206]." > > > > > > > > > > Section 17 > > > > > > > > > > Infact =3D> In fact > > > > > > > > > > > Ok. > > > > > > > > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object =3D> P2MP > > > > > LSP_IPv6 FILTER_SPEC object > > > > > > > > > > > Ok. > > > > > > > > Also some references need to be updated... > > > > > > > > > > > Will do that. > > > > > > Thanks for the detailed comments. > > > > > > rahul > > > > > > > > Best Regards, > > > > > > > > > > JL > > > > > > > > > > > -----Message d'origine----- > > > > > > De : owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa > > > > > Andersson Envoy=E9 : > > > > > > samedi 13 mai 2006 12:48 =C0 : mpls@ietf.org Cc : ccamp; > > > > > George Swallow; > > > > > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross=20 > Callon; Bill=20 > > > > > > Fenner Objet : working group last call on > > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > > > Working Group, > > > > > > > > > > > > this initiates a two week working group last call on=20 > > > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > > > please send comments to the MPLS working group=20 > mailling list=20 > > > > > > and/or working co-chairs. > > > > > > > > > > > > The last call ends eob May 28th. > > > > > > > > > > > > The ccamp mailing list copied as this is a work that has an=20 > > > > > > overlap between the working groups. > > > > > > > > > > > > Loa and George > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Loa Andersson > > > > > > > > > > > > Principal Networking Architect > > > > > > Acreo AB phone: +46 8 632 77 14 > > > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > > > Kista, Sweden email: > > > loa.andersson@acreo.se > > > > > > loa@pi.se > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > > >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 22 18:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtY0i-0005OV-0c; Thu, 22 Jun 2006 18:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXzu-0003yN-Qg; Thu, 22 Jun 2006 18:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXzu-0003FW-8S; Thu, 22 Jun 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo1Hp029318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzt-0007sH-ME; Thu, 22 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --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 : Requirements for point-to-multipoint extensions to the Label Distribution Protocol Author(s) : J. Le Roux, et al. Filename : draft-ietf-mpls-mp-ldp-reqs-01.txt Pages : 17 Date : 2006-6-22 This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mp-ldp-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22151303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-mp-ldp-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22151303.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Thu Jun 22 23:31:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtcM0-0005zs-Dg; Thu, 22 Jun 2006 23:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtcLy-0005zm-Un for mpls@ietf.org; Thu, 22 Jun 2006 23:29:06 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtcLy-0001Ff-Gy for mpls@ietf.org; Thu, 22 Jun 2006 23:29:06 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 16:02:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Thu, 22 Jun 2006 16:02:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaWAzTJKHh8oXw+SIWNoSadlVaMMwAAScKg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 22 Jun 2006 14:02:55.0142 (UTC) FILETIME=[8F187C60:01C69604] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Rahul, >Would you like to propose the modified text ?=20 I can provide some text by the end of the day. Regards, JL > -----Message d'origine----- > De : Rahul Aggarwal [mailto:rahul@juniper.net]=20 > Envoy=E9 : jeudi 22 juin 2006 15:53 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : mpls@ietf.org; Drake, John E > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 >=20 > Hi JL, >=20 > On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Rahul, all > > > > Actually, after thinking a bit more, it seems to me that a=20 > simpler remerge procedure based on RRO analysis could be useful. > > If the RRO is carried in Path messages, the node where the remerge=20 > > occurs could easily identify the node that created the=20 > remerge, simply by analyzing the two RROs. > > When a node detect a remerge it sends a PAthErr with a new=20 > object (Remerge-Spec object) that identifies the remerge=20 > origin. This PathErr carries the set of sub-LSPs received in=20 > the Path message that caused the remerge. > > On receipt of such PAthErr, a node that see its own address in the=20 > > Remerge-spec object moves the set of sub-LSPs... > > > > It seems that this procedure would require simpler processing... > > It requires the use of RRO, but this is the price to pay. > > >=20 > I think this is reasonable. If it is desriable to fix remerge=20 > in the control plane this is a reasonable tradeoff. Else the=20 > spec has the option to fix remerge in the data plane. >=20 > > Would that make sense? > > >=20 > Would you like to propose the modified text ? >=20 > Thanks, > rahul >=20 > > Best Regards, > > > > JL > > > > > > > -----Message d'origine----- > > > De : Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Envoy=E9 : mardi=20 > > > 20 juin 2006 23:59 =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis = > > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR:=20 > working group=20 > > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Rahul, > > > > > > Snipped, comments inline. > > > > > > Thanks, > > > > > > John > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > > > The text says > > > > > > "The PathErr message MUST include all of the objects > > > > > > normally included in a PathErr message, as well as > > > one or more > > > SUB- > > > > > > LSP objects from the set of sub-LSPs associated with the > > > matching > > > > > > P2MP LSP Path state. A minimum of three SUB-LSP=20 > objects is > > > > > > RECOMMENDED. This will allow the node that caused > > > the re-merge > > > to > > > > > > identify the outgoing Path state associated with=20 > the valid=20 > > > > > > portion of > > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > > received Path > > > > > > message > > > > > > MUST also be included" > > > > > > > > > > > > And then: > > > > > > > > > > > > "A node that receives a PathErr message that > > > contains the Error > > > > > > Value > > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > > determine if it is > > > the > > > > > > node that created the re-merge case. This is done > > > by checking > > > > > > whether there is any intersection between the set of=20 > > > > > > SUB-LSP objects > > > > > > associated with the matching P2MP LSP Path state and > > > the set of > > > > > > SUB- > > > > > > LSP objects in the received PathErr message. If > > > there is, then > > > the > > > > > > node created the re-merge case." > > > > > > > > > > > > There is an issue here. Actually there will always be an=20 > > > > > > intersection, because the PathErr includes the set=20 > of sub-lsp=20 > > > > > > objects in the received Path... IMO for this procedure > > > to work the > > > > > > PathErr MUST only include sub-LSP objects=20 > associated with the=20 > > > > > > matching P2MP LSP state on the rermerge LSR and must > > > not include > > > > > > the set of SUB-LSP objects in the received Path message. > > > > > > By the way why are three objects recommended? > > > > > > > > > > > > > > I believe this was clarified by John Drake offline and no=20 > > > > revisions > > > were > > > > needed ? > > > Rahul, > > > > > > Here's the e-mail I sent to JL: > > > > > > "JL, > > > > > > The text was originally stated as you stated. The issue=20 > is that the=20 > > > set of sub-LSPs associated with the interface on the node that=20 > > > caused the re-merge condition may have more members than=20 > the set of=20 > > > sub-LSPs in the received Path message, and you only want=20 > to move the=20 > > > ones that were in the received Path message. > > > > > > Adrian was the one who initially pointed this and he proposed=20 > > > creating a different object/type for the set of sub-LSPs in the=20 > > > received Path message. I think this is reasonable solution. > > > > > > Thanks, > > > > > > John" > > > > > > As you can see from the last paragraph, we do need to=20 > create a new=20 > > > object/type. > > > > > > > >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 00:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftdex-0004Qc-Ql; Fri, 23 Jun 2006 00:52:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftdex-0004QR-0Y for mpls@ietf.org; Fri, 23 Jun 2006 00:52:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftcqy-0007Ig-SW for mpls@ietf.org; Fri, 23 Jun 2006 00:01:08 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ftchc-0007pb-Cy for mpls@ietf.org; Thu, 22 Jun 2006 23:51:30 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FtchO-00068B-Ik; Thu, 22 Jun 2006 23:51:14 -0400 Message-Id: <7.0.1.0.2.20060622235040.041f92e0@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 22 Jun 2006 23:51:22 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" From: Lou Berger Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.1 (--) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org JL, So what happens when no RRO is used (which isn't=20 currently required) or portions of the RRO are removed? Lou At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Rahul, all > >Actually, after thinking a bit more, it seems to=20 >me that a simpler remerge procedure based on RRO analysis could be useful. >If the RRO is carried in Path messages, the node where the remerge >occurs could easily identify the node that=20 >created the remerge, simply by analyzing the two RROs. >When a node detect a remerge it sends a PAthErr=20 >with a new object (Remerge-Spec object) that=20 >identifies the remerge origin. This PathErr=20 >carries the set of sub-LSPs received in the Path=20 >message that caused the remerge. >On receipt of such PAthErr, a node that see its own address in the >Remerge-spec object moves the set of sub-LSPs... > >It seems that this procedure would require simpler processing... >It requires the use of RRO, but this is the price to pay. > >Would that make sense? > >Best Regards, > >JL > > > > -----Message d'origine----- > > De : Drake, John E [mailto:John.E.Drake2@boeing.com] > > Envoy=E9 : mardi 20 juin 2006 23:59 > > =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis RD-CORE-LAN > > Cc : mpls@ietf.org > > Objet : RE: [mpls] TR: working group last call > > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > Rahul, > > > > Snipped, comments inline. > > > > Thanks, > > > > John > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > The text says > > > > > "The PathErr message MUST include all of the objects > > > > > normally included in a PathErr message, as well as > > one or more > > SUB- > > > > > LSP objects from the set of sub-LSPs associated with the > > matching > > > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > > > RECOMMENDED. This will allow the node that caused > > the re-merge > > to > > > > > identify the outgoing Path state associated with the valid > > > > > portion of > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > received Path > > > > > message > > > > > MUST also be included" > > > > > > > > > > And then: > > > > > > > > > > "A node that receives a PathErr message that > > contains the Error > > > > > Value > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > determine if it is > > the > > > > > node that created the re-merge case. This is done > > by checking > > > > > whether there is any intersection between the set of SUB-LSP > > > > > objects > > > > > associated with the matching P2MP LSP Path state and > > the set of > > > > > SUB- > > > > > LSP objects in the received PathErr message. If > > there is, then > > the > > > > > node created the re-merge case." > > > > > > > > > > There is an issue here. Actually there will always be an > > > > > intersection, because the PathErr includes the set of sub-lsp > > > > > objects in the received Path... IMO for this procedure > > to work the > > > > > PathErr MUST only include sub-LSP objects associated with the > > > > > matching P2MP LSP state on the rermerge LSR and must > > not include > > > > > the set of SUB-LSP objects in the received Path message. > > > > > By the way why are three objects recommended? > > > > > > > > > > > I believe this was clarified by John Drake offline and no revisions > > were > > > needed ? > > Rahul, > > > > Here's the e-mail I sent to JL: > > > > "JL, > > > > The text was originally stated as you stated. The issue is > > that the set of sub-LSPs associated with the interface on the > > node that caused the re-merge condition may have more members > > than the set of sub-LSPs in the received Path message, and > > you only want to move the ones that were in the received Path message. > > > > Adrian was the one who initially pointed this and he proposed > > creating a different object/type for the set of sub-LSPs in > > the received Path message. I think this is reasonable solution. > > > > Thanks, > > > > John" > > > > As you can see from the last paragraph, we do need to create > > a new object/type. > > > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 03:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgGB-0002Bl-FG; Fri, 23 Jun 2006 03:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgG9-0002B0-Lt for mpls@ietf.org; Fri, 23 Jun 2006 03:39:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftg0E-0007H6-N9 for mpls@ietf.org; Fri, 23 Jun 2006 03:22:54 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ftfsd-0003SP-6T for mpls@ietf.org; Fri, 23 Jun 2006 03:15:05 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1A00CFLY5L1J@szxga02-in.huawei.com> for mpls@ietf.org; Fri, 23 Jun 2006 15:29:45 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1A00HAOY5KU6@szxga02-in.huawei.com> for mpls@ietf.org; Fri, 23 Jun 2006 15:29:45 +0800 (CST) Received: from l48253 ([10.110.114.51]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1A00CVWXHK11@szxml03-in.huawei.com> for mpls@ietf.org; Fri, 23 Jun 2006 15:15:21 +0800 (CST) Date: Fri, 23 Jun 2006 15:13:40 +0800 From: liushuying To: mpls@ietf.org Message-id: <003601c69694$8e147770$33726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: -1.9 (-) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [mpls] Load-Balancing among a set of candidate upstream LSRs on a LAN-----draft-liu-mpls-upstream-load-balance-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1106341171==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1106341171== Content-type: multipart/alternative; boundary="Boundary_(ID_HZxJBRSqFK6+F+tbOr6n8g)" This is a multi-part message in MIME format. --Boundary_(ID_HZxJBRSqFK6+F+tbOr6n8g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgZm9sa3MuDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhlIGRyYWZ0IGNhbiBiZSBm b3VuZCBoZXJlOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1s aXUtbXBscy11cHN0cmVhbS1sb2FkLWJhbGFuY2UtMDAudHh0DQoNClRpdGxlIDogTG9hZC1CYWxh bmNpbmcgYW1vbmcgYSBzZXQgb2YgY2FuZGlkYXRlIHVwc3RyZWFtIExTUnMgb24gYSBMQU4NCkF1 dGhvcihzKSA6IFNodXlpbmcgTGl1DQpGaWxlbmFtZSA6IGRyYWZ0LWxpdS1tcGxzLXVwc3RyZWFt LWxvYWQtYmFsYW5jZS0wMC50eHQNClBhZ2VzIDogNw0KRGF0ZSA6IDIwMDYtMDYtMTYNCg0KVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIExvYWQtQmFsYW5jaW5nIGFtb25n IGEgc2V0IG9mIA0KY2FuZGlkYXRlIHVwc3RyZWFtIExTUnMgb24gYSBMQU4gaW50ZXJmYWNlLiBX aGVuIHRoZXJlIGFyZSBzZXZlcmFsIA0KY2FuZGlkYXRlcyB0byBiZSBzZWxlY3RlZCBhcyBhbiB1 cHN0cmVhbSBMU1IsIGFjY29yZGluZyB0aGUgY3VycmVudCANCnVwc3RyZWFtIGxhYmVsIGFsbG9j YXRpb24gbWV0aG9kcywgdGhlIGxvYWQgb24gdGhlIGNhbmRpZGF0ZSB1cHN0cmVhbSANCkxTUiB3 aGljaCBpcyBzZWxlY3RlZCBieSB0aGUgcm91dGluZyBwcm90b2NvbCBtYXkgYmUgdmVyeSBoZWF2 eSwgDQp3aGlsZSB0aGUgbG9hZCBvbiBvdGhlciBjYW5kaWRhdGUgdXBzdHJlYW0gTFNScyBpcyBs aXR0bGUuIFRoZSBMb2FkLQ0KQmFsYW5jaW5nIGFsc28gcHJvdmlkZXMgc29tZSBwcm9jZWR1cmVz IHRvIG1pbmltaXplIHRoZSBwYWNrZXQgbG9zcyANCmluIGZvbGxvd2luZyBjYXNlczogMSkgYWRk aW5nL3JlbW92aW5nIGEgY2FuZGlkYXRlIHVwc3RyZWFtIExTUjsgMikgYSANCmJldHRlciBwYXRo IGVtZXJnaW5nLg0KDQpQbGVhc2UgZ2l2ZSB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgZG9jdW1lbnQh IFRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNCkJlc3QgcmVnYXJkcw0KU2h1eWluZyBMaXUNCkh1YVdl aSBCbGQuLCBOby4zIFhpbnhpIFJkLiwgICANClNoYW5nLURpIEluZm9ybWF0aW9uIEluZHVzdHJ5 IEJhc2UsICAgICAgICAgICAgIA0KSGFpLURpYW4gRGlzdHJpY3QgQmVpamluZyBQLlIuIENoaW5h DQpaSVCjujEwMDA4NSANCg0K --Boundary_(ID_HZxJBRSqFK6+F+tbOr6n8g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI4NzMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPg0KPERJVj48Rk9OVCBzaXplPTI+SGkgZm9sa3Mu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSANCm9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoZSBk cmFmdCBjYW4gYmUgZm91bmQgaGVyZTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LW1wbHMtdXBzdHJlYW0tbG9hZC1iYWxhbmNlLTAwLnR4 dCI+PEZPTlQgDQpzaXplPTI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbGl1LW1wbHMtdXBzdHJlYW0tbG9hZC1iYWxhbmNlLTAwLnR4dDwvRk9OVD48L0E+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5UaXRsZSA6IExvYWQtQmFsYW5jaW5nIGFtb25nIGEgc2V0IG9mIGNhbmRpZGF0ZSB1cHN0cmVh bSBMU1JzIA0Kb24gYSBMQU48QlI+QXV0aG9yKHMpIDogU2h1eWluZyBMaXU8QlI+RmlsZW5hbWUg OiANCmRyYWZ0LWxpdS1tcGxzLXVwc3RyZWFtLWxvYWQtYmFsYW5jZS0wMC50eHQ8L0ZPTlQ+DQo8 RElWPjxGT05UIHNpemU9Mj5QYWdlcyA6IDc8QlI+RGF0ZSA6IDIwMDYtMDYtMTY8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5UaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBmb3IgTG9hZC1CYWxhbmNp bmcgYW1vbmcgYSANCnNldCBvZiZuYnNwOzxCUj5jYW5kaWRhdGUgdXBzdHJlYW0gTFNScyBvbiBh IExBTiBpbnRlcmZhY2UuIFdoZW4gdGhlcmUgYXJlIA0Kc2V2ZXJhbCZuYnNwOzxCUj5jYW5kaWRh dGVzIHRvIGJlIHNlbGVjdGVkIGFzIGFuIHVwc3RyZWFtIExTUiwgYWNjb3JkaW5nIHRoZSANCmN1 cnJlbnQmbmJzcDs8QlI+dXBzdHJlYW0gbGFiZWwgYWxsb2NhdGlvbiBtZXRob2RzLCB0aGUgbG9h ZCBvbiB0aGUgY2FuZGlkYXRlIA0KdXBzdHJlYW0mbmJzcDs8QlI+TFNSIHdoaWNoIGlzIHNlbGVj dGVkIGJ5IHRoZSByb3V0aW5nIHByb3RvY29sIG1heSBiZSB2ZXJ5IA0KaGVhdnksJm5ic3A7PEJS PndoaWxlIHRoZSBsb2FkIG9uIG90aGVyIGNhbmRpZGF0ZSB1cHN0cmVhbSBMU1JzIGlzIGxpdHRs ZS4gVGhlIA0KTG9hZC08QlI+QmFsYW5jaW5nIGFsc28gcHJvdmlkZXMgc29tZSBwcm9jZWR1cmVz IHRvIG1pbmltaXplIHRoZSBwYWNrZXQgDQpsb3NzJm5ic3A7PEJSPmluIGZvbGxvd2luZyBjYXNl czogMSkgYWRkaW5nL3JlbW92aW5nIGEgY2FuZGlkYXRlIHVwc3RyZWFtIExTUjsgDQoyKSBhJm5i c3A7PEJSPmJldHRlciBwYXRoIGVtZXJnaW5nLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlBsZWFzZSBnaXZlIHlv dXIgY29tbWVudHMmbmJzcDtvbiB0aGlzIGRvY3VtZW50ISBUaGFuayB5b3UgDQp2ZXJ5IG11Y2gu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+QmVzdCByZWdhcmRzPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZP TlQgZmFjZT3LzszlPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPlNodXlpbmcgTGl1PC9T UEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3LzszlPjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiPjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpmYWNlPcvOzOU+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdCI+SHVhV2VpIEJsZC4sIE5vLjMgWGlueGkgUmQuLCZuYnNwOyZuYnNw OyANCjxCUj5TaGFuZy1EaSBJbmZvcm1hdGlvbiBJbmR1c3RyeSANCkJhc2UsJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KPEJSPkhhaS1EaWFuIERpc3RyaWN0IEJlaWppbmcgUC5SLiBDaGluYTxCUj5aSVA8U1BB TiANCmxhbmc9WkgtQ04+o7o8L1NQQU4+MTAwMDg1Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0RJVj48 QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_HZxJBRSqFK6+F+tbOr6n8g)-- --===============1106341171== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1106341171==-- From mpls-bounces@lists.ietf.org Fri Jun 23 05:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fthvo-0000Jr-Mw; Fri, 23 Jun 2006 05:26:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fthvm-0000BA-Ie for mpls@ietf.org; Fri, 23 Jun 2006 05:26:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtgWJ-0007NY-Cq for mpls@ietf.org; Fri, 23 Jun 2006 03:56:03 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtgJH-00044a-Uo for mpls@ietf.org; Fri, 23 Jun 2006 03:42:38 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 09:21:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Fri, 23 Jun 2006 09:20:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaWeE6hXE9r8kY4RSCO+FiLjzRadwAHC6Cw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Lou Berger" X-OriginalArrivalTime: 23 Jun 2006 07:21:00.0016 (UTC) FILETIME=[93C60700:01C69695] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Lou, When RRO is not used this procedure does not apply and remerge should be = fixed in the data plane on the remerge node.=20 IMO full RRO inclusion is the price to pay if you want to fix remerge in = a simple manner in the control plane. Regards, JL > -----Message d'origine----- > De : Lou Berger [mailto:lberger@labn.net]=20 > Envoy=E9 : vendredi 23 juin 2006 05:51 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : zzx-rahul@juniper.net; mpls@ietf.org; Drake, John E > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > JL, >=20 > So what happens when no RRO is used (which isn't currently=20 > required) or portions of the RRO are removed? >=20 > Lou >=20 > At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > >Hi Rahul, all > > > >Actually, after thinking a bit more, it seems to me that a simpler=20 > >remerge procedure based on RRO analysis could be useful. > >If the RRO is carried in Path messages, the node where the remerge=20 > >occurs could easily identify the node that created the=20 > remerge, simply=20 > >by analyzing the two RROs. > >When a node detect a remerge it sends a PAthErr with a new object=20 > >(Remerge-Spec object) that identifies the remerge origin.=20 > This PathErr=20 > >carries the set of sub-LSPs received in the Path message that caused=20 > >the remerge. > >On receipt of such PAthErr, a node that see its own address in the=20 > >Remerge-spec object moves the set of sub-LSPs... > > > >It seems that this procedure would require simpler processing... > >It requires the use of RRO, but this is the price to pay. > > > >Would that make sense? > > > >Best Regards, > > > >JL > > > > > > > -----Message d'origine----- > > > De : Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Envoy=E9 : mardi=20 > > > 20 juin 2006 23:59 =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis = > > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR:=20 > working group=20 > > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Rahul, > > > > > > Snipped, comments inline. > > > > > > Thanks, > > > > > > John > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > > > The text says > > > > > > "The PathErr message MUST include all of the objects > > > > > > normally included in a PathErr message, as well as > > > one or more > > > SUB- > > > > > > LSP objects from the set of sub-LSPs associated with the > > > matching > > > > > > P2MP LSP Path state. A minimum of three SUB-LSP=20 > objects is > > > > > > RECOMMENDED. This will allow the node that caused > > > the re-merge > > > to > > > > > > identify the outgoing Path state associated with=20 > the valid=20 > > > > > > portion of > > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > > received Path > > > > > > message > > > > > > MUST also be included" > > > > > > > > > > > > And then: > > > > > > > > > > > > "A node that receives a PathErr message that > > > contains the Error > > > > > > Value > > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > > determine if it is > > > the > > > > > > node that created the re-merge case. This is done > > > by checking > > > > > > whether there is any intersection between the set of=20 > > > > > > SUB-LSP objects > > > > > > associated with the matching P2MP LSP Path state and > > > the set of > > > > > > SUB- > > > > > > LSP objects in the received PathErr message. If > > > there is, then > > > the > > > > > > node created the re-merge case." > > > > > > > > > > > > There is an issue here. Actually there will always be an=20 > > > > > > intersection, because the PathErr includes the set=20 > of sub-lsp=20 > > > > > > objects in the received Path... IMO for this procedure > > > to work the > > > > > > PathErr MUST only include sub-LSP objects=20 > associated with the=20 > > > > > > matching P2MP LSP state on the rermerge LSR and must > > > not include > > > > > > the set of SUB-LSP objects in the received Path message. > > > > > > By the way why are three objects recommended? > > > > > > > > > > > > > > I believe this was clarified by John Drake offline and no=20 > > > > revisions > > > were > > > > needed ? > > > Rahul, > > > > > > Here's the e-mail I sent to JL: > > > > > > "JL, > > > > > > The text was originally stated as you stated. The issue=20 > is that the=20 > > > set of sub-LSPs associated with the interface on the node that=20 > > > caused the re-merge condition may have more members than=20 > the set of=20 > > > sub-LSPs in the received Path message, and you only want=20 > to move the=20 > > > ones that were in the received Path message. > > > > > > Adrian was the one who initially pointed this and he proposed=20 > > > creating a different object/type for the set of sub-LSPs in the=20 > > > received Path message. I think this is reasonable solution. > > > > > > Thanks, > > > > > > John" > > > > > > As you can see from the last paragraph, we do need to=20 > create a new=20 > > > object/type. > > > > > > >_______________________________________________ > >mpls mailing list > >mpls@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 07:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtjqQ-0003Hk-DR; Fri, 23 Jun 2006 07:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtjqO-0003HJ-LH for mpls@ietf.org; Fri, 23 Jun 2006 07:29:00 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtjqO-0007Zp-9B for mpls@ietf.org; Fri, 23 Jun 2006 07:29:00 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1Ftjq8-0004GK-H3; Fri, 23 Jun 2006 07:28:44 -0400 Message-Id: <7.0.1.0.2.20060623072207.04218360@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 23 Jun 2006 07:28:52 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" From: Lou Berger Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org JL, See below. At 03:20 AM 6/23/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Lou, > >When RRO is not used this procedure does not=20 >apply and remerge should be fixed in the data plane on the remerge node. "fixing in the data plane" doesn't work for all=20 technologies covered in the spec, e.g., GMPLS optical. (You're making me think about my favorite HL Mencken quote...) >IMO full RRO inclusion is the price to pay if=20 >you want to fix remerge in a simple manner in the control plane. Yes, but there is already a defined, documented,=20 and agreed to mechanism that will work for all=20 the cases. De we really want/need to be making=20 such a significant change at this late date (post=20 WG last call!). If it were broken, then certain=20 a change would be needed, but I haven't heard anyone make such an assertion. Lou >Regards, > >JL > > > -----Message d'origine----- > > De : Lou Berger [mailto:lberger@labn.net] > > Envoy=E9 : vendredi 23 juin 2006 05:51 > > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > > Cc : zzx-rahul@juniper.net; mpls@ietf.org; Drake, John E > > Objet : RE: [mpls] TR: working group last call > > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > JL, > > > > So what happens when no RRO is used (which isn't currently > > required) or portions of the RRO are removed? > > > > Lou > > > > At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > > >Hi Rahul, all > > > > > >Actually, after thinking a bit more, it seems to me that a simpler > > >remerge procedure based on RRO analysis could be useful. > > >If the RRO is carried in Path messages, the node where the remerge > > >occurs could easily identify the node that created the > > remerge, simply > > >by analyzing the two RROs. > > >When a node detect a remerge it sends a PAthErr with a new object > > >(Remerge-Spec object) that identifies the remerge origin. > > This PathErr > > >carries the set of sub-LSPs received in the Path message that caused > > >the remerge. > > >On receipt of such PAthErr, a node that see its own address in the > > >Remerge-spec object moves the set of sub-LSPs... > > > > > >It seems that this procedure would require simpler processing... > > >It requires the use of RRO, but this is the price to pay. > > > > > >Would that make sense? > > > > > >Best Regards, > > > > > >JL > > > > > > > > > > -----Message d'origine----- > > > > De : Drake, John E [mailto:John.E.Drake2@boeing.com] > > Envoy=E9 : mardi > > > > 20 juin 2006 23:59 =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis > > > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR: > > working group > > > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > Rahul, > > > > > > > > Snipped, comments inline. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > > > > > The text says > > > > > > > "The PathErr message MUST include all of the objects > > > > > > > normally included in a PathErr message, as well as > > > > one or more > > > > SUB- > > > > > > > LSP objects from the set of sub-LSPs associated with the > > > > matching > > > > > > > P2MP LSP Path state. A minimum of three SUB-LSP > > objects is > > > > > > > RECOMMENDED. This will allow the node that caused > > > > the re-merge > > > > to > > > > > > > identify the outgoing Path state associated with > > the valid > > > > > > > portion of > > > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > > > received Path > > > > > > > message > > > > > > > MUST also be included" > > > > > > > > > > > > > > And then: > > > > > > > > > > > > > > "A node that receives a PathErr message that > > > > contains the Error > > > > > > > Value > > > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > > > determine if it is > > > > the > > > > > > > node that created the re-merge case. This is done > > > > by checking > > > > > > > whether there is any intersection between the set of > > > > > > > SUB-LSP objects > > > > > > > associated with the matching P2MP LSP Path state and > > > > the set of > > > > > > > SUB- > > > > > > > LSP objects in the received PathErr message. If > > > > there is, then > > > > the > > > > > > > node created the re-merge case." > > > > > > > > > > > > > > There is an issue here. Actually there will always be an > > > > > > > intersection, because the PathErr includes the set > > of sub-lsp > > > > > > > objects in the received Path... IMO for this procedure > > > > to work the > > > > > > > PathErr MUST only include sub-LSP objects > > associated with the > > > > > > > matching P2MP LSP state on the rermerge LSR and must > > > > not include > > > > > > > the set of SUB-LSP objects in the received Path message. > > > > > > > By the way why are three objects recommended? > > > > > > > > > > > > > > > > > I believe this was clarified by John Drake offline and no > > > > > revisions > > > > were > > > > > needed ? > > > > Rahul, > > > > > > > > Here's the e-mail I sent to JL: > > > > > > > > "JL, > > > > > > > > The text was originally stated as you stated. The issue > > is that the > > > > set of sub-LSPs associated with the interface on the node that > > > > caused the re-merge condition may have more members than > > the set of > > > > sub-LSPs in the received Path message, and you only want > > to move the > > > > ones that were in the received Path message. > > > > > > > > Adrian was the one who initially pointed this and he proposed > > > > creating a different object/type for the set of sub-LSPs in the > > > > received Path message. I think this is reasonable solution. > > > > > > > > Thanks, > > > > > > > > John" > > > > > > > > As you can see from the last paragraph, we do need to > > create a new > > > > object/type. > > > > > > > > > >_______________________________________________ > > >mpls mailing list > > >mpls@lists.ietf.org > > >https://www1.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 07:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftk4h-0002br-SX; Fri, 23 Jun 2006 07:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftk4g-0002bl-C8 for mpls@ietf.org; Fri, 23 Jun 2006 07:43:46 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftk4e-0000yY-Sq for mpls@ietf.org; Fri, 23 Jun 2006 07:43:46 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5NBhhbi003599; Fri, 23 Jun 2006 13:43:43 +0200 In-Reply-To: <7.0.1.0.2.20060622145339.043aa0d0@labn.net> To: Lou Berger Subject: Re: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 23 Jun 2006 13:43:47 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/23/2006 13:43:43, Serialize complete at 06/23/2006 13:43:43 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ccamp , fenner@research.att.com, rcallon@juniper.net, mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org lou, all, see in-line Lou Berger 22/06/2006 21:10 To: Rahul Aggarwal cc: fenner@research.att.com, mpls@ietf.org, rcallon@juniper.net, ccamp Subject: Re: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] > All, > > Here's one (but not the only) comment that was made off list. Also > there were already several comments made on these points on the list. > > My comment still applies, and please consider this as an "objection" > to the proposed text: > > At 01:20 PM 6/22/2006, Lou Berger wrote: >>[...] >>At 05:23 PM 6/20/2006, Rahul Aggarwal wrote: >>>Hi All, >>> >>>Attached is draft-ietf-mpls-rsvp-te-p2mp-06.txt that incorporates changes >>>to address Last call comments. >>> >>>Please let me know if you have any comments on *only the changes made to >>>address LC comments* i.e. diff of v05 and v06 by this Friday. >>> >>>A brief summary of changes: >>> >>>1. Editorial changes requested by Benjamin Niven - see MPLS mailing list. >>>2. Several editorial and non editorial changes requestd by Adrian Farrel - >>>see MPLS mailing list for Adrian's comments and my response. There may be >>>one or two open items here. Once Adrian looks at my response these should >>>be resolved quickly. >>>3. Several editorial and non-editorial changes requestd by JL - see MPLS >>>mailing list for JL's comments and my response. >>>4. Clarification of tunnel ID and extended Tunnel ID semantics as >>>requested by Yakov Rekhter and follow on comments by Zafar Ali and George >>>Swallow. > >The objection: > >>I don't have any issues with the changes mentioned by Zafer and >>George, but I didn't see closure on the issue debated by Adrian and >>Yakov. Specifically on the issue of if extended tunnel ID had to >>equal the node ID of the sender. I did see a position state, that I >>too agree with, i.e., that it should be permitted and may be >>required in some environments (e.g., FRR) but may not be required in >>all environments so should be left as before. Also, as I read the >>mails most were in favor of leaving tunnel ID as is, i.e., not >>requiring it to be set to zero. This doesn't match what was done in >>this past rev. > >In summary, my position is: >1) That the extended tunnel ID remain as defined in the previous >version, i.e., retain the semantics from rfc3209/rfc3473. I think >adding a restriction for environments where FRR is used is >acceptable. (This spec covers GMPLS and non-packet environments too!) >2) That Tunnel ID remain as defined in previous version, i.e., retain >the semantics from rfc3209/rfc3473. > >The specifics of the text below is dependent on consensus on these points. [dp] if there is no Tunnel ID (or a single fixed value for the Tunnel ID), there is no possibility to instantiate multiple trunks per destination (set of destinations) now there is a more fundamental issue: what is the purpose of the initial comment, i think it is first to clarify processing of Tunnel ID and Extended Tunnel ID but i don't think i have seen any specific issue in keeping usage of the Tunnel ID & Extended Tunnel ID per RFC 3209/3473 i am deeply concerned about having moving definition departing from base RSVP-TE on objects that are fundamental for the stability of the protocol thanks, - dimitri. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 08:13:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtkV9-0004R9-Ai; Fri, 23 Jun 2006 08:11:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtkV6-0004R4-Mv for mpls@ietf.org; Fri, 23 Jun 2006 08:11:04 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtkV6-0005Qj-35 for mpls@ietf.org; Fri, 23 Jun 2006 08:11:04 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5NCB0ED024911; Fri, 23 Jun 2006 14:11:00 +0200 In-Reply-To: To: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 23 Jun 2006 14:11:03 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/23/2006 14:11:00, Serialize complete at 06/23/2006 14:11:00 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org hi j-l, lou, all, RFC 4461 mentions "The requirements presented in this document apply equally to packet- switched networks under the control of MPLS protocols and to packet- switched, TDM, lambda, and port-switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document MUST attempt to be equally applicable to MPLS and GMPLS." without favoring one technique over the other - this specific requirement=20 output of the MPLS WG shall be verified otherwise we should probably stop=20 writing requirement documents=20 it is therefore, fundamental to keep protocol mechanisms aligned for both=20 MPLS and GMPLS (specialization should only be considered when there is no=20 viable & scalable alternative) thanks, - dimitri. "LE ROUX Jean-Louis RD-CORE-LAN" 23/06/2006 09:20 =20 To: "Lou Berger" cc: mpls@ietf.org, "Drake, John E" Subject: RE: [mpls] TR: working group last call=20 ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Hi Lou, When RRO is not used this procedure does not apply and remerge should be=20 fixed in the data plane on the remerge node.=20 IMO full RRO inclusion is the price to pay if you want to fix remerge in a = simple manner in the control plane. Regards, JL > -----Message d'origine----- > De : Lou Berger [mailto:lberger@labn.net]=20 > Envoy=E9 : vendredi 23 juin 2006 05:51 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : zzx-rahul@juniper.net; mpls@ietf.org; Drake, John E > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > JL, >=20 > So what happens when no RRO is used (which isn't currently=20 > required) or portions of the RRO are removed? >=20 > Lou >=20 > At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > >Hi Rahul, all > > > >Actually, after thinking a bit more, it seems to me that a simpler=20 > >remerge procedure based on RRO analysis could be useful. > >If the RRO is carried in Path messages, the node where the remerge=20 > >occurs could easily identify the node that created the=20 > remerge, simply=20 > >by analyzing the two RROs. > >When a node detect a remerge it sends a PAthErr with a new object=20 > >(Remerge-Spec object) that identifies the remerge origin.=20 > This PathErr=20 > >carries the set of sub-LSPs received in the Path message that caused=20 > >the remerge. > >On receipt of such PAthErr, a node that see its own address in the=20 > >Remerge-spec object moves the set of sub-LSPs... > > > >It seems that this procedure would require simpler processing... > >It requires the use of RRO, but this is the price to pay. > > > >Would that make sense? > > > >Best Regards, > > > >JL > > > > > > > -----Message d'origine----- > > > De : Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Envoy=E9 : mardi=20 > > > 20 juin 2006 23:59 =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis=20 > > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR:=20 > working group=20 > > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Rahul, > > > > > > Snipped, comments inline. > > > > > > Thanks, > > > > > > John > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > > > The text says > > > > > > "The PathErr message MUST include all of the objects > > > > > > normally included in a PathErr message, as well as > > > one or more > > > SUB- > > > > > > LSP objects from the set of sub-LSPs associated with the > > > matching > > > > > > P2MP LSP Path state. A minimum of three SUB-LSP=20 > objects is > > > > > > RECOMMENDED. This will allow the node that caused > > > the re-merge > > > to > > > > > > identify the outgoing Path state associated with=20 > the valid=20 > > > > > > portion of > > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > > received Path > > > > > > message > > > > > > MUST also be included" > > > > > > > > > > > > And then: > > > > > > > > > > > > "A node that receives a PathErr message that > > > contains the Error > > > > > > Value > > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > > determine if it is > > > the > > > > > > node that created the re-merge case. This is done > > > by checking > > > > > > whether there is any intersection between the set of=20 > > > > > > SUB-LSP objects > > > > > > associated with the matching P2MP LSP Path state and > > > the set of > > > > > > SUB- > > > > > > LSP objects in the received PathErr message. If > > > there is, then > > > the > > > > > > node created the re-merge case." > > > > > > > > > > > > There is an issue here. Actually there will always be an=20 > > > > > > intersection, because the PathErr includes the set=20 > of sub-lsp=20 > > > > > > objects in the received Path... IMO for this procedure > > > to work the > > > > > > PathErr MUST only include sub-LSP objects=20 > associated with the=20 > > > > > > matching P2MP LSP state on the rermerge LSR and must > > > not include > > > > > > the set of SUB-LSP objects in the received Path message. > > > > > > By the way why are three objects recommended? > > > > > > > > > > > > > > I believe this was clarified by John Drake offline and no=20 > > > > revisions > > > were > > > > needed ? > > > Rahul, > > > > > > Here's the e-mail I sent to JL: > > > > > > "JL, > > > > > > The text was originally stated as you stated. The issue=20 > is that the=20 > > > set of sub-LSPs associated with the interface on the node that=20 > > > caused the re-merge condition may have more members than=20 > the set of=20 > > > sub-LSPs in the received Path message, and you only want=20 > to move the=20 > > > ones that were in the received Path message. > > > > > > Adrian was the one who initially pointed this and he proposed=20 > > > creating a different object/type for the set of sub-LSPs in the=20 > > > received Path message. I think this is reasonable solution. > > > > > > Thanks, > > > > > > John" > > > > > > As you can see from the last paragraph, we do need to=20 > create a new=20 > > > object/type. > > > > > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >mpls mailing list > >mpls@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 09:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftlp9-0003i2-Kf; Fri, 23 Jun 2006 09:35:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftlp7-0003gN-5x for mpls@ietf.org; Fri, 23 Jun 2006 09:35:49 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftlnp-0005ex-TA for mpls@ietf.org; Fri, 23 Jun 2006 09:34:31 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 23 Jun 2006 06:34:29 -0700 X-IronPort-AV: i="4.06,169,1149490800"; d="scan'208"; a="557191440:sNHT31600440" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 06:34:28 -0700 Date: Fri, 23 Jun 2006 06:34:28 -0700 (PDT) From: Rahul Aggarwal To: Lou Berger Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: <7.0.1.0.2.20060623072207.04218360@labn.net> Message-ID: <20060623062716.O837@sapphire.juniper.net> References: <7.0.1.0.2.20060623072207.04218360@labn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 23 Jun 2006 13:34:28.0904 (UTC) FILETIME=[C082FA80:01C696C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Lou, See below: On Fri, 23 Jun 2006, Lou Berger wrote: > JL, > > See below. > > At 03:20 AM 6/23/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > >Hi Lou, > > > >When RRO is not used this procedure does not > >apply and remerge should be fixed in the data plane on the remerge node. > > "fixing in the data plane" doesn't work for all > technologies covered in the spec, e.g., GMPLS optical. > > (You're making me think about my favorite HL Mencken quote...) > > >IMO full RRO inclusion is the price to pay if > >you want to fix remerge in a simple manner in the control plane. > > Yes, but there is already a defined, documented, > and agreed to mechanism that will work for all > the cases. It doesn't appear that the mechanism for fixing remerge in the control plane works as defined and hence this discussion. See the email snippets below outlining the issue: > 4: Section 18.1.1 Remerge Procedure >The text says > "The PathErr message MUST include all of the objects > normally included in a PathErr message, as well as one or more SUB- > LSP objects from the set of sub-LSPs associated with the matching > P2MP LSP Path state. A minimum of three SUB-LSP objects is > RECOMMENDED. This will allow the node that caused the re-merge to > identify the outgoing Path state associated with the valid > portion of > the P2MP LSP. The set of SUB-LSP objects in the received > Path message > MUST also be included" > > And then: > > "A node that receives a PathErr message that contains the > Error Value > "Routing Problem/P2MP Remerge Detected" MUST determine if it is the >> node that created the re-merge case. This is done by checking > whether there is any intersection between the set of > SUB-LSP objects > associated with the matching P2MP LSP Path state and the > set of SUB- > LSP objects in the received PathErr message. If there is, then the >> node created the re-merge case." > > There is an issue here. Actually there will always be an > intersection, because the PathErr includes the set of sub-lsp > objects in the received Path... IMO for this procedure to work > the PathErr MUST only include sub-LSP objects associated with > the matching P2MP LSP state on the rermerge LSR and must not > include the set of SUB-LSP objects in the received Path message. > By the way why are three objects recommended? > > > I believe this was clarified by John Drake offline and no revisions > were > needed ? Rahul, Here's the e-mail I sent to JL: "JL, The text was originally stated as you stated. The issue is that the set of sub-LSPs associated with the interface on the node that caused the re-merge condition may have more members than the set of sub-LSPs in the received Path message, and you only want to move the ones that were in the received Path message. Adrian was the one who initially pointed this and he proposed creating a different object/type for the set of sub-LSPs in the received Path message. I think this is reasonable solution. Thanks, John" As you can see from the last paragraph, we do need to create a new object/type. > De we really want/need to be making > such a significant change at this late date (post > WG last call!). If it were broken, then certain > a change would be needed, but I haven't heard anyone make such an assertion. > See above for the assertion. rahul _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 11:25:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnVM-00013o-JI; Fri, 23 Jun 2006 11:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnVL-00013j-H5 for mpls@ietf.org; Fri, 23 Jun 2006 11:23:31 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtnVL-0004Td-5I for mpls@ietf.org; Fri, 23 Jun 2006 11:23:31 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FtnV4-0008Mw-Q1; Fri, 23 Jun 2006 11:23:15 -0400 Message-Id: <7.0.1.0.2.20060623093952.0399df38@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 23 Jun 2006 11:23:22 -0400 To: Rahul Aggarwal From: Lou Berger Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: <20060623062716.O837@sapphire.juniper.net> References: <7.0.1.0.2.20060623072207.04218360@labn.net> <20060623062716.O837@sapphire.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org sigh. See below. At 09:34 AM 6/23/2006, Rahul Aggarwal wrote: >Hi Lou, > >See below: > >On Fri, 23 Jun 2006, Lou Berger wrote: > > > JL, > > > > See below. > > > > At 03:20 AM 6/23/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > > >Hi Lou, > > > > > >When RRO is not used this procedure does not > > >apply and remerge should be fixed in the data plane on the remerge node. > > > > "fixing in the data plane" doesn't work for all > > technologies covered in the spec, e.g., GMPLS optical. > > > > (You're making me think about my favorite HL Mencken quote...) > > > > >IMO full RRO inclusion is the price to pay if > > >you want to fix remerge in a simple manner in the control plane. > > > > Yes, but there is already a defined, documented, > > and agreed to mechanism that will work for all > > the cases. > >It doesn't appear that the mechanism for fixing remerge in the control >plane works as defined and hence this discussion. See the email snippets >below outlining the issue: see below for a description of how it *does* work. > > > > 4: Section 18.1.1 Remerge Procedure > > >The text says > > "The PathErr message MUST include all of the objects > > normally included in a PathErr message, as well as one or more >SUB- > > LSP objects from the set of sub-LSPs associated with the >matching > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > RECOMMENDED. This will allow the node that caused the re-merge >to > > identify the outgoing Path state associated with the valid > > portion of > > the P2MP LSP. The set of SUB-LSP objects in the received > > Path message > > MUST also be included" > > > > And then: > > > > "A node that receives a PathErr message that contains the > > Error Value > > "Routing Problem/P2MP Remerge Detected" MUST determine if it is >the > >> node that created the re-merge case. This is done by checking > > whether there is any intersection between the set of > > SUB-LSP objects > > associated with the matching P2MP LSP Path state and the > > set of SUB- > > LSP objects in the received PathErr message. If there is, then >the > >> node created the re-merge case." > > > > There is an issue here. I agree the text could be clearer. But I think this is the sole issue. > Actually there will always be an > > intersection, because the PathErr includes the set of sub-lsp > > objects in the received Path... The text should have stated "... matching P2MP LSP Path state and the set of other-branch SUB-LSP objects in the (added-----^^^^^^^^^^^^, and vvvvvvvvvvvvvvvvvvvvvvv) received PathErr message. Other-branch SUB-LSP objects are those SUB-LSP objects included, by the node detecting the re-merge case, in the PathErr message that were taken from the matching P2MP LSP Path state. Such SUB-LSP objects are identifiable as they will not be include in the Path message associated with the received PathErr message. See Section 11.1 for more details on how such an association is identified." >IMO for this procedure to work > > the PathErr MUST only include sub-LSP objects associated with > > the matching P2MP LSP state on the rermerge LSR and must not > > include the set of SUB-LSP objects in the received Path message. > > > By the way why are three objects recommended? > > > > Both sets of SUB-LSP objects are required. Here's why: 1) SUB-LSP objects from the Path message (your point): this is required to cover the case of other branches between the node that detected a re-merge and the node that caused the re-merge. Just moving all the SUB-LSP objects at the offending branch node is at best unneeded disruption to such (sub) branch destinations and at worst will result in a new re-merge situation. In the latter case, the result could be permanent instability and oscillation between multiple re-merge points. 2) "Other-branch" SUB-LSP objects: These are required to cover the case where a branch node has more than two (or n) outgoing path messages. Consider the case where there are 3 outgoing path messages and one of which results in a (partial) re-merge downstream. To correct the problem, this branch node needs to identify which of the other 2 (or n-1) outgoing path messages is triggering the re-merge. "Other-branch" SUB-LSP objects provide this identification. Also, as they are already being included, these objects are also used to identify the branch node that caused the re-merge. > > > > > > I believe this was clarified by John Drake offline and no revisions > > were > > needed ? > > > > > >Rahul, > >Here's the e-mail I sent to JL: > >"JL, > >The text was originally stated as you stated. The issue is that the set >of sub-LSPs associated with the interface on the node that caused the >re-merge condition may have more members than the set of sub-LSPs in the >received Path message, and you only want to move the ones that were in >the received Path message. > >Adrian was the one who initially pointed this and he proposed creating a >different object/type for the set of sub-LSPs in the received Path >message. I think this is reasonable solution. > >Thanks, > >John" While a different type is a possible solution, I think John is forgetting a detailed discussion that he and I had in which we decided that we could use another object (or c-type) but decided that such identification wasn't really needed for proper processing so we decided not to add the complexity of a new type. >As you can see from the last paragraph, we do need to create a new >object/type. > I think that a new type isn't needed and what is defined (and further clarified above) is sufficient. > > > > De we really want/need to be making > > such a significant change at this late date (post > > WG last call!). If it were broken, then certain > > a change would be needed, but I haven't heard anyone make such an > assertion. > > > >See above for the assertion. see above. Lou >rahul _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 11:31:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnbI-0000CC-Ak; Fri, 23 Jun 2006 11:29:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnbH-00009a-JM for mpls@ietf.org; Fri, 23 Jun 2006 11:29:39 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtnbH-0004dI-2V for mpls@ietf.org; Fri, 23 Jun 2006 11:29:39 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 14:29:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Fri, 23 Jun 2006 14:29:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaWuDvCsM/duDa5TNOD0XNfhhzA3gABOPjw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Lou Berger" X-OriginalArrivalTime: 23 Jun 2006 12:29:17.0764 (UTC) FILETIME=[A54A6040:01C696C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Lou, >=20 > "fixing in the data plane" doesn't work for all technologies=20 > covered in the spec, e.g., GMPLS optical. Couldn't you fix it in the optical case, simply by not activating the = cross connection that causes the re-merge? > If it were broken, then certain a=20 > change would be needed, but I haven't heard anyone make such=20 > an assertion. It seems to me that the current procedure requires a lot of processing. = All LSRs on the path from the re-merge originator to the re-merge node = will have to compare all sub-LSPs in the PathErr with all sub-LSPs in = the corresponding P2MP Path State Block, and this may require a lot of = processing. The other approach only require looking at the re-merge = originator address... However, note that this is not a blocking issue for me if we let the = current procedure as is. Regards, JL =20 > -----Message d'origine----- > De : Lou Berger [mailto:lberger@labn.net]=20 > Envoy=E9 : vendredi 23 juin 2006 13:29 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : Lou Berger; zzx-rahul@juniper.net; mpls@ietf.org; Drake, John E > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > JL, >=20 > See below. >=20 > At 03:20 AM 6/23/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > >Hi Lou, > > > >When RRO is not used this procedure does not apply and=20 > remerge should=20 > >be fixed in the data plane on the remerge node. >=20 > "fixing in the data plane" doesn't work for all technologies=20 > covered in the spec, e.g., GMPLS optical. >=20 > (You're making me think about my favorite HL Mencken quote...) >=20 > >IMO full RRO inclusion is the price to pay if you want to=20 > fix remerge=20 > >in a simple manner in the control plane. >=20 > Yes, but there is already a defined, documented, and agreed=20 > to mechanism that will work for all the cases. De we really=20 > want/need to be making such a significant change at this late=20 > date (post WG last call!). If it were broken, then certain a=20 > change would be needed, but I haven't heard anyone make such=20 > an assertion. >=20 > Lou >=20 > >Regards, > > > >JL > > > > > -----Message d'origine----- > > > De : Lou Berger [mailto:lberger@labn.net] Envoy=E9 :=20 > vendredi 23 juin=20 > > > 2006 05:51 =C0 : LE ROUX Jean-Louis RD-CORE-LAN Cc :=20 > > > zzx-rahul@juniper.net; mpls@ietf.org; Drake, John E Objet : RE:=20 > > > [mpls] TR: working group last call=20 > > > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > JL, > > > > > > So what happens when no RRO is used (which isn't currently > > > required) or portions of the RRO are removed? > > > > > > Lou > > > > > > At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > > > > >Hi Rahul, all > > > > > > > >Actually, after thinking a bit more, it seems to me that=20 > a simpler=20 > > > >remerge procedure based on RRO analysis could be useful. > > > >If the RRO is carried in Path messages, the node where=20 > the remerge=20 > > > >occurs could easily identify the node that created the > > > remerge, simply > > > >by analyzing the two RROs. > > > >When a node detect a remerge it sends a PAthErr with a=20 > new object=20 > > > >(Remerge-Spec object) that identifies the remerge origin. > > > This PathErr > > > >carries the set of sub-LSPs received in the Path message that=20 > > > >caused the remerge. > > > >On receipt of such PAthErr, a node that see its own=20 > address in the=20 > > > >Remerge-spec object moves the set of sub-LSPs... > > > > > > > >It seems that this procedure would require simpler processing... > > > >It requires the use of RRO, but this is the price to pay. > > > > > > > >Would that make sense? > > > > > > > >Best Regards, > > > > > > > >JL > > > > > > > > > > > > > -----Message d'origine----- > > > > > De : Drake, John E [mailto:John.E.Drake2@boeing.com] > > > Envoy=E9 : mardi > > > > > 20 juin 2006 23:59 =C0 : zzx-rahul@juniper.net; LE ROUX=20 > Jean-Louis=20 > > > > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR: > > > working group > > > > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > Rahul, > > > > > > > > > > Snipped, comments inline. > > > > > > > > > > Thanks, > > > > > > > > > > John > > > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > > > > > > > The text says > > > > > > > > "The PathErr message MUST include all of the objects > > > > > > > > normally included in a PathErr message, as well as > > > > > one or more > > > > > SUB- > > > > > > > > LSP objects from the set of sub-LSPs associated with=20 > > > > > > > > the > > > > > matching > > > > > > > > P2MP LSP Path state. A minimum of three SUB-LSP > > > objects is > > > > > > > > RECOMMENDED. This will allow the node that caused > > > > > the re-merge > > > > > to > > > > > > > > identify the outgoing Path state associated with > > > the valid > > > > > > > > portion of > > > > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > > > > received Path > > > > > > > > message > > > > > > > > MUST also be included" > > > > > > > > > > > > > > > > And then: > > > > > > > > > > > > > > > > "A node that receives a PathErr message that > > > > > contains the Error > > > > > > > > Value > > > > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > > > > determine if it is > > > > > the > > > > > > > > node that created the re-merge case. This is done > > > > > by checking > > > > > > > > whether there is any intersection between the set of=20 > > > > > > > > SUB-LSP objects > > > > > > > > associated with the matching P2MP LSP Path state and > > > > > the set of > > > > > > > > SUB- > > > > > > > > LSP objects in the received PathErr message. If > > > > > there is, then > > > > > the > > > > > > > > node created the re-merge case." > > > > > > > > > > > > > > > > There is an issue here. Actually there will=20 > always be an=20 > > > > > > > > intersection, because the PathErr includes the set > > > of sub-lsp > > > > > > > > objects in the received Path... IMO for this procedure > > > > > to work the > > > > > > > > PathErr MUST only include sub-LSP objects > > > associated with the > > > > > > > > matching P2MP LSP state on the rermerge LSR and must > > > > > not include > > > > > > > > the set of SUB-LSP objects in the received Path message. > > > > > > > > By the way why are three objects recommended? > > > > > > > > > > > > > > > > > > > > I believe this was clarified by John Drake offline and no=20 > > > > > > revisions > > > > > were > > > > > > needed ? > > > > > Rahul, > > > > > > > > > > Here's the e-mail I sent to JL: > > > > > > > > > > "JL, > > > > > > > > > > The text was originally stated as you stated. The issue > > > is that the > > > > > set of sub-LSPs associated with the interface on the=20 > node that=20 > > > > > caused the re-merge condition may have more members than > > > the set of > > > > > sub-LSPs in the received Path message, and you only want > > > to move the > > > > > ones that were in the received Path message. > > > > > > > > > > Adrian was the one who initially pointed this and he proposed=20 > > > > > creating a different object/type for the set of=20 > sub-LSPs in the=20 > > > > > received Path message. I think this is reasonable solution. > > > > > > > > > > Thanks, > > > > > > > > > > John" > > > > > > > > > > As you can see from the last paragraph, we do need to > > > create a new > > > > > object/type. > > > > > > > > > > > > >_______________________________________________ > > > >mpls mailing list > > > >mpls@lists.ietf.org > > > >https://www1.ietf.org/mailman/listinfo/mpls > > > > > > >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 12:33:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtoYv-0003K4-3u; Fri, 23 Jun 2006 12:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtoYt-0003J2-B1 for mpls@ietf.org; Fri, 23 Jun 2006 12:31:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtoYq-0007xz-Lp for mpls@ietf.org; Fri, 23 Jun 2006 12:31:15 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 23 Jun 2006 09:31:10 -0700 X-IronPort-AV: i="4.06,169,1149490800"; d="scan'208"; a="300007201:sNHT201531162" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5NGVAUX011368; Fri, 23 Jun 2006 09:31:10 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5NGV7Iu016128; Fri, 23 Jun 2006 09:31:10 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 12:31:07 -0400 Received: from swallow-mini-mac.cisco.com ([10.86.116.2]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 12:31:06 -0400 Received: from cisco.com (localhost [127.0.0.1]) by swallow-mini-mac.cisco.com (Postfix) with ESMTP id D55AA294846; Fri, 23 Jun 2006 12:31:05 -0400 (EDT) To: Rahul Aggarwal Subject: Re: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] In-reply-to: Your message of "Fri, 23 Jun 2006 08:43:48 EDT." <17563.57860.873343.916511@lens.cisco.com> X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Fri, 23 Jun 2006 12:31:05 -0400 From: George Swallow Message-Id: <20060623163105.D55AA294846@swallow-mini-mac.cisco.com> X-OriginalArrivalTime: 23 Jun 2006 16:31:06.0893 (UTC) FILETIME=[6D67C3D0:01C696E2] DKIM-Signature: a=rsa-sha1; q=dns; l=6086; t=1151080270; x=1151944270; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:Re=3A=20[mpls]=20Identifier=20Semantics=20[Re=3A=20working=20group=20las t=20call=20on=20draft-ietf-mpls-rsvp-te-p2mp-05.txt]=20; X=v=3Dcisco.com=3B=20h=3Dd1PG3eSqHxqybPu9pH32ZJoSehg=3D; b=iSQTr6FMTS05ay3BpNXMaU19UwMYQa5h7eO3gwGgXElWpqVCaoGm81IuEChg99LLn9r0uSCI 6shIKl39oay5u3Th3Zmf4trPCL29/TUMcjLf4BAH8BiqEO6k7BjeEJ25; Authentication-Results: sj-dkim-7.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org I see absolutely no need for this change. First it is possible (though perhaps unlikely) that a tunnel head end will need to break up a P2MP tree for scalability reasons and want to keep the same P2MP ID. Second an implementation may find it convenient to interally assign tunnel IDs and index on these. What difference would it make to any midpoint or endpoint if this field "Should" be a constant zero or not? ...George > Hi Folks, > > Yakov brought up the issue of P2MP ID, Tunnel ID, Extended Tunnel ID > semantics as part of the last call and a discussion followed on this list. > > In order to resolve this discussion I had proposed some text. I have > received some comments on this offline and want to move this discussion to > a broader audience. > > Please comment on the text changes below, if you have objections or > suggestions. Else this will be incorporated in the next version of the > spec. > > How about the following rephrasing: > > 1. > > Section 4.1: > > " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes the P2MP ID, a tunnel > ID and an extended tunnel ID. > > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP Identifier (P2MP ID) field. > > The P2MP ID provides an identifier for the set of destinations of the > P2MP TE Tunnel." > > to > > " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes a tuple > , where the P2MP Identifier (P2MP > ID) is unique within the scope of the IP address of the ingress LSR. The > Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP > Tunnel identifier, carried in the P2MP SESSION object, is unique within > the same scope as the ingress LSR IP address. > > The fields of the P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP ID field." > > 2. > > Section 4.2. > > " A P2MP LSP is identified by the combination of the P2MP ID, Tunnel > ID, and Extended Tunnel ID that are part of the P2MP SESSION object, > and the tunnel sender address and LSP ID fields of the P2MP > SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is > defined in section 20.2." > > to > > " A P2MP LSP is identified by the combination of the P2MP ID, > Extended Tunnel ID that are part of the P2MP SESSION object, > and the tunnel sender address and LSP ID fields of the P2MP > SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is > defined in section 20.2." > > 3. > > 19.1.1 > > "P2MP ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP ID and identifies the set of destinations of the P2MP > Tunnel." > > to > > "P2MP ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP Identifier that is unique within the scope of the Ingress LSR > IP address carried in the Extended Tunnel ID. > > 4. > 19.1.1 > > "Tunnel ID > > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel." > > to > > "Tunnel ID > > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It SHOULD be set to 0 > by the ingress LSR and be ignored on receipt." > > > 5. > > "Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Normally set to > all zeros. Ingress nodes that wish to narrow the scope of a > SESSION to the ingress-PID pair may place their IPv4 address > here as a globally unique identifier [RFC3209]." > > to > > "Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. This identifier > MUST be set to the ingress LSR's IPv4 address." > > 6. > > 19.1.2 > > "This is same as the P2MP IPv4 LSP SESSION Object with the difference > that the extended tunnel ID may be set to a 16 byte identifier > [RFC3209]." > > to > > "This is same as the P2MP IPv4 LSP SESSION Object with the difference > that the extended tunnel ID MUST be set to a 16 byte identifier that is > the ingress LSR's IPv6 address." > > 7. > > 19.2.1 > > " IPv4 tunnel sender address > See [RFC3209]" > > to" > > "IPv4 tunnel sender address. This address MUST be the same as the address > in the Extended Tunnel ID field of the SESSION object." > > 8. > > 19.2.2 > > "IPv6 tunnel sender address > See [RFC3209]" > > to > > "IPv6 tunnel sender address. This address MUST be the same as the address > in the Extended Tunnel ID field of the SESSION object." > > Thanks, > rahul > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls -- Elisheva Halevy Hochberg 978-936-1362 ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 19:11:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftuml-0005lw-Ug; Fri, 23 Jun 2006 19:09:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftumk-0005lr-59 for mpls@ietf.org; Fri, 23 Jun 2006 19:09:58 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftumj-0000Oc-LN for mpls@ietf.org; Fri, 23 Jun 2006 19:09:58 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jun 2006 01:09:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Date: Sat, 24 Jun 2006 01:09:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaW2P2Kkb00VGkhSoml4ioc/46WkgAPka7A From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Lou Berger" , X-OriginalArrivalTime: 23 Jun 2006 23:09:55.0332 (UTC) FILETIME=[23DDCC40:01C6971A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Lou, Your proposed update to the remerge text covers my initial LC comment.=20 This requires quite a lot of processing compared to the RRO-based = approach I suggested, but it works in all situations (no RRO or partial = RRO). Hence it must be kept... Also please see inline,=20 > -----Message d'origine----- > De : Lou Berger [mailto:lberger@labn.net]=20 > Envoy=E9 : vendredi 23 juin 2006 17:23 > =C0 : zzx-rahul@juniper.net > Cc : Lou Berger; LE ROUX Jean-Louis RD-CORE-LAN;=20 > mpls@ietf.org; Drake, John E > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > sigh. See below. >=20 > At 09:34 AM 6/23/2006, Rahul Aggarwal wrote: >=20 >=20 > >Hi Lou, > > > >See below: > > > >On Fri, 23 Jun 2006, Lou Berger wrote: > > > > > JL, > > > > > > See below. > > > > > > At 03:20 AM 6/23/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > > > > >Hi Lou, > > > > > > > >When RRO is not used this procedure does not apply and remerge=20 > > > >should be fixed in the data plane on the remerge node. > > > > > > "fixing in the data plane" doesn't work for all=20 > technologies covered=20 > > > in the spec, e.g., GMPLS optical. > > > > > > (You're making me think about my favorite HL Mencken quote...) > > > > > > >IMO full RRO inclusion is the price to pay if you want to fix=20 > > > >remerge in a simple manner in the control plane. > > > > > > Yes, but there is already a defined, documented, and agreed to=20 > > > mechanism that will work for all the cases. > > > >It doesn't appear that the mechanism for fixing remerge in=20 > the control=20 > >plane works as defined and hence this discussion. See the email=20 > >snippets below outlining the issue: >=20 > see below for a description of how it *does* work. >=20 > > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > >The text says > > > "The PathErr message MUST include all of the objects > > > normally included in a PathErr message, as well as one or more > >SUB- > > > LSP objects from the set of sub-LSPs associated with the > >matching > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > RECOMMENDED. This will allow the node that caused the re-merge > >to > > > identify the outgoing Path state associated with the valid=20 > > > portion of > > > the P2MP LSP. The set of SUB-LSP objects in the received Path=20 > > > message > > > MUST also be included" > > > > > > And then: > > > > > > "A node that receives a PathErr message that contains=20 > the Error=20 > > > Value > > > "Routing Problem/P2MP Remerge Detected" MUST determine if it is > >the > > >> node that created the re-merge case. This is done by checking > > > whether there is any intersection between the set of SUB-LSP=20 > > > objects > > > associated with the matching P2MP LSP Path state and=20 > the set of=20 > > > SUB- > > > LSP objects in the received PathErr message. If there is, then > >the > > >> node created the re-merge case." > > > > > > There is an issue here. >=20 > I agree the text could be clearer. But I think this is the=20 > sole issue. >=20 > > Actually there will always be an > > > intersection, because the PathErr includes the set of sub-lsp=20 > > > objects in the received Path... >=20 > The text should have stated "... matching P2MP LSP Path state=20 > and the set of other-branch SUB-LSP objects in the=20 > (added-----^^^^^^^^^^^^, and vvvvvvvvvvvvvvvvvvvvvvv)=20 > received PathErr message. Other-branch SUB-LSP objects are=20 > those SUB-LSP objects included, by the node detecting the=20 > re-merge case, in the PathErr message that were taken from=20 > the matching P2MP LSP Path state. Such SUB-LSP objects are=20 > identifiable as they will not be include in the Path message=20 > associated with the received PathErr message. See Section=20 > 11.1 for more details on how such an association is identified." OK this text is definitely clearer, and easy to understand. >=20 > >IMO for this procedure to work > > > the PathErr MUST only include sub-LSP objects associated with the=20 > > > matching P2MP LSP state on the rermerge LSR and must not=20 > include the=20 > > > set of SUB-LSP objects in the received Path message. > > > > > By the way why are three objects recommended? > > > > > > >=20 >=20 > Both sets of SUB-LSP objects are required. Here's why: > 1) SUB-LSP objects from the Path message (your point): this=20 > is required to cover the case of other branches between the=20 > node that detected a re-merge and the node that caused the=20 > re-merge. =20 OK, I see. > Just moving all the SUB-LSP objects at the=20 > offending branch node is at best unneeded disruption to such=20 > (sub) branch destinations and at worst will result in a new=20 > re-merge situation. In the latter case, the result could be=20 > permanent instability and oscillation between multiple=20 > re-merge points. OK > 2) "Other-branch" SUB-LSP objects: These are required to=20 > cover the case where a branch node has more than two (or n)=20 > outgoing path messages. Consider the case where there are 3=20 > outgoing path messages and one of which results in a=20 > (partial) re-merge downstream. To correct the problem, this=20 > branch node needs to identify which of the other 2 (or n-1)=20 > outgoing path messages is triggering the re-merge. =20 > "Other-branch" SUB-LSP objects provide this identification. =20 > Also, as they are already being included, these objects are=20 > also used to identify the branch node that caused the re-merge. OK >=20 >=20 >=20 > > > > > > > > > > > I believe this was clarified by John Drake offline and no=20 > revisions=20 > > > were needed ? > > > > > > > > > > > >Rahul, > > > >Here's the e-mail I sent to JL: > > > >"JL, > > > >The text was originally stated as you stated. The issue is that the=20 > >set of sub-LSPs associated with the interface on the node=20 > that caused=20 > >the re-merge condition may have more members than the set of=20 > sub-LSPs=20 > >in the received Path message, and you only want to move the=20 > ones that=20 > >were in the received Path message. > > > >Adrian was the one who initially pointed this and he=20 > proposed creating=20 > >a different object/type for the set of sub-LSPs in the received Path=20 > >message. I think this is reasonable solution. > > > >Thanks, > > > >John" >=20 > While a different type is a possible solution, I think John=20 > is forgetting a detailed discussion that he and I had in=20 > which we decided that we could use another object (or c-type)=20 > but decided that such identification wasn't really needed for=20 > proper processing so we decided not to add the complexity of=20 > a new type. >=20 > >As you can see from the last paragraph, we do need to create a new=20 > >object/type. > > >=20 > I think that a new type isn't needed and what is defined (and=20 > further clarified above) is sufficient. A new type would allow easier identification of "other-branch" sub-LSP = objects, it would require less processing, but I agree that this works = as is. Regards JL >=20 > > > > > > > De we really want/need to be making > > > such a significant change at this late date (post WG last=20 > call!). =20 > > > If it were broken, then certain a change would be needed, but I=20 > > > haven't heard anyone make such an > > assertion. > > > > > > >See above for the assertion. >=20 > see above. >=20 > Lou >=20 >=20 > >rahul >=20 >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri Jun 23 20:18:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtvpX-0006RR-BE; Fri, 23 Jun 2006 20:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtvpW-0006RM-Kn for mpls@ietf.org; Fri, 23 Jun 2006 20:16:54 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtvpU-0002Uk-51 for mpls@ietf.org; Fri, 23 Jun 2006 20:16:54 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 23 Jun 2006 17:16:51 -0700 X-IronPort-AV: i="4.06,170,1149490800"; d="scan'208"; a="562224346:sNHT34557360" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 17:16:51 -0700 Date: Fri, 23 Jun 2006 17:16:51 -0700 (PDT) From: Rahul Aggarwal To: LE ROUX Jean-Louis RD-CORE-LAN Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: Message-ID: <20060623171443.T837@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 Jun 2006 00:16:51.0342 (UTC) FILETIME=[7D984AE0:01C69723] X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: mpls@ietf.org, "Drake, John E" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Lou, JL and all, On Sat, 24 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Lou, > > Your proposed update to the remerge text covers my initial LC comment. Great. Please see inline: > This requires quite a lot of processing compared to the RRO-based approach I suggested, but it works in all situations (no RRO or partial RRO). Hence it must be kept... > > Also please see inline, > > > > > I agree the text could be clearer. But I think this is the > > sole issue. > > > > > Actually there will always be an > > > > intersection, because the PathErr includes the set of sub-lsp > > > > objects in the received Path... > > > > The text should have stated "... matching P2MP LSP Path state > > and the set of other-branch SUB-LSP objects in the > > (added-----^^^^^^^^^^^^, and vvvvvvvvvvvvvvvvvvvvvvv) > > received PathErr message. Other-branch SUB-LSP objects are > > those SUB-LSP objects included, by the node detecting the > > re-merge case, in the PathErr message that were taken from > > the matching P2MP LSP Path state. Such SUB-LSP objects are > > identifiable as they will not be include in the Path message > > associated with the received PathErr message. See Section > > 11.1 for more details on how such an association is identified." > > OK this text is definitely clearer, and easy to understand. > The editors will include this in the next rev and consider this LC comment addressed.. Thanks JL for identifiying the issue and Lou for fixing the text. rahul > > > > > >IMO for this procedure to work > > > > the PathErr MUST only include sub-LSP objects associated with the > > > > matching P2MP LSP state on the rermerge LSR and must not > > include the > > > > set of SUB-LSP objects in the received Path message. > > > > > > > By the way why are three objects recommended? > > > > > > > > > > > > > > Both sets of SUB-LSP objects are required. Here's why: > > 1) SUB-LSP objects from the Path message (your point): this > > is required to cover the case of other branches between the > > node that detected a re-merge and the node that caused the > > re-merge. > > OK, I see. > > > Just moving all the SUB-LSP objects at the > > offending branch node is at best unneeded disruption to such > > (sub) branch destinations and at worst will result in a new > > re-merge situation. In the latter case, the result could be > > permanent instability and oscillation between multiple > > re-merge points. > > OK > > > 2) "Other-branch" SUB-LSP objects: These are required to > > cover the case where a branch node has more than two (or n) > > outgoing path messages. Consider the case where there are 3 > > outgoing path messages and one of which results in a > > (partial) re-merge downstream. To correct the problem, this > > branch node needs to identify which of the other 2 (or n-1) > > outgoing path messages is triggering the re-merge. > > "Other-branch" SUB-LSP objects provide this identification. > > Also, as they are already being included, these objects are > > also used to identify the branch node that caused the re-merge. > > OK > > > > > > > > > > > > > > > > > > > > > > > I believe this was clarified by John Drake offline and no > > revisions > > > > were needed ? > > > > > > > > > > > > > > > > > >Rahul, > > > > > >Here's the e-mail I sent to JL: > > > > > >"JL, > > > > > >The text was originally stated as you stated. The issue is that the > > >set of sub-LSPs associated with the interface on the node > > that caused > > >the re-merge condition may have more members than the set of > > sub-LSPs > > >in the received Path message, and you only want to move the > > ones that > > >were in the received Path message. > > > > > >Adrian was the one who initially pointed this and he > > proposed creating > > >a different object/type for the set of sub-LSPs in the received Path > > >message. I think this is reasonable solution. > > > > > >Thanks, > > > > > >John" > > > > While a different type is a possible solution, I think John > > is forgetting a detailed discussion that he and I had in > > which we decided that we could use another object (or c-type) > > but decided that such identification wasn't really needed for > > proper processing so we decided not to add the complexity of > > a new type. > > > > >As you can see from the last paragraph, we do need to create a new > > >object/type. > > > > > > > I think that a new type isn't needed and what is defined (and > > further clarified above) is sufficient. > > A new type would allow easier identification of "other-branch" sub-LSP objects, it would require less processing, but I agree that this works as is. > > Regards > > JL > > > > > > > > > > > > > De we really want/need to be making > > > > such a significant change at this late date (post WG last > > call!). > > > > If it were broken, then certain a change would be needed, but I > > > > haven't heard anyone make such an > > > assertion. > > > > > > > > > >See above for the assertion. > > > > see above. > > > > Lou > > > > > > >rahul > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat Jun 24 06:53:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu5jx-0006e3-9t; Sat, 24 Jun 2006 06:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu5jw-0006dy-30 for mpls@lists.ietf.org; Sat, 24 Jun 2006 06:51:48 -0400 Received: from mum-pop2-b1.vsnl.net ([203.200.235.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu5ju-0000lc-Il for mpls@lists.ietf.org; Sat, 24 Jun 2006 06:51:48 -0400 Received: from vsnl.net (pop2.vsnl.net [172.16.28.140]) by pop2.vsnl.net (vsnl mail server) with ESMTP id <0J1D000C8268XK@pop2.vsnl.net> for mpls@lists.ietf.org; Sat, 24 Jun 2006 16:21:44 +0530 (IST) Received: from [172.16.28.181] (Forwarded-For: 172.1.13.117, [203.199.104.65]) by pop2.vsnl.net (mshttpd); Sat, 24 Jun 2006 15:51:44 +0500 Date: Sat, 24 Jun 2006 15:51:44 +0500 From: sanjay.chalikar@vsnl.net In-reply-to: To: mpls@lists.ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.10 (built Dec 26 2005) Content-type: multipart/mixed; boundary="Boundary_(ID_MsCVk8wM8hfEWd+/58OouQ)" Content-language: en X-Accept-Language: en Priority: normal References: X-Spam-Score: 0.8 (/) X-Scan-Signature: 8db6b1eef878f11b7d6324adee263d0c Subject: [mpls] Contents of mpls digest...Vol 26 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_MsCVk8wM8hfEWd+/58OouQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline

I am not abe to find the file stated "Filename : draft-ietf-mpls-mp-ldp-reqs-01.txt" can i be guided ?

with kind regards,

Sanjay Chalikar (m) 9223468245.




with kind regards,
Sanjay Chalikar
(m) 9223 468245.

--Boundary_(ID_MsCVk8wM8hfEWd+/58OouQ) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-description: Today's Topics (5 messages) Today's Topics: 1. I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-01.txt (Internet-Drafts@ietf.org) 2. RE: TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt (LE ROUX Jean-Louis RD-CORE-LAN) 3. RE: TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt (Lou Berger) 4. Load-Balancing among a set of candidate upstream LSRs on a LAN-----draft-liu-mpls-upstream-load-balance-00.txt (liushuying) 5. RE: TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt (LE ROUX Jean-Louis RD-CORE-LAN) --Boundary_(ID_MsCVk8wM8hfEWd+/58OouQ) MIME-version: 1.0 Content-type: multipart/digest; boundary="Boundary_(ID_BpsNw5/pXe3+iuFLzBBELg)" --Boundary_(ID_BpsNw5/pXe3+iuFLzBBELg) MIME-version: 1.0 Content-type: message/rfc822 Date: Thu, 22 Jun 2006 18:50:01 -0400 From: Internet-Drafts@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-01.txt To: i-d-announce@ietf.org Cc: mpls@lists.ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_SP4JLO3xhO5P0D+sALvACA)" Precedence: list Message: 1 --Boundary_(ID_SP4JLO3xhO5P0D+sALvACA) Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT 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 : Requirements for point-to-multipoint extensions to the Label Distribution Protocol Author(s) : J. Le Roux, et al. Filename : draft-ietf-mpls-mp-ldp-reqs-01.txt Pages : 17 Date : 2006-6-22 This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mp-ldp-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_SP4JLO3xhO5P0D+sALvACA) Content-type: multipart/alternative; boundary="Boundary_(ID_6rO+UMQRX6Y5cWwp2mE/WQ)" --Boundary_(ID_6rO+UMQRX6Y5cWwp2mE/WQ) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server --Boundary_(ID_6rO+UMQRX6Y5cWwp2mE/WQ) Content-type: Message/External-body; name=draft-ietf-mpls-mp-ldp-reqs-01.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-mpls-mp-ldp-reqs-01.txt --Boundary_(ID_6rO+UMQRX6Y5cWwp2mE/WQ)-- --Boundary_(ID_SP4JLO3xhO5P0D+sALvACA)-- --Boundary_(ID_BpsNw5/pXe3+iuFLzBBELg) MIME-version: 1.0 Content-type: message/rfc822 Date: Thu, 22 Jun 2006 16:02:39 +0200 From: LE ROUX Jean-Louis RD-CORE-LAN Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt To: rahul@juniper.net Cc: mpls@ietf.org, "Drake, John E" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Precedence: list Message: 2 Hi Rahul, >Would you like to propose the modified text ?=20 I can provide some text by the end of the day. Regards, JL > -----Message d'origine----- > De : Rahul Aggarwal [mailto:rahul@juniper.net]=20 > Envoy=E9 : jeudi 22 juin 2006 15:53 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : mpls@ietf.org; Drake, John E > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 >=20 > Hi JL, >=20 > On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > > Hi Rahul, all > > > > Actually, after thinking a bit more, it seems to me that a=20 > simpler remerge procedure based on RRO analysis could be useful. > > If the RRO is carried in Path messages, the node where the remerge=20 > > occurs could easily identify the node that created the=20 > remerge, simply by analyzing the two RROs. > > When a node detect a remerge it sends a PAthErr with a new=20 > object (Remerge-Spec object) that identifies the remerge=20 > origin. This PathErr carries the set of sub-LSPs received in=20 > the Path message that caused the remerge. > > On receipt of such PAthErr, a node that see its own address in the=20 > > Remerge-spec object moves the set of sub-LSPs... > > > > It seems that this procedure would require simpler processing... > > It requires the use of RRO, but this is the price to pay. > > >=20 > I think this is reasonable. If it is desriable to fix remerge=20 > in the control plane this is a reasonable tradeoff. Else the=20 > spec has the option to fix remerge in the data plane. >=20 > > Would that make sense? > > >=20 > Would you like to propose the modified text ? >=20 > Thanks, > rahul >=20 > > Best Regards, > > > > JL > > > > > > > -----Message d'origine----- > > > De : Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Envoy=E9 : mardi=20 > > > 20 juin 2006 23:59 =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis = > > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR:=20 > working group=20 > > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Rahul, > > > > > > Snipped, comments inline. > > > > > > Thanks, > > > > > > John > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > > > The text says > > > > > > "The PathErr message MUST include all of the objects > > > > > > normally included in a PathErr message, as well as > > > one or more > > > SUB- > > > > > > LSP objects from the set of sub-LSPs associated with the > > > matching > > > > > > P2MP LSP Path state. A minimum of three SUB-LSP=20 > objects is > > > > > > RECOMMENDED. This will allow the node that caused > > > the re-merge > > > to > > > > > > identify the outgoing Path state associated with=20 > the valid=20 > > > > > > portion of > > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > > received Path > > > > > > message > > > > > > MUST also be included" > > > > > > > > > > > > And then: > > > > > > > > > > > > "A node that receives a PathErr message that > > > contains the Error > > > > > > Value > > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > > determine if it is > > > the > > > > > > node that created the re-merge case. This is done > > > by checking > > > > > > whether there is any intersection between the set of=20 > > > > > > SUB-LSP objects > > > > > > associated with the matching P2MP LSP Path state and > > > the set of > > > > > > SUB- > > > > > > LSP objects in the received PathErr message. If > > > there is, then > > > the > > > > > > node created the re-merge case." > > > > > > > > > > > > There is an issue here. Actually there will always be an=20 > > > > > > intersection, because the PathErr includes the set=20 > of sub-lsp=20 > > > > > > objects in the received Path... IMO for this procedure > > > to work the > > > > > > PathErr MUST only include sub-LSP objects=20 > associated with the=20 > > > > > > matching P2MP LSP state on the rermerge LSR and must > > > not include > > > > > > the set of SUB-LSP objects in the received Path message. > > > > > > By the way why are three objects recommended? > > > > > > > > > > > > > > I believe this was clarified by John Drake offline and no=20 > > > > revisions > > > were > > > > needed ? > > > Rahul, > > > > > > Here's the e-mail I sent to JL: > > > > > > "JL, > > > > > > The text was originally stated as you stated. The issue=20 > is that the=20 > > > set of sub-LSPs associated with the interface on the node that=20 > > > caused the re-merge condition may have more members than=20 > the set of=20 > > > sub-LSPs in the received Path message, and you only want=20 > to move the=20 > > > ones that were in the received Path message. > > > > > > Adrian was the one who initially pointed this and he proposed=20 > > > creating a different object/type for the set of sub-LSPs in the=20 > > > received Path message. I think this is reasonable solution. > > > > > > Thanks, > > > > > > John" > > > > > > As you can see from the last paragraph, we do need to=20 > create a new=20 > > > object/type. > > > > > > > >=20 --Boundary_(ID_BpsNw5/pXe3+iuFLzBBELg) MIME-version: 1.0 Content-type: message/rfc822 Date: Thu, 22 Jun 2006 23:51:22 -0400 From: Lou Berger Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt In-reply-to: To: LE ROUX Jean-Louis RD-CORE-LAN Cc: mpls@ietf.org, "Drake, John E" Message-id: <7.0.1.0.2.20060622235040.041f92e0@labn.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1; format=flowed Content-transfer-encoding: quoted-printable Precedence: list Message: 3 References: JL, So what happens when no RRO is used (which isn't=20 currently required) or portions of the RRO are removed? Lou At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Rahul, all > >Actually, after thinking a bit more, it seems to=20 >me that a simpler remerge procedure based on RRO analysis could be useful. >If the RRO is carried in Path messages, the node where the remerge >occurs could easily identify the node that=20 >created the remerge, simply by analyzing the two RROs. >When a node detect a remerge it sends a PAthErr=20 >with a new object (Remerge-Spec object) that=20 >identifies the remerge origin. This PathErr=20 >carries the set of sub-LSPs received in the Path=20 >message that caused the remerge. >On receipt of such PAthErr, a node that see its own address in the >Remerge-spec object moves the set of sub-LSPs... > >It seems that this procedure would require simpler processing... >It requires the use of RRO, but this is the price to pay. > >Would that make sense? > >Best Regards, > >JL > > > > -----Message d'origine----- > > De : Drake, John E [mailto:John.E.Drake2@boeing.com] > > Envoy=E9 : mardi 20 juin 2006 23:59 > > =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis RD-CORE-LAN > > Cc : mpls@ietf.org > > Objet : RE: [mpls] TR: working group last call > > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > Rahul, > > > > Snipped, comments inline. > > > > Thanks, > > > > John > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > The text says > > > > > "The PathErr message MUST include all of the objects > > > > > normally included in a PathErr message, as well as > > one or more > > SUB- > > > > > LSP objects from the set of sub-LSPs associated with the > > matching > > > > > P2MP LSP Path state. A minimum of three SUB-LSP objects is > > > > > RECOMMENDED. This will allow the node that caused > > the re-merge > > to > > > > > identify the outgoing Path state associated with the valid > > > > > portion of > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > received Path > > > > > message > > > > > MUST also be included" > > > > > > > > > > And then: > > > > > > > > > > "A node that receives a PathErr message that > > contains the Error > > > > > Value > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > determine if it is > > the > > > > > node that created the re-merge case. This is done > > by checking > > > > > whether there is any intersection between the set of SUB-LSP > > > > > objects > > > > > associated with the matching P2MP LSP Path state and > > the set of > > > > > SUB- > > > > > LSP objects in the received PathErr message. If > > there is, then > > the > > > > > node created the re-merge case." > > > > > > > > > > There is an issue here. Actually there will always be an > > > > > intersection, because the PathErr includes the set of sub-lsp > > > > > objects in the received Path... IMO for this procedure > > to work the > > > > > PathErr MUST only include sub-LSP objects associated with the > > > > > matching P2MP LSP state on the rermerge LSR and must > > not include > > > > > the set of SUB-LSP objects in the received Path message. > > > > > By the way why are three objects recommended? > > > > > > > > > > > I believe this was clarified by John Drake offline and no revisions > > were > > > needed ? > > Rahul, > > > > Here's the e-mail I sent to JL: > > > > "JL, > > > > The text was originally stated as you stated. The issue is > > that the set of sub-LSPs associated with the interface on the > > node that caused the re-merge condition may have more members > > than the set of sub-LSPs in the received Path message, and > > you only want to move the ones that were in the received Path message. > > > > Adrian was the one who initially pointed this and he proposed > > creating a different object/type for the set of sub-LSPs in > > the received Path message. I think this is reasonable solution. > > > > Thanks, > > > > John" > > > > As you can see from the last paragraph, we do need to create > > a new object/type. > > > >_______________________________________________ >mpls mailing list >mpls@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/mpls --Boundary_(ID_BpsNw5/pXe3+iuFLzBBELg) MIME-version: 1.0 Content-type: message/rfc822 Date: Fri, 23 Jun 2006 15:13:40 +0800 From: liushuying Subject: [mpls] Load-Balancing among a set of candidate upstream LSRs on a LAN-----draft-liu-mpls-upstream-load-balance-00.txt To: mpls@ietf.org Cc: Message-id: <003601c69694$8e147770$33726e0a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_kmZZuWrXMleoyg60euYIIA)" Precedence: list Message: 4 --Boundary_(ID_kmZZuWrXMleoyg60euYIIA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgZm9sa3MuDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhlIGRyYWZ0IGNhbiBiZSBm b3VuZCBoZXJlOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1s aXUtbXBscy11cHN0cmVhbS1sb2FkLWJhbGFuY2UtMDAudHh0DQoNClRpdGxlIDogTG9hZC1CYWxh bmNpbmcgYW1vbmcgYSBzZXQgb2YgY2FuZGlkYXRlIHVwc3RyZWFtIExTUnMgb24gYSBMQU4NCkF1 dGhvcihzKSA6IFNodXlpbmcgTGl1DQpGaWxlbmFtZSA6IGRyYWZ0LWxpdS1tcGxzLXVwc3RyZWFt LWxvYWQtYmFsYW5jZS0wMC50eHQNClBhZ2VzIDogNw0KRGF0ZSA6IDIwMDYtMDYtMTYNCg0KVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIExvYWQtQmFsYW5jaW5nIGFtb25n IGEgc2V0IG9mIA0KY2FuZGlkYXRlIHVwc3RyZWFtIExTUnMgb24gYSBMQU4gaW50ZXJmYWNlLiBX aGVuIHRoZXJlIGFyZSBzZXZlcmFsIA0KY2FuZGlkYXRlcyB0byBiZSBzZWxlY3RlZCBhcyBhbiB1 cHN0cmVhbSBMU1IsIGFjY29yZGluZyB0aGUgY3VycmVudCANCnVwc3RyZWFtIGxhYmVsIGFsbG9j YXRpb24gbWV0aG9kcywgdGhlIGxvYWQgb24gdGhlIGNhbmRpZGF0ZSB1cHN0cmVhbSANCkxTUiB3 aGljaCBpcyBzZWxlY3RlZCBieSB0aGUgcm91dGluZyBwcm90b2NvbCBtYXkgYmUgdmVyeSBoZWF2 eSwgDQp3aGlsZSB0aGUgbG9hZCBvbiBvdGhlciBjYW5kaWRhdGUgdXBzdHJlYW0gTFNScyBpcyBs aXR0bGUuIFRoZSBMb2FkLQ0KQmFsYW5jaW5nIGFsc28gcHJvdmlkZXMgc29tZSBwcm9jZWR1cmVz IHRvIG1pbmltaXplIHRoZSBwYWNrZXQgbG9zcyANCmluIGZvbGxvd2luZyBjYXNlczogMSkgYWRk aW5nL3JlbW92aW5nIGEgY2FuZGlkYXRlIHVwc3RyZWFtIExTUjsgMikgYSANCmJldHRlciBwYXRo IGVtZXJnaW5nLg0KDQpQbGVhc2UgZ2l2ZSB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgZG9jdW1lbnQh IFRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNCkJlc3QgcmVnYXJkcw0KU2h1eWluZyBMaXUNCkh1YVdl aSBCbGQuLCBOby4zIFhpbnhpIFJkLiwgICANClNoYW5nLURpIEluZm9ybWF0aW9uIEluZHVzdHJ5 IEJhc2UsICAgICAgICAgICAgIA0KSGFpLURpYW4gRGlzdHJpY3QgQmVpamluZyBQLlIuIENoaW5h DQpaSVCjujEwMDA4NSANCg0K --Boundary_(ID_kmZZuWrXMleoyg60euYIIA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI4NzMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPg0KPERJVj48Rk9OVCBzaXplPTI+SGkgZm9sa3Mu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSANCm9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoZSBk cmFmdCBjYW4gYmUgZm91bmQgaGVyZTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LW1wbHMtdXBzdHJlYW0tbG9hZC1iYWxhbmNlLTAwLnR4 dCI+PEZPTlQgDQpzaXplPTI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbGl1LW1wbHMtdXBzdHJlYW0tbG9hZC1iYWxhbmNlLTAwLnR4dDwvRk9OVD48L0E+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5UaXRsZSA6IExvYWQtQmFsYW5jaW5nIGFtb25nIGEgc2V0IG9mIGNhbmRpZGF0ZSB1cHN0cmVh bSBMU1JzIA0Kb24gYSBMQU48QlI+QXV0aG9yKHMpIDogU2h1eWluZyBMaXU8QlI+RmlsZW5hbWUg OiANCmRyYWZ0LWxpdS1tcGxzLXVwc3RyZWFtLWxvYWQtYmFsYW5jZS0wMC50eHQ8L0ZPTlQ+DQo8 RElWPjxGT05UIHNpemU9Mj5QYWdlcyA6IDc8QlI+RGF0ZSA6IDIwMDYtMDYtMTY8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5UaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBmb3IgTG9hZC1CYWxhbmNp bmcgYW1vbmcgYSANCnNldCBvZiZuYnNwOzxCUj5jYW5kaWRhdGUgdXBzdHJlYW0gTFNScyBvbiBh IExBTiBpbnRlcmZhY2UuIFdoZW4gdGhlcmUgYXJlIA0Kc2V2ZXJhbCZuYnNwOzxCUj5jYW5kaWRh dGVzIHRvIGJlIHNlbGVjdGVkIGFzIGFuIHVwc3RyZWFtIExTUiwgYWNjb3JkaW5nIHRoZSANCmN1 cnJlbnQmbmJzcDs8QlI+dXBzdHJlYW0gbGFiZWwgYWxsb2NhdGlvbiBtZXRob2RzLCB0aGUgbG9h ZCBvbiB0aGUgY2FuZGlkYXRlIA0KdXBzdHJlYW0mbmJzcDs8QlI+TFNSIHdoaWNoIGlzIHNlbGVj dGVkIGJ5IHRoZSByb3V0aW5nIHByb3RvY29sIG1heSBiZSB2ZXJ5IA0KaGVhdnksJm5ic3A7PEJS PndoaWxlIHRoZSBsb2FkIG9uIG90aGVyIGNhbmRpZGF0ZSB1cHN0cmVhbSBMU1JzIGlzIGxpdHRs ZS4gVGhlIA0KTG9hZC08QlI+QmFsYW5jaW5nIGFsc28gcHJvdmlkZXMgc29tZSBwcm9jZWR1cmVz IHRvIG1pbmltaXplIHRoZSBwYWNrZXQgDQpsb3NzJm5ic3A7PEJSPmluIGZvbGxvd2luZyBjYXNl czogMSkgYWRkaW5nL3JlbW92aW5nIGEgY2FuZGlkYXRlIHVwc3RyZWFtIExTUjsgDQoyKSBhJm5i c3A7PEJSPmJldHRlciBwYXRoIGVtZXJnaW5nLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlBsZWFzZSBnaXZlIHlv dXIgY29tbWVudHMmbmJzcDtvbiB0aGlzIGRvY3VtZW50ISBUaGFuayB5b3UgDQp2ZXJ5IG11Y2gu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+QmVzdCByZWdhcmRzPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZP TlQgZmFjZT3LzszlPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPlNodXlpbmcgTGl1PC9T UEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3LzszlPjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiPjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpmYWNlPcvOzOU+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdCI+SHVhV2VpIEJsZC4sIE5vLjMgWGlueGkgUmQuLCZuYnNwOyZuYnNw OyANCjxCUj5TaGFuZy1EaSBJbmZvcm1hdGlvbiBJbmR1c3RyeSANCkJhc2UsJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KPEJSPkhhaS1EaWFuIERpc3RyaWN0IEJlaWppbmcgUC5SLiBDaGluYTxCUj5aSVA8U1BB TiANCmxhbmc9WkgtQ04+o7o8L1NQQU4+MTAwMDg1Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0RJVj48 QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_kmZZuWrXMleoyg60euYIIA)-- --Boundary_(ID_BpsNw5/pXe3+iuFLzBBELg) MIME-version: 1.0 Content-type: message/rfc822 Date: Fri, 23 Jun 2006 09:20:57 +0200 From: LE ROUX Jean-Louis RD-CORE-LAN Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt To: Lou Berger Cc: mpls@ietf.org, "Drake, John E" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Precedence: list Message: 5 Hi Lou, When RRO is not used this procedure does not apply and remerge should be = fixed in the data plane on the remerge node.=20 IMO full RRO inclusion is the price to pay if you want to fix remerge in = a simple manner in the control plane. Regards, JL > -----Message d'origine----- > De : Lou Berger [mailto:lberger@labn.net]=20 > Envoy=E9 : vendredi 23 juin 2006 05:51 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : zzx-rahul@juniper.net; mpls@ietf.org; Drake, John E > Objet : RE: [mpls] TR: working group last call=20 > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > JL, >=20 > So what happens when no RRO is used (which isn't currently=20 > required) or portions of the RRO are removed? >=20 > Lou >=20 > At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 > >Hi Rahul, all > > > >Actually, after thinking a bit more, it seems to me that a simpler=20 > >remerge procedure based on RRO analysis could be useful. > >If the RRO is carried in Path messages, the node where the remerge=20 > >occurs could easily identify the node that created the=20 > remerge, simply=20 > >by analyzing the two RROs. > >When a node detect a remerge it sends a PAthErr with a new object=20 > >(Remerge-Spec object) that identifies the remerge origin.=20 > This PathErr=20 > >carries the set of sub-LSPs received in the Path message that caused=20 > >the remerge. > >On receipt of such PAthErr, a node that see its own address in the=20 > >Remerge-spec object moves the set of sub-LSPs... > > > >It seems that this procedure would require simpler processing... > >It requires the use of RRO, but this is the price to pay. > > > >Would that make sense? > > > >Best Regards, > > > >JL > > > > > > > -----Message d'origine----- > > > De : Drake, John E [mailto:John.E.Drake2@boeing.com]=20 > Envoy=E9 : mardi=20 > > > 20 juin 2006 23:59 =C0 : zzx-rahul@juniper.net; LE ROUX Jean-Louis = > > > RD-CORE-LAN Cc : mpls@ietf.org Objet : RE: [mpls] TR:=20 > working group=20 > > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > Rahul, > > > > > > Snipped, comments inline. > > > > > > Thanks, > > > > > > John > > > > > > 4: Section 18.1.1 Remerge Procedure > > > > > > > > > > > > The text says > > > > > > "The PathErr message MUST include all of the objects > > > > > > normally included in a PathErr message, as well as > > > one or more > > > SUB- > > > > > > LSP objects from the set of sub-LSPs associated with the > > > matching > > > > > > P2MP LSP Path state. A minimum of three SUB-LSP=20 > objects is > > > > > > RECOMMENDED. This will allow the node that caused > > > the re-merge > > > to > > > > > > identify the outgoing Path state associated with=20 > the valid=20 > > > > > > portion of > > > > > > the P2MP LSP. The set of SUB-LSP objects in the > > > received Path > > > > > > message > > > > > > MUST also be included" > > > > > > > > > > > > And then: > > > > > > > > > > > > "A node that receives a PathErr message that > > > contains the Error > > > > > > Value > > > > > > "Routing Problem/P2MP Remerge Detected" MUST > > > determine if it is > > > the > > > > > > node that created the re-merge case. This is done > > > by checking > > > > > > whether there is any intersection between the set of=20 > > > > > > SUB-LSP objects > > > > > > associated with the matching P2MP LSP Path state and > > > the set of > > > > > > SUB- > > > > > > LSP objects in the received PathErr message. If > > > there is, then > > > the > > > > > > node created the re-merge case." > > > > > > > > > > > > There is an issue here. Actually there will always be an=20 > > > > > > intersection, because the PathErr includes the set=20 > of sub-lsp=20 > > > > > > objects in the received Path... IMO for this procedure > > > to work the > > > > > > PathErr MUST only include sub-LSP objects=20 > associated with the=20 > > > > > > matching P2MP LSP state on the rermerge LSR and must > > > not include > > > > > > the set of SUB-LSP objects in the received Path message. > > > > > > By the way why are three objects recommended? > > > > > > > > > > > > > > I believe this was clarified by John Drake offline and no=20 > > > > revisions > > > were > > > > needed ? > > > Rahul, > > > > > > Here's the e-mail I sent to JL: > > > > > > "JL, > > > > > > The text was originally stated as you stated. The issue=20 > is that the=20 > > > set of sub-LSPs associated with the interface on the node that=20 > > > caused the re-merge condition may have more members than=20 > the set of=20 > > > sub-LSPs in the received Path message, and you only want=20 > to move the=20 > > > ones that were in the received Path message. > > > > > > Adrian was the one who initially pointed this and he proposed=20 > > > creating a different object/type for the set of sub-LSPs in the=20 > > > received Path message. I think this is reasonable solution. > > > > > > Thanks, > > > > > > John" > > > > > > As you can see from the last paragraph, we do need to=20 > create a new=20 > > > object/type. > > > > > > >_______________________________________________ > >mpls mailing list > >mpls@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/mpls >=20 >=20 --Boundary_(ID_BpsNw5/pXe3+iuFLzBBELg)-- --Boundary_(ID_MsCVk8wM8hfEWd+/58OouQ) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-description: Digest Footer _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --Boundary_(ID_MsCVk8wM8hfEWd+/58OouQ) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --Boundary_(ID_MsCVk8wM8hfEWd+/58OouQ)-- From mpls-bounces@lists.ietf.org Sat Jun 24 06:56:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu5mn-0002jS-O6; Sat, 24 Jun 2006 06:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu5mm-0002gH-3R for mpls@lists.ietf.org; Sat, 24 Jun 2006 06:54:44 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu5mk-00011I-M5 for mpls@lists.ietf.org; Sat, 24 Jun 2006 06:54:44 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jun 2006 12:54:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mpls] Contents of mpls digest...Vol 26 Date: Sat, 24 Jun 2006 12:54:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Contents of mpls digest...Vol 26 Thread-Index: AcaXfD7mOOn6jBUgQ3qSzLvTMdWxCQAACMbQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 24 Jun 2006 10:54:32.0636 (UTC) FILETIME=[931A6FC0:01C6977C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034887130==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1034887130== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6977C.92EB5779" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6977C.92EB5779 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sanjay, =20 Here it is: = http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01.txt =20 Regards, =20 JL ________________________________ De : sanjay.chalikar@vsnl.net [mailto:sanjay.chalikar@vsnl.net]=20 Envoy=E9 : samedi 24 juin 2006 12:52 =C0 : mpls@lists.ietf.org Objet : [mpls] Contents of mpls digest...Vol 26 =09 =09 =09 I am not abe to find the file stated "Filename : = draft-ietf-mpls-mp-ldp-reqs-01.txt" can i be guided ? with kind regards, Sanjay Chalikar (m) 9223468245. =09 with kind regards,=20 Sanjay Chalikar=20 (m) 9223 468245. =09 =09 ------_=_NextPart_001_01C6977C.92EB5779 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Sanjay,
 
Here it is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-01= .txt
 
Regards,
 
JL

De : sanjay.chalikar@vsnl.net = [mailto:sanjay.chalikar@vsnl.net]
Envoy=E9 : samedi 24 = juin 2006=20 12:52
=C0 : mpls@lists.ietf.org
Objet : = [mpls]=20 Contents of mpls digest...Vol 26

I am not abe to find the file stated "Filename :=20 draft-ietf-mpls-mp-ldp-reqs-01.txt" can i be guided ?

with kind regards,

Sanjay Chalikar (m) 9223468245.




with kind = regards,=20
Sanjay Chalikar
(m) 9223 = 468245.

------_=_NextPart_001_01C6977C.92EB5779-- --===============1034887130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1034887130==-- From mpls-bounces@lists.ietf.org Mon Jun 26 09:51:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurTF-0005Rr-RD; Mon, 26 Jun 2006 09:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurTE-0005Rm-PF for mpls@ietf.org; Mon, 26 Jun 2006 09:49:44 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurTD-00013i-EH for mpls@ietf.org; Mon, 26 Jun 2006 09:49:44 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5QDngX89928; Mon, 26 Jun 2006 06:49:42 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5QDnY577849; Mon, 26 Jun 2006 06:49:34 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606261349.k5QDnY577849@merlot.juniper.net> To: Dimitri.Papadimitriou@alcatel.be Subject: Re: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] In-Reply-To: Your message of "Fri, 23 Jun 2006 13:43:47 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <65367.1151329774.1@juniper.net> Date: Mon, 26 Jun 2006 06:49:34 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mpls@ietf.org, fenner@research.att.com, ccamp , rcallon@juniper.net X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Dimitri, [clipped...] > > now there is a more fundamental issue: what is the purpose of the initial > > comment, i think it is first to clarify processing of Tunnel ID and > > Extended Tunnel ID but i don't think i have seen any specific issue in > > keeping usage of the Tunnel ID & Extended Tunnel ID per RFC 3209/3473 The purpose of the initial comment is to clarify the definition of P2MP ID. The current spec said the following (Section 19.1.1): P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP ID and identifies the set of destinations of the P2MP Tunnel. What is the uniqueness scope of this 32 bit identifier ? Is it the root node scope, or a global scope ? At the minimum the spec should spell out support for the root node uniqueness scope. If some folks want the spec to support global scope, then it has to be an option (in which case the root node scope will be another option), *and* the spec has to spell out the procedures for assigining such globally unique P2MP IDs (in the absence of such procedures the spec should just have the root node uniqueness scope). Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Jun 26 21:55:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2lu-00014Q-9m; Mon, 26 Jun 2006 21:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2lt-00014J-39 for mpls@ietf.org; Mon, 26 Jun 2006 21:53:45 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv2lr-0002zB-PT for mpls@ietf.org; Mon, 26 Jun 2006 21:53:45 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5R1rJX07078; Mon, 26 Jun 2006 18:53:19 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5R1rE538453; Mon, 26 Jun 2006 18:53:14 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606270153.k5R1rE538453@merlot.juniper.net> To: "Zafar Ali \(zali\)" In-Reply-To: Your message of "Wed, 31 May 2006 10:44:33 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42107.1151373194.1@juniper.net> Date: Mon, 26 Jun 2006 18:53:14 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Zafar, [clipped...] > Yakov, Adrian, et al > > I think global scoping will be a bad idea. Furthermore, we cannot force > it to come from multicast IP address space. So Ingress node scoping is > quite obvious and IMHO suffices. Agreed. What I am asking is to explicitly spell this out in the document (see the e-mail I sent today). Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Jun 26 23:40:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv4Pg-0002Mw-1R; Mon, 26 Jun 2006 23:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv4Pd-0002GV-5j; Mon, 26 Jun 2006 23:38:53 -0400 Received: from ns.ft.solteria.net ([210.142.173.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv4Pb-00033E-OE; Mon, 26 Jun 2006 23:38:53 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ns.ft.solteria.net (Postfix) with ESMTP id 372CB38712; Tue, 27 Jun 2006 12:38:50 +0900 (JST) Message-ID: <44A0A7EE.8060602@ft.solteria.net> Date: Tue, 27 Jun 2006 12:37:18 +0900 From: "S.Matsushima" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Zheng Hewen Subject: Re: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically References: <000001c68c73$32b72970$3e05a40a@china.huawei.com> In-Reply-To: <000001c68c73$32b72970$3e05a40a@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ccamp@ops.ietf.org, mpls@ietf.org, l3vpn@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, Agreed. I think that it is good point. Dynamic discover and membership distribution of p2mp LSP will be needed to operate p2mp LSP in real networks. Also, I would say that policy-based mechanism to establish p2mp LSP in per LSP basis is needed. In BGP P2MP solution, you can see some ideas to achieve above requirements. Your interest and comment are welcome. http://www3.ietf.org/proceedings/05nov/slides/mpls-3/sld1.htm -03 version of this draft will appear soon. -- Satoru Matsushima Zheng Hewen wrote: > Hi, > > The signaling solution for the construction of P2MP MPLS-TE LSPs defined in draft-ietf-mpls-rsvp-te-p2mp-05.txt assumes that > the ingress node for any P2MP LSP knows the identities of all of the receivers. No mechanism in that document is provided by > which it can discover the identities of those receivers. > > In multicast LDP (mLDP) defined in draft-ietf-mpls-ldp-p2mp-00.txt it is assumed that each receiver knows the identity of > the source of the distribution tree, but no mechanism is provided whereby the receivers can discover that information. > > In order to successfully operate P2MP MPLS, and to consider extending MPLS to support MP2MP it is necessary to examine > the requirements for exchanging and learning the identities of P2MP roots and leaves. One mechanism is desired to discover > and distribute multicast membership information dynamically. > > Currently some work is in progress. For L3VPN applications, it is one choice to carry and distribute multicast membership > information through auto-discovery mechanism based on extended BGP defined in the > draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.txt. For P2MP MPLS-TE applications, one effort is to extend IGP-TE for such > purpose using one analogous mechanism defined in draft-ietf-ccamp-te-node-cap-01.txt. For connection-oriented transport > network basing on MPLS, one mechanism defined in RFC2022 may be referred. Extension to MSDP is another choice to satisfy > those requirements directly if possible. > > It is desired to clear the requirements for that mechanism. Is there any interest for this? I want to do something about it > and hope to receive advices. > > > Best Regards, > Heaven > > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon Jun 26 23:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv4em-0007nm-B0; Mon, 26 Jun 2006 23:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv4el-0007nU-7s; Mon, 26 Jun 2006 23:54:31 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv4eh-0004cF-N2; Mon, 26 Jun 2006 23:54:31 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1I00ATI392QJ@szxga03-in.huawei.com>; Tue, 27 Jun 2006 12:03:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1I003Y43910F@szxga03-in.huawei.com>; Tue, 27 Jun 2006 12:03:02 +0800 (CST) Received: from z52048 ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1I003FM2WB09@szxml03-in.huawei.com>; Tue, 27 Jun 2006 11:55:27 +0800 (CST) Date: Tue, 27 Jun 2006 11:53:36 +0800 From: Zheng Hewen Subject: RE: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically In-reply-to: <44A0A7EE.8060602@ft.solteria.net> To: "'S.Matsushima'" Message-id: <000001c6999d$44c82380$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcaZmzex2RuLvlXPQ6uWho+5IaCvhQAARVng X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ccamp@ops.ietf.org, mpls@ietf.org, l3vpn@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, I wrote one draft about those requirements, your comments are appreciated. http://tools.ietf.org/wg/mpls/draft-zheng-mpls-p2mp-topology-agent-reqs-00.txt To Extend BGP to achieve those requirements is one good choice, especially for policy-based mechanism. There is also another choice to extend IGP to achieve those requirements from J.L. Le Roux. http://tools.ietf.org/wg/mpls/draft-leroux-mpls-p2mp-te-autoleaf-00.txt -----Original Message----- From: S.Matsushima [mailto:satoru@ft.solteria.net] Sent: 2006年6月27日 11:37 To: Zheng Hewen Cc: mpls@ietf.org; ccamp@ops.ietf.org; l3vpn@ietf.org Subject: Re: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically Hi, Agreed. I think that it is good point. Dynamic discover and membership distribution of p2mp LSP will be needed to operate p2mp LSP in real networks. Also, I would say that policy-based mechanism to establish p2mp LSP in per LSP basis is needed. In BGP P2MP solution, you can see some ideas to achieve above requirements. Your interest and comment are welcome. http://www3.ietf.org/proceedings/05nov/slides/mpls-3/sld1.htm -03 version of this draft will appear soon. -- Satoru Matsushima Zheng Hewen wrote: > Hi, > > The signaling solution for the construction of P2MP MPLS-TE LSPs > defined in draft-ietf-mpls-rsvp-te-p2mp-05.txt assumes that the > ingress node for any P2MP LSP knows the identities of all of the receivers. No mechanism in that document is provided by which it can discover the identities of those receivers. > > In multicast LDP (mLDP) defined in draft-ietf-mpls-ldp-p2mp-00.txt it > is assumed that each receiver knows the identity of the source of the distribution tree, but no mechanism is provided whereby the receivers can discover that information. > > In order to successfully operate P2MP MPLS, and to consider extending > MPLS to support MP2MP it is necessary to examine the requirements for > exchanging and learning the identities of P2MP roots and leaves. One mechanism is desired to discover and distribute multicast membership information dynamically. > > Currently some work is in progress. For L3VPN applications, it is one > choice to carry and distribute multicast membership information > through auto-discovery mechanism based on extended BGP defined in the > draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.txt. For P2MP MPLS-TE > applications, one effort is to extend IGP-TE for such purpose using > one analogous mechanism defined in draft-ietf-ccamp-te-node-cap-01.txt. For connection-oriented transport network basing on MPLS, one mechanism defined in RFC2022 may be referred. Extension to MSDP is another choice to satisfy those requirements directly if possible. > > It is desired to clear the requirements for that mechanism. Is there > any interest for this? I want to do something about it and hope to receive advices. > > > Best Regards, > Heaven > > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 10:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEmj-0000Jg-AY; Tue, 27 Jun 2006 10:43:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEmi-0000Jb-BM for mpls@ietf.org; Tue, 27 Jun 2006 10:43:24 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvEmh-0002r7-12 for mpls@ietf.org; Tue, 27 Jun 2006 10:43:24 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k5REhM1Z099174; Tue, 27 Jun 2006 07:43:22 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5REhL583773; Tue, 27 Jun 2006 07:43:21 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606271443.k5REhL583773@merlot.juniper.net> To: Lou Berger In-Reply-To: Your message of "Tue, 27 Jun 2006 09:01:22 EDT." <7.0.1.0.2.20060627085502.03654c10@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70529.1151419401.1@juniper.net> Date: Tue, 27 Jun 2006 07:43:21 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: p2mp@labn.net, ccamp@ops.ietf.org, mpls@ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Lou, [since the answer to the question you posed below may benefit other folks, I added mpls and ccamp mailing list to the cc:] > Rahul, > Okay, so I'm just a bit slow. Can you explain why the > semantics of P2MP-TE needs to be different than P2P-TE? > > Yakov, > > Perhaps you should answer this? > > Lou To answer your question observe that in P2P-TE the Session object carries IPv4 tunnel end point address, while in P2MP-TE the Session object carried P2MP-ID. Here are some of the reason(s) semantics of IPv4 tunnel end point address needs to be different than P2MP-ID: 1. IPv4 tunnel end point address is a unicast address. P2MP-ID is not. 2. IPv4 tunnel end point address is suitable for hierarchical routing (e.g., CIDR). P2MP-ID is not. 3. There are well-established procedures for assigining (globally) unique unicast IP addresses. There are no such procedures for assigining (globally) unique P2MP IDs. Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 11:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvF63-0005bm-3l; Tue, 27 Jun 2006 11:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvF61-0005bh-QN for mpls@ietf.org; Tue, 27 Jun 2006 11:03:21 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvF60-000438-Ho for mpls@ietf.org; Tue, 27 Jun 2006 11:03:21 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FvF5i-0000YU-0R; Tue, 27 Jun 2006 11:03:02 -0400 Message-Id: <7.0.1.0.2.20060627104617.03ca8008@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 27 Jun 2006 11:03:03 -0400 To: Yakov Rekhter From: Lou Berger In-Reply-To: <200606271443.k5REhL583773@merlot.juniper.net> References: <200606271443.k5REhL583773@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mpls@ietf.org, ccamp@ops.ietf.org, p2mp@labn.net Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yakov, Thank you for the concise response to a question that has been outstanding for some time. Now there are two specific aspects to the proposed response (Rahul's) to the issues you raise below: 1) Tunnel ID [From rahul's mail] > 4. > 19.1.1 > > "Tunnel ID > > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel." > > to > > "Tunnel ID > > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It SHOULD be set to 0 > by the ingress LSR and be ignored on receipt." > I don't see how this change, setting the ID to zero, relates to the issue you raise. Can justify why this change is required? 2) Extended Tunnel ID [again from rahul's mail] > 5. > > "Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Normally set to > all zeros. Ingress nodes that wish to narrow the scope of a > SESSION to the ingress-PID pair may place their IPv4 address > here as a globally unique identifier [RFC3209]." > > to > > "Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. This identifier > MUST be set to the ingress LSR's IPv4 address." > So the original text, allowed for global uniqueness and included a "well-established procedures for assigning (globally) unique" P2MP IDs. It seems to me that the -05 text covered the issue you raised. So now we come to the heart of the matter: Why is a change in the -05 definition of the IDs needed? It seems to me that at most the text needs to replace a "may" with a "MUST", as in "Ingress nodes that wish to narrow the scope of a SESSION to the ingress-PID pair MUST place their..." Lou At 10:43 AM 6/27/2006, Yakov Rekhter wrote: >Lou, > >[since the answer to the question you posed below may benefit >other folks, I added mpls and ccamp mailing list to the cc:] a bit unusual to redirect private mail, but whatever... > > Rahul, > > Okay, so I'm just a bit slow. Can you explain why the > > semantics of P2MP-TE needs to be different than P2P-TE? > > > > Yakov, > > > > Perhaps you should answer this? > > > > Lou > >To answer your question observe that in P2P-TE the Session object >carries IPv4 tunnel end point address, while in P2MP-TE the Session >object carried P2MP-ID. > >Here are some of the reason(s) semantics of IPv4 tunnel end point >address needs to be different than P2MP-ID: > >1. IPv4 tunnel end point address is a unicast address. P2MP-ID >is not. > >2. IPv4 tunnel end point address is suitable for hierarchical routing >(e.g., CIDR). P2MP-ID is not. > >3. There are well-established procedures for assigining (globally) >unique unicast IP addresses. There are no such procedures for >assigining (globally) unique P2MP IDs. > >Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 12:30:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGQK-0002WI-Dx; Tue, 27 Jun 2006 12:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGQI-0002WA-9w for mpls@ietf.org; Tue, 27 Jun 2006 12:28:22 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGQF-0005R7-Ss for mpls@ietf.org; Tue, 27 Jun 2006 12:28:22 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k5RGSJ1Z001759; Tue, 27 Jun 2006 09:28:19 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5RGSJ505803; Tue, 27 Jun 2006 09:28:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606271628.k5RGSJ505803@merlot.juniper.net> To: Lou Berger In-Reply-To: Your message of "Tue, 27 Jun 2006 11:03:03 EDT." <7.0.1.0.2.20060627104617.03ca8008@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81482.1151425699.1@juniper.net> Date: Tue, 27 Jun 2006 09:28:19 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: p2mp@labn.net, ccamp@ops.ietf.org, mpls@ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Lou, > Yakov, > Thank you for the concise response to a question that has > been outstanding for some time. Now there are two specific aspects > to the proposed response (Rahul's) to the issues you raise below: > > 1) Tunnel ID > [From rahul's mail] > > 4. > > 19.1.1 > > > > "Tunnel ID > > > > A 16-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel." > > > > to > > > > "Tunnel ID > > > > A 16-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel. It SHOULD be set to 0 > > by the ingress LSR and be ignored on receipt." > > > > I don't see how this change, setting the ID to zero, relates to the > issue you raise. Can justify why this change is required? This is orthogonal to the issue of P2MP ID uniqueness scope. > 2) Extended Tunnel ID > [again from rahul's mail] > > > 5. > > > > "Extended Tunnel ID > > > > A 32-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel. Normally set to > > all zeros. Ingress nodes that wish to narrow the scope of a > > SESSION to the ingress-PID pair may place their IPv4 address > > here as a globally unique identifier [RFC3209]." > > > > to > > > > "Extended Tunnel ID > > > > A 32-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel. This identifier > > MUST be set to the ingress LSR's IPv4 address." > > So the original text, allowed for global uniqueness and included a > "well-established procedures for assigning (globally) unique" P2MP IDs. Could you please point me to the text that spells out procedures for assigning P2MP IDs that are globally unique *on their own* (not in a combination with the Extended Tunnel ID). > It seems to me that the -05 text covered the issue you raised. So > now we come to the heart of the matter: Why is a change in the -05 > definition of the IDs needed? > > It seems to me that at most the text needs to replace a "may" with a > "MUST", as in "Ingress nodes that wish to narrow the scope of a > SESSION to the ingress-PID pair MUST place their..." That is necessary, but not sufficient. Here are the changes that need to be made: 1. Section 4.1: A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session which includes the P2MP ID, a tunnel ID and an extended tunnel ID. The fields of a P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP Identifier (P2MP ID) field. The P2MP ID provides an identifier for the set of destinations of the P2MP TE Tunnel. The last sentence above has to be deleted. 2. Section 19.1.1 replace: P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP ID and identifies the set of destinations of the P2MP Tunnel." with the following: P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP Identifier that is unique within the scope of the Ingress LSR whose IP address is carried in the Extended Tunnel ID. 3. Section 19.1.1 replace Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-PID pair may place their IPv4 address here as a globally unique identifier [RFC3209]." with the following: Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. Ingress nodes that use the locally scoped P2MP ID MUST place their IPv4 address here; a combination of this address and P2MP ID provides a globally unique identifier for the P2MP tunnel. 4. Make similar changes in 19.1.2 Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 14:23:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvICE-0007r8-Nb; Tue, 27 Jun 2006 14:21:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvICD-0007r0-Sw for mpls@ietf.org; Tue, 27 Jun 2006 14:21:57 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvICD-0008Hl-IT for mpls@ietf.org; Tue, 27 Jun 2006 14:21:57 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FvIBt-0006sS-Jw; Tue, 27 Jun 2006 14:21:37 -0400 Message-Id: <7.0.1.0.2.20060627141025.0365ece0@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 27 Jun 2006 14:21:40 -0400 To: Yakov Rekhter From: Lou Berger In-Reply-To: <200606271628.k5RGSJ505803@merlot.juniper.net> References: <200606271628.k5RGSJ505803@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: mpls@ietf.org, ccamp@ops.ietf.org, p2mp@labn.net Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yakov, See below. At 12:28 PM 6/27/2006, Yakov Rekhter wrote: >Lou, > > > Yakov, > > Thank you for the concise response to a question that has > > been outstanding for some time. Now there are two specific aspects > > to the proposed response (Rahul's) to the issues you raise below: > > > > 1) Tunnel ID > > [From rahul's mail] > > > 4. > > > 19.1.1 > > > > > > "Tunnel ID > > > > > > A 16-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel." > > > > > > to > > > > > > "Tunnel ID > > > > > > A 16-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel. It SHOULD be set to 0 > > > by the ingress LSR and be ignored on receipt." > > > > > > > I don't see how this change, setting the ID to zero, relates to the > > issue you raise. Can justify why this change is required? > >This is orthogonal to the issue of P2MP ID uniqueness scope. okay, that's not how it's been presented. What *is* the reason for this change? > > > 2) Extended Tunnel ID > > [again from rahul's mail] > > > > > 5. > > > > > > "Extended Tunnel ID > > > > > > A 32-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel. Normally set to > > > all zeros. Ingress nodes that wish to narrow the scope of a > > > SESSION to the ingress-PID pair may place their IPv4 address > > > here as a globally unique identifier [RFC3209]." > > > > > > to > > > > > > "Extended Tunnel ID > > > > > > A 32-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel. This identifier > > > MUST be set to the ingress LSR's IPv4 address." > > > > So the original text, allowed for global uniqueness and included a > > "well-established procedures for assigning (globally) unique" P2MP IDs. > >Could you please point me to the text that spells out procedures >for assigning P2MP IDs that are globally unique *on their own* (not >in a combination with the Extended Tunnel ID). Ahh, good point, I was referring to the uniqueness of the tuple . I must admit, I made the assumption that this is what you cared about for uniqueness. Is this not the case? If not, why is uniqueness of the tuple insufficient? > > It seems to me that the -05 text covered the issue you raised. So > > now we come to the heart of the matter: Why is a change in the -05 > > definition of the IDs needed? > > > > It seems to me that at most the text needs to replace a "may" with a > > "MUST", as in "Ingress nodes that wish to narrow the scope of a > > SESSION to the ingress-PID pair MUST place their..." > >That is necessary, but not sufficient. Here are the changes that >need to be made: > >1. Section 4.1: > > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes the P2MP ID, a tunnel > ID and an extended tunnel ID. > > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP Identifier (P2MP ID) field. > > The P2MP ID provides an identifier for the set of destinations of the > P2MP TE Tunnel. > >The last sentence above has to be deleted. why, what's incorrect about it? >2. Section 19.1.1 replace: > > P2MP ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP ID and identifies the set of destinations of the P2MP > Tunnel." > >with the following: > > P2MP ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP Identifier that is unique within the scope of the Ingress LSR > whose IP address is carried in the Extended Tunnel ID. Why not, just "Identifier that is unique within the scope of the Ingress LSR."? >3. Section 19.1.1 replace > > Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Normally set to > all zeros. Ingress nodes that wish to narrow the scope of a > SESSION to the ingress-PID pair may place their IPv4 address > here as a globally unique identifier [RFC3209]." > >with the following: > > Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Ingress nodes > that use the locally scoped P2MP ID MUST place their IPv4 > address here; a combination of this address and P2MP ID > provides a globally unique identifier for the P2MP tunnel. How about: >A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Ingress nodes > that wish to a globally unique identifier for the P2MP tunnel >MUST place their tunnel sender address here. > >4. Make similar changes in 19.1.2 yes. Lou >Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 15:28:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJCL-0005OB-13; Tue, 27 Jun 2006 15:26:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJCJ-0005O5-G0 for mpls@ietf.org; Tue, 27 Jun 2006 15:26:07 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJCJ-0006R5-1U for mpls@ietf.org; Tue, 27 Jun 2006 15:26:07 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k5RJQ61Z004130; Tue, 27 Jun 2006 12:26:06 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5RJQ2548914; Tue, 27 Jun 2006 12:26:02 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606271926.k5RJQ2548914@merlot.juniper.net> To: Lou Berger In-Reply-To: Your message of "Tue, 27 Jun 2006 14:21:40 EDT." <7.0.1.0.2.20060627141025.0365ece0@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97467.1151436362.1@juniper.net> Date: Tue, 27 Jun 2006 12:26:02 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: p2mp@labn.net, ccamp@ops.ietf.org, mpls@ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Lou, > > > 2) Extended Tunnel ID > > > [again from rahul's mail] > > > > > > > 5. > > > > > > > > "Extended Tunnel ID > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > constant over the life of the P2MP tunnel. Normally set to > > > > all zeros. Ingress nodes that wish to narrow the scope of a > > > > SESSION to the ingress-PID pair may place their IPv4 address > > > > here as a globally unique identifier [RFC3209]." > > > > > > > > to > > > > > > > > "Extended Tunnel ID > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > constant over the life of the P2MP tunnel. This identifier > > > > MUST be set to the ingress LSR's IPv4 address." > > > > > > So the original text, allowed for global uniqueness and included a > > > "well-established procedures for assigning (globally) unique" P2MP IDs. > > > >Could you please point me to the text that spells out procedures > >for assigning P2MP IDs that are globally unique *on their own* (not > >in a combination with the Extended Tunnel ID). > > Ahh, good point, I was referring to the uniqueness of the tuple ID, Tunnel ID, Extended Tunnel ID>. I must admit, I made the > assumption that this is what you cared about for uniqueness. That is precisely what I care about. > Is this > not the case? If not, why is uniqueness of the tuple insufficient? Uniqueness of the tuple is sufficient. > > > It seems to me that the -05 text covered the issue you raised. So > > > now we come to the heart of the matter: Why is a change in the -05 > > > definition of the IDs needed? > > > > > > It seems to me that at most the text needs to replace a "may" with a > > > "MUST", as in "Ingress nodes that wish to narrow the scope of a > > > SESSION to the ingress-PID pair MUST place their..." > > > >That is necessary, but not sufficient. Here are the changes that > >need to be made: > > > >1. Section 4.1: > > > > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > > identified by a P2MP SESSION object. This object contains the > > identifier of the P2MP Session which includes the P2MP ID, a tunnel > > ID and an extended tunnel ID. > > > > The fields of a P2MP SESSION object are identical to those of the > > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > > Address field is replaced by the P2MP Identifier (P2MP ID) field. > > > > The P2MP ID provides an identifier for the set of destinations of the > > P2MP TE Tunnel. > > > >The last sentence above has to be deleted. > > why, what's incorrect about it? To begin with, the last sentence states that the P2MP ID, *by itself* "provides an identifier for the set of destinations of a given P2MP TE Tunnel". However, since a given P2MP ID, *by itself*, may not be unique, how could it unambiguously identify the set of destinations of such tunnel ? > >2. Section 19.1.1 replace: > > > > P2MP ID > > > > A 32-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel. It encodes the > > P2MP ID and identifies the set of destinations of the P2MP > > Tunnel." > > > >with the following: > > > > P2MP ID > > > > A 32-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel. It encodes the > > P2MP Identifier that is unique within the scope of the Ingress LSR > > whose IP address is carried in the Extended Tunnel ID. > > Why not, just "Identifier that is unique within the scope of the > Ingress LSR."? That would be fine with me. > >3. Section 19.1.1 replace > > > > Extended Tunnel ID > > > > A 32-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel. Normally set to > > all zeros. Ingress nodes that wish to narrow the scope of a > > SESSION to the ingress-PID pair may place their IPv4 address > > here as a globally unique identifier [RFC3209]." > > > >with the following: > > > > Extended Tunnel ID > > > > A 32-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel. Ingress nodes > > that use the locally scoped P2MP ID MUST place their IPv4 > > address here; a combination of this address and P2MP ID > > provides a globally unique identifier for the P2MP tunnel. > > How about: > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Ingress nodes > that wish to a globally unique identifier for the P2MP tunnel > MUST place their tunnel sender address here. The above will be ok if we'll add the following to spell out what constitutes this (globally unique) identifier. A combination of this address and P2MP ID provides a globally unique identifier for the P2MP tunnel. Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 15:52:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJZq-0006oF-8h; Tue, 27 Jun 2006 15:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJZU-0005sM-JX; Tue, 27 Jun 2006 15:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJZS-0001O1-5E; Tue, 27 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo19F012449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZR-0005FR-LS; Tue, 27 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-number-0-bw-te-lsps-02.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --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 : A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switch Paths signalled across a link Author(s) : J. Vasseur, et al. Filename : draft-ietf-mpls-number-0-bw-te-lsps-02.txt Pages : 8 Date : 2006-6-27 Several Link-type sub-TLVs have been defined for OSPF and ISIS in the context of MPLS Traffic Engineering in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group and so on. There are various circumstances (for example in order to load balance unconstrained TE Label Switched Path (LSP) across a set of equal cost paths) where it would be useful to also advertise the number of unconstrained Traffic Engineering Label Switched Path(s) (TE LSP) signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSP(s) signalled across a link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-number-0-bw-te-lsps-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27105501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-number-0-bw-te-lsps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27105501.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Tue Jun 27 16:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKJ4-0006a2-Oe; Tue, 27 Jun 2006 16:37:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKJ3-0006YO-ET for mpls@ietf.org; Tue, 27 Jun 2006 16:37:09 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKJ2-0007KP-12 for mpls@ietf.org; Tue, 27 Jun 2006 16:37:09 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5RKb7X28705; Tue, 27 Jun 2006 13:37:07 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5RKb1563798; Tue, 27 Jun 2006 13:37:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606272037.k5RKb1563798@merlot.juniper.net> To: Lou Berger In-Reply-To: Your message of "Tue, 27 Jun 2006 16:08:21 EDT." <7.0.1.0.2.20060627154305.058b7928@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2921.1151440621.1@juniper.net> Date: Tue, 27 Jun 2006 13:37:01 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Lou, [clipped...] > > > > > It seems to me that the -05 text covered the issue you raised. So > > > > > now we come to the heart of the matter: Why is a change in the -05 > > > > > definition of the IDs needed? > > > > > > > > > > It seems to me that at most the text needs to replace a "may" with a > > > > > "MUST", as in "Ingress nodes that wish to narrow the scope of a > > > > > SESSION to the ingress-PID pair MUST place their..." > > > > > > > >That is necessary, but not sufficient. Here are the changes that > > > >need to be made: > > > > > > > >1. Section 4.1: > > > > > > > > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > > > > identified by a P2MP SESSION object. This object contains the > > > > identifier of the P2MP Session which includes the P2MP ID, a tunnel > > > > ID and an extended tunnel ID. > > > > > > > > The fields of a P2MP SESSION object are identical to those of the > > > > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > > > > Address field is replaced by the P2MP Identifier (P2MP ID) field. > > > > > > > > The P2MP ID provides an identifier for the set of destinations of the > > > > P2MP TE Tunnel. > > > > > > > >The last sentence above has to be deleted. > > > > > > why, what's incorrect about it? > > > >To begin with, the last sentence states that the P2MP ID, *by itself* > >"provides an identifier for the set of destinations of a given P2MP > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not > >be unique, how could it unambiguously identify the set of destinations > >of such tunnel ? > > You are 100% correct, how about fixing it by saying: > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an > identifier for the set of destinations of the P2MP TE Tunnel." Given that P2MP ID is unique within the scope of the root, why a tuple is not sufficient to identify the set of destinations of a P2MP tunnel ? After all, you agreed further down that such a tuple identifies a P2MP tunnel. > > > >2. Section 19.1.1 replace: > > > > > > > > P2MP ID > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > constant over the life of the P2MP tunnel. It encodes the > > > > P2MP ID and identifies the set of destinations of the P2MP > > > > Tunnel." > > > > > > > >with the following: > > > > > > > > P2MP ID > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > constant over the life of the P2MP tunnel. It encodes the > > > > P2MP Identifier that is unique within the scope of the Ingress > > > > LSR whose IP address is carried in the Extended Tunnel ID. > > > > > > Why not, just "Identifier that is unique within the scope of the > > > Ingress LSR."? > > > >That would be fine with me. > > great. > > > > > > >3. Section 19.1.1 replace > > > > > > > > Extended Tunnel ID > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > constant over the life of the P2MP tunnel. Normally set to > > > > all zeros. Ingress nodes that wish to narrow the scope of a > > > > SESSION to the ingress-PID pair may place their IPv4 address > > > > here as a globally unique identifier [RFC3209]." > > > > > > > >with the following: > > > > > > > > Extended Tunnel ID > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > constant over the life of the P2MP tunnel. Ingress nodes > > > > that use the locally scoped P2MP ID MUST place their IPv4 > > > > address here; a combination of this address and P2MP ID > > > > provides a globally unique identifier for the P2MP tunnel. > > > > > > How about: > > > > > > A 32-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel. Ingress nodes > > > that wish to a globally unique identifier for the P2MP tunnel > > > MUST place their tunnel sender address here. > > > >The above will be ok if we'll add the following to spell out > >what constitutes this (globally unique) identifier. > > > > A combination of this address and P2MP ID > > provides a globally unique identifier for the P2MP tunnel. > > Agreed! Good, so we are in agreement that a combination of root node address and P2MP ID forms a (globally unique) identifier for the P2MP tunnel. > Much thanks, > Lou > > PS I assume there is no need to change the definition of Tunnel ID, correct? Correct. Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 16:53:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKXC-0003hg-1L; Tue, 27 Jun 2006 16:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKXA-0003gS-HF for mpls@ietf.org; Tue, 27 Jun 2006 16:51:44 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKX9-00021W-71 for mpls@ietf.org; Tue, 27 Jun 2006 16:51:44 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FvKWu-00028d-Tu; Tue, 27 Jun 2006 16:51:29 -0400 Message-Id: <7.0.1.0.2.20060627164635.0376b170@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 27 Jun 2006 16:51:32 -0400 To: Yakov Rekhter From: Lou Berger In-Reply-To: <200606272037.k5RKb1563798@merlot.juniper.net> References: <200606272037.k5RKb1563798@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yakov, At 04:37 PM 6/27/2006, Yakov Rekhter wrote: >Lou, > >[clipped...] > > > > > > > It seems to me that the -05 text covered the issue you raised. So > > > > > > now we come to the heart of the matter: Why is a change in the -05 > > > > > > definition of the IDs needed? > > > > > > > > > > > > It seems to me that at most the text needs to replace a > "may" with a > > > > > > "MUST", as in "Ingress nodes that wish to narrow the scope of a > > > > > > SESSION to the ingress-PID pair MUST place their..." > > > > > > > > > >That is necessary, but not sufficient. Here are the changes that > > > > >need to be made: > > > > > > > > > >1. Section 4.1: > > > > > > > > > > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP > TE Tunnel is > > > > > identified by a P2MP SESSION object. This object contains the > > > > > identifier of the P2MP Session which includes the P2MP > ID, a tunnel > > > > > ID and an extended tunnel ID. > > > > > > > > > > The fields of a P2MP SESSION object are identical to those of the > > > > > SESSION object defined in [RFC3209] except that the > Tunnel Endpoint > > > > > Address field is replaced by the P2MP Identifier (P2MP ID) field. > > > > > > > > > > The P2MP ID provides an identifier for the set of > destinations of the > > > > > P2MP TE Tunnel. > > > > > > > > > >The last sentence above has to be deleted. > > > > > > > > why, what's incorrect about it? > > > > > >To begin with, the last sentence states that the P2MP ID, *by itself* > > >"provides an identifier for the set of destinations of a given P2MP > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not > > >be unique, how could it unambiguously identify the set of destinations > > >of such tunnel ? > > > > You are 100% correct, how about fixing it by saying: > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an > > identifier for the set of destinations of the P2MP TE Tunnel." > >Given that P2MP ID is unique within the scope of the root, why a >tuple is not sufficient to identify >the set of destinations of a P2MP tunnel ? After all, you agreed >further down that such a tuple identifies a P2MP tunnel. Because this would preclude the use of tunnel ID to further partition the session space (as is done today for P2P-TE.) The tuple I mentioned included all three. > > > > >2. Section 19.1.1 replace: > > > > > > > > > > P2MP ID > > > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > > constant over the life of the P2MP tunnel. It encodes the > > > > > P2MP ID and identifies the set of destinations of the P2MP > > > > > Tunnel." > > > > > > > > > >with the following: > > > > > > > > > > P2MP ID > > > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > > constant over the life of the P2MP tunnel. It encodes the > > > > > P2MP Identifier that is unique within the scope of the Ingress > > > > > LSR whose IP address is carried in the Extended Tunnel ID. > > > > > > > > Why not, just "Identifier that is unique within the scope of the > > > > Ingress LSR."? > > > > > >That would be fine with me. > > > > great. > > > > > > > > > >3. Section 19.1.1 replace > > > > > > > > > > Extended Tunnel ID > > > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > > constant over the life of the P2MP tunnel. Normally set to > > > > > all zeros. Ingress nodes that wish to narrow the scope of a > > > > > SESSION to the ingress-PID pair may place their IPv4 address > > > > > here as a globally unique identifier [RFC3209]." > > > > > > > > > >with the following: > > > > > > > > > > Extended Tunnel ID > > > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > > constant over the life of the P2MP tunnel. Ingress nodes > > > > > that use the locally scoped P2MP ID MUST place their IPv4 > > > > > address here; a combination of this address and P2MP ID > > > > > provides a globally unique identifier for the P2MP tunnel. > > > > > > > > How about: > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > constant over the life of the P2MP tunnel. Ingress nodes > > > > that wish to a globally unique identifier for the P2MP tunnel > > > > MUST place their tunnel sender address here. > > > > > >The above will be ok if we'll add the following to spell out > > >what constitutes this (globally unique) identifier. > > > > > > A combination of this address and P2MP ID > > > provides a globally unique identifier for the P2MP tunnel. > > > > Agreed! > >Good, so we are in agreement that a combination of root node address >and P2MP ID forms a (globally unique) identifier for the P2MP tunnel. > > > Much thanks, > > Lou > > > > PS I assume there is no need to change the definition of Tunnel > ID, correct? > >Correct. Much thanks, Lou >Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 17:09:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKn8-0007Ig-EX; Tue, 27 Jun 2006 17:08:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKn3-00079E-JE for mpls@ietf.org; Tue, 27 Jun 2006 17:08:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJvU-0005O4-06 for mpls@ietf.org; Tue, 27 Jun 2006 16:12:48 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJrY-0004hx-BG for mpls@ietf.org; Tue, 27 Jun 2006 16:08:45 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FvJr8-0000rp-RZ; Tue, 27 Jun 2006 16:08:19 -0400 Message-Id: <7.0.1.0.2.20060627154305.058b7928@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 27 Jun 2006 16:08:21 -0400 To: Yakov Rekhter From: Lou Berger In-Reply-To: <200606271926.k5RJQ2548914@merlot.juniper.net> References: <200606271926.k5RJQ2548914@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.4 (--) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: mpls@ietf.org, ccamp@ops.ietf.org, p2mp@labn.net Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yakov, See below, I think we're almost there. At 03:26 PM 6/27/2006, Yakov Rekhter wrote: >Lou, > > > > > 2) Extended Tunnel ID > > > > [again from rahul's mail] > > > > > > > > > 5. > > > > > > > > > > "Extended Tunnel ID > > > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > > constant over the life of the P2MP tunnel. Normally set to > > > > > all zeros. Ingress nodes that wish to narrow the scope of a > > > > > SESSION to the ingress-PID pair may place their IPv4 address > > > > > here as a globally unique identifier [RFC3209]." > > > > > > > > > > to > > > > > > > > > > "Extended Tunnel ID > > > > > > > > > > A 32-bit identifier used in the SESSION object that remains > > > > > constant over the life of the P2MP tunnel. This identifier > > > > > MUST be set to the ingress LSR's IPv4 address." > > > > > > > > So the original text, allowed for global uniqueness and included a > > > > "well-established procedures for assigning (globally) unique" P2MP IDs. > > > > > >Could you please point me to the text that spells out procedures > > >for assigning P2MP IDs that are globally unique *on their own* (not > > >in a combination with the Extended Tunnel ID). > > > > Ahh, good point, I was referring to the uniqueness of the tuple > ID, Tunnel ID, Extended Tunnel ID>. I must admit, I made the > > assumption that this is what you cared about for uniqueness. > >That is precisely what I care about. > > > Is this > > not the case? If not, why is uniqueness of the tuple insufficient? > >Uniqueness of the tuple is sufficient. > > > > > It seems to me that the -05 text covered the issue you raised. So > > > > now we come to the heart of the matter: Why is a change in the -05 > > > > definition of the IDs needed? > > > > > > > > It seems to me that at most the text needs to replace a "may" with a > > > > "MUST", as in "Ingress nodes that wish to narrow the scope of a > > > > SESSION to the ingress-PID pair MUST place their..." > > > > > >That is necessary, but not sufficient. Here are the changes that > > >need to be made: > > > > > >1. Section 4.1: > > > > > > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > > > identified by a P2MP SESSION object. This object contains the > > > identifier of the P2MP Session which includes the P2MP ID, a tunnel > > > ID and an extended tunnel ID. > > > > > > The fields of a P2MP SESSION object are identical to those of the > > > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > > > Address field is replaced by the P2MP Identifier (P2MP ID) field. > > > > > > The P2MP ID provides an identifier for the set of destinations of the > > > P2MP TE Tunnel. > > > > > >The last sentence above has to be deleted. > > > > why, what's incorrect about it? > >To begin with, the last sentence states that the P2MP ID, *by itself* >"provides an identifier for the set of destinations of a given P2MP >TE Tunnel". However, since a given P2MP ID, *by itself*, may not >be unique, how could it unambiguously identify the set of destinations >of such tunnel ? You are 100% correct, how about fixing it by saying: "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an identifier for the set of destinations of the P2MP TE Tunnel." > > >2. Section 19.1.1 replace: > > > > > > P2MP ID > > > > > > A 32-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel. It encodes the > > > P2MP ID and identifies the set of destinations of the P2MP > > > Tunnel." > > > > > >with the following: > > > > > > P2MP ID > > > > > > A 32-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel. It encodes the > > > P2MP Identifier that is unique within the scope of the Ingress LSR > > > whose IP address is carried in the Extended Tunnel ID. > > > > Why not, just "Identifier that is unique within the scope of the > > Ingress LSR."? > >That would be fine with me. great. > > > >3. Section 19.1.1 replace > > > > > > Extended Tunnel ID > > > > > > A 32-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel. Normally set to > > > all zeros. Ingress nodes that wish to narrow the scope of a > > > SESSION to the ingress-PID pair may place their IPv4 address > > > here as a globally unique identifier [RFC3209]." > > > > > >with the following: > > > > > > Extended Tunnel ID > > > > > > A 32-bit identifier used in the SESSION object that remains > > > constant over the life of the P2MP tunnel. Ingress nodes > > > that use the locally scoped P2MP ID MUST place their IPv4 > > > address here; a combination of this address and P2MP ID > > > provides a globally unique identifier for the P2MP tunnel. > > > > How about: > > > > A 32-bit identifier used in the SESSION object that remains > > constant over the life of the P2MP tunnel. Ingress nodes > > that wish to a globally unique identifier for the P2MP tunnel > > MUST place their tunnel sender address here. > >The above will be ok if we'll add the following to spell out >what constitutes this (globally unique) identifier. > > A combination of this address and P2MP ID > provides a globally unique identifier for the P2MP tunnel. Agreed! Much thanks, Lou PS I assume there is no need to change the definition of Tunnel ID, correct? >Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 19:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMZp-0008S5-Bz; Tue, 27 Jun 2006 19:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMZn-0008RM-TT for mpls@ietf.org; Tue, 27 Jun 2006 19:02:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvLpj-0002er-66 for mpls@ietf.org; Tue, 27 Jun 2006 18:14:59 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvLah-0003XV-SV for mpls@ietf.org; Tue, 27 Jun 2006 17:59:30 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5RLxQX29928; Tue, 27 Jun 2006 14:59:26 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k5RLxL581057; Tue, 27 Jun 2006 14:59:21 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200606272159.k5RLxL581057@merlot.juniper.net> To: Lou Berger In-Reply-To: Your message of "Tue, 27 Jun 2006 16:51:32 EDT." <7.0.1.0.2.20060627164635.0376b170@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12447.1151445561.1@juniper.net> Date: Tue, 27 Jun 2006 14:59:21 -0700 From: Yakov Rekhter X-Spam-Score: -2.5 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Lou, [clipped...] > > > > > > The P2MP ID provides an identifier for the set of > > > > > > destinations of the P2MP TE Tunnel. > > > > > > > > > > > >The last sentence above has to be deleted. > > > > > > > > > > why, what's incorrect about it? > > > > > > > >To begin with, the last sentence states that the P2MP ID, *by itself* > > > >"provides an identifier for the set of destinations of a given P2MP > > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not > > > >be unique, how could it unambiguously identify the set of destinations > > > >of such tunnel ? > > > > > > You are 100% correct, how about fixing it by saying: > > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an > > > identifier for the set of destinations of the P2MP TE Tunnel." > > > >Given that P2MP ID is unique within the scope of the root, why a > >tuple is not sufficient to identify > >the set of destinations of a P2MP tunnel ? After all, you agreed > >further down that such a tuple identifies a P2MP tunnel. > > Because this would preclude the use of tunnel ID to further partition > the session space (as is done today for P2P-TE.) The tuple I > mentioned included all three. You, yourself agreed that "A combination of this address and P2MP ID provides a globally unique identifier for the P2MP tunnel." Since the set of destinations of a P2MP tunnel is just a part of the tunnel, identifying the tunnel should be sufficient in order to identify the set of destinations. Since a tuple is sufficient to identify the tunnel, the same tuple is sufficient to identify the set of destinations of the tunnel. Therefore, the Tunnel ID is not needed to identify the set of destinations of the tunnel. Yakov. P.S. I would also caution against trying to draw too much analogy with the P2P tunnels. As I explained to you in one of my previous e-mails, the semantics of some of the fields carried in the Session object in P2MP tunnels is quite different from the semantics of their counterparts in P2P tunnels. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 27 22:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvPNK-0000V2-Hc; Tue, 27 Jun 2006 22:01:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvPNJ-0000UZ-8l for mpls@ietf.org; Tue, 27 Jun 2006 22:01:53 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvPNI-0004Bh-0h for mpls@ietf.org; Tue, 27 Jun 2006 22:01:53 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FvPMz-0004Ew-Mh; Tue, 27 Jun 2006 22:01:33 -0400 Message-Id: <7.0.1.0.2.20060627215027.050aaf60@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 27 Jun 2006 22:01:37 -0400 To: Yakov Rekhter From: Lou Berger In-Reply-To: <200606272159.k5RLxL581057@merlot.juniper.net> References: <200606272159.k5RLxL581057@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yakov, See below. At 05:59 PM 6/27/2006, Yakov Rekhter wrote: >Lou, > >[clipped...] > > > > > > > > The P2MP ID provides an identifier for the set of > > > > > > > destinations of the P2MP TE Tunnel. > > > > > > > > > > > > > >The last sentence above has to be deleted. > > > > > > > > > > > > why, what's incorrect about it? > > > > > > > > > >To begin with, the last sentence states that the P2MP ID, *by itself* > > > > >"provides an identifier for the set of destinations of a given P2MP > > > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not > > > > >be unique, how could it unambiguously identify the set of destinations > > > > >of such tunnel ? > > > > > > > > You are 100% correct, how about fixing it by saying: > > > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an > > > > identifier for the set of destinations of the P2MP TE Tunnel." > > > > > >Given that P2MP ID is unique within the scope of the root, why a > > >tuple is not sufficient to identify > > >the set of destinations of a P2MP tunnel ? After all, you agreed > > >further down that such a tuple identifies a P2MP tunnel. > > > > Because this would preclude the use of tunnel ID to further partition > > the session space (as is done today for P2P-TE.) The tuple I > > mentioned included all three. > >You, yourself agreed that "A combination of this address and P2MP >ID provides a globally unique identifier for the P2MP tunnel." Well actually my point was: "... the uniqueness of the tuple . " >Since the set of destinations of a P2MP tunnel is just a part of >the tunnel, identifying the tunnel should be sufficient in order >to identify the set of destinations. right, and all three fields are needed. >Since a tuple is sufficient to identify >the tunnel, the same tuple is sufficient to identify the set of >destinations of the tunnel. Therefore, the Tunnel ID is not >needed to identify the set of destinations of the tunnel. we disagree. >Yakov. > >P.S. I would also caution against trying to draw too much analogy >with the P2P tunnels. As I explained to you in one of my previous >e-mails, the semantics of some of the fields carried in the Session >object in P2MP tunnels is quite different from the semantics of >their counterparts in P2P tunnels. Sure, but you've not stated any reason or need to change the semantics wrt tunnel ID... Lou _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 28 09:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZlm-00068U-Sl; Wed, 28 Jun 2006 09:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZlm-00068P-4M for mpls@ietf.org; Wed, 28 Jun 2006 09:07:50 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvZlg-0005xf-Lz for mpls@ietf.org; Wed, 28 Jun 2006 09:07:50 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FvZld-0003va-00 for mpls@ietf.org; Wed, 28 Jun 2006 14:07:41 +0100 Received: from your029b8cecfe ([194.94.109.154] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 14:07:41 +0100 Message-ID: <091501c69ab3$d40eefd0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Yakov Rekhter" , "Lou Berger" References: <200606272159.k5RLxL581057@merlot.juniper.net> <7.0.1.0.2.20060627215027.050aaf60@labn.net> Subject: Re: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] Date: Wed, 28 Jun 2006 14:07:31 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 28 Jun 2006 13:07:41.0354 (UTC) FILETIME=[D66710A0:01C69AB3] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Just FWIW P2MP-ID (P2ID): A unique identifier of a P2MP TE LSP, which is constant for the whole LSP regardless of the number of branches and/or leaves. Extracted from RFC4461. We do not have to use that description in the protocol fields, but if we choose not to, I suggest that we change the name of the field to avoid confusion. Historically, the reason for the text "The P2MP ID provides an identifier for the set of destinations of the P2MP TE Tunnel." is that some folk hoped to use something akin to a group address in this space. Thus the tunnel would be identified by tunnel ID, extended tunnel ID and group destination address. Multiple tunnels to the same destination group address would have different tunnel IDs (if from the same sender) and could have different extended tunnel IDs (if the senders made that choice). Adrian ----- Original Message ----- From: "Lou Berger" To: "Yakov Rekhter" Cc: ; ; Sent: Wednesday, June 28, 2006 3:01 AM Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] > Yakov, > See below. > > At 05:59 PM 6/27/2006, Yakov Rekhter wrote: > >>Lou, >> >>[clipped...] >> >> > > > > > > The P2MP ID provides an identifier for the set of >> > > > > > > destinations of the P2MP TE Tunnel. >> > > > > > > >> > > > > > >The last sentence above has to be deleted. >> > > > > > >> > > > > > why, what's incorrect about it? >> > > > > >> > > > >To begin with, the last sentence states that the P2MP ID, *by >> > > > >itself* >> > > > >"provides an identifier for the set of destinations of a given >> > > > >P2MP >> > > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not >> > > > >be unique, how could it unambiguously identify the set of >> > > > >destinations >> > > > >of such tunnel ? >> > > > >> > > > You are 100% correct, how about fixing it by saying: >> > > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an >> > > > identifier for the set of destinations of the P2MP TE Tunnel." >> > > >> > >Given that P2MP ID is unique within the scope of the root, why a >> > >tuple is not sufficient to identify >> > >the set of destinations of a P2MP tunnel ? After all, you agreed >> > >further down that such a tuple identifies a P2MP tunnel. >> > >> > Because this would preclude the use of tunnel ID to further partition >> > the session space (as is done today for P2P-TE.) The tuple I >> > mentioned included all three. >> >>You, yourself agreed that "A combination of this address and P2MP >>ID provides a globally unique identifier for the P2MP tunnel." > > Well actually my point was: "... the uniqueness of the tuple Tunnel ID, Extended Tunnel ID>. " > >>Since the set of destinations of a P2MP tunnel is just a part of >>the tunnel, identifying the tunnel should be sufficient in order >>to identify the set of destinations. > > right, and all three fields are needed. > >>Since a tuple is sufficient to identify >>the tunnel, the same tuple is sufficient to identify the set of >>destinations of the tunnel. Therefore, the Tunnel ID is not >>needed to identify the set of destinations of the tunnel. > > we disagree. > >>Yakov. >> >>P.S. I would also caution against trying to draw too much analogy >>with the P2P tunnels. As I explained to you in one of my previous >>e-mails, the semantics of some of the fields carried in the Session >>object in P2MP tunnels is quite different from the semantics of >>their counterparts in P2P tunnels. > > Sure, but you've not stated any reason or need to change the semantics wrt > tunnel ID... > > Lou > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 28 15:12:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfQi-0005Tn-7E; Wed, 28 Jun 2006 15:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfQf-0005Th-N9 for mpls@ietf.org; Wed, 28 Jun 2006 15:10:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvfQe-0000rn-Fs for mpls@ietf.org; Wed, 28 Jun 2006 15:10:25 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Jun 2006 12:10:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="30690725:sNHT19683586" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5SJANno012582; Wed, 28 Jun 2006 15:10:23 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 15:10:23 -0400 Received: from SwallowPB.local ([161.44.74.167]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 15:10:23 -0400 Received: from cisco.com (localhost [127.0.0.1]) by SwallowPB.local (Postfix) with ESMTP id 2E1CA218E53; Wed, 28 Jun 2006 15:11:25 -0400 (EDT) To: Yakov Rekhter In-reply-to: Your message of "Tue, 27 Jun 2006 14:59:21 PDT." <200606272159.k5RLxL581057@merlot.juniper.net> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Wed, 28 Jun 2006 15:11:24 -0400 Message-Id: <20060628191125.2E1CA218E53@SwallowPB.local> X-OriginalArrivalTime: 28 Jun 2006 19:10:23.0112 (UTC) FILETIME=[816BD080:01C69AE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mpls@ietf.org, ccamp@ops.ietf.org, p2mp@labn.net Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > Since a tuple is sufficient to identify > the tunnel, the same tuple is sufficient to identify the set of > destinations of the tunnel. Therefore, the Tunnel ID is not > needed to identify the set of destinations of the tunnel. I really don't understand this drive to change semantics that have been stable since we began working on this draft, and that are consistent with 3209 this late in the game. I am TOTALLY opposed to it. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 28 16:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgDu-0002Ab-4d; Wed, 28 Jun 2006 16:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvTHQ-0008Qk-3Y; Wed, 28 Jun 2006 02:12:04 -0400 Received: from mx2.lb.mrv.com ([66.43.110.200] helo=mailserver.corp.int.mrv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvTHO-0006lR-Px; Wed, 28 Jun 2006 02:12:04 -0400 Received: from chmailsrv.int.mrv.com ([192.168.11.19]) by mailserver.corp.int.mrv.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id NV34D647; Tue, 27 Jun 2006 23:11:57 -0700 Received: from zeus.yok.int.mrv.com ([172.21.9.11]) by chmailsrv.int.mrv.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 23:11:57 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 28 Jun 2006 09:11:53 +0300 Message-ID: <685D66DF6DB563459D23ECD8B30C73A40CD3B8@zeus.yok.int.mrv.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fast Reroute related question according to RFC4090 Thread-Index: AcaaecB60A8sX5esQS2bpzlzCcTK1Q== From: "Asaf Henig" To: , , X-OriginalArrivalTime: 28 Jun 2006 06:11:57.0341 (UTC) FILETIME=[C29CBCD0:01C69A79] X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Wed, 28 Jun 2006 16:01:17 -0400 Cc: Subject: [mpls] Fast Reroute related question according to RFC4090 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0210168784==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0210168784== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69A79.C088A7CA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69A79.C088A7CA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable This question is related to the Facility Backup Method in Fast Reroute = as mentioned in RFC 4090. The RFC mentions many times that in Facility Backup method a router = doesn=92t know it is an MP (merge point) until the link connecting it to = the PLR (incase of link protection) is down. The RFC explains that when = such an event occurs the MP should wait for PATH messages to arrive from = the backup path which help the MP connect between the protected LSP and = the backup session. According to the above scenario, is it correct that after the link is = down the MP should handle three different types of PATH messages which = arrive from the backup direction? 1) The original protected lsp path messages which are now = encapsulated in MPLS. 2) New path messages, which are also mpls encapsulated, initiated = by the PLR and have almost the same session identifier as the path = messages of the protected lsp but with a different sender id. 3) The original backup path messages which simply maintain the = backup tunnel which starts at the PLR and ends at the MP. =20 Thanks for your help.=20 Asaf Henig. Software engineer=20 MRV International =20 ------_=_NextPart_001_01C69A79.C088A7CA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
=0A=

This question is related to the Facility Backup Method = in Fast =0A= Reroute as mentioned in RFC 4090.

The RFC mentions many times = that in =0A= Facility Backup method a router doesn=92t know it is an MP (merge point) = until the =0A= link connecting it to the PLR (incase of link protection) is down. The = RFC =0A= explains that when such an event occurs the MP should wait for PATH = messages to =0A= arrive from the backup path which help the MP connect between the = protected LSP =0A= and the backup session.

According to the above scenario, is it = correct =0A= that after the link is down the MP should handle three different types = of PATH =0A= messages which arrive from the backup = direction?
     1) =0A= The original protected lsp path messages which are now encapsulated in =0A= MPLS.

=0A=

     2) New path messages, which = are also =0A= mpls encapsulated, initiated by the PLR and have almost the same =0A= session identifier as the path messages of the protected lsp but = with a =0A= different sender id.

     3) The = original backup =0A= path messages which simply maintain the backup tunnel which starts at = the PLR =0A= and ends at the MP.

=0A=

       
Thanks = for your =0A= help. 

=0A=

Asaf Henig. Software engineer 

=0A=

MRV =0A= International



 

 ------_=_NextPart_001_01C69A79.C088A7CA-- --===============0210168784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0210168784==-- From mpls-bounces@lists.ietf.org Wed Jun 28 16:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgIc-0005of-Uo; Wed, 28 Jun 2006 16:06:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgIa-0005na-VT for mpls@ietf.org; Wed, 28 Jun 2006 16:06:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgIZ-0005zo-Nj for mpls@ietf.org; Wed, 28 Jun 2006 16:06:08 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Jun 2006 16:06:08 -0400 X-IronPort-AV: i="4.06,189,1149480000"; d="scan'208"; a="91232712:sNHT30460712" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5SK67YL003436; Wed, 28 Jun 2006 16:06:07 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 16:06:07 -0400 Received: from SwallowPB.local ([161.44.74.167]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 16:06:07 -0400 Received: from cisco.com (localhost [127.0.0.1]) by SwallowPB.local (Postfix) with ESMTP id A711E219BE1; Wed, 28 Jun 2006 16:07:09 -0400 (EDT) To: Yakov Rekhter In-reply-to: Your message of "Tue, 27 Jun 2006 12:26:02 PDT." <200606271926.k5RJQ2548914@merlot.juniper.net> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Wed, 28 Jun 2006 16:07:09 -0400 Message-Id: <20060628200709.A711E219BE1@SwallowPB.local> X-OriginalArrivalTime: 28 Jun 2006 20:06:07.0051 (UTC) FILETIME=[4A9069B0:01C69AEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mpls@ietf.org, ccamp@ops.ietf.org, p2mp@labn.net Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > A combination of this address and P2MP ID > provides a globally unique identifier for the P2MP tunnel. I want this to be the full tuple: Further we should only be calling this a globally unique identifier of a tunnel since the set of endpoint can change over the lifetime of the tunnel. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 28 16:58:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvh5X-0000CR-8v; Wed, 28 Jun 2006 16:56:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvh5L-00005m-UP for mpls@ietf.org; Wed, 28 Jun 2006 16:56:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvh5I-0005ft-2s for mpls@ietf.org; Wed, 28 Jun 2006 16:56:31 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Jun 2006 13:56:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="30701555:sNHT21488748" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5SKuRYL014926; Wed, 28 Jun 2006 16:56:27 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 16:56:26 -0400 Received: from SwallowPB.local ([161.44.74.167]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 16:56:25 -0400 Received: from cisco.com (localhost [127.0.0.1]) by SwallowPB.local (Postfix) with ESMTP id D3C4321A0A1; Wed, 28 Jun 2006 16:57:27 -0400 (EDT) To: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org Subject: Re: Rahul Aggarwal: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] In-reply-to: Your message of "Mon, 26 Jun 2006 09:07:48 EDT." <17567.56356.471802.735174@lens.cisco.com> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Wed, 28 Jun 2006 16:57:27 -0400 Message-Id: <20060628205727.D3C4321A0A1@SwallowPB.local> X-OriginalArrivalTime: 28 Jun 2006 20:56:25.0065 (UTC) FILETIME=[5170CD90:01C69AF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org The text below should not be changed (at least not to what has been proposed!) > > 19.2.1 > > " IPv4 tunnel sender address > See [RFC3209]" > > to" > > "IPv4 tunnel sender address. This address MUST be the same as the address > in the Extended Tunnel ID field of the SESSION object." > > 8. > > 19.2.2 > > "IPv6 tunnel sender address > See [RFC3209]" > > to > > "IPv6 tunnel sender address. This address MUST be the same as the address > in the Extended Tunnel ID field of the SESSION object." These changes bill break bypass FRR. When a node want to establish a fast reroute LSP that merges back in over a bypass tunnel, the Sender address is set to its own IP address (which in most cases would be some midpoint node). Further i think that we should only RECOMMEND that the Extended tunnel ID be used to carry the tunnel headend address. So we couldn't say MUST here anyway. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 28 17:02:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvh9B-0003YP-7i; Wed, 28 Jun 2006 17:00:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvh99-0003YF-JS for mpls@ietf.org; Wed, 28 Jun 2006 17:00:27 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvh98-0006aF-B8 for mpls@ietf.org; Wed, 28 Jun 2006 17:00:27 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 28 Jun 2006 14:00:26 -0700 X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="563655220:sNHT28266544" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 14:00:24 -0700 Date: Wed, 28 Jun 2006 14:00:25 -0700 (PDT) From: Rahul Aggarwal To: George Swallow Subject: Re: Rahul Aggarwal: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt] In-Reply-To: <20060628205727.D3C4321A0A1@SwallowPB.local> Message-ID: <20060628135819.M15184@sapphire.juniper.net> References: <20060628205727.D3C4321A0A1@SwallowPB.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 28 Jun 2006 21:00:24.0961 (UTC) FILETIME=[E06E0710:01C69AF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi George, On Wed, 28 Jun 2006, George Swallow wrote: > The text below should not be changed (at least not to what has been > proposed!) > > > > > > 19.2.1 > > > > " IPv4 tunnel sender address > > See [RFC3209]" > > > > to" > > > > "IPv4 tunnel sender address. This address MUST be the same as the address > > in the Extended Tunnel ID field of the SESSION object." > > > > 8. > > > > 19.2.2 > > > > "IPv6 tunnel sender address > > See [RFC3209]" > > > > to > > > > "IPv6 tunnel sender address. This address MUST be the same as the address > > in the Extended Tunnel ID field of the SESSION object." > > These changes bill break bypass FRR. When a node want to establish a > fast reroute LSP that merges back in over a bypass tunnel, the Sender > address is set to its own IP address (which in most cases would be some > midpoint node). > Agreed. rahul > Further i think that we should only RECOMMEND that the Extended tunnel > ID be used to carry the tunnel headend address. So we couldn't say MUST > here anyway. > > ...George > > ======================================================================== > George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 28 18:12:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviEu-0000YK-VM; Wed, 28 Jun 2006 18:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviEt-0000YF-RX for mpls@ietf.org; Wed, 28 Jun 2006 18:10:27 -0400 Received: from esc71.midphase.com ([216.246.11.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviEs-00040U-LQ for mpls@ietf.org; Wed, 28 Jun 2006 18:10:27 -0400 Received: from esc71.midphase.com ([216.246.11.148] helo=LC1.labn.net) by esc71.midphase.com with esmtpa (Exim 4.52) id 1FviEU-0000ep-Ll; Wed, 28 Jun 2006 18:10:02 -0400 Message-Id: <7.0.1.0.2.20060628180932.039cd900@labn.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 28 Jun 2006 18:10:03 -0400 To: George Swallow From: Lou Berger In-Reply-To: <20060628191125.2E1CA218E53@SwallowPB.local> References: <20060628191125.2E1CA218E53@SwallowPB.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc71.midphase.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mpls@ietf.org, ccamp@ops.ietf.org, p2mp@labn.net Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org George, Glad to see I'm not the only one who holds this opinion! Lou At 03:11 PM 6/28/2006, George Swallow wrote: > > Since a tuple is sufficient to identify > > the tunnel, the same tuple is sufficient to identify the set of > > destinations of the tunnel. Therefore, the Tunnel ID is not > > needed to identify the set of destinations of the tunnel. > >I really don't understand this drive to change semantics that have been >stable since we began working on this draft, and that are consistent >with 3209 this late in the game. I am TOTALLY opposed to it. > >...George > >======================================================================== >George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed Jun 28 19:00:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvizE-0007m8-PI; Wed, 28 Jun 2006 18:58:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvirM-00064r-JJ; Wed, 28 Jun 2006 18:50:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvirM-0000CM-H5; Wed, 28 Jun 2006 18:50:12 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvirC-0000Fq-S6; Wed, 28 Jun 2006 18:50:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5SMo21u006601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvirC-0004oA-EC; Wed, 28 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 18:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --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 : Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Author(s) : I. Minei, et al. Filename : draft-ietf-mpls-ldp-p2mp-01.txt Pages : 24 Date : 2006-6-28 This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The solution relies on LDP without requiring a multicast routing protocol in the network. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/MP2MP LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-p2mp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-p2mp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-p2mp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-28170843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-p2mp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-p2mp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28170843.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Thu Jun 29 06:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvtz0-0000Iq-EL; Thu, 29 Jun 2006 06:42:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvtyw-0008HN-OY; Thu, 29 Jun 2006 06:42:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvt79-0004La-Sl; Thu, 29 Jun 2006 05:47:11 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvsmp-00074l-GJ; Thu, 29 Jun 2006 05:26:21 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1M002RO7GA1T@szxga01-in.huawei.com>; Thu, 29 Jun 2006 17:24:10 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1M00EKZ7GAYJ@szxga01-in.huawei.com>; Thu, 29 Jun 2006 17:24:10 +0800 (CST) Received: from z52048 ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1M0077K7G9NF@szxml03-in.huawei.com>; Thu, 29 Jun 2006 17:24:12 +0800 (CST) Date: Thu, 29 Jun 2006 17:22:15 +0800 From: Zheng Hewen Subject: RE: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically In-reply-to: <44A0A7EE.8060602@ft.solteria.net> To: "'S.Matsushima'" Message-id: <001c01c69b5d$834a5b70$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcaZmzex2RuLvlXPQ6uWho+5IaCvhQBwidmQ X-Spam-Score: -1.3 (-) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ccamp@ops.ietf.org, mpls@ietf.org, l3vpn@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, Is your solution inside draft-satoru-mpls-bgp-multipoint-01.txt? If so, it is applicable for inter-area/domain applications. Best regards, Hewen -----Original Message----- From: S.Matsushima [mailto:satoru@ft.solteria.net] Sent: 2006年6月27日 11:37 To: Zheng Hewen Cc: mpls@ietf.org; ccamp@ops.ietf.org; l3vpn@ietf.org Subject: Re: [MPLS]Suggestion to discover and distribute multicast membership for P2MP automatically and dynamically Hi, Agreed. I think that it is good point. Dynamic discover and membership distribution of p2mp LSP will be needed to operate p2mp LSP in real networks. Also, I would say that policy-based mechanism to establish p2mp LSP in per LSP basis is needed. In BGP P2MP solution, you can see some ideas to achieve above requirements. Your interest and comment are welcome. http://www3.ietf.org/proceedings/05nov/slides/mpls-3/sld1.htm -03 version of this draft will appear soon. -- Satoru Matsushima Zheng Hewen wrote: > Hi, > > The signaling solution for the construction of P2MP MPLS-TE LSPs > defined in draft-ietf-mpls-rsvp-te-p2mp-05.txt assumes that the > ingress node for any P2MP LSP knows the identities of all of the receivers. No mechanism in that document is provided by which it can discover the identities of those receivers. > > In multicast LDP (mLDP) defined in draft-ietf-mpls-ldp-p2mp-00.txt it > is assumed that each receiver knows the identity of the source of the distribution tree, but no mechanism is provided whereby the receivers can discover that information. > > In order to successfully operate P2MP MPLS, and to consider extending > MPLS to support MP2MP it is necessary to examine the requirements for > exchanging and learning the identities of P2MP roots and leaves. One mechanism is desired to discover and distribute multicast membership information dynamically. > > Currently some work is in progress. For L3VPN applications, it is one > choice to carry and distribute multicast membership information > through auto-discovery mechanism based on extended BGP defined in the > draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.txt. For P2MP MPLS-TE > applications, one effort is to extend IGP-TE for such purpose using > one analogous mechanism defined in draft-ietf-ccamp-te-node-cap-01.txt. For connection-oriented transport network basing on MPLS, one mechanism defined in RFC2022 may be referred. Extension to MSDP is another choice to satisfy those requirements directly if possible. > > It is desired to clear the requirements for that mechanism. Is there > any interest for this? I want to do something about it and hope to receive advices. > > > Best Regards, > Heaven > > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 29 12:17:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzAZ-0002Fg-JM; Thu, 29 Jun 2006 12:15:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzAX-0002Fb-Jg for mpls@ietf.org; Thu, 29 Jun 2006 12:15:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvzAX-0004p8-1y for mpls@ietf.org; Thu, 29 Jun 2006 12:15:05 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2006 09:15:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208,217"; a="30769149:sNHT45184984" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5TGF4YL009175 for ; Thu, 29 Jun 2006 12:15:04 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 12:15:04 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 12:15:03 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: mpls@ietf.org Message-Id: <0703E806-E955-4D8C-8046-21978965AF28@cisco.com> References: From: JP Vasseur Subject: Fwd: [mpls] I-D ACTION:draft-ietf-mpls-number-0-bw-te-lsps-02.txt Date: Thu, 29 Jun 2006 12:15:01 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 29 Jun 2006 16:15:03.0190 (UTC) FILETIME=[2D78DB60:01C69B97] X-Spam-Score: 0.2 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1862016929==" Errors-To: mpls-bounces@lists.ietf.org --===============1862016929== Content-Type: multipart/alternative; boundary=Apple-Mail-38--655674389 --Apple-Mail-38--655674389 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Just a quick note to let you know that this new revision does not bring any content change, just editorial clarifications. This ID is quite stable. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 27, 2006 3:50:01 PM EDT > To: i-d-announce@ietf.org > Cc: mpls@lists.ietf.org > Subject: [mpls] I-D ACTION:draft-ietf-mpls-number-0-bw-te-lsps-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching > Working Group of the IETF. > > Title : A Link-Type sub-TLV to convey the number of Traffic > Engineering Label Switch Paths signalled across a link > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-mpls-number-0-bw-te-lsps-02.txt > Pages : 8 > Date : 2006-6-27 > > Several Link-type sub-TLVs have been defined for OSPF and ISIS in the > context of MPLS Traffic Engineering in order to advertise some link > characteristics such as the available bandwidth, traffic engineering > metric, administrative group and so on. There are various > circumstances (for example in order to load balance unconstrained TE > Label Switched Path (LSP) across a set of equal cost paths) where it > would be useful to also advertise the number of unconstrained Traffic > Engineering Label Switched Path(s) (TE LSP) signalled across a link. > This document specifies a new Link-type Traffic Engineering sub-TLV > used to advertise the number of unconstrained TE LSP(s) signalled > across a link. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te- > lsps-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-number-0-bw-te-lsps-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-6-27105501.I-D@ietf.org> > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls --Apple-Mail-38--655674389 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear WG,

Just a quick note to let = you know that this new revision does not bring any content change, just = editorial clarifications. This ID is quite stable.

Thanks.

JP.

Begin = forwarded message:

Date: June 27, 2006 3:50:01 PM = EDT
To: i-d-announce@ietf.orgSubject: = [mpls] I-D = ACTION:draft-ietf-mpls-number-0-bw-te-lsps-02.txt=A0

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 = = : A Link-Type sub-TLV to convey the number of Traffic Engineering = Label Switch Paths signalled across a link
= Author(s) = : J. Vasseur, et al.
= Filename = : draft-ietf-mpls-number-0-bw-te-lsps-02.txt
Pages : 8
Date : = 2006-6-27

Several = Link-type sub-TLVs have been defined for OSPF and ISIS in the
context of MPLS Traffic Engineering in order to = advertise some link
characteristics such as the = available bandwidth, traffic engineering
metric, = administrative group and so on.=A0 = There are various
circumstances = (for example in order to load balance unconstrained TE
Label Switched Path (LSP) across a set of equal cost = paths) where it
would be useful to also = advertise the number of unconstrained Traffic
Engineering Label Switched Path(s) (TE LSP) = signalled across a link.
This document = specifies a new Link-type Traffic Engineering sub-TLV
used to advertise the number of unconstrained TE = LSP(s) signalled
across a link.

A URL = for this Internet-Draft is:
To remove yourself from the I-D = Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of the message. =A0
to = change your subscription settings.


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-number-0-bw-te-lsps-02.txt".

A list = of Internet-Drafts directories can be found in

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

Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-02.txt".

NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 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
Content-Type: = text/plain

=

= --Apple-Mail-38--655674389-- --===============1862016929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1862016929==-- From mpls-bounces@lists.ietf.org Fri Jun 30 08:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHtu-0000TY-1f; Fri, 30 Jun 2006 08:15:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHtt-0000St-BD for mpls@ietf.org; Fri, 30 Jun 2006 08:15:09 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwHts-0006z9-10 for mpls@ietf.org; Fri, 30 Jun 2006 08:15:09 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2006 05:15:08 -0700 X-IronPort-AV: i="4.06,196,1149490800"; d="scan'208"; a="326704913:sNHT31221600" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5UCF7OC014770 for ; Fri, 30 Jun 2006 05:15:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5UCF29u011353 for ; Fri, 30 Jun 2006 05:15:07 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 05:15:03 -0700 Received: from [10.32.241.75] ([10.32.241.75]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 05:15:03 -0700 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mpls@ietf.org From: Bruce Davie Date: Fri, 30 Jun 2006 08:15:19 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 30 Jun 2006 12:15:03.0411 (UTC) FILETIME=[D0F2B430:01C69C3E] DKIM-Signature: a=rsa-sha1; q=dns; l=1164; t=1151669707; x=1152533707; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=bdavie@cisco.com; z=From:Bruce=20Davie=20 |Subject:ECN-MPLS=20draft; X=v=3Dcisco.com=3B=20h=3DpMA/q795zomWdY3R0YQJRLrh8Dc=3D; b=ODKDTDJ7JC0JBGdapY+8El4OY1Adl9m3Lj7t0QkDrXe6Rszs3AIB7YhGiMWMSYvBk/UmW3Oe V1DVeebpIEWk2TbpMMBqaZ9l4yEPDG6OqSj2v4bbbUJBN7IoNMVekAVl; Authentication-Results: sj-dkim-1.cisco.com; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [mpls] ECN-MPLS draft X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org The draft below may be of interest to the MPLS WG. I plan to discuss it at the TSVWG meeting on Monday morning in Montreal. Bruce > I-D ACTION:draft-davie-ecn-mpls-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Explicit Congestion Marking in MPLS > Author(s) : B. Davie, et al. > Filename : draft-davie-ecn-mpls-00.txt > Pages : 21 > Date : 2006-6-20 > > RFC 3270 defines how to support the Diffserv arhitecture in MPLS > networks, including how to encode Diffserv Code Points (DSCPs) > in an > MPLS header. DSCPs may be encoded in the EXP field, while > other uses > of that field are not precluded. RFC3270 makes no statement about > how Explicit Congestion Notification (ECN) marking might be encoded > in the MPLS header. This draft defines how an operator might > define > some of the EXP codepoints for explicit congestion notification, > without precluding other uses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-davie-ecn-mpls-00.txt > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls