From owner-mpls@UU.NET Mon Feb 3 09:59:44 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09342 for ; Mon, 3 Feb 2003 09:59:43 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoalo09969 for ; Mon, 3 Feb 2003 15:03:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoalo09852; Mon, 3 Feb 2003 15:03:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQoalo17648 for mpls-outgoing; Mon, 3 Feb 2003 15:02:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoalo16915 for ; Mon, 3 Feb 2003 15:02:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoalo02389 for ; Mon, 3 Feb 2003 15:00:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoalo16050 for ; Mon, 3 Feb 2003 15:00:07 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQoalo16029 for ; Mon, 3 Feb 2003 15:00:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h13F0vbY008285 for ; Mon, 3 Feb 2003 10:00:58 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA14355 for ; Mon, 3 Feb 2003 10:00:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h13F05E23261 for mpls@uu.net; Mon, 3 Feb 2003 10:00:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoace23990 for ; Sat, 1 Feb 2003 02:06:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoace15786 for ; Sat, 1 Feb 2003 02:04:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoace25233 for ; Sat, 1 Feb 2003 02:04:12 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f43.sea2.hotmail.com [207.68.165.43]) id QQoace25225 for ; Sat, 1 Feb 2003 02:04:12 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 31 Jan 2003 18:04:11 -0800 Received: from 63.104.212.252 by sea2fd.sea2.hotmail.msn.com with HTTP; Sat, 01 Feb 2003 02:04:11 GMT X-Originating-IP: [63.104.212.252] From: "Sandeep B" To: mpls@UU.NET Subject: Vpns vs explicit null label Date: Sat, 01 Feb 2003 02:04:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Feb 2003 02:04:11.0755 (UTC) FILETIME=[369113B0:01C2C996] Sender: owner-mpls@UU.NET Precedence: bulk What should be the behaviour in following case - node1---- node2-----node3 all links are ethernet. VPN is setup between node1 and node3 (BGP or LDP). RSVP-TE is used to setup transport LSP between 2 sites. node3 gives either '0' or '3' as transport label to node2 and label 100 as VPN label to node1. Node2 gets a packet with 2 label stack from node1. removes the first label and forwards it to node3. how would node2 figure out what sort of ethertype marking it is suppose to mark on ethernet frame. cuz now it is suppose to be MPLS instead of IP. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-mpls@UU.NET Mon Feb 3 10:44:20 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10784 for ; Mon, 3 Feb 2003 10:44:19 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoalr27743 for ; Mon, 3 Feb 2003 15:47:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoalr27639; Mon, 3 Feb 2003 15:47:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoalr28453 for mpls-outgoing; Mon, 3 Feb 2003 15:47:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoalr28448 for ; Mon, 3 Feb 2003 15:47:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoalr22443 for ; Mon, 3 Feb 2003 15:46:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoalr11136 for ; Mon, 3 Feb 2003 15:46:39 GMT Received: from morpheus.lanterncom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.161.157.68]) id QQoalr11114 for ; Mon, 3 Feb 2003 15:46:38 GMT Received: by MORPHEUS with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 07:40:01 -0800 Message-ID: <58BE468BAC66D511AFE6000347251A2D01A16957@MORPHEUS> From: Anoop Ghanwani To: "'Sandeep B '" , "'mpls@UU.NET '" Subject: RE: Vpns vs explicit null label Date: Mon, 3 Feb 2003 07:40:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk If the bottom of stack bit of the the label that it popped is 1, node 2 would use the Ethertype for IP. Since the bottom of stack bit would be 0 in this case, it will continue to use the Ethertype for MPLS. -----Original Message----- From: Sandeep B To: mpls@UU.NET Sent: 1/31/03 6:04 PM Subject: Vpns vs explicit null label What should be the behaviour in following case - node1---- node2-----node3 all links are ethernet. VPN is setup between node1 and node3 (BGP or LDP). RSVP-TE is used to setup transport LSP between 2 sites. node3 gives either '0' or '3' as transport label to node2 and label 100 as VPN label to node1. Node2 gets a packet with 2 label stack from node1. removes the first label and forwards it to node3. how would node2 figure out what sort of ethertype marking it is suppose to mark on ethernet frame. cuz now it is suppose to be MPLS instead of IP. From owner-mpls@UU.NET Mon Feb 3 14:08:03 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17736 for ; Mon, 3 Feb 2003 14:08:03 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoame03729 for ; Mon, 3 Feb 2003 19:11:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoame03463; Mon, 3 Feb 2003 19:11:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQoame26023 for mpls-outgoing; Mon, 3 Feb 2003 19:10:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoame25895 for ; Mon, 3 Feb 2003 19:10:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoame13921 for ; Mon, 3 Feb 2003 19:10:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoame20188 for ; Mon, 3 Feb 2003 19:10:07 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQoame20162 for ; Mon, 3 Feb 2003 19:10:06 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h13JA5S16635 for ; Mon, 3 Feb 2003 11:10:06 -0800 (PST) (envelope-from ina@juniper.net) Date: Mon, 3 Feb 2003 11:10:05 -0800 (PST) From: Ina Minei To: Subject: Question on draft-ietf-mpls-tc-mib Message-ID: <20030203110738.J7984-100000@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Has the object iddentifier for the mplsMIB been assigned yet? Are there any guidelines on what implementors should use in the meantime? Thank you, Ina Minei From owner-mpls@UU.NET Mon Feb 3 14:21:33 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18184 for ; Mon, 3 Feb 2003 14:21:32 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoamf02922 for ; Mon, 3 Feb 2003 19:25:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoamf02690; Mon, 3 Feb 2003 19:25:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQoamf27560 for mpls-outgoing; Mon, 3 Feb 2003 19:24:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoamf27543 for ; Mon, 3 Feb 2003 19:24:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoamf27061 for ; Mon, 3 Feb 2003 19:24:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoamf02229 for ; Mon, 3 Feb 2003 19:24:05 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQoamf02217 for ; Mon, 3 Feb 2003 19:24:04 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h13JOt7R018936 for ; Mon, 3 Feb 2003 14:24:55 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA06001 for ; Mon, 3 Feb 2003 14:24:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h13JO2209276 for mpls@uu.net; Mon, 3 Feb 2003 14:24:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoamf27507 for ; Mon, 3 Feb 2003 19:22:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoamf16042 for ; Mon, 3 Feb 2003 19:22:45 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoamf00888 for ; Mon, 3 Feb 2003 19:22:45 GMT Received: from rooster.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hen.cisco.com [64.102.19.198]) id QQoamf00877 for ; Mon, 3 Feb 2003 19:22:45 GMT Received: from CPIGNATA-W2K.cisco.com (rtp-vpn2-407.cisco.com [10.82.241.151]) by rooster.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h13JMe016067; Mon, 3 Feb 2003 14:22:40 -0500 (EST) Message-Id: <4.3.2.7.2.20030203134021.0500cab0@rooster> X-Sender: cpignata@rooster X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Feb 2003 14:22:39 -0500 To: mpls@UU.NET From: "Carlos M. Pignataro" Subject: Question regarding draft-nadeau-mpls-lc-if-mib-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello, I've got 2 question regarding draft-nadeau-mpls-lc-if-mib-00: 1. The object mplsLcAtmVcMerge (from its description) is indicating ATM VC Merge capability of the LC-ATM interface, and is somewhat independent from the VC-Merge LDP configuration in mplsLdpEntityAtmMergeCap (MPLS-LDP-ATM-MIB). Similarly, the mplsLdpEntityAtmLsrConnectivity (MPLS-LDP-ATM-MIB) is specifying the LDP Connectivity configuration for LC-ATM (direct vs. indirect) but the connectivity can also be a property of LC-ATMs. Would it make sense to include an mplsLcAtmConnectivity object in mplsLcAtmIfConfEntry (MPLS-LC-ATM-MIB) to account for direct vs. indirect LC-ATM interfaces? 2. Would it be useful to include ATM OAM cell generation/looping in the control/unlabeled_traffic PVCs? That can include capability (of generating/looping OAM cells), status (ON/OFF), timers (frequency/retry) and counters (retry). Thanks, --Carlos. ================================================================= | Carlos Pignataro - CCIE 4619 cisco Systems, Inc. | Escalation RTP | cpignata@cisco.com || || | +1 919 392 7428 - office .||. .||. | +1 919 345 3028 - mobile .||||. .||||. | +1 919 392 6470 - fax .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 Are you Ready ? | Research Triangle Park, NC 27709 ================================================================= From owner-mpls@UU.NET Mon Feb 3 16:48:14 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22819 for ; Mon, 3 Feb 2003 16:48:14 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoamp25796 for ; Mon, 3 Feb 2003 21:51:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoamp25535; Mon, 3 Feb 2003 21:51:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQoamp15521 for mpls-outgoing; Mon, 3 Feb 2003 21:51:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoamp15516 for ; Mon, 3 Feb 2003 21:51:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoamp15913 for ; Mon, 3 Feb 2003 21:50:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoamp03950 for ; Mon, 3 Feb 2003 21:50:31 GMT Received: from mailc.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailc.telia.com [194.22.190.4]) id QQoamp03929 for ; Mon, 3 Feb 2003 21:50:30 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailc.telia.com (8.12.5/8.12.5) with ESMTP id h13LoOGq026240; Mon, 3 Feb 2003 22:50:24 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h13LoN205857; Mon, 3 Feb 2003 22:50:24 +0100 (CET) Message-ID: <3E3EE35A.8090807@pi.se> Date: Mon, 03 Feb 2003 22:47:06 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS WG CC: George Swallow Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003)] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, the included mail, from the Internet Drafts administrator, gives the cut off dates for the San Francisco meeting. Note: That it is not only important to meet cut off dates, it is also important to notice that time allocated on the working group agenda is NOT for presenting a draft, BUT for discussing the un-solved technical issues or issues where there are diverging opinions with that particular draft. Discussion on the working group mailing list is therefore a prerequisite for getting time on the agenda. When discussing issues with your draft at the meeting, plan it so that there are time for other members of the working group to participate in the discussion. Loa and George ----------------------- include mail --------------------------------- NOTE: There are two (2) Internet-Draft Cutoff dates February 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, February 24th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, February 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of February 24th will NOT be accepted. March 3rd: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, March 3rd, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_56.html From owner-mpls@UU.NET Mon Feb 3 17:18:49 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23656 for ; Mon, 3 Feb 2003 17:18:48 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoamr04179 for ; Mon, 3 Feb 2003 22:22:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoamr04005; Mon, 3 Feb 2003 22:22:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQoamr06367 for mpls-outgoing; Mon, 3 Feb 2003 22:21:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoamr06354 for ; Mon, 3 Feb 2003 22:21:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoamr15701 for ; Mon, 3 Feb 2003 22:19:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoamr01504 for ; Mon, 3 Feb 2003 22:19:15 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQoamr01500 for ; Mon, 3 Feb 2003 22:19:15 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h13MJDQ15589 for ; Mon, 3 Feb 2003 17:19:13 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 23:19:12 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155D6C3D1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Ina Minei , mpls@UU.NET Subject: RE: Question on draft-ietf-mpls-tc-mib Date: Mon, 3 Feb 2003 23:19:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Nope... it still needs another revision, probably another WG last call, then IETF Last Call, then goes to RFC-Editor queue and then gets an assignment. Several months before we get there I suspect. In the meantime, you might use a branch under your enterprise OID tree. Thanks, Bert > -----Original Message----- > From: Ina Minei [mailto:ina@juniper.net] > Sent: maandag 3 februari 2003 20:10 > To: mpls@UU.NET > Subject: Question on draft-ietf-mpls-tc-mib > > > > Has the object iddentifier for the mplsMIB been > assigned yet? Are > there any guidelines on what implementors should use in the meantime? > > Thank you, > > Ina Minei > From owner-mpls@UU.NET Mon Feb 3 19:35:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26098 for ; Mon, 3 Feb 2003 19:35:33 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoana02168 for ; Tue, 4 Feb 2003 00:39:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoana02018; Tue, 4 Feb 2003 00:39:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQoana23148 for mpls-outgoing; Tue, 4 Feb 2003 00:38:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoana23141 for ; Tue, 4 Feb 2003 00:38:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoana21474 for ; Tue, 4 Feb 2003 00:37:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoana00909 for ; Tue, 4 Feb 2003 00:37:40 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQoana00887 for ; Tue, 4 Feb 2003 00:37:40 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h140bcS46248; Mon, 3 Feb 2003 16:37:38 -0800 (PST) (envelope-from ina@juniper.net) Date: Mon, 3 Feb 2003 16:37:38 -0800 (PST) From: Ina Minei To: "Wijnen, Bert (Bert)" cc: Subject: RE: Question on draft-ietf-mpls-tc-mib In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155D6C3D1@nl0006exch001u.nl.lucent.com> Message-ID: <20030203155535.C19480-100000@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello Bert, Thank you for the quick reply. Indeed, using the enterprise OID tree could be a solution. However, it's been pointed out to me that in the past the experimental branch was used in similar situations. The use of the experimental branch is good because it provides uniformity for the early implementations, and also because it is well understood that this is a temporary location. Letting each vendor use its enterprise OID tree places a burden on both the users and the vendors. Using the experimental branch was the solution adopted for the mroute mib for example. When the mib became an rfc, the mib was moved from the experimental branch. Would the authors of the mib comment on adopting the same approach in this case? Thank you, Ina On Mon, 3 Feb 2003, Wijnen, Bert (Bert) wrote: > Nope... it still needs another revision, probably another > WG last call, then IETF Last Call, then goes to RFC-Editor > queue and then gets an assignment. Several months before we > get there I suspect. > > In the meantime, you might use a branch under your enterprise > OID tree. > > Thanks, > Bert > > > -----Original Message----- > > From: Ina Minei [mailto:ina@juniper.net] > > Sent: maandag 3 februari 2003 20:10 > > To: mpls@UU.NET > > Subject: Question on draft-ietf-mpls-tc-mib > > > > > > > > Has the object iddentifier for the mplsMIB been > > assigned yet? Are > > there any guidelines on what implementors should use in the meantime? > > > > Thank you, > > > > Ina Minei > > > From owner-mpls@UU.NET Wed Feb 5 19:03:01 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16102 for ; Wed, 5 Feb 2003 19:03:00 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoaui21101 for ; Thu, 6 Feb 2003 00:06:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoaui20955; Thu, 6 Feb 2003 00:06:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQoaui06245 for mpls-outgoing; Thu, 6 Feb 2003 00:06:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoaui06021 for ; Thu, 6 Feb 2003 00:05:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoaui08978 for ; Thu, 6 Feb 2003 00:03:48 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoaui27292 for ; Thu, 6 Feb 2003 00:03:48 GMT Received: from maynard.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maynard.mail.mindspring.net [207.69.200.243]) id QQoaui27283 for ; Thu, 6 Feb 2003 00:03:48 GMT Received: from [192.168.167.43] (helo=wamui05.slb.atl.earthlink.net) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 18gZW4-0002c0-00; Wed, 05 Feb 2003 19:03:44 -0500 Received: from [192.168.167.58] by EarthlinkWAM via HTTP; Wed Feb 05 19:03:44 EST 2003 Message-ID: <5546843.1044489824884.JavaMail.nobody@wamui05.slb.atl.earthlink.net> Date: Wed, 5 Feb 2003 19:08:49 -0500 (EST) To: Ina Minei , "Wijnen, Bert (Bert)" Subject: Re: RE: Question on draft-ietf-mpls-tc-mib Cc: mpls@UU.NET, jcucchiara@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Web Access Mail version 3.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ina, Speaking as the co-author that is updating this MIB, can confirm that we have no plans to request an experimental number for this draft. -Joan -------Original Message------- From: Ina Minei Sent: 02/03/03 07:37 PM To: "Wijnen, Bert (Bert)" Subject: RE: Question on draft-ietf-mpls-tc-mib > > Hello Bert, Thank you for the quick reply. Indeed, using the enterprise OID tree could be a solution. However, it's been pointed out to me that in the past the experimental branch was used in similar situations. The use of the experimental branch is good because it provides uniformity for the early implementations, and also because it is well understood that this is a temporary location. Letting each vendor use its enterprise OID tree places a burden on both the users and the vendors. Using the experimental branch was the solution adopted for the mroute mib for example. When the mib became an rfc, the mib was moved from the experimental branch. Would the authors of the mib comment on adopting the same approach in this case? Thank you, Ina On Mon, 3 Feb 2003, Wijnen, Bert (Bert) wrote: > Nope... it still needs another revision, probably another > WG last call, then IETF Last Call, then goes to RFC-Editor > queue and then gets an assignment. Several months before we > get there I suspect. > > In the meantime, you might use a branch under your enterprise > OID tree. > > Thanks, > Bert > > > -----Original Message----- > > From: Ina Minei [mailto:ina@juniper.net] > > Sent: maandag 3 februari 2003 20:10 > > To: mpls@UU.NET > > Subject: Question on draft-ietf-mpls-tc-mib > > > > > > > > Has the object iddentifier for the mplsMIB been > > assigned yet? Are > > there any guidelines on what implementors should use in the meantime? > > > > Thank you, > > > > Ina Minei > > > > From owner-mpls@UU.NET Thu Feb 6 09:19:26 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18512 for ; Thu, 6 Feb 2003 09:19:25 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoawn16177 for ; Thu, 6 Feb 2003 14:22:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoawn16046; Thu, 6 Feb 2003 14:22:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQoawn25154 for mpls-outgoing; Thu, 6 Feb 2003 14:22:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoawn25149 for ; Thu, 6 Feb 2003 14:22:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoawn00504 for ; Thu, 6 Feb 2003 14:22:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoawn17302 for ; Thu, 6 Feb 2003 14:22:03 GMT Received: from smtpgw6.sprintspectrum.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtpgw6.sprintspectrum.com [207.40.188.14]) id QQoawn17298 for ; Thu, 6 Feb 2003 14:22:03 GMT Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw6.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id h16EM2822901 for ; Thu, 6 Feb 2003 08:22:02 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2654.89) id <1GFJJAP6>; Thu, 6 Feb 2003 08:22:00 -0600 Message-ID: <2BFC9CF478B9744B8F79303CAA4C75E1384F3C@PKDWB02C.ad.sprint.com> From: "Nagarajan, Ananth [GMG]" To: "'mpls@UU.NET'" Subject: IPOM 2003 : CFP: IEEE Workshop on IP Operations & Management Date: Thu, 6 Feb 2003 08:21:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk * Apologies if you receive multiple copies of this announcement and apologies to those who think this is abuse of the list. This is a not-for-profit workshop, with no corporate sponsorship, and this announcement is being sent as information for those that may be interested in participating/contributing * IPOM 2003: CALL FOR PAPERS 2003 IEEE Workshop on IP Operations and Management Kansas City, Missouri October 1-3, 2003 Web-site: http://conrel.sice.umkc.edu/ipom2003/ The 3rd Workshop on IP Operations and Management (IPOM 2003) will be held in Kansas City, Missouri. This workshop will include presentations based on original research in the area of Operations and Management of IP Networks, spanning from current to future infrastructure. Several Tutorials and panels will also be included as part of this workshop. The intent of the workshop is to bring together researchers and practitioners from academia and industry to address current and future issues that face operations and management of IP-oriented networks. Original papers are invited in the following areas (but not limited to): - Network Monitoring and Measurement of IP networks - Day-to-Day Operations of IP networks - Traffic Modeling, Analysis and Engineering for IP networks - Network Planning and Design - Intra-/Inter-Domain Routing Policy Issues and Management - SNMP - Interworking Operations and Management of IP over SONET/SDH or WDM networks - Security Management in IP Networks - Complexity Issues in Large-Scale IP Network Management - Wireless IP network deployment and Management Issues - Management Complexity of IPv4 and IPv6 interworking - IPv4-to-IPv6 transition/migration process - Managed Services on IP networks (e.g., IP-VPN, QoS, VoIP) - Enterprise IP network Management - Grid Management - Case Studies Paper Submission Deadline: March 31, 2003. Notification of Acceptance: June 15, 2003. Final Versions Due: July 15, 2003. Submission Guideline: Full papers should be submitted electronically either in PDF, or Microsoft Word format. Submissions should be limited to 7 pages (standard double-column IEEE conference format). Instructions on format can be found from IPOM2003 web-site. All papers will be peer-reviewed. All paper submission will be handled through the EDAS system (http://edas.info). General Chair: G.-S. Kuo, gskuo@ieee.org National Chengchi University, Taiwan Technical Program Chair: Deep Medhi, dmedhi@umkc.edu, University of Missouri-Kansas City, USA Publicity Chair: Ananth Nagarajan, ananth.nagarajan@mail.sprint.com, Sprint Corporation Treasurer: Cory Beard, University of Missouri-Kansas City, USA Local Arrangement: Appie van de Liefvoort, Univeristy of Missouri-Kansas City, USA Technical Program Committee: Nail Akar, Bilkent University, Turkey Mario Baldi, Politecnico di Torino, Italy Supratik Bhattacharya, Sprint ATL Labs, USA Marcus Brunner, NEC Europe Ltd., Germany Tom Chen, Southern Methodist University, USA Willie Donnelly, Waterford Institute of Technology, Ireland Bob Doverspike, AT&T Research Lab, USA Nick Duffield, AT&T Research Lab, USA Michael Eder, Nokia Research, USA Cynthia Hood, Illinois Institute of Technology, USA Chuanyi Ji, Georgia Institute of Technology, USA Manu Malek, Stevens Institute of Technology, USA Ken Mitchell, University of Missouri-Kansas City, USA Sid Nag, IRTF Service Management Group, USA George Pavlou, University of Surrey, UK Michal Pioro, Warsaw University of Technology, Poland & Lund University, Sweden Iraj Saniee, Bell Labs -- Lucent Technologies, USA Martin Stiemerling, NEC Europe Ltd., Germany Carlos Becker Westphall, Federal University of Santa Catarina, Brazil Juha Wiljakka, Nokia, Finland ======================= From owner-mpls@UU.NET Thu Feb 6 10:40:53 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22721 for ; Thu, 6 Feb 2003 10:40:53 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoaws27854 for ; Thu, 6 Feb 2003 15:44:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoaws27639; Thu, 6 Feb 2003 15:44:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQoaws19425 for mpls-outgoing; Thu, 6 Feb 2003 15:44:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoaws19417 for ; Thu, 6 Feb 2003 15:43:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoaws10338 for ; Thu, 6 Feb 2003 15:43:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoaws26541 for ; Thu, 6 Feb 2003 15:43:03 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQoaws26525 for ; Thu, 6 Feb 2003 15:43:03 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16Fhtdv002239 for ; Thu, 6 Feb 2003 10:43:55 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA07593 for ; Thu, 6 Feb 2003 10:43:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h16Fh1e05373 for mpls@uu.net; Thu, 6 Feb 2003 10:43:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoaws19215 for ; Thu, 6 Feb 2003 15:41:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoaws15553 for ; Thu, 6 Feb 2003 15:41:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoaws24981 for ; Thu, 6 Feb 2003 15:41:20 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQoaws24970 for ; Thu, 6 Feb 2003 15:41:20 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16Fg839001997; Thu, 6 Feb 2003 10:42:09 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-27.cisco.com [10.86.242.27]) by bucket.cisco.com (Mirapoint) with ESMTP id ACN70310; Thu, 6 Feb 2003 10:41:13 -0500 (EST) Message-Id: <5.2.0.9.2.20030206104044.05976830@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 06 Feb 2003 10:41:08 -0500 To: jcucchiara@mindspring.com From: "Thomas D. Nadeau" Subject: Re: RE: Question on draft-ietf-mpls-tc-mib Cc: Ina Minei , "Wijnen, Bert (Bert)" , mpls@UU.NET, jcucchiara@mindspring.com In-Reply-To: <5546843.1044489824884.JavaMail.nobody@wamui05.slb.atl.eart hlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Joan is correct. The draft will shortly have a real number, so there is no need to cut a draft just to have an experimental number. --Tom >Hi Ina, > >Speaking as the co-author that is updating >this MIB, can confirm that we have no plans >to request an experimental number >for this draft. > > -Joan > >-------Original Message------- >From: Ina Minei >Sent: 02/03/03 07:37 PM >To: "Wijnen, Bert (Bert)" >Subject: RE: Question on draft-ietf-mpls-tc-mib > > > > > > Hello Bert, > > Thank you for the quick reply. Indeed, using the enterprise OID >tree could be a solution. > > However, it's been pointed out to me that in the past the >experimental branch was used in similar situations. > The use of the experimental branch is good because it provides >uniformity for the early implementations, and also because it is well >understood that this is a temporary location. Letting each vendor use >its enterprise OID tree places a burden on both the users and the >vendors. > Using the experimental branch was the solution adopted for >the mroute mib for example. When the mib became an rfc, the mib was moved >from the experimental branch. > > Would the authors of the mib comment on adopting the same approach >in this case? > > > > > Thank you, > > Ina > >On Mon, 3 Feb 2003, Wijnen, Bert (Bert) wrote: > > > Nope... it still needs another revision, probably another > > WG last call, then IETF Last Call, then goes to RFC-Editor > > queue and then gets an assignment. Several months before we > > get there I suspect. > > > > In the meantime, you might use a branch under your enterprise > > OID tree. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Ina Minei [mailto:ina@juniper.net] > > > Sent: maandag 3 februari 2003 20:10 > > > To: mpls@UU.NET > > > Subject: Question on draft-ietf-mpls-tc-mib > > > > > > > > > > > > Has the object iddentifier for the mplsMIB been > > > assigned yet? Are > > > there any guidelines on what implementors should use in the meantime? > > > > > > Thank you, > > > > > > Ina Minei > > > > > > > > > "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X From owner-mpls@UU.NET Thu Feb 6 11:58:12 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25718 for ; Thu, 6 Feb 2003 11:58:11 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoawy26225 for ; Thu, 6 Feb 2003 17:01:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoawy25903; Thu, 6 Feb 2003 17:01:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQoawy20811 for mpls-outgoing; Thu, 6 Feb 2003 17:01:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoawy19362 for ; Thu, 6 Feb 2003 17:00:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoawy22909 for ; Thu, 6 Feb 2003 17:00:27 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoawy16848 for ; Thu, 6 Feb 2003 17:00:27 GMT Received: from mta8.wss.scd.yahoo.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mta8.wss.scd.yahoo.com [66.218.85.39]) id QQoawy16840 for ; Thu, 6 Feb 2003 17:00:26 GMT Received: from [65.213.193.49] by mta8.wss.scd.yahoo.com with HTTP; Thu, 6 Feb 2003 09:00:22 -0800 Date: Thu, 6 Feb 2003 12:00:22 -0500 Message-ID: <3E3AE1880000677D@mta8.wss.scd.yahoo.com> From: "Kavita Khanna" Subject: MPLS 2003: October 26-28, 2003; Washington DC To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25718 Dear friends, We are delighted to inform you that MPLS 2003 - the 6th Annual International Conference on MPLS will be held in Washington DC, October 26-28, 2003. The conference begins with tutorial sessions on Sunday, October 26 and continues with full-day technical sessions on Monday and Tuesday, October 27 and 28. A series of public Interoperability demonstrations will follow on October 29. Conference information, technical program, and other details, including the testing and public interoperability events are being made available at: http://www.mpls2003.com The topics and the technical program for MPLS 2003 will be selected by the Technical Program Committee of the conference. The TPC will solicit presentations, based on the topics discussed by the committee, from experts in the selected areas and will invite them for presentation at MPLS 2003. If you wish to bring out a particular topic or a contribution to the attention of the Technical Program Committee, please send your request to tpc@MPLS2003.com Thanks. - Kavita From owner-mpls@UU.NET Thu Feb 6 15:26:17 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03002 for ; Thu, 6 Feb 2003 15:26:16 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoaxl19984 for ; Thu, 6 Feb 2003 20:29:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoaxl19794; Thu, 6 Feb 2003 20:29:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQoaxl12874 for mpls-outgoing; Thu, 6 Feb 2003 20:29:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoaxl12867 for ; Thu, 6 Feb 2003 20:29:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoaxl23706 for ; Thu, 6 Feb 2003 20:29:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoaxl26521 for ; Thu, 6 Feb 2003 20:29:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQoaxl26515 for ; Thu, 6 Feb 2003 20:29:06 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16KTwBM017281 for ; Thu, 6 Feb 2003 15:29:58 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA02416 for ; Thu, 6 Feb 2003 15:29:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h16KT4D21454 for mpls@uu.net; Thu, 6 Feb 2003 15:29:04 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoaxl12848 for ; Thu, 6 Feb 2003 20:28:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoaxl09278 for ; Thu, 6 Feb 2003 20:27:39 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoaxl25510 for ; Thu, 6 Feb 2003 20:27:38 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQoaxl25506 for ; Thu, 6 Feb 2003 20:27:38 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02928; Thu, 6 Feb 2003 15:23:57 -0500 (EST) Message-Id: <200302062023.PAA02928@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-meyer-mpls-soft-preemption-00.txt Date: Thu, 06 Feb 2003 15:23:57 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS Traffic Engineering Soft preemption Author(s) : M. Meyer, D. Maddux, J. Vasseur Filename : draft-meyer-mpls-soft-preemption-00.txt Pages : 9 Date : 2003-2-5 This draft documents MPLS TE Soft Preemption, a suite of protocol modifications extending the current concept of preemption with the goal of reducing/eliminating traffic disruption of preempted TE LSPs. Under present RSVP-TE signaling methods, LSPs are immediately displaced upon preemption. The introduction of a new preemption pending flag helps more gracefully mitigate the re-route process of displaced LSPs. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect overbooked until the LSP can be re-routed. For this reason, the feature is primarily interesting in packet oriented MPLS networks with Diffserv and TE capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-meyer-mpls-soft-preemption-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-meyer-mpls-soft-preemption-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-meyer-mpls-soft-preemption-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-6154150.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-meyer-mpls-soft-preemption-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-meyer-mpls-soft-preemption-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-6154150.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Feb 6 21:51:14 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13479 for ; Thu, 6 Feb 2003 21:51:14 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoayl15858 for ; Fri, 7 Feb 2003 02:54:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoayl15700; Fri, 7 Feb 2003 02:54:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQoayl01216 for mpls-outgoing; Fri, 7 Feb 2003 02:54:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoayl01211 for ; Fri, 7 Feb 2003 02:54:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoayl10382 for ; Fri, 7 Feb 2003 02:52:06 GMT From: hyryu@etri.re.kr Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoayl28008 for ; Fri, 7 Feb 2003 02:52:06 GMT Received: from cms1.etri.re.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cms1.etri.re.kr [129.254.16.11]) id QQoayl27990 for ; Fri, 7 Feb 2003 02:52:04 GMT Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id <13MDDW5H>; Fri, 7 Feb 2003 11:49:41 +0900 Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC08347A1C@cms1.etri.re.kr> To: mpls@UU.NET Subject: discriminate ping & traceroute Date: Fri, 7 Feb 2003 11:03:55 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CE4D.2B6BE490" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CE4D.2B6BE490 Content-Type: text/plain; charset="euc-kr" Hi ! I have some question for ping and traceroute in draft "Detecting MPLS Data Plane Liveness". In draft, ping ICMP Message should reach the end of the path(Egress LSR). Ping Message is sent to the control plane of the egress LSR. And, Traceroute ICMP Message is sent to the control plane of each transit LSR. If yes, How could I discriminate between two messages at each transit LSR ? Best Regards Ryu Ho Yong. Internet Department Technology Netwrok Labratory Electronics & Telecommunications Research Institue (ETRI) ------_=_NextPart_001_01C2CE4D.2B6BE490 Content-Type: text/html; charset="euc-kr" discriminate ping & traceroute

Hi !
 
I have some question for ping and traceroute in draft "Detecting MPLS Data Plane Liveness".
 
In draft, ping ICMP Message should reach the end of the path(Egress LSR).
 
Ping Message is sent to the control plane of the egress LSR.
 
And, Traceroute ICMP Message is sent to the control plane of each transit LSR.
 
If yes, How could I discriminate between two messages at each transit LSR ?
 
Best Regards
 
Ryu Ho Yong.
Internet Department Technology
Netwrok Labratory
Electronics & Telecommunications Research Institue (ETRI)

------_=_NextPart_001_01C2CE4D.2B6BE490-- From owner-mpls@UU.NET Thu Feb 6 22:17:49 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14097 for ; Thu, 6 Feb 2003 22:17:49 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoayn12569 for ; Fri, 7 Feb 2003 03:21:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoayn06086; Fri, 7 Feb 2003 03:17:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQoayn21684 for mpls-outgoing; Fri, 7 Feb 2003 03:17:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoayn21674 for ; Fri, 7 Feb 2003 03:17:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoayn00298 for ; Fri, 7 Feb 2003 03:15:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoayn04066 for ; Fri, 7 Feb 2003 03:15:27 GMT Received: from cms1.etri.re.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cms1.etri.re.kr [129.254.16.11]) id QQoayn04058 for ; Fri, 7 Feb 2003 03:15:26 GMT Received: from etrievebw7kr3n (hyryu3.etri.re.kr [129.254.171.123]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 13MDDZWC; Fri, 7 Feb 2003 12:15:46 +0900 Message-ID: <003401c2ce56$bd24f3a0$7babfe81@etrievebw7kr3n> From: =?ks_c_5601-1987?B?t/nIo7/r?= To: Subject: discriminate ping and traceroute Date: Fri, 7 Feb 2003 12:12:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C2CEA2.2735B450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C2CEA2.2735B450 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgIQ0KDQpJIGhhdmUgc29tZSBxdWVzdGlvbiBmb3IgcGluZyBhbmQgdHJhY2Vyb3V0ZSBpbiBk cmFmdCAiRGV0ZWN0aW5nIE1QTFMgRGF0YSBQbGFuZSBMaXZlbmVzcyIuDQoNCkluIGRyYWZ0LCBw aW5nIElDTVAgTWVzc2FnZSBzaG91bGQgcmVhY2ggdGhlIGVuZCBvZiB0aGUgcGF0aChFZ3Jlc3Mg TFNSKS4gDQoNClBpbmcgTWVzc2FnZSBpcyBzZW50IHRvIHRoZSBjb250cm9sIHBsYW5lIG9mIHRo ZSBlZ3Jlc3MgTFNSLiANCg0KQW5kLCBUcmFjZXJvdXRlIElDTVAgTWVzc2FnZSBpcyBzZW50IHRv IHRoZSBjb250cm9sIHBsYW5lIG9mIGVhY2ggdHJhbnNpdCBMU1IuDQoNCklmIHllcywgSG93IGNv dWxkIEkgZGlzY3JpbWluYXRlIGJldHdlZW4gdHdvIG1lc3NhZ2VzIGF0IGVhY2ggdHJhbnNpdCBM U1IgPw0KDQpCZXN0IFJlZ2FyZHMgDQoNClJ5dSBIbyBZb25nLg0KDQoNCg0KSU5URVJORVQgRGVw YXJ0bWVudCBUZWNobm9sb2d5Lg0KDQpOZXR3b3JrIExhYnJhdG9yeS4NCg0KRVRSSS4gKEtPUkVB KQ0KDQogDQoNCg== ------=_NextPart_000_0031_01C2CEA2.2735B450 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjM1MDIuNTM5MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPFA+PEZP TlQgc2l6ZT0tMT5IaSAhPC9GT05UPjwvUD4NCjxQPjxGT05UIHNpemU9LTE+SSBoYXZlIHNvbWUg cXVlc3Rpb24gZm9yIHBpbmcgYW5kIHRyYWNlcm91dGUgaW4gZHJhZnQgDQoiRGV0ZWN0aW5nIE1Q TFMgRGF0YSBQbGFuZSBMaXZlbmVzcyIuPC9GT05UPjwvUD4NCjxQPjxGT05UIHNpemU9LTE+SW4g ZHJhZnQsIHBpbmcgSUNNUCBNZXNzYWdlIHNob3VsZCByZWFjaCB0aGUgZW5kIG9mIHRoZSANCnBh dGgoRWdyZXNzIExTUikuIDwvRk9OVD48L1A+DQo8UD48Rk9OVCBzaXplPS0xPlBpbmcgTWVzc2Fn ZSBpcyBzZW50IHRvIHRoZSBjb250cm9sIHBsYW5lIG9mIHRoZSBlZ3Jlc3MgTFNSLiANCjwvRk9O VD48L1A+DQo8UD48Rk9OVCBzaXplPS0xPkFuZCwgVHJhY2Vyb3V0ZSBJQ01QIE1lc3NhZ2UgaXMg c2VudCB0byB0aGUgY29udHJvbCBwbGFuZSBvZiANCmVhY2ggdHJhbnNpdCBMU1IuPC9GT05UPjwv UD4NCjxQPjxGT05UIHNpemU9LTE+SWYgeWVzLCBIb3cgY291bGQgSSBkaXNjcmltaW5hdGUgYmV0 d2VlbiB0d28gbWVzc2FnZXMgYXQgZWFjaCANCnRyYW5zaXQgTFNSID88L0ZPTlQ+PC9QPg0KPFA+ PEZPTlQgc2l6ZT0tMT5CZXN0IFJlZ2FyZHMgPC9GT05UPjwvUD4NCjxQPjxGT05UIHNpemU9LTE+ Unl1IEhvJm5ic3A7WW9uZy48L0ZPTlQ+PC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+SU5URVJORVQg RGVwYXJ0bWVudCBUZWNobm9sb2d5LjwvUD4NCjxQPk5ldHdvcmsgTGFicmF0b3J5LjwvUD4NCjxQ PkVUUkkuIChLT1JFQSk8L1A+DQo8UD4mbmJzcDs8L1A+PC9GT05UPjwvRElWPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_0031_01C2CEA2.2735B450-- From owner-mpls@UU.NET Fri Feb 7 15:45:36 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21226 for ; Fri, 7 Feb 2003 15:45:36 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobbf12382 for ; Fri, 7 Feb 2003 20:49:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobbf12169; Fri, 7 Feb 2003 20:49:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQobbf25533 for mpls-outgoing; Fri, 7 Feb 2003 20:48:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQobbf25524 for ; Fri, 7 Feb 2003 20:48:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQobbf05689 for ; Fri, 7 Feb 2003 20:45:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobbf23441 for ; Fri, 7 Feb 2003 20:45:57 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQobbf23423 for ; Fri, 7 Feb 2003 20:45:56 GMT Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h17Kkj5q010747 for ; Fri, 7 Feb 2003 15:46:45 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03324 for ; Fri, 7 Feb 2003 15:45:51 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h17KjpV26245 for mpls@uu.net; Fri, 7 Feb 2003 15:45:51 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQobas16504 for ; Fri, 7 Feb 2003 17:30:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQobar14382 for ; Fri, 7 Feb 2003 17:27:17 GMT From: mld@horizon.dk Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobar03260 for ; Fri, 7 Feb 2003 17:27:17 GMT Received: from mail.2t.dk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.150.60.145]) id QQobar03247 for ; Fri, 7 Feb 2003 17:27:16 GMT Received: by TILDE with Internet Mail Service (5.5.2656.59) id <13ZAP7MY>; Fri, 7 Feb 2003 18:26:00 +0100 Message-ID: To: hyryu@etri.re.kr Cc: mpls@UU.NET Subject: Re: discriminate ping & traceroute Date: Fri, 7 Feb 2003 18:25:58 +0100 X-Mailer: Internet Mail Service (5.5.2656.59) Sender: owner-mpls@UU.NET Precedence: bulk Hi, well I have not read the spec in detail but ip workes like this ping is a aplication that uses a icmp echo-request and will get a icmp echo-reply back TTL will always be valid ie a non zero value in the ip header for traceroute the outgoing packet could be a lot of different kind traditionaly its a udp packet but it could be icmp echo-request to (microsoft is doing this, they just have to do it in a different way) the important thing for a traceroute packet is that it always has a TTL value of zero, when you should respond to it and traceroute will usualy get a icpm destination unreachable back with sub-code of TTL-exeded in transit since the packet is droped due to TTL value is zero ps i hope you remember how traceroute work. /micke At 11:03 2003-02-07 +0900, you wrote: Hi ! I have some question for ping and traceroute in draft "Detecting MPLS Data Plane Liveness". In draft, ping ICMP Message should reach the end of the path(Egress LSR). Ping Message is sent to the control plane of the egress LSR. And, Traceroute ICMP Message is sent to the control plane of each transit LSR. If yes, How could I discriminate between two messages at each transit LSR ? Best Regards Ryu Ho Yong. Internet Department Technology Netwrok Labratory Electronics & Telecommunications Research Institue (ETRI) From owner-mpls@UU.NET Fri Feb 7 16:34:13 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22100 for ; Fri, 7 Feb 2003 16:34:13 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobbi19034 for ; Fri, 7 Feb 2003 21:37:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobbi18556; Fri, 7 Feb 2003 21:37:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQobbi17816 for mpls-outgoing; Fri, 7 Feb 2003 21:37:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQobbi17811 for ; Fri, 7 Feb 2003 21:37:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQobbi11338 for ; Fri, 7 Feb 2003 21:35:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobbi15644 for ; Fri, 7 Feb 2003 21:35:45 GMT Received: from motgate.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate.mot.com [129.188.136.100]) id QQobbi15635 for ; Fri, 7 Feb 2003 21:35:45 GMT Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h17LZb0J000766 for ; Fri, 7 Feb 2003 14:35:45 -0700 (MST) Received: [from ma19exm01.e2.bcs.mot.com (ma19exm01.e2.bcs.mot.com [10.14.8.10]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA03214 for ; Fri, 7 Feb 2003 14:35:37 -0700 (MST)] Received: by ma19exm01.e2.bcs.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Feb 2003 16:34:51 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF2381FCA2D3@ma19exm01.e2.bcs.mot.com> From: Konar Allan-MGIA0525 To: mpls@UU.NET Subject: RE: discriminate ping & traceroute Date: Fri, 7 Feb 2003 16:34:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk In most Unix platforms, this is done using a UDP message (nowadays), but, traditionally, it was all icmp. Ping is usually implemented using the Internet Control Message Protocol (ICMP) ECHO facility. It is also possible to implement a ping capability using alternate methods, some popular implementations of which are: - Using the UDP echo port (7), if supported. This is defined by RFC 862 - Timing an SNMP query - Timing a TCP connect attempt More explicitly, traceroute will send an icmp echo to the destination address with a ttl of one, so that when it transits the next hop, the ttl is decremented and a ttl exceeded is sent. Then sending host then sends the next icmp echo with a ttl of one and two hops later, it is returned with ttl exceeded. This is continued (incrementing the sending ttl) until it reaches the destination, at which point we get the final response and can display the full path (and min/max/average response times). In general, almost any request/response flow can be used to generate a round-trip time. Often many of the non-ICMP ECHO facility methods stand a better chance of yielding a good response (not timing out for example) since some routers don't honor Echo Requests (timeout situation) or they are handled at lower (or higher) priority, hence possibly giving false indications of round trip times. In the Unix world, Traceroute is usually implemented by transmitting a series of probe packets with increasing time-to-live values. A probe packet is a UDP datagram encapsulated into an IP packet. Traceroute works by sending a sequence of User Datagram Protocol (UDP) datagrams to an invalid port address at the remote host. Using the default settings, three datagrams are sent, each with a Time-To-Live (TTL) field value set to one. The TTL value of 1 causes the datagram to timeout as soon as it hits the first router in the path; this router will then respond with an ICMP Time Exceeded Message (TEM) indicating that the datagram has expired. Another three UDP messages are now sent, each with the TTL value set to 2, which causes the second router to return ICMP TEMs. This process continues until the packets actually reach the other destination. Since these datagrams are trying to access an invalid port at the destination host, ICMP Destination Unreachable Messages are returned indicating an unreachable port; this event signals the Traceroute program that it is finished and can display the round-trip delay associated with each of the attempts (min/max/average). As to the original question, I guess I'm missing the gist of what's being asked...but, if I'm interpreting it correctly, the question is how will the transit LSRs be able to differentiate between MPLS Traceroutes and Pings - and from what I can gather from the "Detecting MPLS Data Plane Liveness" draft, there is no difference between the two types of messages--specifically, the Traceroute mechanism will mimic the standard IP Traceroute mechanisms by sending MPLS pings with incrementing TTLs. That means that when a transit LSR receives an MPLS Ping with a TTL of one, it will decrement to zero and respond to the sender, whose job it will be to send the next MPLS Ping with a TTL of two, etc. I hope this helps. Cheers, a -----Original Message----- From: mld@horizon.dk [mailto:mld@horizon.dk] Sent: Friday, February 07, 2003 12:26 PM To: hyryu@etri.re.kr Cc: mpls@UU.NET Subject: Re: discriminate ping & traceroute Hi, well I have not read the spec in detail but ip workes like this ping is a aplication that uses a icmp echo-request and will get a icmp echo-reply back TTL will always be valid ie a non zero value in the ip header for traceroute the outgoing packet could be a lot of different kind traditionaly its a udp packet but it could be icmp echo-request to (microsoft is doing this, they just have to do it in a different way) the important thing for a traceroute packet is that it always has a TTL value of zero, when you should respond to it and traceroute will usualy get a icpm destination unreachable back with sub-code of TTL-exeded in transit since the packet is droped due to TTL value is zero ps i hope you remember how traceroute work. /micke At 11:03 2003-02-07 +0900, you wrote: Hi ! I have some question for ping and traceroute in draft "Detecting MPLS Data Plane Liveness". In draft, ping ICMP Message should reach the end of the path(Egress LSR). Ping Message is sent to the control plane of the egress LSR. And, Traceroute ICMP Message is sent to the control plane of each transit LSR. If yes, How could I discriminate between two messages at each transit LSR ? Best Regards Ryu Ho Yong. Internet Department Technology Netwrok Labratory Electronics & Telecommunications Research Institue (ETRI) From owner-mpls@UU.NET Fri Feb 7 17:58:29 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24111 for ; Fri, 7 Feb 2003 17:58:29 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobbo04229 for ; Fri, 7 Feb 2003 23:02:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobbo04082; Fri, 7 Feb 2003 23:02:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQobbo22830 for mpls-outgoing; Fri, 7 Feb 2003 23:01:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQobbo22777 for ; Fri, 7 Feb 2003 23:01:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQobbo15874 for ; Fri, 7 Feb 2003 23:00:36 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobbo03139 for ; Fri, 7 Feb 2003 23:00:35 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQobbo03121 for ; Fri, 7 Feb 2003 23:00:35 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h17N0YS21792 for ; Fri, 7 Feb 2003 15:00:34 -0800 (PST) (envelope-from ina@juniper.net) Date: Fri, 7 Feb 2003 15:00:34 -0800 (PST) From: Ina Minei To: mpls@UU.NET Subject: Comments on draft-ietf-mpls-ldp-mib-09.txt Message-ID: <20030207145450.B16753@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello, Please find below a few comments on draft-ietf-mpls-ldp-mib-09.txt. Let me start by saying that moving to 4 mib modules (from version 8 to version 9 of the draft) was an excellent step, making the document much easier to read and use. Please find below a few additions to the MPLS-LDP-MIB module. 1) Authentication information ----------------------------- TCP MD5 signature is mentioned in the LDP RFC, but not in the mib. It is useful to know whether a session is authenticated or not. mplsLdpSesAuthenticationType OBJECT-TYPE SYNTAX INTEGER { none(0), md5(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "The authentication type for this session." ::= { mplsLdpSessionEntry 6 } 2) Reason for the session going down ------------------------------------ From an operator's point of view, it is useful to know the cause for a session going down. Similar functionality can be found in the bgp mib. This information could be passed in the session down trap as well, providing a powerful debugging tool for network operators. mplsLdpSesDownReason OBJECT-TYPE SYNTAX INTEGER { holdExpired (1), connectionExpired (2), allAdjacenciesDown (3), badTLV (4), badPDU (5), badPacket (6), connectionError (7), peerSentNotification (8), unexpectedEOF (9), authenticationChanged (10), initError (11), gracefulRestartAbort (12), unknown (13) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The reason why the session transitioned to nonexistent state. Can be one of the following: hold time expired, connection time expired, all adjacencies down, received bad tlv, received bad packet, connection error, received notification from peer, received unexpected end-of-file, authentication key was changed, error during initialization, graceful restart was aborted, or unknown reason." ::= {mplsLdpSessionEntry 7} 3) Additional information for hello adjacencies ----------------------------------------------- a) The mib currently provides no interface information. It is important to know which interface the hello adjacency is on. mplsLdpHelloAdjIntf OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "For a hello adjacency of type link(1), the ifIndex of the interface, for a hello adjacency of type targeted(2), the ifIndex of the loopback interface." ::= { mplsLdpHelloAdjacencyEntry 4 } b) It is useful to have the address information as well, though this can be obtained from the interface index. c) It is useful to have a timestamp of when this adjacency came up. 4) Interface information for the LDP entity ------------------------------------------- LDP is a discovery protocol. In many systems, the configuration of the protocol is done by specifying the interfaces on which the discovery should be attempted. It is not guaranteed that adjacencies will be formed on these interfaces. A table specifying for each LDP entity which interfaces it is running on, and how many adjacencies were established on each of these interfaces, would provide valuable insight for the network operator. 5) Graceful restart information ------------------------------- draft-ietf-mpls-ldp-restart-06.txt is now moving to Proposed Standard. It might be useful to include the graceful restart information at this time, in order to avoid having to add it later. The graceful restart info is: - graceful restart enabled/disabled - helper mode enabled/disabled - recovery time - max recovery time - reconnect time Some of this belongs to the entity, and some to the peer. If there is agreement on adding this information, I can write it up. 6) Additional identifier of the LDP Entity ------------------------------------------ Currently the MplsLdpIdentifier is the only identifier for an LDP Entity. This is based on the assumption that the LdpIdentifier will be unique. However, when implementing several instances with overlapping address space, this may not be true (I am thinking of the vpn case). It would be good to have an additional identifier (perhaps an integer) that can be used to differentiate between these otherwise equal entities. (otherwise things like traps will be of limited use). The linkage between this additional identifier and the instances can be done separately, but I think having the hook in now will be good for the future. 7) Summary information for LDP Entity ------------------------------------- To be able to sanity check the state of the protocol on a particular box, it is useful to have a snapshot of the state of the sessions for each ldp entity. Something along the lines: # of operational sessions, total number of sessions in all states, number of interfaces, number of neighbors. The idea is for this table to be polled at regular intervals, to make sure nothing is going wrong. (traps won't always be the key, since they can be disabled, or may not make it) Traps ===== Change in the session down trap ------------------------------- From an operator's point of view, it is useful to know the cause for a session going down. This can be passed in the trap, and would provide more information than the number of unknown messages or unknown TLVs received. mplsLdpSessionDown NOTIFICATION-TYPE OBJECTS { mplsLdpSesState, mplsLdpSesDownReason } STATUS current DESCRIPTION "If this notification is enabled to generated, then this notification is sent when the the value of 'mplsLdpSesState' leaves the 'operational(5)' state." ::= { mplsLdpNotificationPrefix 4 } Change in the session up trap ----------------------------- It was not clear to me the reason whty we send the number of unknown messages/tlv in the session up trap. Would you explain the usage? Add an adjacency-down trap ------------------------- Losing adjacencies may lead to losing a session. (though when a session is established over several adjacencies, this is not the case). In any case, a user can decide if it is beneficial for his network to track adjacencies going down anyway. It can be used to alert the operator that something went wrong in the redundant path, and his ldp session is at risk. Thank you, Ina Minei From owner-mpls@UU.NET Sun Feb 9 09:02:09 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28684 for ; Sun, 9 Feb 2003 09:02:09 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobho23286 for ; Sun, 9 Feb 2003 14:05:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobho23018; Sun, 9 Feb 2003 14:05:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQobho12912 for mpls-outgoing; Sun, 9 Feb 2003 14:05:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQobho12907 for ; Sun, 9 Feb 2003 14:05:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQobho20545 for ; Sun, 9 Feb 2003 14:04:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobho13292 for ; Sun, 9 Feb 2003 14:04:37 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe22.law9.hotmail.com [64.4.8.79]) id QQobho13288 for ; Sun, 9 Feb 2003 14:04:37 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Feb 2003 06:04:36 -0800 X-Originating-IP: [219.65.149.64] From: "john smith" To: Subject: queries on draft-ietf-mpls-lsp-hierarchy-08.txt Date: Sun, 9 Feb 2003 19:36:32 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 09 Feb 2003 14:04:36.0541 (UTC) FILETIME=[2DD9FED0:01C2D044] Sender: owner-mpls@UU.NET Precedence: bulk Hello, in the draft draft-ietf-mpls-lsp-hierarchy-08.txt can the procedure defined to establish TE-LSPs be summarized as follows: 1. An FA is a LSP treated as a Layer-2 path between 2 end points. This is treated as "link" in the OSPF/ISIS SPF algorithm with the link given its associated parameters. A LSP between 2 adjacent nodes could also be a TE LSP...an LSP between any 2 LERs could be a FA LSP...is this correct? 2. All the TE LSDB information for the entire topology (assuming a single OSPF area) computed and each node knows the "total bandwidth" avaliable per FA/TE link...is this correct? 3. each TE-LSP that is now setup with bandwidth constraints now eats away on the total bandwdith per FA/TE LSP..is this correct? 4. can the TE LSP and FA LSPs overlap..that is can multiple TE LSPs be included in 1 FA LSP..is this correct? 5. Consider a topology with multiple LERs and LSRs.....as and when bandwidth from each TE-LSP or FA-LSP is allocated to flows, how does one signal other nodes in the topology that they should use the total - reserved bandwdith for their path computation?..is this mentioned in this or any other draft? hope someone can take the time off to clarify this, -regards JS From owner-mpls@UU.NET Sun Feb 9 09:34:55 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29421 for ; Sun, 9 Feb 2003 09:34:55 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobhq16187 for ; Sun, 9 Feb 2003 14:38:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobhq16012; Sun, 9 Feb 2003 14:38:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQobhq16115 for mpls-outgoing; Sun, 9 Feb 2003 14:38:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQobhq16110 for ; Sun, 9 Feb 2003 14:37:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQobhq29515 for ; Sun, 9 Feb 2003 14:36:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobhq14741 for ; Sun, 9 Feb 2003 14:36:38 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe16.law9.hotmail.com [64.4.8.120]) id QQobhq14731 for ; Sun, 9 Feb 2003 14:36:38 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 9 Feb 2003 06:36:37 -0800 X-Originating-IP: [219.65.149.64] From: "john smith" To: Subject: Re: queries on draft-ietf-mpls-lsp-hierarchy-08.txt Date: Sun, 9 Feb 2003 20:08:33 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 09 Feb 2003 14:36:37.0722 (UTC) FILETIME=[A6F6F3A0:01C2D048] Sender: owner-mpls@UU.NET Precedence: bulk > 5. Consider a topology with multiple LERs and LSRs.....as and when bandwidth > from each TE-LSP or FA-LSP is allocated to flows, how does one signal other > nodes in the topology that they should use the total - reserved bandwdith > for their path computation?..is this mentioned in this or any other draft? > will this imply that if there are n possible ways to setup an LSP, between 2 points with given constraints, this will lead to each of the n possible paths being checked one by one till a suitable match is found.... and if the end points are p hops away, each hop having n[k] possible paths, one may end up computing sum (n[k],0; Mon, 10 Feb 2003 11:45:08 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoblr03536 for ; Mon, 10 Feb 2003 16:48:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoblr03351; Mon, 10 Feb 2003 16:48:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQoblr16174 for mpls-outgoing; Mon, 10 Feb 2003 16:48:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoblr16153 for ; Mon, 10 Feb 2003 16:47:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoblr29569 for ; Mon, 10 Feb 2003 16:47:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoblr01936 for ; Mon, 10 Feb 2003 16:47:25 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f144.pav1.hotmail.com [64.4.31.144]) id QQoblr01915 for ; Mon, 10 Feb 2003 16:47:24 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 10 Feb 2003 08:47:24 -0800 Received: from 203.124.140.97 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 10 Feb 2003 16:47:23 GMT X-Originating-IP: [203.124.140.97] From: "K 9" To: johnsmith0302@hotmail.com, mpls@UU.NET Subject: Re: queries on draft-ietf-mpls-lsp-hierarchy-08.txt Date: Mon, 10 Feb 2003 22:17:23 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Feb 2003 16:47:24.0020 (UTC) FILETIME=[1622C340:01C2D124] Sender: owner-mpls@UU.NET Precedence: bulk Hello John okie lets assume no unnumbered links..... i would use strict there.... is that a problem with you? >From: "john smith" >To: >Subject: Re: queries on draft-ietf-mpls-lsp-hierarchy-08.txt >Date: Sun, 9 Feb 2003 20:08:33 +0530 > > > 5. Consider a topology with multiple LERs and LSRs.....as and when >bandwidth > > from each TE-LSP or FA-LSP is allocated to flows, how does one signal >other > > nodes in the topology that they should use the total - reserved >bandwdith > > for their path computation?..is this mentioned in this or any other >draft? > > > > >will this imply that if there are n possible ways to setup an LSP, between >2 >points with given constraints, this will lead to each of the n possible >paths being checked one by one till a suitable match is found.... > >and if the end points are p hops away, each hop having n[k] possible paths, >one may end up computing >sum (n[k],0a >highly congested network?)? > >-JS _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-mpls@UU.NET Wed Feb 12 16:04:23 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15627 for ; Wed, 12 Feb 2003 16:04:23 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobts05989 for ; Wed, 12 Feb 2003 21:08:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobts05643; Wed, 12 Feb 2003 21:07:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQobts09861 for mpls-outgoing; Wed, 12 Feb 2003 21:07:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQobts09848 for ; Wed, 12 Feb 2003 21:07:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQobts08165 for ; Wed, 12 Feb 2003 21:05:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobts25256 for ; Wed, 12 Feb 2003 21:05:53 GMT Received: from almso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQobts25241 for ; Wed, 12 Feb 2003 21:05:53 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1CKx6Hx027696 for ; Wed, 12 Feb 2003 16:05:53 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032) id 3DF6BD4E0251682A; Wed, 12 Feb 2003 16:05:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: E2E VoIP over MPLS ('VoMPLS') Header Compression Date: Wed, 12 Feb 2003 16:05:50 -0500 Message-ID: <28F05913385EAC43AF019413F674A01704A1770F@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [PWE3] IETF 55 PWE3 Agenda Thread-Index: AcKE42oWyk7XsvD2SFmWYcpa3fPdUAAx/ZCwE0q+jwA= From: "Ash, Gerald R (Jerry), ALABS" To: "MPLS@UU.net" Cc: "Ash, Gerald R (Jerry), ALABS" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA15627 All, I'd like to propose that the MPLS WG take on work regarding VoIP over MPLS header compression. This work was earlier accepted for consideration by the MPLS WG (see the background summary below). Two I-D's related to this work are at: http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt (George is added as co-author in the next rev) http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt Please review the documents and raise any issues/comments to the list. The work was presented at the IETF-55 PWE3 WG meeting (slides and meetings notes at http://ietf.org/proceedings/02nov/index.html). It was generally agreed that the work did not fit well in PWE3, and that MPLS might be the best overall fit. I propose a brief time slot at the IETF-56 MPLS WG meeting to very briefly review the above proposals and issues, and get a sense of the room. Comments welcome Thanks, Jerry Ash Background: Some service providers (such as AT&T) have plans to migrate large amounts of legacy voice traffic to VoIP, as well as to provide VPN services enabling VoIP. VoIP over MPLS ('VoMPLS') typically uses the encapsulation voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes. VoIP over MPLS header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). VoIP over MPLS header compression methods have been proposed earlier (March, 2000) in the MPLS working group, however the relevant drafts have expired. In particular, George Swallow and Lou Berger proposed a 'simple' end-to-end compression scheme in which all first-order differences in the RTP/UDP/IP headers were transmitted, and in which the header compression context was established through RSVP signaling. The work was accepted into the MPLS WG pending an addition to the MPLS WG charter. In the I-D's we propose 3 approaches to VoMPLS header compression: a) re-use the methods in cRTP to determine the context and MPLS to route packets, b) re-use the methods in Swallow's and Berger's 'simple' approach to determine the context and MPLS to route packets, and c) re-use the methods in cRTP to determine the context and the SCID (session context ID) to route packets. Issues to discuss: 1. WG charter -- The VoMPLS header compression work is not within the current charter of the MPLS WG, so a charter extension is needed. George said he 'would have no objection to the work being done in MPLS'... but suggested that the 'work fits more closely in the Transport Area/PWE3 WG' (which is why it was brought there first). 2. Protocol extensions -- As detailed in the I-Ds, extensions are proposed to [cRTP] and [cRTP-ENHANCE], which involve a new packet type field to identify FULL_HEADER, CONTEXT_STATE, etc. packets. New objects are defined for [RSVP-TE]. Extensions are also proposed to RFC2547 VPNs, which create 'SCID routing tables' to allow routing based on the session context ID (SCID). These extensions need coordination with other WGs (MPLS, CCAMP, AVT, ROHC, PPVPN, etc.). 3. Resynchronization -- E2E VoMPLS using cRTP header compression might not perform well with frequent resynchronizations. The applicability and performance need to be addressed (the 'simple' header compression approach would avoid the need for resynchronization, but achieves less efficiency than cRTP). 4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps require a large number of LSPs to be created. There is concern for CE ability to do the necessary processing and the scalability of the architecture. 4. LDP application -- It would be desirable to signal the VoMPLS tunnels with LDP, since many RFC2547 VPN implementations use LDP as the underlying LSP signaling mechanism. From owner-mpls@UU.NET Wed Feb 12 17:18:22 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17588 for ; Wed, 12 Feb 2003 17:18:22 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobtx11590 for ; Wed, 12 Feb 2003 22:22:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobtx11378; Wed, 12 Feb 2003 22:21:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQobtx04635 for mpls-outgoing; Wed, 12 Feb 2003 22:21:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQobtx04628 for ; Wed, 12 Feb 2003 22:21:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQobtx22283 for ; Wed, 12 Feb 2003 22:21:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobtx26539 for ; Wed, 12 Feb 2003 22:21:09 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQobtx26461 for ; Wed, 12 Feb 2003 22:21:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1CML2JR013258 for ; Wed, 12 Feb 2003 17:21:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA27908 for ; Wed, 12 Feb 2003 17:21:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1CML2g20036 for mpls@uu.net; Wed, 12 Feb 2003 17:21:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQobtx04580 for ; Wed, 12 Feb 2003 22:19:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQobtx22378 for ; Wed, 12 Feb 2003 22:19:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobtx17794 for ; Wed, 12 Feb 2003 22:19:14 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQobtx17781 for ; Wed, 12 Feb 2003 22:19:13 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA42529; Wed, 12 Feb 2003 17:16:49 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302122216.RAA42529@workhorse.fictitious.org> To: "Ash, Gerald R (Jerry), ALABS" cc: "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Wed, 12 Feb 2003 16:05:50 EST." <28F05913385EAC43AF019413F674A01704A1770F@OCCLUST04EVS1.ugd.att.com> Date: Wed, 12 Feb 2003 17:16:49 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <28F05913385EAC43AF019413F674A01704A1770F@OCCLUST04EVS1.ugd.att.com> , "Ash, Gerald R (Jerry), ALABS" writes: > All, > > I'd like to propose that the MPLS WG take on work regarding VoIP over MPLS he > ader compression. This work was earlier accepted for consideration by the MP > LS WG (see the background summary below). > > Two I-D's related to this work are at: > http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt > (George is added as co-author in the next rev) > > http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt > > Please review the documents and raise any issues/comments to the list. > > The work was presented at the IETF-55 PWE3 WG meeting (slides and meetings no > tes at http://ietf.org/proceedings/02nov/index.html). It was generally agree > d that the work did not fit well in PWE3, and that MPLS might be the best ove > rall fit. > > I propose a brief time slot at the IETF-56 MPLS WG meeting to very briefly re > view the above proposals and issues, and get a sense of the room. > > Comments welcome > > Thanks, > Jerry Ash Jerry, A fix more appropriately belongs in the VoIP implementations that are putting 30 byte payloads into a lot of tiny packets for a continuous stream of relatively low bandwidth traffic rather than buffer a tiny amount of the stream and produce more reasonable payload sizes. A mere 5-10 milliseconds of buffering is imperceptible, would allow very large payloads, and would make the framing overhead quite negligible rather than just reduce it somewhat. Putting an application protocol directly over MPLS to solve an overhead problem that results from an oversight in specific implementations of that applications protocol is very poor engineering. The problem is certainly not inherent to RTP, UDP, or IP. The choice of payload formats (media encodings) may be at fault but more likely the implementation itself. Note the following in rfc1890 (page 7): All frame-oriented audio codecs should be able to encode and decode several consecutive frames within a single packet. Since the frame size for the frame-oriented codecs is given, there is no need to use a separate designation for the same encoding, but with different number of frames per packet. If VoIP equipment follows the advice in rfc1890, one of the base RFCs for RTP, then there won't be an overhead problem. If you are having problems with specific equipment you should forward the above paragraph to the suppier and ask for a bug fix. If this is just a hypothetical problem, then all the better - problem solved. Curtis ps - There is a big difference between one WG asking an author to take their work to another WG and that other WG accepting a WG item. The PWE3 WG cannot accept a WG item for the MPLS WG and I'm sure that was not their intent. > Background: > > Some service providers (such as AT&T) have plans to migrate large amounts of > legacy voice traffic to VoIP, as well as to provide VPN services enabling VoI > P. VoIP over MPLS ('VoMPLS') typically uses the encapsulation voice/RTP/UDP/ > IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the > voice payload is typically no more than 30 bytes. VoIP over MPLS header comp > ression can significantly reduce the VoIP overhead through various compressio > n mechanisms. This is important on access links where bandwidth is scarce, a > nd can be important on backbone facilities, especially where costs are high ( > e.g., some global cross-sections). > > VoIP over MPLS header compression methods have been proposed earlier (March, > 2000) in the MPLS working group, however the relevant drafts have expired. I > n particular, George Swallow and Lou Berger proposed a 'simple' end-to-end co > mpression scheme in which all first-order differences in the RTP/UDP/IP heade > rs were transmitted, and in which the header compression context was establis > hed through RSVP signaling. The work was accepted into the MPLS WG pending a > n addition to the MPLS WG charter. > > In the I-D's we propose 3 approaches to VoMPLS header compression: a) re-use > the methods in cRTP to determine the context and MPLS to route packets, b) re > -use the methods in Swallow's and Berger's 'simple' approach to determine the > context and MPLS to route packets, and c) re-use the methods in cRTP to dete > rmine the context and the SCID (session context ID) to route packets. > > Issues to discuss: > > 1. WG charter -- The VoMPLS header compression work is not within the current > charter of the MPLS WG, so a charter extension is needed. George said he 'w > ould have no objection to the work being done in MPLS'... but suggested that > the 'work fits more closely in the Transport Area/PWE3 WG' (which is why it w > as brought there first). > > 2. Protocol extensions -- As detailed in the I-Ds, extensions are proposed to > [cRTP] and [cRTP-ENHANCE], which involve a new packet type field to identify > FULL_HEADER, CONTEXT_STATE, etc. packets. New objects are defined for [RSVP > -TE]. Extensions are also proposed to RFC2547 VPNs, which create 'SCID routi > ng tables' to allow routing based on the session context ID (SCID). These ex > tensions need coordination with other WGs (MPLS, CCAMP, AVT, ROHC, PPVPN, etc > .). > > 3. Resynchronization -- E2E VoMPLS using cRTP header compression might not pe > rform well with frequent resynchronizations. The applicability and performan > ce need to be addressed (the 'simple' header compression approach would avoid > the need for resynchronization, but achieves less efficiency than cRTP). > > 4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps require a la > rge number of LSPs to be created. There is concern for CE ability to do the > necessary processing and the scalability of the architecture. > > 4. LDP application -- It would be desirable to signal the VoMPLS tunnels with > LDP, since many RFC2547 VPN implementations use LDP as the underlying LSP si > gnaling mechanism. > From owner-mpls@UU.NET Wed Feb 12 18:16:42 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18661 for ; Wed, 12 Feb 2003 18:16:42 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobub24922 for ; Wed, 12 Feb 2003 23:20:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobub24519; Wed, 12 Feb 2003 23:20:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQobub27789 for mpls-outgoing; Wed, 12 Feb 2003 23:19:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQobub27779 for ; Wed, 12 Feb 2003 23:19:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQobub29614 for ; Wed, 12 Feb 2003 23:18:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobub17344 for ; Wed, 12 Feb 2003 23:18:47 GMT Received: from mailg.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailg.telia.com [194.22.194.26]) id QQobub17294 for ; Wed, 12 Feb 2003 23:18:46 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.5/8.12.5) with ESMTP id h1CNIRNY000813; Thu, 13 Feb 2003 00:18:27 +0100 (CET) X-Original-Recipient: MPLS@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1CNIQ222329; Thu, 13 Feb 2003 00:18:26 +0100 (CET) Message-ID: <3E4AD563.4090908@pi.se> Date: Thu, 13 Feb 2003 00:14:43 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" CC: George Swallow , Loa Andersson , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression References: <28F05913385EAC43AF019413F674A01704A1770F@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jerry, (with the wg chair hat on) your proposal is received. I've not made up my mind on this yet. However I've one question and one suggestion for the time being. Question: Are there any requirements doc on this - there is a small section in the documents sent out, but it is hardly enough to take a decission. Suggestion: It is my take that for the time being what should be discussed on the list is whether we want to take this up as a working group task, and whether we should ask ADs and IESG to extend our charter to cover this. This is to say that we don't want to take the discussion on the solution before (or even in parallel) with the discussion if we want to do it or not. /Loa Ash, Gerald R (Jerry), ALABS wrote: >All, > >I'd like to propose that the MPLS WG take on work regarding VoIP over MPLS header compression. This work was earlier accepted for consideration by the MPLS WG (see the background summary below). > >Two I-D's related to this work are at: >http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt (George is added as co-author in the next rev) > >http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt > >Please review the documents and raise any issues/comments to the list. > >The work was presented at the IETF-55 PWE3 WG meeting (slides and meetings notes at http://ietf.org/proceedings/02nov/index.html). It was generally agreed that the work did not fit well in PWE3, and that MPLS might be the best overall fit. > >I propose a brief time slot at the IETF-56 MPLS WG meeting to very briefly review the above proposals and issues, and get a sense of the room. > >Comments welcome > >Thanks, >Jerry Ash > >Background: > >Some service providers (such as AT&T) have plans to migrate large amounts of legacy voice traffic to VoIP, as well as to provide VPN services enabling VoIP. VoIP over MPLS ('VoMPLS') typically uses the encapsulation voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes. VoIP over MPLS header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). > >VoIP over MPLS header compression methods have been proposed earlier (March, 2000) in the MPLS working group, however the relevant drafts have expired. In particular, George Swallow and Lou Berger proposed a 'simple' end-to-end compression scheme in which all first-order differences in the RTP/UDP/IP headers were transmitted, and in which the header compression context was established through RSVP signaling. The work was accepted into the MPLS WG pending an addition to the MPLS WG charter. > >In the I-D's we propose 3 approaches to VoMPLS header compression: a) re-use the methods in cRTP to determine the context and MPLS to route packets, b) re-use the methods in Swallow's and Berger's 'simple' approach to determine the context and MPLS to route packets, and c) re-use the methods in cRTP to determine the context and the SCID (session context ID) to route packets. > >Issues to discuss: > >1. WG charter -- The VoMPLS header compression work is not within the current charter of the MPLS WG, so a charter extension is needed. George said he 'would have no objection to the work being done in MPLS'... but suggested that the 'work fits more closely in the Transport Area/PWE3 WG' (which is why it was brought there first). > >2. Protocol extensions -- As detailed in the I-Ds, extensions are proposed to [cRTP] and [cRTP-ENHANCE], which involve a new packet type field to identify FULL_HEADER, CONTEXT_STATE, etc. packets. New objects are defined for [RSVP-TE]. Extensions are also proposed to RFC2547 VPNs, which create 'SCID routing tables' to allow routing based on the session context ID (SCID). These extensions need coordination with other WGs (MPLS, CCAMP, AVT, ROHC, PPVPN, etc.). > >3. Resynchronization -- E2E VoMPLS using cRTP header compression might not perform well with frequent resynchronizations. The applicability and performance need to be addressed (the 'simple' header compression approach would avoid the need for resynchronization, but achieves less efficiency than cRTP). > >4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps require a large number of LSPs to be created. There is concern for CE ability to do the necessary processing and the scalability of the architecture. > >4. LDP application -- It would be desirable to signal the VoMPLS tunnels with LDP, since many RFC2547 VPN implementations use LDP as the underlying LSP signaling mechanism. > > > From owner-mpls@UU.NET Wed Feb 12 20:19:14 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20603 for ; Wed, 12 Feb 2003 20:19:14 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobuj22162 for ; Thu, 13 Feb 2003 01:22:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobuj21980; Thu, 13 Feb 2003 01:22:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQobuj13827 for mpls-outgoing; Thu, 13 Feb 2003 01:22:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQobuj13822 for ; Thu, 13 Feb 2003 01:22:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQobuj23005 for ; Thu, 13 Feb 2003 01:21:19 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobuj19435 for ; Thu, 13 Feb 2003 01:21:18 GMT Received: from almso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQobuj19422 for ; Thu, 13 Feb 2003 01:21:17 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1CNcaVJ005961 for ; Wed, 12 Feb 2003 20:21:17 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032) id 3DF6BD4E025413F4; Wed, 12 Feb 2003 20:21:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression Date: Wed, 12 Feb 2003 20:21:15 -0500 Message-ID: <28F05913385EAC43AF019413F674A01704A17717@OCCLUST04EVS1.ugd.att.com> Thread-Topic: E2E VoIP over MPLS ('VoMPLS') Header Compression Thread-Index: AcLS7REDTwK1Hu8ESwOW/VwXhG4KLgABXKbQ From: "Ash, Gerald R (Jerry), ALABS" To: "Loa Andersson" , "MPLS@UU.net" Cc: "Ash, Gerald R (Jerry), ALABS" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA20603 Loa, > Question: > Are there any requirements doc on this - there is a small > section in the documents sent out, but it is hardly enough > to take a decision. Yes, Section 4.1 in http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt contains requirements. In addition, these requirements were specified in slide 3 of the IETF-55/PWE3 presentation http://ietf.org/proceedings/02nov/index.html: a. need mechanism for end-to-end VoIP over MPLS CE --> CE header compression (e.g., from CE1 --> PE1 --> P --> PE2 --> CE2), to provide for efficient voice transport. b. support various voice encoding (G.729, G.723.1, etc.). c. compress/decompress header using cRTP (RFC 2508) and/or 'simple' algorithm. d. operate in RFC2547 VPN context. e. scalable to very large number of CE --> CE flows. These additional requirements are added to the next (01) revision of the I-D. Do you suggest any further elucidation of the requirements? > Suggestion: > It is my take that for the time being what should be > discussed on the list is whether we want to take this > up as a working group task, and whether we should ask > ADs and IESG to extend our charter to cover this. Agreed, that is what I was trying to suggest as well. Jerry From owner-mpls@UU.NET Thu Feb 13 02:53:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06665 for ; Thu, 13 Feb 2003 02:53:57 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobvj19717 for ; Thu, 13 Feb 2003 07:57:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobvj19043; Thu, 13 Feb 2003 07:57:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQobvj02772 for mpls-outgoing; Thu, 13 Feb 2003 07:57:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQobvj02767 for ; Thu, 13 Feb 2003 07:57:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQobvj05918 for ; Thu, 13 Feb 2003 07:55:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobvj16295 for ; Thu, 13 Feb 2003 07:55:34 GMT Received: from mailg.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailg.telia.com [194.22.194.26]) id QQobvj16290 for ; Thu, 13 Feb 2003 07:55:33 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.5/8.12.5) with ESMTP id h1D7tONY016190; Thu, 13 Feb 2003 08:55:24 +0100 (CET) X-Original-Recipient: MPLS@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1D7tN228296; Thu, 13 Feb 2003 08:55:23 +0100 (CET) Message-ID: <3E4B4E8A.30608@pi.se> Date: Thu, 13 Feb 2003 08:51:38 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R (Jerry), ALABS" CC: "MPLS@UU.net" , George Swallow , Loa Andersson , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression References: <28F05913385EAC43AF019413F674A01704A17717@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jerry, (still with my wg chair hat on) yes I suggest that you elucidate the requirements further, and ideally I would prefer a separate requirments doc, that we could use to decide. Also, the requirements are very "bare boned", you should put some meat on them. What I would like to is a requirments doc that 1. describe the problem you want to solve 2. state the requirments in such a way that it is possible to verify whether they are met nor not, e.g. the and/or is hard to understand as requirment. This doc would be the basis on which the wg reach consensus (go/no go) and what the IESG use to ack/nak the charter extension. We (wg chairs for ccamp and mpls and the ads) has just posted an ID describing the process we think should be used to change/extend protocols specified by the ccamp and mpls wgs. will show up shortly. Now, I'm not going slam that process in your face, we need to reach consensus on the process before we start using it :). And this reached us before the process is in use. However, it would be possible for you to read and understand how we are thinking. /Loa Ash, Gerald R (Jerry), ALABS wrote: >Loa, > > >>Question: >>Are there any requirements doc on this - there is a small >>section in the documents sent out, but it is hardly enough >>to take a decision. >> > >Yes, Section 4.1 in http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt contains requirements. In addition, these requirements were specified in slide 3 of the IETF-55/PWE3 presentation http://ietf.org/proceedings/02nov/index.html: > >a. need mechanism for end-to-end VoIP over MPLS CE --> CE header compression >(e.g., from CE1 --> PE1 --> P --> PE2 --> CE2), to provide for efficient voice transport. >b. support various voice encoding (G.729, G.723.1, etc.). >c. compress/decompress header using cRTP (RFC 2508) and/or 'simple' algorithm. >d. operate in RFC2547 VPN context. >e. scalable to very large number of CE --> CE flows. > >These additional requirements are added to the next (01) revision of the I-D. Do you suggest any further elucidation of the requirements? > > >>Suggestion: >>It is my take that for the time being what should be >>discussed on the list is whether we want to take this >>up as a working group task, and whether we should ask >>ADs and IESG to extend our charter to cover this. >> > >Agreed, that is what I was trying to suggest as well. > >Jerry > > > From owner-mpls@UU.NET Thu Feb 13 16:08:33 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00394 for ; Thu, 13 Feb 2003 16:08:32 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxk14539 for ; Thu, 13 Feb 2003 21:12:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobxk14268; Thu, 13 Feb 2003 21:12:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQobxk18947 for mpls-outgoing; Thu, 13 Feb 2003 21:11:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQobxk18931 for ; Thu, 13 Feb 2003 21:11:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQobxk01227 for ; Thu, 13 Feb 2003 21:10:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxk21179 for ; Thu, 13 Feb 2003 21:10:53 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQobxk21167 for ; Thu, 13 Feb 2003 21:10:52 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1DL9QS68809; Thu, 13 Feb 2003 13:09:26 -0800 (PST) (envelope-from ina@juniper.net) Date: Thu, 13 Feb 2003 13:09:26 -0800 (PST) From: Ina Minei To: jcucchiara@mindspring.com, "" , "" cc: mpls@UU.NET Subject: Comments on draft-ietf-mpls-ldp-mib-09.txt (fwd) Message-ID: <20030212102555.W18200@garnet.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Resending... Would the authors comment on the following additions to the ldp mib? Should these comments be incorporated in a separate document? Thank you, Ina Minei ---------- Forwarded message ---------- Date: Fri, 7 Feb 2003 15:00:34 -0800 (PST) From: Ina Minei To: mpls@UU.NET Subject: Comments on draft-ietf-mpls-ldp-mib-09.txt Hello, Please find below a few comments on draft-ietf-mpls-ldp-mib-09.txt. Let me start by saying that moving to 4 mib modules (from version 8 to version 9 of the draft) was an excellent step, making the document much easier to read and use. Please find below a few additions to the MPLS-LDP-MIB module. 1) Authentication information ----------------------------- TCP MD5 signature is mentioned in the LDP RFC, but not in the mib. It is useful to know whether a session is authenticated or not. mplsLdpSesAuthenticationType OBJECT-TYPE SYNTAX INTEGER { none(0), md5(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "The authentication type for this session." ::= { mplsLdpSessionEntry 6 } 2) Reason for the session going down ------------------------------------ From an operator's point of view, it is useful to know the cause for a session going down. Similar functionality can be found in the bgp mib. This information could be passed in the session down trap as well, providing a powerful debugging tool for network operators. mplsLdpSesDownReason OBJECT-TYPE SYNTAX INTEGER { holdExpired (1), connectionExpired (2), allAdjacenciesDown (3), badTLV (4), badPDU (5), badPacket (6), connectionError (7), peerSentNotification (8), unexpectedEOF (9), authenticationChanged (10), initError (11), gracefulRestartAbort (12), unknown (13) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The reason why the session transitioned to nonexistent state. Can be one of the following: hold time expired, connection time expired, all adjacencies down, received bad tlv, received bad packet, connection error, received notification from peer, received unexpected end-of-file, authentication key was changed, error during initialization, graceful restart was aborted, or unknown reason." ::= {mplsLdpSessionEntry 7} 3) Additional information for hello adjacencies ----------------------------------------------- a) The mib currently provides no interface information. It is important to know which interface the hello adjacency is on. mplsLdpHelloAdjIntf OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "For a hello adjacency of type link(1), the ifIndex of the interface, for a hello adjacency of type targeted(2), the ifIndex of the loopback interface." ::= { mplsLdpHelloAdjacencyEntry 4 } b) It is useful to have the address information as well, though this can be obtained from the interface index. c) It is useful to have a timestamp of when this adjacency came up. 4) Interface information for the LDP entity ------------------------------------------- LDP is a discovery protocol. In many systems, the configuration of the protocol is done by specifying the interfaces on which the discovery should be attempted. It is not guaranteed that adjacencies will be formed on these interfaces. A table specifying for each LDP entity which interfaces it is running on, and how many adjacencies were established on each of these interfaces, would provide valuable insight for the network operator. 5) Graceful restart information ------------------------------- draft-ietf-mpls-ldp-restart-06.txt is now moving to Proposed Standard. It might be useful to include the graceful restart information at this time, in order to avoid having to add it later. The graceful restart info is: - graceful restart enabled/disabled - helper mode enabled/disabled - recovery time - max recovery time - reconnect time Some of this belongs to the entity, and some to the peer. If there is agreement on adding this information, I can write it up. 6) Additional identifier of the LDP Entity ------------------------------------------ Currently the MplsLdpIdentifier is the only identifier for an LDP Entity. This is based on the assumption that the LdpIdentifier will be unique. However, when implementing several instances with overlapping address space, this may not be true (I am thinking of the vpn case). It would be good to have an additional identifier (perhaps an integer) that can be used to differentiate between these otherwise equal entities. (otherwise things like traps will be of limited use). The linkage between this additional identifier and the instances can be done separately, but I think having the hook in now will be good for the future. 7) Summary information for LDP Entity ------------------------------------- To be able to sanity check the state of the protocol on a particular box, it is useful to have a snapshot of the state of the sessions for each ldp entity. Something along the lines: # of operational sessions, total number of sessions in all states, number of interfaces, number of neighbors. The idea is for this table to be polled at regular intervals, to make sure nothing is going wrong. (traps won't always be the key, since they can be disabled, or may not make it) Traps ===== Change in the session down trap ------------------------------- From an operator's point of view, it is useful to know the cause for a session going down. This can be passed in the trap, and would provide more information than the number of unknown messages or unknown TLVs received. mplsLdpSessionDown NOTIFICATION-TYPE OBJECTS { mplsLdpSesState, mplsLdpSesDownReason } STATUS current DESCRIPTION "If this notification is enabled to generated, then this notification is sent when the the value of 'mplsLdpSesState' leaves the 'operational(5)' state." ::= { mplsLdpNotificationPrefix 4 } Change in the session up trap ----------------------------- It was not clear to me the reason whty we send the number of unknown messages/tlv in the session up trap. Would you explain the usage? Add an adjacency-down trap ------------------------- Losing adjacencies may lead to losing a session. (though when a session is established over several adjacencies, this is not the case). In any case, a user can decide if it is beneficial for his network to track adjacencies going down anyway. It can be used to alert the operator that something went wrong in the redundant path, and his ldp session is at risk. Thank you, Ina Minei From owner-mpls@UU.NET Thu Feb 13 17:08:12 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11868 for ; Thu, 13 Feb 2003 17:08:12 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxo26857 for ; Thu, 13 Feb 2003 22:11:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobxo26350; Thu, 13 Feb 2003 22:11:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQobxo12052 for mpls-outgoing; Thu, 13 Feb 2003 22:11:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQobxo12045 for ; Thu, 13 Feb 2003 22:11:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQobxo29183 for ; Thu, 13 Feb 2003 22:10:10 GMT From: jcucchiara@mindspring.com Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxo14565 for ; Thu, 13 Feb 2003 22:10:08 GMT Received: from blount.mail.mindspring.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: blount.mail.mindspring.net [207.69.200.226]) id QQobxo14553 for ; Thu, 13 Feb 2003 22:10:08 GMT Received: from dialup-63.214.109.73.dial1.boston1.level3.net ([63.214.109.73] helo=jluciani-laptop) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 18jRYS-00070H-00; Thu, 13 Feb 2003 17:10:04 -0500 Message-Id: <3.0.1.32.20030213172029.00697994@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 13 Feb 2003 17:20:29 -0500 To: Ina Minei , mpls@UU.NET Subject: Re: Comments on draft-ietf-mpls-ldp-mib-09.txt In-Reply-To: <20030207145450.B16753@garnet.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 03:00 PM 2/7/03 -0800, Ina Minei wrote: > > Hello, > > Please find below a few comments on draft-ietf-mpls-ldp-mib-09.txt. > > Let me start by saying that moving to 4 mib modules (from version >8 to version 9 of the draft) was an excellent step, making the >document much easier to read and use. Thanks for the feedback. Most of the comments that I have received on this re-organization are favorable also. This was suggested by Bert W. during the IESG MIB review. > > Please find below a few additions to the MPLS-LDP-MIB module. > >1) Authentication information >----------------------------- >TCP MD5 signature is mentioned in the LDP RFC, but not in the >mib. It is useful to know whether a session is authenticated or not. > > mplsLdpSesAuthenticationType OBJECT-TYPE > SYNTAX INTEGER { > none(0), > md5(1) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The authentication type for this session." > ::= { mplsLdpSessionEntry 6 } > There is some discussion of this in the archives. As you point out this is a TCP mechanism which other protocols such as BGP or LDP may use. As I recall the consensus about this discussion was that it would be better to add something to the TCP MIB and not put this in other MIBs such as LDP or BGP. As you may have noticed such an object does not appear in the lastest drafts of the BGP4 MIB either. > >2) Reason for the session going down >------------------------------------ >From an operator's point of view, it is useful to know the cause for a >session going down. Similar functionality can be found in the bgp mib. >This information could be passed in the session down trap as well, >providing a powerful debugging tool for network operators. > >mplsLdpSesDownReason OBJECT-TYPE > SYNTAX INTEGER { > holdExpired (1), > connectionExpired (2), > allAdjacenciesDown (3), > badTLV (4), > badPDU (5), > badPacket (6), > connectionError (7), > peerSentNotification (8), > unexpectedEOF (9), > authenticationChanged (10), > initError (11), > gracefulRestartAbort (12), > unknown (13) } > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The reason why the session transitioned to nonexistent state. > Can be one of the following: > hold time expired, connection time expired, all adjacencies down, > received bad tlv, received bad packet, connection error, > received notification from peer, received unexpected end-of-file, > authentication key was changed, error during initialization, > graceful restart was aborted, or unknown reason." > ::= {mplsLdpSessionEntry 7} The above does not really clarify why a session was torn down. An NMS by looking at each entity and peer in the Session in a network should be able to discern why the session was torn down. But I think this is a network issue, not just an individual node issue. As a point of clarity, are you an operator or are you giving feedback based on conversations with an operator? > >3) Additional information for hello adjacencies >----------------------------------------------- >a) The mib currently provides no interface information. It is important >to know which interface the hello adjacency is on. > >mplsLdpHelloAdjIntf OBJECT-TYPE > SYNTAX InterfaceIndex > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "For a hello adjacency of type link(1), the ifIndex of the > interface, for a hello adjacency of type targeted(2), the > ifIndex of the loopback interface." > ::= { mplsLdpHelloAdjacencyEntry 4 } > >b) It is useful to have the address information as well, though this >can be obtained from the interface index. Not sure I understand this. If LSRa receives a hello message from LSRb, why can't the NMS be smart enough to look at LSRb Entity table to see the UDP Ports that the hello was sent out on? > >c) It is useful to have a timestamp of when this adjacency came >up. It would be very close to mplsLdpSesStateLastChange, wouldn't it? Not sure that this is really needed. > >4) Interface information for the LDP entity >------------------------------------------- >LDP is a discovery protocol. In many systems, the configuration of the >protocol is done by specifying the interfaces on which the discovery >should be attempted. It is not guaranteed that adjacencies will be >formed on these interfaces. >A table specifying for each LDP entity which interfaces it is running >on, and how many adjacencies were established on each of these >interfaces, would provide valuable insight for the network operator. LDP Entities do not run on interfaces. Entities are simply the way to configure a potential session. Please see section 3.5.1 and 3.5.1.1 of the MIB for further information. > >5) Graceful restart information >------------------------------- >draft-ietf-mpls-ldp-restart-06.txt is now moving to Proposed >Standard. It might be useful to include the graceful restart information >at this time, in order to avoid having to add it later. > The graceful restart info is: >- graceful restart enabled/disabled >- helper mode enabled/disabled >- recovery time >- max recovery time >- reconnect time > Some of this belongs to the entity, and some to the peer. If >there is agreement on adding this information, I can write it up. It is beyond the scope of this document to add new functionality. Please note, this MIB has gone through several last calls, and has just gone through IESG review for a second time. Also, there was an open meeting in Nov at the IETF. In other words, it is too late in the process of this MIB to be adding new functionality. Certainly, you may create a MIB for this functionality and propose it to the working group. > >6) Additional identifier of the LDP Entity >------------------------------------------ >Currently the MplsLdpIdentifier is the only identifier for an LDP >Entity. This is based on the assumption that the LdpIdentifier will >be unique. However, when implementing several instances with >overlapping address space, this may not be true (I am thinking of the >vpn case). It would be good to have an additional identifier (perhaps >an integer) that can be used to differentiate between these otherwise >equal entities. (otherwise things like traps will be of limited use). >The linkage between this additional identifier and the instances can >be done separately, but I think having the hook in now will be good >for the future. There are 2 indices for this table, so am unclear as to if you are asking for a 2nd or 3rd index? > >7) Summary information for LDP Entity >------------------------------------- >To be able to sanity check the state of the protocol on a particular >box, it is useful to have a snapshot of the state of the sessions for >each ldp entity. Something along the lines: # of operational sessions, >total number of sessions in all states, number of interfaces, number >of neighbors. The idea is for this table to be polled at regular >intervals, to make sure nothing is going wrong. (traps won't always be >the key, since they can be disabled, or may not make it) > As the AUGMENTS relations in the Session table indicates, there is one session for each entity-peer relationship. If you are saying that you want to understand how many LSPs per session then you need to look at the mplsLdpLspTable. >Traps >===== >Change in the session down trap >------------------------------- >From an operator's point of view, it is useful to know the cause for a >session going down. This can be passed in the trap, and would provide more >information than the number of unknown messages or unknown TLVs >received. > >mplsLdpSessionDown NOTIFICATION-TYPE > OBJECTS { > mplsLdpSesState, > mplsLdpSesDownReason > > } > STATUS current > DESCRIPTION > "If this notification is enabled to generated, > then this notification is sent when the > the value of 'mplsLdpSesState' leaves > the 'operational(5)' state." > ::= { mplsLdpNotificationPrefix 4 } > >Change in the session up trap >----------------------------- >It was not clear to me the reason whty we send the number of unknown >messages/tlv in the session up trap. Would you explain the usage? These 2 counters are maintained throughout the life of a session and so are forwarded with the traps to give extra information. > >Add an adjacency-down trap >------------------------- >Losing adjacencies may lead to losing a session. (though when a >session is established over several adjacencies, this is not the >case). In any case, a user can decide if it is beneficial for his >network to track adjacencies going down anyway. It can be used to alert >the operator that something went wrong in the redundant path, and his ldp >session is at risk. > Not sure I agree with this. There may be only one adjacency and that is not indicative that a session is about to be closed. -Joan > > Thank you, > > Ina Minei > > From owner-mpls@UU.NET Thu Feb 13 17:58:48 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17146 for ; Thu, 13 Feb 2003 17:58:48 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxs05614 for ; Thu, 13 Feb 2003 23:02:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobxs04815; Thu, 13 Feb 2003 23:02:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQobxs26070 for mpls-outgoing; Thu, 13 Feb 2003 23:01:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQobxs26017 for ; Thu, 13 Feb 2003 23:01:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQobxs25933 for ; Thu, 13 Feb 2003 23:00:58 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxs03206 for ; Thu, 13 Feb 2003 23:00:58 GMT Received: from web20702.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20702.mail.yahoo.com [216.136.226.175]) id QQobxs03182 for ; Thu, 13 Feb 2003 23:00:57 GMT Message-ID: <20030213230057.47285.qmail@web20702.mail.yahoo.com> Received: from [216.174.224.251] by web20702.mail.yahoo.com via HTTP; Thu, 13 Feb 2003 15:00:57 PST Date: Thu, 13 Feb 2003 15:00:57 -0800 (PST) From: Sameer K Subject: Regarding Switching capability and GPID in OSPF-TE and GMPLS-RSVP To: ccamp@ops.ietf.org, mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello All, I have some questions regarding switching capability descriptor, encoding type and GPID parameters, and the correlation between the values signaled in signaling request and the values advertised in OSPF TE LSAs. From the previous discussions, it appears that if a data capable device has to establish LSP through a network of OXCs, the switching type requested would be FSC, the encoding type would be SDH/SONET with GPID being PPP (assuming that the data device that is LSP ingress wants to send IP data over the LSP). Now, the LSP will be established without any problem as long as the destination node is advertising a switching capability FSC and the encoding type SONET/SDH for all its interfaces. However, for the LSP to be of any use to ingress node, the destination must be capable of terminating PPP (which in turn requires data capability on the incoming interface of egress node). The way to ensure this would be to read GPID and then egress can reject the LSP if it cannot support the GPID. However, what if destination is a multi-service switch and bears certain interfaces that are FSC capable and can terminate PPP as well (that is, support data over FSC -if you will), other than the FSC only interfaces. CSPF running at ingress can never tell the difference between these (data over FSC type) interfaces and other (FSC only) interfaces and the LSP might end up on an interface that cannot support PPP termination. In such a case, even though the node supports PPP at certain interfaces, the LSP will have to be rejected. Now, if some "higher layer" information (PPP termination capability for this example), is advertised as a part of OSPF TE LSAs, the CSPF running on the ingress node can pick up the correct incoming interface on egress node based on the GPID desired, thus reducing the probability of LSP failures. Would like to hear opinions. TIA - Sameer. __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-mpls@UU.NET Thu Feb 13 19:25:18 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24264 for ; Thu, 13 Feb 2003 19:25:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxx09031 for ; Fri, 14 Feb 2003 00:29:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobxx08644; Fri, 14 Feb 2003 00:28:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQobxx29086 for mpls-outgoing; Fri, 14 Feb 2003 00:28:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQobxx29071 for ; Fri, 14 Feb 2003 00:28:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQobxx15168 for ; Fri, 14 Feb 2003 00:27:52 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxx07139 for ; Fri, 14 Feb 2003 00:27:50 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQobxx07111 for ; Fri, 14 Feb 2003 00:27:50 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1E0RmS84531; Thu, 13 Feb 2003 16:27:48 -0800 (PST) (envelope-from ina@juniper.net) Date: Thu, 13 Feb 2003 16:27:48 -0800 (PST) From: Ina Minei To: jcucchiara@mindspring.com cc: mpls@UU.NET Subject: Re: Comments on draft-ietf-mpls-ldp-mib-09.txt In-Reply-To: <3.0.1.32.20030213172029.00697994@pop.mindspring.com> Message-ID: <20030213141757.H45365@garnet.juniper.net> References: <3.0.1.32.20030213172029.00697994@pop.mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Thank you for the quick feedback. Please find responses inline below, marked ###. Ina On Thu, 13 Feb 2003 jcucchiara@mindspring.com wrote: > > > >2) Reason for the session going down > >------------------------------------ > >From an operator's point of view, it is useful to know the cause for a > >session going down. Similar functionality can be found in the bgp mib. > >This information could be passed in the session down trap as well, > >providing a powerful debugging tool for network operators. > > > >mplsLdpSesDownReason OBJECT-TYPE > > SYNTAX INTEGER { > > holdExpired (1), > > connectionExpired (2), > > allAdjacenciesDown (3), > > badTLV (4), > > badPDU (5), > > badPacket (6), > > connectionError (7), > > peerSentNotification (8), > > unexpectedEOF (9), > > authenticationChanged (10), > > initError (11), > > gracefulRestartAbort (12), > > unknown (13) } > > MAX-ACCESS accessible-for-notify > > STATUS current > > DESCRIPTION > > "The reason why the session transitioned to nonexistent state. > > Can be one of the following: > > hold time expired, connection time expired, all adjacencies down, > > received bad tlv, received bad packet, connection error, > > received notification from peer, received unexpected end-of-file, > > authentication key was changed, error during initialization, > > graceful restart was aborted, or unknown reason." > > ::= {mplsLdpSessionEntry 7} > > > The above does not really clarify why a session was torn down. > An NMS by looking at each entity and peer in the Session in a network > should be able to discern why the session was torn down. But I think > this is a network issue, not just an individual node issue. > > As a point of clarity, are you an operator or are you giving feedback > based on conversations with an operator? ### I am not an operator. The feedback I was giving was based on conversations with an operator. There are two reasons why having the above is useful: - 1) It provides information about the reason the session went down. E.g. "all adjacencies down" is a very clear indication that all the neighbors went down. So is "hold time expired". Having such information readily available can cut the "detective work" involved in troubleshooting a session failure. - 2) This information can be included in traps. Currently there is no clue in the trap why the session went down. When an error condition occurs in a network, (e.g. a link fails), there will be many traps generated for this event - the ifmib, the ldp mib, the igp mib will all report the failure. Usually, the operator wants to identify that these failures are all related, and an error code can help him do that. I think the main benefit is to include this information in the session down trap. > > > > > >3) Additional information for hello adjacencies > >----------------------------------------------- > >a) The mib currently provides no interface information. It is important > >to know which interface the hello adjacency is on. > > > >mplsLdpHelloAdjIntf OBJECT-TYPE > > SYNTAX InterfaceIndex > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "For a hello adjacency of type link(1), the ifIndex of the > > interface, for a hello adjacency of type targeted(2), the > > ifIndex of the loopback interface." > > ::= { mplsLdpHelloAdjacencyEntry 4 } > > > >b) It is useful to have the address information as well, though this > >can be obtained from the interface index. > > Not sure I understand this. If LSRa receives a hello message from > LSRb, why can't the NMS be smart enough to look at LSRb Entity table > to see the UDP Ports that the hello was sent out on? ### Because this information can be made readily available on LSRa at extremely little cost. What do we do in the scenario above if LSRb is not snmp enabled? I always think about how i would feel if the cli was providing the same functionality and I would have to go to the neighboring router in order to find out on which interface the adjacency is formed - not very usable. I agree with you that the address information is not as useful, but the interface information is essential. > > > > > >c) It is useful to have a timestamp of when this adjacency came > >up. > > It would be very close to mplsLdpSesStateLastChange, wouldn't it? > ### Not really. A session may go down because of a bad packet for example, or a change in authentication. These are events that wouldn't cause the adjacency to go down. Also, there may be several adjacencies that belong to the same session (e.g. for parallel interfaces which is a common scenario). An adjacency may go down, but the session will stay up. So the timers can be very different. One of the ways to troubleshoot a session-down from the cli is to compare the time an adjacency is up and the session is up. > > > >4) Interface information for the LDP entity > >------------------------------------------- > >LDP is a discovery protocol. In many systems, the configuration of the > >protocol is done by specifying the interfaces on which the discovery > >should be attempted. It is not guaranteed that adjacencies will be > >formed on these interfaces. > >A table specifying for each LDP entity which interfaces it is running > >on, and how many adjacencies were established on each of these > >interfaces, would provide valuable insight for the network operator. > > LDP Entities do not run on interfaces. Entities are simply the > way to configure a potential session. Please see section 3.5.1 and > 3.5.1.1 of the MIB for further information. > ### My previous comment was referring to the cli, thus the miscommunication. My point is that an LDP entity will be associated with one or more sessions (the case where no sessions are established is not interesting) Each session is established thanks to one or more adjacencies, and each of these adjacencies is running on an interface. Knowing which are the interfaces that an entity is associated with is very important. From the cli, for many vendors, the way to configure the protocol is to specify on which interfaces the adjacency discovery should take place. I hope this makes my previous comment clearer. I believe the different optic comes from the fact that the mib was written with ATM/FR in mind, where indeed the interface information is not as interesting. > > > >6) Additional identifier of the LDP Entity > >------------------------------------------ > >Currently the MplsLdpIdentifier is the only identifier for an LDP > >Entity. This is based on the assumption that the LdpIdentifier will > >be unique. However, when implementing several instances with > >overlapping address space, this may not be true (I am thinking of the > >vpn case). It would be good to have an additional identifier (perhaps > >an integer) that can be used to differentiate between these otherwise > >equal entities. (otherwise things like traps will be of limited use). > >The linkage between this additional identifier and the instances can > >be done separately, but I think having the hook in now will be good > >for the future. > > > There are 2 indices for this table, so am unclear as to if you are > asking for a 2nd or 3rd index? ### Sorry, I missed this. I wanted a 2nd index, and didn't notice there were two already. Please ignore my comment > > > > >7) Summary information for LDP Entity > >------------------------------------- > >To be able to sanity check the state of the protocol on a particular > >box, it is useful to have a snapshot of the state of the sessions for > >each ldp entity. Something along the lines: # of operational sessions, > >total number of sessions in all states, number of interfaces, number > >of neighbors. The idea is for this table to be polled at regular > >intervals, to make sure nothing is going wrong. (traps won't always be > >the key, since they can be disabled, or may not make it) > > > > As the AUGMENTS relations in the Session table indicates, there is > one session for each entity-peer relationship. ### Agreed, but I don't want to have to walk the entire Peer Table to extract this information. Since this info is likely to be polled often, it would be nice if it was readily available. > >Traps > >===== > >Change in the session down trap > >------------------------------- > >From an operator's point of view, it is useful to know the cause for a > >session going down. This can be passed in the trap, and would provide more > >information than the number of unknown messages or unknown TLVs > >received. > > > >mplsLdpSessionDown NOTIFICATION-TYPE > > OBJECTS { > > mplsLdpSesState, > > mplsLdpSesDownReason > > > > } > > STATUS current > > DESCRIPTION > > "If this notification is enabled to generated, > > then this notification is sent when the > > the value of 'mplsLdpSesState' leaves > > the 'operational(5)' state." > > ::= { mplsLdpNotificationPrefix 4 } > > > >Change in the session up trap > >----------------------------- > >It was not clear to me the reason whty we send the number of unknown > >messages/tlv in the session up trap. Would you explain the usage? > > These 2 counters are maintained throughout the life of a session and > so are forwarded with the traps to give extra information. ### In the session up trap, the number of unknown messages received will not really give the operator any useful info. I would not send this extra info, though it can't do any harm either. > > > > >Add an adjacency-down trap > >------------------------- > >Losing adjacencies may lead to losing a session. (though when a > >session is established over several adjacencies, this is not the > >case). In any case, a user can decide if it is beneficial for his > >network to track adjacencies going down anyway. It can be used to alert > >the operator that something went wrong in the redundant path, and his ldp > >session is at risk. > > > > Not sure I agree with this. There may be only one adjacency and that > is not indicative that a session is about to be closed. > ### I'm afraid I don't understand the comment. Are you saying there are more than one or just one adjacency? > > > > > > > Thank you, > > > > Ina Minei > > > > > From owner-mpls@UU.NET Thu Feb 13 21:47:54 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27389 for ; Thu, 13 Feb 2003 21:47:54 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobyh23535 for ; Fri, 14 Feb 2003 02:51:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQobyh23026; Fri, 14 Feb 2003 02:51:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQobyh16641 for mpls-outgoing; Fri, 14 Feb 2003 02:50:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQobyh16629 for ; Fri, 14 Feb 2003 02:50:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQobyh02176 for ; Fri, 14 Feb 2003 02:46:48 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobyh19068 for ; Fri, 14 Feb 2003 02:46:48 GMT Received: from blount.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: blount.mail.mindspring.net [207.69.200.226]) id QQobyh19063 for ; Fri, 14 Feb 2003 02:46:48 GMT Received: from dialup-63.214.109.73.dial1.boston1.level3.net ([63.214.109.73] helo=jluciani-laptop) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 18jVsC-0008Tq-00; Thu, 13 Feb 2003 21:46:44 -0500 Message-Id: <3.0.1.32.20030213215653.0131b334@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 13 Feb 2003 21:56:53 -0500 To: Ina Minei Subject: Re: Comments on draft-ietf-mpls-ldp-mib-09.txt Cc: mpls@UU.NET In-Reply-To: <20030213141757.H45365@garnet.juniper.net> References: <3.0.1.32.20030213172029.00697994@pop.mindspring.com> <3.0.1.32.20030213172029.00697994@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 04:27 PM 2/13/03 -0800, Ina Minei wrote: > > Thank you for the quick feedback. Please find responses inline >below, marked ###. > > Ina > >On Thu, 13 Feb 2003 jcucchiara@mindspring.com wrote: > >> > >> >2) Reason for the session going down >> >------------------------------------ >> >From an operator's point of view, it is useful to know the cause for a >> >session going down. Similar functionality can be found in the bgp mib. >> >This information could be passed in the session down trap as well, >> >providing a powerful debugging tool for network operators. >> > >> >mplsLdpSesDownReason OBJECT-TYPE >> > SYNTAX INTEGER { >> > holdExpired (1), >> > connectionExpired (2), >> > allAdjacenciesDown (3), >> > badTLV (4), >> > badPDU (5), >> > badPacket (6), >> > connectionError (7), >> > peerSentNotification (8), >> > unexpectedEOF (9), >> > authenticationChanged (10), >> > initError (11), >> > gracefulRestartAbort (12), >> > unknown (13) } >> > MAX-ACCESS accessible-for-notify >> > STATUS current >> > DESCRIPTION >> > "The reason why the session transitioned to nonexistent state. >> > Can be one of the following: >> > hold time expired, connection time expired, all adjacencies down, >> > received bad tlv, received bad packet, connection error, >> > received notification from peer, received unexpected end-of-file, >> > authentication key was changed, error during initialization, >> > graceful restart was aborted, or unknown reason." >> > ::= {mplsLdpSessionEntry 7} >> >> >> The above does not really clarify why a session was torn down. >> An NMS by looking at each entity and peer in the Session in a network >> should be able to discern why the session was torn down. But I think >> this is a network issue, not just an individual node issue. >> >> As a point of clarity, are you an operator or are you giving feedback >> based on conversations with an operator? > >### I am not an operator. The feedback I was giving was based on >conversations with an operator. Sure. > >There are two reasons why having the above is useful: >- 1) It provides information about the reason the session went down. >E.g. "all adjacencies down" is a very clear indication that all the >neighbors went down. So is "hold time expired". Having such information >readily available can cut the "detective work" involved in troubleshooting >a session failure. >- 2) This information can be included in traps. Currently there is no >clue in the trap why the session went down. >When an error condition occurs in a network, (e.g. a link fails), there >will be many traps generated for this event - the ifmib, the ldp mib, the >igp mib will all report the failure. Usually, the operator wants to >identify that these failures are all related, and an error code can help >him do that. > >I think the main benefit is to include this information in the session >down trap. > As I said above, this is still a network issue and not an individual node issue. In other words, each LSR/LER involved in the session will generate a trap that says something different. This is because they only see why their side of the session was torn down. It is upto an NMS to figure out the root cause. This is not something that an individual node can do accurately. >> >> >> > >> >3) Additional information for hello adjacencies >> >----------------------------------------------- >> >a) The mib currently provides no interface information. It is important >> >to know which interface the hello adjacency is on. >> > >> >mplsLdpHelloAdjIntf OBJECT-TYPE >> > SYNTAX InterfaceIndex >> > MAX-ACCESS read-only >> > STATUS current >> > DESCRIPTION >> > "For a hello adjacency of type link(1), the ifIndex of the >> > interface, for a hello adjacency of type targeted(2), the >> > ifIndex of the loopback interface." >> > ::= { mplsLdpHelloAdjacencyEntry 4 } >> > >> >b) It is useful to have the address information as well, though this >> >can be obtained from the interface index. >> >> Not sure I understand this. If LSRa receives a hello message from >> LSRb, why can't the NMS be smart enough to look at LSRb Entity table >> to see the UDP Ports that the hello was sent out on? > >### Because this information can be made readily available on LSRa at >extremely little cost. What do we do in the scenario above if LSRb is >not snmp enabled? I always think about how i would feel if the cli >was providing the same functionality and I would have to go to the >neighboring router in order to find out on which interface the adjacency >is formed - not very usable. This is exactly why an NMS should be used. Also, in my humble opinion, it is a little unrealistic to expect that an SNMP-based MIB should make provisions for nodes which don't have snmp enabled. > I agree with you that the address information is not as useful, >but the interface information is essential. > The point I was trying to make is that if you know that hellos are being sent from a UDP port, then you should be able to know the interface. >> >> >> > >> >c) It is useful to have a timestamp of when this adjacency came >> >up. >> >> It would be very close to mplsLdpSesStateLastChange, wouldn't it? >> > >### Not really. A session may go down because of a bad packet for >example, or a change in authentication. These are events that >wouldn't cause the adjacency to go down. Also, there may be several >adjacencies that belong to the same session (e.g. for parallel interfaces >which is a common scenario). An adjacency may go down, but the session >will stay up. So the timers can be very different. One of the ways to >troubleshoot a session-down from the cli is to compare the time an >adjacency is up and the session is up. > >> > >> >4) Interface information for the LDP entity >> >------------------------------------------- >> >LDP is a discovery protocol. In many systems, the configuration of the >> >protocol is done by specifying the interfaces on which the discovery >> >should be attempted. It is not guaranteed that adjacencies will be >> >formed on these interfaces. >> >A table specifying for each LDP entity which interfaces it is running >> >on, and how many adjacencies were established on each of these >> >interfaces, would provide valuable insight for the network operator. >> >> LDP Entities do not run on interfaces. Entities are simply the >> way to configure a potential session. Please see section 3.5.1 and >> 3.5.1.1 of the MIB for further information. >> > >### My previous comment was referring to the cli, thus the >miscommunication. My point is that an LDP entity >will be associated with one or more sessions (the case where no >sessions are established is not interesting) Each session is >established thanks to one or more adjacencies, and each of these >adjacencies is running on an interface. As I stated before an entity is a "potential session" meaning that the entity contains all the configuration information needed to create a SINGLE session. > Knowing which are the interfaces >that an entity is associated with is very important. From the cli, for >many vendors, the way to configure the protocol is to specify on which >interfaces the adjacency discovery should take place. I hope this makes >my previous comment clearer. > > I believe the different optic comes from the fact that the mib was >written with ATM/FR in mind, where indeed the interface information is not >as interesting. > The DESCRIPTION of mplsLdpEntityIndex states: "...Another way to use this index is to give this the value of ifIndex. However, this is dependant on the implementation." > > > >> > >> >6) Additional identifier of the LDP Entity >> >------------------------------------------ >> >Currently the MplsLdpIdentifier is the only identifier for an LDP >> >Entity. This is based on the assumption that the LdpIdentifier will >> >be unique. However, when implementing several instances with >> >overlapping address space, this may not be true (I am thinking of the >> >vpn case). It would be good to have an additional identifier (perhaps >> >an integer) that can be used to differentiate between these otherwise >> >equal entities. (otherwise things like traps will be of limited use). >> >The linkage between this additional identifier and the instances can >> >be done separately, but I think having the hook in now will be good >> >for the future. >> >> >> There are 2 indices for this table, so am unclear as to if you are >> asking for a 2nd or 3rd index? > >### Sorry, I missed this. I wanted a 2nd index, and didn't notice there >were two already. Please ignore my comment > >> >> > >> >7) Summary information for LDP Entity >> >------------------------------------- >> >To be able to sanity check the state of the protocol on a particular >> >box, it is useful to have a snapshot of the state of the sessions for >> >each ldp entity. Something along the lines: # of operational sessions, >> >total number of sessions in all states, number of interfaces, number >> >of neighbors. The idea is for this table to be polled at regular >> >intervals, to make sure nothing is going wrong. (traps won't always be >> >the key, since they can be disabled, or may not make it) >> > >> >> As the AUGMENTS relations in the Session table indicates, there is >> one session for each entity-peer relationship. > >### Agreed, but I don't want to have to walk the entire Peer Table to >extract this information. Since this info is likely to be polled often, it >would be nice if it was readily available. These totals and other objects you are asking for are traditionally left up to an NMS to aggregate and maintain. You can certainly add them to a proprietary MIB. > >> >Traps >> >===== >> >Change in the session down trap >> >------------------------------- >> >From an operator's point of view, it is useful to know the cause for a >> >session going down. This can be passed in the trap, and would provide more >> >information than the number of unknown messages or unknown TLVs >> >received. >> > >> >mplsLdpSessionDown NOTIFICATION-TYPE >> > OBJECTS { >> > mplsLdpSesState, >> > mplsLdpSesDownReason >> > >> > } >> > STATUS current >> > DESCRIPTION >> > "If this notification is enabled to generated, >> > then this notification is sent when the >> > the value of 'mplsLdpSesState' leaves >> > the 'operational(5)' state." >> > ::= { mplsLdpNotificationPrefix 4 } >> > >> >Change in the session up trap >> >----------------------------- >> >It was not clear to me the reason whty we send the number of unknown >> >messages/tlv in the session up trap. Would you explain the usage? >> >> These 2 counters are maintained throughout the life of a session and >> so are forwarded with the traps to give extra information. > >### In the session up trap, the number of unknown messages received will >not really give the operator any useful info. I would not send this extra >info, though it can't do any harm either. > >> >> > >> >Add an adjacency-down trap >> >------------------------- >> >Losing adjacencies may lead to losing a session. (though when a >> >session is established over several adjacencies, this is not the >> >case). In any case, a user can decide if it is beneficial for his >> >network to track adjacencies going down anyway. It can be used to alert >> >the operator that something went wrong in the redundant path, and his ldp >> >session is at risk. >> > >> >> Not sure I agree with this. There may be only one adjacency and that >> is not indicative that a session is about to be closed. >> > >### I'm afraid I don't understand the comment. Are you saying there are >more than one or just one adjacency? > Yes, either situation is possible. But it seems overkill to send a trap everytime an adjacency is lost. -Joan > >> >> >> >> > >> > Thank you, >> > >> > Ina Minei >> > >> > >> > From owner-mpls@UU.NET Fri Feb 14 13:05:45 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29196 for ; Fri, 14 Feb 2003 13:05:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocaq06484 for ; Fri, 14 Feb 2003 18:09:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocaq06026; Fri, 14 Feb 2003 18:09:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQocaq14113 for mpls-outgoing; Fri, 14 Feb 2003 18:08:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocaq14060 for ; Fri, 14 Feb 2003 18:08:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocaq16108 for ; Fri, 14 Feb 2003 18:08:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocaq09835 for ; Fri, 14 Feb 2003 18:08:05 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocaq09823 for ; Fri, 14 Feb 2003 18:08:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1EI82Nh004392 for ; Fri, 14 Feb 2003 13:08:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04516 for ; Fri, 14 Feb 2003 13:08:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1EI82N21396 for mpls@uu.net; Fri, 14 Feb 2003 13:08:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocaq13616 for ; Fri, 14 Feb 2003 18:05:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocaq14602 for ; Fri, 14 Feb 2003 18:05:40 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocaq07694 for ; Fri, 14 Feb 2003 18:05:40 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocaq07685 for ; Fri, 14 Feb 2003 18:05:39 GMT Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1EI5ZNh004262; Fri, 14 Feb 2003 13:05:36 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-1-73.cisco.com [10.86.240.73]) by bucket.cisco.com (Mirapoint) with ESMTP id ACO98062; Fri, 14 Feb 2003 13:05:34 -0500 (EST) Message-Id: <5.2.0.9.2.20030214130248.03c1fde8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 13:05:31 -0500 To: jcucchiara@mindspring.com From: "Thomas D. Nadeau" Subject: Re: Comments on draft-ietf-mpls-ldp-mib-09.txt Cc: Ina Minei , mpls@UU.NET In-Reply-To: <3.0.1.32.20030213172029.00697994@pop.mindspring.com> References: <20030207145450.B16753@garnet.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:20 PM 2/13/2003 -0500, jcucchiara@mindspring.com wrote: >At 03:00 PM 2/7/03 -0800, Ina Minei wrote: > > > > Hello, > > > > Please find below a few comments on draft-ietf-mpls-ldp-mib-09.txt. > > > > Let me start by saying that moving to 4 mib modules (from version > >8 to version 9 of the draft) was an excellent step, making the > >document much easier to read and use. > >Thanks for the feedback. Most of the comments that I have >received on this re-organization are favorable also. >This was suggested by Bert W. during the IESG MIB review. > > > > > > Please find below a few additions to the MPLS-LDP-MIB module. > > > >1) Authentication information > >----------------------------- > >TCP MD5 signature is mentioned in the LDP RFC, but not in the > >mib. It is useful to know whether a session is authenticated or not. > > > > mplsLdpSesAuthenticationType OBJECT-TYPE > > SYNTAX INTEGER { > > none(0), > > md5(1) > > } > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The authentication type for this session." > > ::= { mplsLdpSessionEntry 6 } > > > > >There is some discussion of this in the archives. As you point >out this is a TCP mechanism which other protocols such as BGP or LDP >may use. As I recall the consensus about this discussion was that >it would be better to add something to the TCP MIB and not put this >in other MIBs such as LDP or BGP. As you may have noticed such an object does >not appear in the lastest drafts of the BGP4 MIB either. I believe you are correct that this was the outcome at the time. > >2) Reason for the session going down > >------------------------------------ > >From an operator's point of view, it is useful to know the cause for a > >session going down. Similar functionality can be found in the bgp mib. > >This information could be passed in the session down trap as well, > >providing a powerful debugging tool for network operators. > > > >mplsLdpSesDownReason OBJECT-TYPE > > SYNTAX INTEGER { > > holdExpired (1), > > connectionExpired (2), > > allAdjacenciesDown (3), > > badTLV (4), > > badPDU (5), > > badPacket (6), > > connectionError (7), > > peerSentNotification (8), > > unexpectedEOF (9), > > authenticationChanged (10), > > initError (11), > > gracefulRestartAbort (12), > > unknown (13) } > > MAX-ACCESS accessible-for-notify > > STATUS current > > DESCRIPTION > > "The reason why the session transitioned to nonexistent state. > > Can be one of the following: > > hold time expired, connection time expired, all adjacencies down, > > received bad tlv, received bad packet, connection error, > > received notification from peer, received unexpected end-of-file, > > authentication key was changed, error during initialization, > > graceful restart was aborted, or unknown reason." > > ::= {mplsLdpSessionEntry 7} > > >The above does not really clarify why a session was torn down. >An NMS by looking at each entity and peer in the Session in a network >should be able to discern why the session was torn down. But I think >this is a network issue, not just an individual node issue. > >As a point of clarity, are you an operator or are you giving feedback >based on conversations with an operator? > >3) Additional information for hello adjacencies > >----------------------------------------------- > >a) The mib currently provides no interface information. It is important > >to know which interface the hello adjacency is on. > > > >mplsLdpHelloAdjIntf OBJECT-TYPE > > SYNTAX InterfaceIndex > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "For a hello adjacency of type link(1), the ifIndex of the > > interface, for a hello adjacency of type targeted(2), the > > ifIndex of the loopback interface." > > ::= { mplsLdpHelloAdjacencyEntry 4 } > > > >b) It is useful to have the address information as well, though this > >can be obtained from the interface index. > >Not sure I understand this. If LSRa receives a hello message from >LSRb, why can't the NMS be smart enough to look at LSRb Entity table >to see the UDP Ports that the hello was sent out on? > > > > > >c) It is useful to have a timestamp of when this adjacency came > >up. > >It would be very close to mplsLdpSesStateLastChange, wouldn't it? >Not sure that this is really needed. > > > > >4) Interface information for the LDP entity > >------------------------------------------- > >LDP is a discovery protocol. In many systems, the configuration of the > >protocol is done by specifying the interfaces on which the discovery > >should be attempted. It is not guaranteed that adjacencies will be > >formed on these interfaces. > >A table specifying for each LDP entity which interfaces it is running > >on, and how many adjacencies were established on each of these > >interfaces, would provide valuable insight for the network operator. > >LDP Entities do not run on interfaces. Entities are simply the >way to configure a potential session. Please see section 3.5.1 and >3.5.1.1 of the MIB for further information. > > > > >5) Graceful restart information > >------------------------------- > >draft-ietf-mpls-ldp-restart-06.txt is now moving to Proposed > >Standard. It might be useful to include the graceful restart information > >at this time, in order to avoid having to add it later. > > The graceful restart info is: > >- graceful restart enabled/disabled > >- helper mode enabled/disabled > >- recovery time > >- max recovery time > >- reconnect time > > Some of this belongs to the entity, and some to the peer. If > >there is agreement on adding this information, I can write it up. > > >It is beyond the scope of this document to add new functionality. >Please note, this MIB has gone through several last calls, and has just gone >through IESG review for a second time. Also, there was an open meeting in >Nov at the >IETF. In other words, it is too late in the process of this MIB to be >adding new functionality. > >Certainly, you may create a MIB for this functionality and >propose it to the working group. > > > > >6) Additional identifier of the LDP Entity > >------------------------------------------ > >Currently the MplsLdpIdentifier is the only identifier for an LDP > >Entity. This is based on the assumption that the LdpIdentifier will > >be unique. However, when implementing several instances with > >overlapping address space, this may not be true (I am thinking of the > >vpn case). It would be good to have an additional identifier (perhaps > >an integer) that can be used to differentiate between these otherwise > >equal entities. (otherwise things like traps will be of limited use). > >The linkage between this additional identifier and the instances can > >be done separately, but I think having the hook in now will be good > >for the future. > > >There are 2 indices for this table, so am unclear as to if you are >asking for a 2nd or 3rd index? > > > > >7) Summary information for LDP Entity > >------------------------------------- > >To be able to sanity check the state of the protocol on a particular > >box, it is useful to have a snapshot of the state of the sessions for > >each ldp entity. Something along the lines: # of operational sessions, > >total number of sessions in all states, number of interfaces, number > >of neighbors. The idea is for this table to be polled at regular > >intervals, to make sure nothing is going wrong. (traps won't always be > >the key, since they can be disabled, or may not make it) > > > >As the AUGMENTS relations in the Session table indicates, there is >one session for each entity-peer relationship. > >If you are saying that you want to understand how many LSPs per session >then you need to look at the mplsLdpLspTable. > > > >Traps > >===== > >Change in the session down trap > >------------------------------- > >From an operator's point of view, it is useful to know the cause for a > >session going down. This can be passed in the trap, and would provide more > >information than the number of unknown messages or unknown TLVs > >received. > > > >mplsLdpSessionDown NOTIFICATION-TYPE > > OBJECTS { > > mplsLdpSesState, > > mplsLdpSesDownReason > > > > } > > STATUS current > > DESCRIPTION > > "If this notification is enabled to generated, > > then this notification is sent when the > > the value of 'mplsLdpSesState' leaves > > the 'operational(5)' state." > > ::= { mplsLdpNotificationPrefix 4 } > > > >Change in the session up trap > >----------------------------- > >It was not clear to me the reason whty we send the number of unknown > >messages/tlv in the session up trap. Would you explain the usage? > >These 2 counters are maintained throughout the life of a session and >so are forwarded with the traps to give extra information. > > > > >Add an adjacency-down trap > >------------------------- > >Losing adjacencies may lead to losing a session. (though when a > >session is established over several adjacencies, this is not the > >case). In any case, a user can decide if it is beneficial for his > >network to track adjacencies going down anyway. It can be used to alert > >the operator that something went wrong in the redundant path, and his ldp > >session is at risk. > > > >Not sure I agree with this. There may be only one adjacency and that >is not indicative that a session is about to be closed. > >-Joan > > > > > > > Thank you, > > > > Ina Minei > > > > "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X From owner-mpls@UU.NET Fri Feb 14 13:59:19 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01116 for ; Fri, 14 Feb 2003 13:59:19 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocaf10256 for ; Fri, 14 Feb 2003 15:21:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocaf09288; Fri, 14 Feb 2003 15:20:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQocaf07031 for mpls-outgoing; Fri, 14 Feb 2003 15:20:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocaf07017 for ; Fri, 14 Feb 2003 15:20:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocaf16749 for ; Fri, 14 Feb 2003 15:17:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocaf29329 for ; Fri, 14 Feb 2003 15:17:42 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocaf29314 for ; Fri, 14 Feb 2003 15:17:41 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1EFHdJR019658 for ; Fri, 14 Feb 2003 10:17:39 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA18975 for ; Fri, 14 Feb 2003 10:17:38 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1EFHcu09248 for mpls@uu.net; Fri, 14 Feb 2003 10:17:38 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQobxx28489 for ; Fri, 14 Feb 2003 00:18:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQobxx18631 for ; Fri, 14 Feb 2003 00:16:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxx14679 for ; Fri, 14 Feb 2003 00:16:02 GMT Received: from gamma.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gamma.isi.edu [128.9.144.145]) id QQobxx14661 for ; Fri, 14 Feb 2003 00:16:01 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h1E0FwD05096; Thu, 13 Feb 2003 16:15:58 -0800 (PST) Message-Id: <200302140015.h1E0FwD05096@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3477 on Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) Cc: rfc-editor@rfc-editor.org, mpls@UU.NET From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 13 Feb 2003 16:15:58 -0800 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3477 Title: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) Author(s): K. Kompella, Y. Rekhter Status: Standards Track Date: January 2003 Mailbox: kireeti@juniper.net, yakov@juniper.net Pages: 9 Characters: 19899 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-rsvp-unnum-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3477.txt Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. 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.echo 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030213161429.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3477 --OtherAccess Content-Type: Message/External-body; name="rfc3477.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030213161429.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Feb 14 15:39:23 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04307 for ; Fri, 14 Feb 2003 15:39:23 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocaf09943 for ; Fri, 14 Feb 2003 15:18:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocaf09486; Fri, 14 Feb 2003 15:18:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQocaf06948 for mpls-outgoing; Fri, 14 Feb 2003 15:18:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocaf06943 for ; Fri, 14 Feb 2003 15:17:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocaf22512 for ; Fri, 14 Feb 2003 15:17:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocaf29124 for ; Fri, 14 Feb 2003 15:17:32 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocaf29105 for ; Fri, 14 Feb 2003 15:17:32 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1EFHTNh015376 for ; Fri, 14 Feb 2003 10:17:29 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA18961 for ; Fri, 14 Feb 2003 10:17:29 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1EFHSU09243 for mpls@uu.net; Fri, 14 Feb 2003 10:17:28 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQobxv07818 for ; Thu, 13 Feb 2003 23:47:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQobxv06610 for ; Thu, 13 Feb 2003 23:46:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQobxv05652 for ; Thu, 13 Feb 2003 23:46:17 GMT Received: from interceptor.mahinetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: 216-174-224-194.atgi.net [216.174.224.194]) id QQobxv05633 for ; Thu, 13 Feb 2003 23:46:17 GMT Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Thu, 13 Feb 2003 15:40:24 -0800 Received: by main.mahinetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Feb 2003 15:45:58 -0800 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C9045DDBC6@main.mahinetworks.com> From: Charles Chen To: "'Sameer K'" , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Regarding Switching capability and GPID in OSPF-TE and GMPLS- RSVP Date: Thu, 13 Feb 2003 15:45:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk It is an interesting question to ask, but it may not be an issue in the real world. In your example, one can assume that a router A would like to ask the transport network to set up a PPP link dynamically to a remote router B. Let's put this in the overlay mode perspective, the router A (edge device) will request a connection to a core device (OXC). In reality, the router A has some prior knowledge or is driven by the traffic engineering policy that it wants to connect to the remote router B. At the minimum, the router A has to provide the information about the router B (destination address in the transport network), the path constraints and so on. It is not possible to build a network that provides all possible application level information. The above issue makes no difference from that a user A establishes a UDP connection in order to transmit JPEG video over it to a user B. The user A finds out later that the receiving user B only supports the MPEG coding scheme. Yes, it is a blocking model but scalable. Charles > -----Original Message----- > From: Sameer K [mailto:sameerdw@yahoo.com] > Sent: Thursday, February 13, 2003 3:01 PM > To: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Regarding Switching capability and GPID in OSPF-TE and > GMPLS-RSVP > > > Hello All, > > I have some questions regarding switching capability > descriptor, encoding type and GPID parameters, and the > correlation between the values signaled in signaling > request and the values advertised in OSPF TE LSAs. > > From the previous discussions, it appears that if a > data capable device has to establish LSP through a > network of OXCs, the switching type requested would be > FSC, the encoding type would be SDH/SONET with GPID > being PPP (assuming that the data device that is LSP > ingress wants to send IP data over the LSP). Now, the > LSP will be established without any problem as long as > the destination node is advertising a switching > capability FSC and the encoding type SONET/SDH for all > its interfaces. > > However, for the LSP to be of any use to ingress node, > the destination must be capable of terminating PPP > (which in turn requires data capability on the > incoming interface of egress node). The way to ensure > this would be to read GPID and then egress can reject > the LSP if it cannot support the GPID. > > However, what if destination is a multi-service switch > and bears certain interfaces that are FSC capable and > can terminate PPP as well (that is, support data over > FSC -if you will), other than the FSC only interfaces. > CSPF running at ingress can never tell the difference > between these (data over FSC type) interfaces and > other (FSC only) interfaces and the LSP might end up > on an interface that cannot support PPP termination. > In such a case, even though the node supports PPP at > certain interfaces, the LSP will have to be rejected. > > > Now, if some "higher layer" information (PPP > termination capability for this example), is > advertised as a part of OSPF TE LSAs, the CSPF running > on the ingress node can pick up the correct incoming > interface on egress node based on the GPID desired, > thus reducing the probability of LSP failures. > > Would like to hear opinions. > TIA > - Sameer. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com > From owner-mpls@UU.NET Fri Feb 14 16:17:21 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05260 for ; Fri, 14 Feb 2003 16:17:21 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocbd20616 for ; Fri, 14 Feb 2003 21:21:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocbd20467; Fri, 14 Feb 2003 21:21:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQocbd24841 for mpls-outgoing; Fri, 14 Feb 2003 21:20:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocbd24836 for ; Fri, 14 Feb 2003 21:20:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocbd14759 for ; Fri, 14 Feb 2003 21:19:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocbd11265 for ; Fri, 14 Feb 2003 21:19:52 GMT Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [64.221.212.135]) id QQocbd11253 for ; Fri, 14 Feb 2003 21:19:51 GMT Received: from amalisxp.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Feb 2003 13:19:48 -0800 Message-Id: <5.2.0.9.0.20030214155201.043ebe30@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 16:05:57 -0500 To: Loa Andersson From: "Andrew G. Malis" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Cc: mpls@UU.NET, ccamp@ops.ietf.org, pwe3@ietf.org In-Reply-To: <200302141143.GAA16759@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Feb 2003 21:19:48.0576 (UTC) FILETIME=[CDE71600:01C2D46E] Sender: owner-mpls@UU.NET Precedence: bulk Loa, I assume that the mpls and ccamp lists are the appropriate places for discussion of this draft. I also included the pwe3 list, since this also affects the work in that WG. I apologize for the crossposts to those of you on more than one of these lists (including myself). Perhaps once the discussion has started, we can pick just one place to continue it. My initial reaction on reading your draft was that I didn't see any discussion of the pwe3 WG, which as you know is specifying extensions to RFC 3036. For the purposes of your draft, would pwe3 be classified as a "protocol specifying working group"? And is it your intention that the current work in the pwe3 WG be approved by the "requirement evaluating working group" prior to its documents being published as RFCs? Or would this be grandfathered in as already having been chartered by the IESG? Thanks, Andy ------- At 2/14/2003 06:43 AM -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : MPLS and GMPLS Change Process > Author(s) : L. Andersson > Filename : draft-andersson-mpls-g-chng-proc-00.txt > Pages : 11 > Date : 2003-2-13 > >This memo describes the process through which individuals, working >groups and external standards bodies can influence the development of >MPLS and GMPLS standards. With respect to standardization, this >process means that (G)MPLS extensions and changes can be done through >the IETF only, the body that created the (G)MPLS technology. The >IETF will not publish a (G)MPLS technology extension RFC outside of >the processes described here. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-andersson-mpls-g-chng-proc-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-13152703.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt > > From owner-mpls@UU.NET Fri Feb 14 17:14:54 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07268 for ; Fri, 14 Feb 2003 17:14:54 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocbh14551 for ; Fri, 14 Feb 2003 22:18:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocbh13727; Fri, 14 Feb 2003 22:18:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQocbh16687 for mpls-outgoing; Fri, 14 Feb 2003 22:17:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocbh16679 for ; Fri, 14 Feb 2003 22:17:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocbh22531 for ; Fri, 14 Feb 2003 22:17:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocbh06309 for ; Fri, 14 Feb 2003 22:17:23 GMT Received: from maila.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maila.telia.com [194.22.194.231]) id QQocbh06265 for ; Fri, 14 Feb 2003 22:17:21 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maila.telia.com (8.12.5/8.12.5) with ESMTP id h1EMH1Xr004785; Fri, 14 Feb 2003 23:17:02 +0100 (CET) X-Original-Recipient: mpls@uu.net Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1EMGx220659; Fri, 14 Feb 2003 23:16:59 +0100 (CET) Message-ID: <3E4D69F3.6080900@pi.se> Date: Fri, 14 Feb 2003 23:13:07 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Andrew G. Malis" CC: mpls@UU.NET, ccamp@ops.ietf.org, pwe3@ietf.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <5.2.0.9.0.20030214155201.043ebe30@po1.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Andy, when writing the draft we briefly discussed whether to mention pwe3 or not, I gather that ther were different reasons for different people not to. The mpls and ccamp wg-chairs and the SubIP ADs had discussed the process for some time, on my part I did not want to delay publication by throwing this on the pwe3 chair just minutes before the prublication. I also think that there is an issue that pwe3 is not squarely within what we define as (G)MPLS technology, pwe3 is an end to end technology and that is why it is in transport. This could be splitting hairs by an axe, we took the decision to publish to get the type of reaction you given us here. The draft is out there to be discussed. If the pwe3 were to take up those extensions to ldp today, we would ask for problem description and requirments, on my part it is not my intention (and I don't think of any of the other authors) to retro-engineer existing work to fit the process. You might have noticed that I gave Jerry Ash the same answer when he suggested that the mpls should take up work on header compression over mpls. But since his work is not accepted or rejected yet, give us as much of the information as possible in the format we want to have in the change process. Though he has a certain freedom here. pwe3 in specifying extensions to ldp, would be a "protocol specifying working group", but note that this does not automatically transmorgraphies it into a (g)mpls technology working group. If you suggest that the pwe3 wg should be included as one of the (g)mpls technology working groups, then I suggest that you give us text to be discussed and if a consensus is reached included in the draft. Personally I would like to hear the transport ADs and pwe3 wg chairs opinion on this. Strictly I don't think we can require that people follow the process until the IESG has OKed it, but as a wg chair I can clearly have an opinion on how and where work on protocols specified by the mpls wg are done and how the mpls wg takes on new work. To avoid cross-posts I suggest that we taken the discussion on the draft-andersson-mpls-g-chng-proc-00.txt on the mpls list :). We will allocate time in both the mpls and ccamp working group meetings in SF to discuss this. /Loa Andrew G. Malis wrote: > Loa, > > I assume that the mpls and ccamp lists are the appropriate places for > discussion of this draft. I also included the pwe3 list, since this > also affects the work in that WG. I apologize for the crossposts to > those of you on more than one of these lists (including myself). > Perhaps once the discussion has started, we can pick just one place to > continue it. > > My initial reaction on reading your draft was that I didn't see any > discussion of the pwe3 WG, which as you know is specifying extensions > to RFC 3036. For the purposes of your draft, would pwe3 be classified > as a "protocol specifying working group"? And is it your intention > that the current work in the pwe3 WG be approved by the "requirement > evaluating working group" prior to its documents being published as > RFCs? Or would this be grandfathered in as already having been > chartered by the IESG? > > Thanks, > Andy > > ------- > > At 2/14/2003 06:43 AM -0500, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : MPLS and GMPLS Change Process >> Author(s) : L. Andersson >> Filename : draft-andersson-mpls-g-chng-proc-00.txt >> Pages : 11 >> Date : 2003-2-13 >> >> This memo describes the process through which individuals, working >> groups and external standards bodies can influence the development of >> MPLS and GMPLS standards. With respect to standardization, this >> process means that (G)MPLS extensions and changes can be done through >> the IETF only, the body that created the (G)MPLS technology. The >> IETF will not publish a (G)MPLS technology extension RFC outside of >> the processes described here. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt >> >> >> To remove yourself from the IETF Announcement list, send a message to >> ietf-announce-request with the word unsubscribe in the body of the >> message. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-andersson-mpls-g-chng-proc-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2003-2-13152703.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt >> >> >> > > > > From owner-mpls@UU.NET Mon Feb 17 18:35:31 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04003 for ; Mon, 17 Feb 2003 18:35:31 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocmo21966 for ; Mon, 17 Feb 2003 23:39:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocmo21622; Mon, 17 Feb 2003 23:39:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQocmo22957 for mpls-outgoing; Mon, 17 Feb 2003 23:38:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocmo22944 for ; Mon, 17 Feb 2003 23:38:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocmo25615 for ; Mon, 17 Feb 2003 23:38:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocmo15516 for ; Mon, 17 Feb 2003 23:38:13 GMT Received: from sa.infonet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sa.infonet.com [192.157.130.21]) id QQocmo15493 for ; Mon, 17 Feb 2003 23:38:12 GMT Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id h1HNbwge020942; Mon, 17 Feb 2003 23:37:58 GMT Received: from zhangr2.info.net (lasi254.us.info.net [204.140.71.254]) by delta.info.net with ESMTP id XAA29965; Mon, 17 Feb 2003 23:37:55 GMT Message-Id: <5.1.0.14.0.20030216140944.0281f240@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 16 Feb 2003 14:16:24 -0800 To: "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" From: raymond zhang Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression Cc: "Ash, Gerald R (Jerry), ALABS" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" In-Reply-To: <28F05913385EAC43AF019413F674A01704A1770F@OCCLUST04EVS1.ugd .att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Jerry, The draft "http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt" and "http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt" indeed touch upon a practical requirement for SPs offering VoIP over their networks. I'd support the suggestion of MPLS WG taking the lead on such efforts as discussed in this draft, perhaps in coordination with other WGs. Regards, Raymond At 04:05 PM 2/12/2003 -0500, Ash, Gerald R (Jerry), ALABS wrote: >All, > >I'd like to propose that the MPLS WG take on work regarding VoIP over MPLS >header compression. This work was earlier accepted for consideration by >the MPLS WG (see the background summary below). > >Two I-D's related to this work are at: >http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt >(George is added as co-author in the next rev) > >http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt > >Please review the documents and raise any issues/comments to the list. > >The work was presented at the IETF-55 PWE3 WG meeting (slides and meetings >notes at http://ietf.org/proceedings/02nov/index.html). It was generally >agreed that the work did not fit well in PWE3, and that MPLS might be the >best overall fit. > >I propose a brief time slot at the IETF-56 MPLS WG meeting to very briefly >review the above proposals and issues, and get a sense of the room. > >Comments welcome > >Thanks, >Jerry Ash > >Background: > >Some service providers (such as AT&T) have plans to migrate large amounts >of legacy voice traffic to VoIP, as well as to provide VPN services >enabling VoIP. VoIP over MPLS ('VoMPLS') typically uses the encapsulation >voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 >bytes, while the voice payload is typically no more than 30 bytes. VoIP >over MPLS header compression can significantly reduce the VoIP overhead >through various compression mechanisms. This is important on access links >where bandwidth is scarce, and can be important on backbone facilities, >especially where costs are high (e.g., some global cross-sections). > >VoIP over MPLS header compression methods have been proposed earlier >(March, 2000) in the MPLS working group, however the relevant drafts have >expired. In particular, George Swallow and Lou Berger proposed a 'simple' >end-to-end compression scheme in which all first-order differences in the >RTP/UDP/IP headers were transmitted, and in which the header compression >context was established through RSVP signaling. The work was accepted >into the MPLS WG pending an addition to the MPLS WG charter. > >In the I-D's we propose 3 approaches to VoMPLS header compression: a) >re-use the methods in cRTP to determine the context and MPLS to route >packets, b) re-use the methods in Swallow's and Berger's 'simple' approach >to determine the context and MPLS to route packets, and c) re-use the >methods in cRTP to determine the context and the SCID (session context ID) >to route packets. > >Issues to discuss: > >1. WG charter -- The VoMPLS header compression work is not within the >current charter of the MPLS WG, so a charter extension is needed. George >said he 'would have no objection to the work being done in MPLS'... but >suggested that the 'work fits more closely in the Transport Area/PWE3 WG' >(which is why it was brought there first). > >2. Protocol extensions -- As detailed in the I-Ds, extensions are proposed >to [cRTP] and [cRTP-ENHANCE], which involve a new packet type field to >identify FULL_HEADER, CONTEXT_STATE, etc. packets. New objects are >defined for [RSVP-TE]. Extensions are also proposed to RFC2547 VPNs, >which create 'SCID routing tables' to allow routing based on the session >context ID (SCID). These extensions need coordination with other WGs >(MPLS, CCAMP, AVT, ROHC, PPVPN, etc.). > >3. Resynchronization -- E2E VoMPLS using cRTP header compression might not >perform well with frequent resynchronizations. The applicability and >performance need to be addressed (the 'simple' header compression approach >would avoid the need for resynchronization, but achieves less efficiency >than cRTP). > >4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps require a >large number of LSPs to be created. There is concern for CE ability to do >the necessary processing and the scalability of the architecture. > >4. LDP application -- It would be desirable to signal the VoMPLS tunnels >with LDP, since many RFC2547 VPN implementations use LDP as the underlying >LSP signaling mechanism. From owner-mpls@UU.NET Tue Feb 18 11:45:01 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01669 for ; Tue, 18 Feb 2003 11:45:01 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpf10292 for ; Tue, 18 Feb 2003 16:48:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocpf10150; Tue, 18 Feb 2003 16:48:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQocpf19041 for mpls-outgoing; Tue, 18 Feb 2003 16:48:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocpf19032 for ; Tue, 18 Feb 2003 16:48:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocpf08613 for ; Tue, 18 Feb 2003 16:47:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpf14831 for ; Tue, 18 Feb 2003 16:47:37 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocpf14784 for ; Tue, 18 Feb 2003 16:47:35 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1IGlRJR013613 for ; Tue, 18 Feb 2003 11:47:33 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA06422 for ; Tue, 18 Feb 2003 11:47:24 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1IGlNK09142 for mpls@uu.net; Tue, 18 Feb 2003 11:47:23 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocmr14151 for ; Tue, 18 Feb 2003 00:15:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocmq12998 for ; Tue, 18 Feb 2003 00:14:41 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocmq00959 for ; Tue, 18 Feb 2003 00:14:41 GMT Received: from smtp1.phx.gblx.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQocmq00949 for ; Tue, 18 Feb 2003 00:14:40 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1I0Ed317476 for ; Mon, 17 Feb 2003 17:14:39 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAA2faWgI; Mon Feb 17 17:14:33 2003 Received: (from mmeyer@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) id RAA05827 for mpls@UU.NET; Mon, 17 Feb 2003 17:14:33 -0700 (MST) Date: Mon, 17 Feb 2003 17:14:33 -0700 From: Matthew Meyer To: mpls@UU.NET Subject: draft-meyer-mpls-soft-preemption-00.txt Message-ID: <20030218001433.GS10825@gblx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Folks, There have been some off line conversations showing interest regarding this draft. Would anyone be willing to comment on- list? Matthew From owner-mpls@UU.NET Tue Feb 18 12:42:17 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02809 for ; Tue, 18 Feb 2003 12:42:16 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpj10744 for ; Tue, 18 Feb 2003 17:46:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocpj10377; Tue, 18 Feb 2003 17:45:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQocpj11879 for mpls-outgoing; Tue, 18 Feb 2003 17:45:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocpj11868 for ; Tue, 18 Feb 2003 17:45:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocpj10324 for ; Tue, 18 Feb 2003 17:45:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpj10524 for ; Tue, 18 Feb 2003 17:45:05 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocpj10500 for ; Tue, 18 Feb 2003 17:45:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1IHj2Nh026404 for ; Tue, 18 Feb 2003 12:45:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA10621 for ; Tue, 18 Feb 2003 12:45:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1IHj1a14459 for mpls@uu.net; Tue, 18 Feb 2003 12:45:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocpi11537 for ; Tue, 18 Feb 2003 17:44:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocpi02241 for ; Tue, 18 Feb 2003 17:43:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpi12948 for ; Tue, 18 Feb 2003 17:43:04 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocpi12892 for ; Tue, 18 Feb 2003 17:43:02 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA72563; Tue, 18 Feb 2003 12:42:26 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302181742.MAA72563@workhorse.fictitious.org> To: raymond zhang cc: "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Sun, 16 Feb 2003 14:16:24 PST." <5.1.0.14.0.20030216140944.0281f240@delta.info.net> Date: Tue, 18 Feb 2003 12:42:26 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.1.0.14.0.20030216140944.0281f240@delta.info.net>, raymond zhang w rites: > Hi Jerry, > > The draft > "http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt > " > and > "http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt" > indeed touch upon a practical requirement for SPs offering VoIP over their > networks. I'd support the suggestion of MPLS WG taking the lead on such > efforts as discussed in this draft, perhaps in coordination with other WGs. > > Regards, > Raymond Raymond, Since you spoke in support of this and mention "practical requirement for SPs offering VoIP", I'd be interested to hear 1) which service provider is using gear that sends 30 byte payloads, 2) which gear is sending 30 byte payloads. I just spoke to someone at another SP yesterday about other things and asked about packet sizes in the VOIP deployment. The gear is Sonus and the packet sizes were said to be "oh I don't know, I think about 200 on average but might depend on content due to silence suppression and compression". That is a far cry from 30 byte payloads. It may be that some voice over ATM gear sends a 30 byte payload in a 55 byte cell. That's stupid to start with. Ten cells would get you 480 bytes minus some for LLC/SNAP if used plus AAL trailer for at least 450 payload. That's 15 times the payload for 10 times the cells allowing 50% more capacity on the same network. A more moderate 224 byte payload could be fit in 5 cells still yielding close to a 50% gain. But voice over ATM gear didn't do it that way. Some voice over ATM product did things in a stupid way. There is no point in perpetuating this. If the problem is migrating from these then a better way to do the migration might be to put new VOIP gear on the edges to replace the voice over ATM gear. Use voice over RTP/UDP/IP/MPLS/ATM temporarily. This will still be more efficient that using 30 byte payloads in ATM or 30 byte payloads in RTP/UDP/IP/MPLS or RTP/UDP/MPLS with header compression. Then gradually get rid of the ATM. Alternately if the SP needs to keep the voice/ATM gear the SP will need some sort of gateway to the modern world. Whether doing this or not it would be good to get the voice/ATM vendor to change their gear to use a larger frame rather than voice in individual cells, but that may be unlikely to happen. If anyone is going to make a voice/ATM to voice/*/MPLS gateway (or IWU if you prefer that term), and wants to improve efficiency, it would make more sense to go RTP/UDP/IP/MPLS and don't bother leaving out IP and UDP or doing RTP header compression but collect multiple ATM cells and build a bigger payload. Curtis > At 04:05 PM 2/12/2003 -0500, Ash, Gerald R (Jerry), ALABS wrote: > >All, > > > >I'd like to propose that the MPLS WG take on work regarding VoIP over MPLS > >header compression. This work was earlier accepted for consideration by > >the MPLS WG (see the background summary below). > > > >Two I-D's related to this work are at: > >http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt > > >(George is added as co-author in the next rev) > > > >http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt > > > >Please review the documents and raise any issues/comments to the list. > > > >The work was presented at the IETF-55 PWE3 WG meeting (slides and meetings > >notes at http://ietf.org/proceedings/02nov/index.html). It was generally > >agreed that the work did not fit well in PWE3, and that MPLS might be the > >best overall fit. > > > >I propose a brief time slot at the IETF-56 MPLS WG meeting to very briefly > >review the above proposals and issues, and get a sense of the room. > > > >Comments welcome > > > >Thanks, > >Jerry Ash > > > >Background: > > > >Some service providers (such as AT&T) have plans to migrate large amounts > >of legacy voice traffic to VoIP, as well as to provide VPN services > >enabling VoIP. VoIP over MPLS ('VoMPLS') typically uses the encapsulation > >voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 > >bytes, while the voice payload is typically no more than 30 bytes. VoIP > >over MPLS header compression can significantly reduce the VoIP overhead > >through various compression mechanisms. This is important on access links > >where bandwidth is scarce, and can be important on backbone facilities, > >especially where costs are high (e.g., some global cross-sections). > > > >VoIP over MPLS header compression methods have been proposed earlier > >(March, 2000) in the MPLS working group, however the relevant drafts have > >expired. In particular, George Swallow and Lou Berger proposed a 'simple' > >end-to-end compression scheme in which all first-order differences in the > >RTP/UDP/IP headers were transmitted, and in which the header compression > >context was established through RSVP signaling. The work was accepted > >into the MPLS WG pending an addition to the MPLS WG charter. > > > >In the I-D's we propose 3 approaches to VoMPLS header compression: a) > >re-use the methods in cRTP to determine the context and MPLS to route > >packets, b) re-use the methods in Swallow's and Berger's 'simple' approach > >to determine the context and MPLS to route packets, and c) re-use the > >methods in cRTP to determine the context and the SCID (session context ID) > >to route packets. > > > >Issues to discuss: > > > >1. WG charter -- The VoMPLS header compression work is not within the > >current charter of the MPLS WG, so a charter extension is needed. George > >said he 'would have no objection to the work being done in MPLS'... but > >suggested that the 'work fits more closely in the Transport Area/PWE3 WG' > >(which is why it was brought there first). > > > >2. Protocol extensions -- As detailed in the I-Ds, extensions are proposed > >to [cRTP] and [cRTP-ENHANCE], which involve a new packet type field to > >identify FULL_HEADER, CONTEXT_STATE, etc. packets. New objects are > >defined for [RSVP-TE]. Extensions are also proposed to RFC2547 VPNs, > >which create 'SCID routing tables' to allow routing based on the session > >context ID (SCID). These extensions need coordination with other WGs > >(MPLS, CCAMP, AVT, ROHC, PPVPN, etc.). > > > >3. Resynchronization -- E2E VoMPLS using cRTP header compression might not > >perform well with frequent resynchronizations. The applicability and > >performance need to be addressed (the 'simple' header compression approach > >would avoid the need for resynchronization, but achieves less efficiency > >than cRTP). > > > >4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps require a > >large number of LSPs to be created. There is concern for CE ability to do > >the necessary processing and the scalability of the architecture. > > > >4. LDP application -- It would be desirable to signal the VoMPLS tunnels > >with LDP, since many RFC2547 VPN implementations use LDP as the underlying > >LSP signaling mechanism. > > > From owner-mpls@UU.NET Tue Feb 18 14:29:10 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05962 for ; Tue, 18 Feb 2003 14:29:10 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpq06914 for ; Tue, 18 Feb 2003 19:32:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocpq05333; Tue, 18 Feb 2003 19:32:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQocpq27046 for mpls-outgoing; Tue, 18 Feb 2003 19:31:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocpq27041 for ; Tue, 18 Feb 2003 19:31:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocpq13410 for ; Tue, 18 Feb 2003 19:31:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpq03507 for ; Tue, 18 Feb 2003 19:31:29 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocpq02395 for ; Tue, 18 Feb 2003 19:31:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1IJV2Nh002771 for ; Tue, 18 Feb 2003 14:31:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18995 for ; Tue, 18 Feb 2003 14:31:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1IJV2w21568 for mpls@uu.net; Tue, 18 Feb 2003 14:31:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocpq26825 for ; Tue, 18 Feb 2003 19:30:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocpp08698 for ; Tue, 18 Feb 2003 19:28:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpp24708 for ; Tue, 18 Feb 2003 19:28:49 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocpp24691 for ; Tue, 18 Feb 2003 19:28:48 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA72985; Tue, 18 Feb 2003 14:28:13 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302181928.OAA72985@workhorse.fictitious.org> To: Matthew Meyer cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-reply-to: Your message of "Mon, 17 Feb 2003 17:14:33 MST." <20030218001433.GS10825@gblx.net> Date: Tue, 18 Feb 2003 14:28:13 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20030218001433.GS10825@gblx.net>, Matthew Meyer writes: > Folks, > > There have been some off line conversations showing interest > regarding this draft. Would anyone be willing to comment on- > list? > > Matthew As one of the offliners I'd like to say that this is much needed. Every ISP that we talk to regards preemption as a hole in the MPLS protocols that if utilized renders make-before-break and fast-reroute ineffective. Soft preemption fixes that. I also support using the RRO as described in the draft. It is the best way to accomplish soft preemption. It is saying exactly what is happenning, namely that the LSP is still up but it is about to go down so do something top avoid having bits dropped. The one thing I would add is some object or bit somewhere that indicates that the ingress is capable of understanding and acting on the "Preemption pending" bit. If the midpoint where the preemption occurs knows that the ingress is capable of dealing with the "Preemption pending" bit, it can do a soft preemption. If not, then the midpoint might as well do a hard preemption, because the older ingress does not understand the "Preemption pending" bit and will ignore it. Non-broken midpoint LSRs already have to pass on changes to the "Local protection available" and "Local protection in use" bits back to the ingress. Non-broken ingress LSRs already have to (or should) act upon changes to the "Local protection available" and "Local protection in use" bits. Adding a "Preemption pending" bit to the same bitmask poses no additional scaling issues for existing non-broken routers. There might be some partially broken implementations that currently don't look at "RRO IPv4/IPv6 Sub-Object Flags" and don't pass along changes to it or act on it but they have to be fixed to support existing fast-reroute related capabilities. Curtis From owner-mpls@UU.NET Tue Feb 18 14:38:05 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06284 for ; Tue, 18 Feb 2003 14:38:05 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpq14188 for ; Tue, 18 Feb 2003 19:41:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocpq13478; Tue, 18 Feb 2003 19:41:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQocpq27793 for mpls-outgoing; Tue, 18 Feb 2003 19:41:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocpq27739 for ; Tue, 18 Feb 2003 19:41:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocpq16063 for ; Tue, 18 Feb 2003 19:40:25 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpq12244 for ; Tue, 18 Feb 2003 19:40:23 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQocpq12209 for ; Tue, 18 Feb 2003 19:40:22 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1IJeDS75985; Tue, 18 Feb 2003 11:40:13 -0800 (PST) (envelope-from ina@juniper.net) Date: Tue, 18 Feb 2003 11:40:13 -0800 (PST) From: Ina Minei To: Curtis Villamizar cc: Matthew Meyer , "" Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-Reply-To: <200302181928.OAA72985@workhorse.fictitious.org> Message-ID: <20030218113816.O88996@garnet.juniper.net> References: <200302181928.OAA72985@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Please find comments inline below. Ina On Tue, 18 Feb 2003, Curtis Villamizar wrote: > > The one thing I would add is some object or bit somewhere that > indicates that the ingress is capable of understanding and acting on > the "Preemption pending" bit. If the midpoint where the preemption > occurs knows that the ingress is capable of dealing with the > "Preemption pending" bit, it can do a soft preemption. If not, then > the midpoint might as well do a hard preemption, because the older > ingress does not understand the "Preemption pending" bit and will > ignore it. The HE LSR is the one requesting soft-preemption by setting the flag in the session attribute object. A transit will only send a Resv message with the RRO 'Preemption Pending' bit set if it previously received a path message requesting soft-preemption, meaning that the HE always knows how to handle it. > > Non-broken midpoint LSRs already have to pass on changes to the "Local > protection available" and "Local protection in use" bits back to the > ingress. Non-broken ingress LSRs already have to (or should) act upon > changes to the "Local protection available" and "Local protection in > use" bits. Adding a "Preemption pending" bit to the same bitmask > poses no additional scaling issues for existing non-broken routers. > > There might be some partially broken implementations that currently > don't look at "RRO IPv4/IPv6 Sub-Object Flags" and don't pass along > changes to it or act on it but they have to be fixed to support > existing fast-reroute related capabilities. > From owner-mpls@UU.NET Tue Feb 18 19:05:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12288 for ; Tue, 18 Feb 2003 19:05:52 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocqi01346 for ; Wed, 19 Feb 2003 00:09:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocqi00951; Wed, 19 Feb 2003 00:09:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQocqi19508 for mpls-outgoing; Wed, 19 Feb 2003 00:09:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocqi19503 for ; Wed, 19 Feb 2003 00:08:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocqi12958 for ; Wed, 19 Feb 2003 00:07:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocqi02396 for ; Wed, 19 Feb 2003 00:07:18 GMT Received: from sa.infonet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sa.infonet.com [192.157.130.21]) id QQocqi02372 for ; Wed, 19 Feb 2003 00:07:17 GMT Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id h1J06Jbi014020; Wed, 19 Feb 2003 00:06:19 GMT Received: from zhangr2.info.net (sfjl114.us.info.net [204.79.139.114]) by delta.info.net with ESMTP id AAA16513; Wed, 19 Feb 2003 00:06:16 GMT Message-Id: <5.1.0.14.0.20030218154944.0283e668@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Feb 2003 16:03:55 -0800 To: curtis@fictitious.org From: raymond zhang Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression Cc: "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" In-Reply-To: <200302181742.MAA72563@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Curtis, At 12:42 PM 2/18/2003 -0500, Curtis Villamizar wrote: >In message <5.1.0.14.0.20030216140944.0281f240@delta.info.net>, raymond >zhang w >rites: > > Hi Jerry, > > > > The draft > > > "http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt > > " > > and > > > "http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt" > > indeed touch upon a practical requirement for SPs offering VoIP over their > > networks. I'd support the suggestion of MPLS WG taking the lead on such > > efforts as discussed in this draft, perhaps in coordination with other WGs. > > > > Regards, > > Raymond > > >Raymond, > >Since you spoke in support of this and mention "practical requirement >for SPs offering VoIP", I'd be interested to hear 1) which service >provider is using gear that sends 30 byte payloads, 2) which gear is >sending 30 byte payloads. The practicality in my previous email pertains to the requirement for e2e compressed path for VoIP packets, not about the feasibility of offering "VoIP" over SP's network. Regarding payload size, firstly the voice frame size varies with the ITU codecs selected on the CPE. For example, G.729a has 10ms per voice sampling frame and one could configure to stuff either two or three frames per VoIP packet... Hence 20 to 30 byte payload. Larger payload size may present an issue in terms of loss, esp for a global network since loss of one packet would result in multiple voice frame losses. As for vendors, I'd say any CPE vendors should have this capability built in... >I just spoke to someone at another SP yesterday about other things and >asked about packet sizes in the VOIP deployment. The gear is Sonus >and the packet sizes were said to be "oh I don't know, I think about >200 on average but might depend on content due to silence suppression >and compression". That is a far cry from 30 byte payloads. > >It may be that some voice over ATM gear sends a 30 byte payload in a >55 byte cell. That's stupid to start with. Ten cells would get you >480 bytes minus some for LLC/SNAP if used plus AAL trailer for at >least 450 payload. That's 15 times the payload for 10 times the cells >allowing 50% more capacity on the same network. A more moderate 224 >byte payload could be fit in 5 cells still yielding close to a 50% >gain. But voice over ATM gear didn't do it that way. > >Some voice over ATM product did things in a stupid way. There is no >point in perpetuating this. If the problem is migrating from these >then a better way to do the migration might be to put new VOIP gear on >the edges to replace the voice over ATM gear. Use voice over >RTP/UDP/IP/MPLS/ATM temporarily. This will still be more efficient >that using 30 byte payloads in ATM or 30 byte payloads in >RTP/UDP/IP/MPLS or RTP/UDP/MPLS with header compression. Then >gradually get rid of the ATM. > >Alternately if the SP needs to keep the voice/ATM gear the SP will >need some sort of gateway to the modern world. Whether doing this or >not it would be good to get the voice/ATM vendor to change their gear >to use a larger frame rather than voice in individual cells, but that >may be unlikely to happen. If anyone is going to make a voice/ATM to >voice/*/MPLS gateway (or IWU if you prefer that term), Not likely >and wants to >improve efficiency, it would make more sense to go RTP/UDP/IP/MPLS and >don't bother leaving out IP and UDP or doing RTP header compression >but collect multiple ATM cells and build a bigger payload. In the cases I am thinking of, voice frames are encaped in RTP/UDP/IP and transported over a MPLS network directly in frame mode... Regards, Raymond >Curtis > > > > At 04:05 PM 2/12/2003 -0500, Ash, Gerald R (Jerry), ALABS wrote: > > >All, > > > > > >I'd like to propose that the MPLS WG take on work regarding VoIP over > MPLS > > >header compression. This work was earlier accepted for consideration by > > >the MPLS WG (see the background summary below). > > > > > >Two I-D's related to this work are at: > > >http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-0 > 0.txt > > > > >(George is added as co-author in the next rev) > > > > > >http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt > > > > > >Please review the documents and raise any issues/comments to the list. > > > > > >The work was presented at the IETF-55 PWE3 WG meeting (slides and > meetings > > >notes at http://ietf.org/proceedings/02nov/index.html). It was generally > > >agreed that the work did not fit well in PWE3, and that MPLS might be the > > >best overall fit. > > > > > >I propose a brief time slot at the IETF-56 MPLS WG meeting to very > briefly > > >review the above proposals and issues, and get a sense of the room. > > > > > >Comments welcome > > > > > >Thanks, > > >Jerry Ash > > > > > >Background: > > > > > >Some service providers (such as AT&T) have plans to migrate large amounts > > >of legacy voice traffic to VoIP, as well as to provide VPN services > > >enabling VoIP. VoIP over MPLS ('VoMPLS') typically uses the > encapsulation > > >voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 > > >bytes, while the voice payload is typically no more than 30 bytes. VoIP > > >over MPLS header compression can significantly reduce the VoIP overhead > > >through various compression mechanisms. This is important on access > links > > >where bandwidth is scarce, and can be important on backbone facilities, > > >especially where costs are high (e.g., some global cross-sections). > > > > > >VoIP over MPLS header compression methods have been proposed earlier > > >(March, 2000) in the MPLS working group, however the relevant drafts have > > >expired. In particular, George Swallow and Lou Berger proposed a > 'simple' > > >end-to-end compression scheme in which all first-order differences in the > > >RTP/UDP/IP headers were transmitted, and in which the header compression > > >context was established through RSVP signaling. The work was accepted > > >into the MPLS WG pending an addition to the MPLS WG charter. > > > > > >In the I-D's we propose 3 approaches to VoMPLS header compression: a) > > >re-use the methods in cRTP to determine the context and MPLS to route > > >packets, b) re-use the methods in Swallow's and Berger's 'simple' > approach > > >to determine the context and MPLS to route packets, and c) re-use the > > >methods in cRTP to determine the context and the SCID (session context > ID) > > >to route packets. > > > > > >Issues to discuss: > > > > > >1. WG charter -- The VoMPLS header compression work is not within the > > >current charter of the MPLS WG, so a charter extension is needed. George > > >said he 'would have no objection to the work being done in MPLS'... but > > >suggested that the 'work fits more closely in the Transport Area/PWE3 WG' > > >(which is why it was brought there first). > > > > > >2. Protocol extensions -- As detailed in the I-Ds, extensions are > proposed > > >to [cRTP] and [cRTP-ENHANCE], which involve a new packet type field to > > >identify FULL_HEADER, CONTEXT_STATE, etc. packets. New objects are > > >defined for [RSVP-TE]. Extensions are also proposed to RFC2547 VPNs, > > >which create 'SCID routing tables' to allow routing based on the session > > >context ID (SCID). These extensions need coordination with other WGs > > >(MPLS, CCAMP, AVT, ROHC, PPVPN, etc.). > > > > > >3. Resynchronization -- E2E VoMPLS using cRTP header compression might > not > > >perform well with frequent resynchronizations. The applicability and > > >performance need to be addressed (the 'simple' header compression > approach > > >would avoid the need for resynchronization, but achieves less efficiency > > >than cRTP). > > > > > >4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps > require a > > >large number of LSPs to be created. There is concern for CE ability > to do > > >the necessary processing and the scalability of the architecture. > > > > > >4. LDP application -- It would be desirable to signal the VoMPLS tunnels > > >with LDP, since many RFC2547 VPN implementations use LDP as the > underlying > > >LSP signaling mechanism. > > > > > > From owner-mpls@UU.NET Tue Feb 18 21:53:08 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15945 for ; Tue, 18 Feb 2003 21:53:08 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocqt23077 for ; Wed, 19 Feb 2003 02:56:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocqt10190; Wed, 19 Feb 2003 02:48:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQocqt09012 for mpls-outgoing; Wed, 19 Feb 2003 02:47:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocqt08901 for ; Wed, 19 Feb 2003 02:47:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocqt22266 for ; Wed, 19 Feb 2003 02:46:59 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocqt14701 for ; Wed, 19 Feb 2003 02:46:58 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocqt14695 for ; Wed, 19 Feb 2003 02:46:58 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1J2ktNh019945 for ; Tue, 18 Feb 2003 21:46:56 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA17674 for ; Tue, 18 Feb 2003 21:46:55 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1J2ktI15690 for mpls@uu.net; Tue, 18 Feb 2003 21:46:55 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocql23195 for ; Wed, 19 Feb 2003 00:47:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocql21085 for ; Wed, 19 Feb 2003 00:47:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocql10110 for ; Wed, 19 Feb 2003 00:47:05 GMT Received: from gamma.isi.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gamma.isi.edu [128.9.144.145]) id QQocql10104 for ; Wed, 19 Feb 2003 00:47:05 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h1J0ktD22747; Tue, 18 Feb 2003 16:46:55 -0800 (PST) Message-Id: <200302190046.h1J0ktD22747@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3469 on Framework for Multi-Protocol Label Switching (MPLS)-based Recovery Cc: rfc-editor@rfc-editor.org, mpls@UU.NET From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 18 Feb 2003 16:46:55 -0800 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3469 Title: Framework for Multi-Protocol Label Switching (MPLS)-based Recovery Author(s): V. Sharma, F. Hellstrand (Editors) Status: Informational Date: February 2003 Mailbox: v.sharma@ieee.org, fiffi@nortelnetworks.com Pages: 40 Characters: 89331 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-recovery-frmwrk-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3469.txt Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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.echo 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030218164516.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3469 --OtherAccess Content-Type: Message/External-body; name="rfc3469.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030218164516.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Feb 18 21:57:49 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15990 for ; Tue, 18 Feb 2003 21:57:49 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocpu13844; Tue, 18 Feb 2003 20:36:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQocpu20531 for mpls-outgoing; Tue, 18 Feb 2003 20:36:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocpu20351 for ; Tue, 18 Feb 2003 20:35:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocpu04015 for ; Tue, 18 Feb 2003 20:35:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpu11650 for ; Tue, 18 Feb 2003 20:35:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocpu11629 for ; Tue, 18 Feb 2003 20:35:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1IKZ2JR028407 for ; Tue, 18 Feb 2003 15:35:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA24498 for ; Tue, 18 Feb 2003 15:35:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1IKZ1626472 for mpls@uu.net; Tue, 18 Feb 2003 15:35:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocpu20290 for ; Tue, 18 Feb 2003 20:34:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocpu02888 for ; Tue, 18 Feb 2003 20:33:57 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocpu09889 for ; Tue, 18 Feb 2003 20:33:56 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocpu09851 for ; Tue, 18 Feb 2003 20:33:55 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA73412; Tue, 18 Feb 2003 15:33:23 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302182033.PAA73412@workhorse.fictitious.org> To: Ina Minei cc: Curtis Villamizar , Matthew Meyer , "" Reply-To: curtis@fictitious.org Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-reply-to: Your message of "Tue, 18 Feb 2003 11:40:13 PST." <20030218113816.O88996@garnet.juniper.net> Date: Tue, 18 Feb 2003 15:33:23 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20030218113816.O88996@garnet.juniper.net>, Ina Minei writes: > > Please find comments inline below. > > Ina > > On Tue, 18 Feb 2003, Curtis Villamizar wrote: > > > > > The one thing I would add is some object or bit somewhere that > > indicates that the ingress is capable of understanding and acting on > > the "Preemption pending" bit. If the midpoint where the preemption > > occurs knows that the ingress is capable of dealing with the > > "Preemption pending" bit, it can do a soft preemption. If not, then > > the midpoint might as well do a hard preemption, because the older > > ingress does not understand the "Preemption pending" bit and will > > ignore it. > > The HE LSR is the one requesting soft-preemption by setting the > flag in the session attribute object. A transit will only send > a Resv message with the RRO 'Preemption Pending' bit set if it > previously received a path message requesting soft-preemption, meaning > that the HE always knows how to handle it. I missed the "Soft preempted desired" bit in the SESSION-ATTRIBUTE object, sect 4.1. My fault. Thanks. Curtis From owner-mpls@UU.NET Tue Feb 18 22:48:40 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17191 for ; Tue, 18 Feb 2003 22:48:40 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocqx16789 for ; Wed, 19 Feb 2003 03:52:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocqx15956; Wed, 19 Feb 2003 03:51:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQocqx02343 for mpls-outgoing; Wed, 19 Feb 2003 03:51:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocqx02334 for ; Wed, 19 Feb 2003 03:51:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocqx22672 for ; Wed, 19 Feb 2003 03:51:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocqx16195 for ; Wed, 19 Feb 2003 03:51:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocqx16174 for ; Wed, 19 Feb 2003 03:51:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1J3p2JR016603 for ; Tue, 18 Feb 2003 22:51:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA20199 for ; Tue, 18 Feb 2003 22:51:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1J3p2I20490 for mpls@uu.net; Tue, 18 Feb 2003 22:51:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocqx02129 for ; Wed, 19 Feb 2003 03:49:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocqx15342 for ; Wed, 19 Feb 2003 03:48:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocqx14183 for ; Wed, 19 Feb 2003 03:48:46 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocqx14165 for ; Wed, 19 Feb 2003 03:48:45 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA76199; Tue, 18 Feb 2003 22:48:08 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302190348.WAA76199@workhorse.fictitious.org> To: raymond zhang cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Tue, 18 Feb 2003 16:03:55 PST." <5.1.0.14.0.20030218154944.0283e668@delta.info.net> Date: Tue, 18 Feb 2003 22:48:08 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.1.0.14.0.20030218154944.0283e668@delta.info.net>, raymond zhang w rites: > > Regarding payload size, firstly the voice frame size varies with the ITU > codecs selected on the CPE. For example, G.729a has 10ms per voice > sampling frame and one could configure to stuff either two or three frames > per VoIP packet... Hence 20 to 30 byte payload. Larger payload size may > present an issue in terms of loss, esp for a global network since loss of > one packet would result in multiple voice frame losses. > > As for vendors, I'd say any CPE vendors should have this capability built in. > .. I think the SPs should speak as to whether the bandwidth inefficiency of 30 byte payloads or the potential to lose a packet with a 200 byte is a greater problem. All of the SP I've spoken to that are doing VOIP are using diffserv EF service or otherwise insuring that voice traffic is rarely if ever dropped. Curtis From owner-mpls@UU.NET Wed Feb 19 00:54:15 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19465 for ; Wed, 19 Feb 2003 00:54:14 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocrf16024 for ; Wed, 19 Feb 2003 05:58:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocrf15346; Wed, 19 Feb 2003 05:57:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQocrf18267 for mpls-outgoing; Wed, 19 Feb 2003 05:57:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocrf18262 for ; Wed, 19 Feb 2003 05:57:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocrf26693 for ; Wed, 19 Feb 2003 05:56:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocrf13335 for ; Wed, 19 Feb 2003 05:56:24 GMT Received: from sa.infonet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sa.infonet.com [192.157.130.21]) id QQocrf13319 for ; Wed, 19 Feb 2003 05:56:23 GMT Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id h1J5u9s9017480; Wed, 19 Feb 2003 05:56:09 GMT Received: from zhangr2.info.net (lasi254.us.info.net [204.140.71.254]) by delta.info.net with ESMTP id FAA19457; Wed, 19 Feb 2003 05:56:06 GMT Message-Id: <5.1.0.14.0.20030218213848.03324f20@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Feb 2003 21:55:45 -0800 To: curtis@fictitious.org From: raymond zhang Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression Cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" In-Reply-To: <200302190348.WAA76199@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:48 PM 2/18/2003 -0500, Curtis Villamizar wrote: Hi Curtis, >In message <5.1.0.14.0.20030218154944.0283e668@delta.info.net>, raymond >zhang w >rites: > > > > Regarding payload size, firstly the voice frame size varies with the ITU > > codecs selected on the CPE. For example, G.729a has 10ms per voice > > sampling frame and one could configure to stuff either two or three frames > > per VoIP packet... Hence 20 to 30 byte payload. Larger payload size may > > present an issue in terms of loss, esp for a global network since loss of > > one packet would result in multiple voice frame losses. > > > > As for vendors, I'd say any CPE vendors should have this capability > built in. > > .. > > >I think the SPs should speak as to whether the bandwidth inefficiency >of 30 byte payloads or the potential to lose a packet with a 200 byte >is a greater problem. All of the SP I've spoken to that are doing >VOIP are using diffserv EF service or otherwise insuring that voice >traffic is rarely if ever dropped. Surely... bandwidth inefficiency is certainly of a great concern to SPs. In areas where ample capacity can absorb any kind of network abnormality, some SPs has choosen not to even have diffserve provisioned at each HoP which would warrant larger payload size. There are two areas, where EF is essential to provide a consistent level of statistical performance targets for voice traffic which are prone to congestion - PE-CE links and where SP's network spans over capacity scarce or expensive regions... One example, if GK is not used and calls are made directly between two CEs across the network, there is basically no bandwidth admission mechanism to regulate the call request... If EF bandwidth is allocated for 100 calls, when the 101st call comes in, EF would police across all voice packets of all calls hence packet drops may occur (the ash draft using rsvp signalling may resolve this issue). In cases such as these, smaller payload size may help minimize the frame loss ratio while bandwidth efficiency may then be achieved via header compression... These are just a couple of reasons I would like to voice support the two Ash drafts. Regards, Raymond >Curtis From owner-mpls@UU.NET Wed Feb 19 03:18:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15916 for ; Wed, 19 Feb 2003 03:18:56 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocrp23375 for ; Wed, 19 Feb 2003 08:22:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocrp23011; Wed, 19 Feb 2003 08:22:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQocrp24310 for mpls-outgoing; Wed, 19 Feb 2003 08:22:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocrp24303 for ; Wed, 19 Feb 2003 08:21:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocrp14828 for ; Wed, 19 Feb 2003 08:21:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocrp21966 for ; Wed, 19 Feb 2003 08:21:36 GMT Received: from smtp1.phx.gblx.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQocrp21955 for ; Wed, 19 Feb 2003 08:21:36 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1J8LZi06834; Wed, 19 Feb 2003 01:21:35 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAAKIaitn; Wed Feb 19 01:21:29 2003 Received: (from mmeyer@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) id BAA10799; Wed, 19 Feb 2003 01:21:29 -0700 (MST) Date: Wed, 19 Feb 2003 01:21:29 -0700 From: "Matthew R. Meyer" To: Curtis Villamizar Cc: Matthew Meyer , mpls@UU.NET Subject: Re: draft-meyer-mpls-soft-preemption-00.txt Message-ID: <20030219082128.GG7943@gblx.net> References: <20030218001433.GS10825@gblx.net> <200302181928.OAA72985@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302181928.OAA72985@workhorse.fictitious.org> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Thanks for the response, comments below. Thus spake Curtis Villamizar (curtis@fictitious.org): | |In message <20030218001433.GS10825@gblx.net>, Matthew Meyer writes: |> Folks, |> |> There have been some off line conversations showing interest |> regarding this draft. Would anyone be willing to comment on- |> list? |> |> Matthew | | | |As one of the offliners I'd like to say that this is much needed. |Every ISP that we talk to regards preemption as a hole in the MPLS |protocols that if utilized renders make-before-break and fast-reroute |ineffective. Soft preemption fixes that. Frequent re-sizing of LSPs in a multiple setup/hold priority level network will become basically non-intrusive as well. |I also support using the RRO as described in the draft. It is the |best way to accomplish soft preemption. It is saying exactly what is |happening, namely that the LSP is still up but it is about to go |down so do something top avoid having bits dropped. | |The one thing I would add is some object or bit somewhere that |indicates that the ingress is capable of understanding and acting on |the "Preemption pending" bit. If the midpoint where the preemption |occurs knows that the ingress is capable of dealing with the |"Preemption pending" bit, it can do a soft preemption. If not, then |the midpoint might as well do a hard preemption, because the older |ingress does not understand the "Preemption pending" bit and will |ignore it. Section 7 misled you: > - Section 7 - Interoperability > "Backward compatibility is assured since any HE LSR not compliant with > this draft that receives a Resv message with the RRO 'Preemption > Pending' bit set will simply ignore the flag and treat the > Resv message as a regular Resv refresh message." This was in the document before the session object was added and includes the now obsolete assumption that a correctly functioning midpoint would make the mistake of sending an RESV+Flagged-RRO to a non-supporting HE. Ina pointed this out off-line a few days ago and it will be corrected for version 01. [message clipped] Matthew From owner-mpls@UU.NET Wed Feb 19 07:08:34 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20280 for ; Wed, 19 Feb 2003 07:08:33 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocse09378 for ; Wed, 19 Feb 2003 12:12:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocse09022; Wed, 19 Feb 2003 12:12:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQocse24227 for mpls-outgoing; Wed, 19 Feb 2003 12:11:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocse24222 for ; Wed, 19 Feb 2003 12:11:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocse17264 for ; Wed, 19 Feb 2003 12:10:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocse07343 for ; Wed, 19 Feb 2003 12:10:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocse07326 for ; Wed, 19 Feb 2003 12:10:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JCA2JR028415 for ; Wed, 19 Feb 2003 07:10:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA14604 for ; Wed, 19 Feb 2003 07:10:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JCA2Z14567 for mpls@uu.net; Wed, 19 Feb 2003 07:10:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocse23288 for ; Wed, 19 Feb 2003 12:08:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocse03555 for ; Wed, 19 Feb 2003 12:08:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocse06186 for ; Wed, 19 Feb 2003 12:08:26 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQocse06180 for ; Wed, 19 Feb 2003 12:08:25 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20102; Wed, 19 Feb 2003 07:04:35 -0500 (EST) Message-Id: <200302191204.HAA20102@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-restart-applic-00.txt Date: Wed, 19 Feb 2003 07:04:34 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Applicability Statement for Restart Mechanisms for the Label Distribution Protocol Author(s) : A. Farrel Filename : draft-ietf-mpls-ldp-restart-applic-00.txt Pages : 14 Date : 2003-2-14 Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to a minimum. Similarly, where MPLS is at the network edges (for example, in Provider Edge routers) system downtime must also be kept as small as possible. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including the switching hardware and the TCP stack are implementation specific. How the software module itself chooses to implement FT for the state created by the Label Distribution Protocol (LDP) is also implementation specific but there are several issues in the LDP specification in RFC 3036 'LDP Specification' that make it difficult to implement an FT LSR using the LDP protocols without some extensions to those protocols. Proposals have been made in 'Fault Tolerance for the Label Distribution Protocol (LDP)' [LDP-FT] and A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-applic-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-restart-applic-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-restart-applic-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-14105220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-restart-applic-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-restart-applic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-14105220.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Feb 19 10:06:52 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27340 for ; Wed, 19 Feb 2003 10:06:51 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocsq15019 for ; Wed, 19 Feb 2003 15:10:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocsq14473; Wed, 19 Feb 2003 15:10:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQocsq28928 for mpls-outgoing; Wed, 19 Feb 2003 15:09:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocsq28921 for ; Wed, 19 Feb 2003 15:09:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocsq20350 for ; Wed, 19 Feb 2003 15:08:56 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocsq00568 for ; Wed, 19 Feb 2003 15:08:56 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocsq00559 for ; Wed, 19 Feb 2003 15:08:55 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1JF8pNh008818 for ; Wed, 19 Feb 2003 10:08:52 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA24522 for ; Wed, 19 Feb 2003 10:08:51 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JF8pV24003 for mpls@uu.net; Wed, 19 Feb 2003 10:08:51 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocrb25314 for ; Wed, 19 Feb 2003 04:50:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocrb25590 for ; Wed, 19 Feb 2003 04:50:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocrb24816 for ; Wed, 19 Feb 2003 04:50:33 GMT Received: from smtp1.phx.gblx.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQocrb24776 for ; Wed, 19 Feb 2003 04:50:33 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1J4oPW18806; Tue, 18 Feb 2003 21:50:25 -0700 (MST) Received: from unknown-228-phx.globalcrossing.com(64.213.82.228), claiming to be "GBLX.net" via SMTP by smtp1.phx.gblx.net, id smtpdAAAa.aORK; Tue Feb 18 21:50:22 2003 Message-ID: <3E530D05.8080202@GBLX.net> Date: Tue, 18 Feb 2003 20:50:13 -0800 From: Dave Cooper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: raymond zhang , "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , George Swallow , Loa Andersson , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression References: <200302190348.WAA76199@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: >In message <5.1.0.14.0.20030218154944.0283e668@delta.info.net>, raymond zhang w >rites: > > >>Regarding payload size, firstly the voice frame size varies with the ITU >>codecs selected on the CPE. For example, G.729a has 10ms per voice >>sampling frame and one could configure to stuff either two or three frames >>per VoIP packet... Hence 20 to 30 byte payload. Larger payload size may >>present an issue in terms of loss, esp for a global network since loss of >>one packet would result in multiple voice frame losses. >> >>As for vendors, I'd say any CPE vendors should have this capability built in. >>.. >> >> > > >I think the SPs should speak as to whether the bandwidth inefficiency >of 30 byte payloads or the potential to lose a packet with a 200 byte >is a greater problem. All of the SP I've spoken to that are doing > > Bandwidth inefficiency is a much greater problem. >VOIP are using diffserv EF service or otherwise insuring that voice >traffic is rarely if ever dropped. > Correct. > >Curtis > > > > > From owner-mpls@UU.NET Wed Feb 19 10:26:31 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28695 for ; Wed, 19 Feb 2003 10:26:30 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocss20596 for ; Wed, 19 Feb 2003 15:30:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocsr20021; Wed, 19 Feb 2003 15:29:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQocsr01289 for mpls-outgoing; Wed, 19 Feb 2003 15:29:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocsr01284 for ; Wed, 19 Feb 2003 15:29:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocsr09705 for ; Wed, 19 Feb 2003 15:29:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocsr01869 for ; Wed, 19 Feb 2003 15:29:11 GMT Received: from almso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQocsr01863 for ; Wed, 19 Feb 2003 15:29:10 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1JEUuhg004241 for ; Wed, 19 Feb 2003 10:29:10 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032) id 3DF6BD4E0299156A; Wed, 19 Feb 2003 10:29:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression Date: Wed, 19 Feb 2003 10:29:06 -0500 Message-ID: <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com> Thread-Topic: E2E VoIP over MPLS ('VoMPLS') Header Compression Thread-Index: AcLX0nC9C2v8Rxd4TDuCeRrgnh/KvAAVNQvQ From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" , "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" , "Dave Cooper" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28695 Curtis, >I think the SPs should speak as to whether the bandwidth inefficiency >of 30 byte payloads or the potential to lose a packet with a 200 byte >is a greater problem. Both are important issues, but if you read the first few sentences of http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt you'll see that bandwidth efficiency plays a major role in the motivation for the proposed capability. Further, the packet sizes quoted in the I-D are typical for VoIP in SP networks, as Raymond noted. Also, VoIP header compression (cRTP, for example) is in use in SP networks on a link by link basis to address the bandwidth efficiency issue. The proposal in the I-Ds is to extend VoIP header compression on an end-to-end basis, in an MPLS context. Your suggestions for muxing voice calls into larger packets connote a PSTN/TDM-like model. Some people actually think that the TDM model is pretty efficient for voice, however, VoIP is another matter, and has issues for larger packets, e.g., increased e2e delay, etc. Jerry From owner-mpls@UU.NET Wed Feb 19 10:47:38 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29409 for ; Wed, 19 Feb 2003 10:47:37 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocst17061 for ; Wed, 19 Feb 2003 15:51:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocst16433; Wed, 19 Feb 2003 15:50:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQocst02865 for mpls-outgoing; Wed, 19 Feb 2003 15:50:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocst02860 for ; Wed, 19 Feb 2003 15:50:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocst09653 for ; Wed, 19 Feb 2003 15:50:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocst15957 for ; Wed, 19 Feb 2003 15:50:04 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocst15950 for ; Wed, 19 Feb 2003 15:50:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JFo2JR009744 for ; Wed, 19 Feb 2003 10:50:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA27938 for ; Wed, 19 Feb 2003 10:50:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JFo1929413 for mpls@uu.net; Wed, 19 Feb 2003 10:50:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocst02808 for ; Wed, 19 Feb 2003 15:48:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocst27928 for ; Wed, 19 Feb 2003 15:47:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocst15871 for ; Wed, 19 Feb 2003 15:47:14 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocst15859 for ; Wed, 19 Feb 2003 15:47:13 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA78386; Wed, 19 Feb 2003 10:46:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302191546.KAA78386@workhorse.fictitious.org> To: raymond zhang cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Tue, 18 Feb 2003 21:55:45 PST." <5.1.0.14.0.20030218213848.03324f20@delta.info.net> Date: Wed, 19 Feb 2003 10:46:29 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.1.0.14.0.20030218213848.03324f20@delta.info.net>, raymond zhang w rites: > At 10:48 PM 2/18/2003 -0500, Curtis Villamizar wrote: > Hi Curtis, > > >In message <5.1.0.14.0.20030218154944.0283e668@delta.info.net>, raymond > >zhang w > >rites: > > > > > > Regarding payload size, firstly the voice frame size varies with the ITU > > > codecs selected on the CPE. For example, G.729a has 10ms per voice > > > sampling frame and one could configure to stuff either two or three frame > s > > > per VoIP packet... Hence 20 to 30 byte payload. Larger payload size may > > > present an issue in terms of loss, esp for a global network since loss of > > > one packet would result in multiple voice frame losses. > > > > > > As for vendors, I'd say any CPE vendors should have this capability > > built in. > > > .. > > > > > >I think the SPs should speak as to whether the bandwidth inefficiency > >of 30 byte payloads or the potential to lose a packet with a 200 byte > >is a greater problem. All of the SP I've spoken to that are doing > >VOIP are using diffserv EF service or otherwise insuring that voice > >traffic is rarely if ever dropped. > > Surely... bandwidth inefficiency is certainly of a great concern to > SPs. In areas where ample capacity can absorb any kind of network > abnormality, some SPs has choosen not to even have diffserve provisioned at > each HoP which would warrant larger payload size. There are two areas, > where EF is essential to provide a consistent level of statistical > performance targets for voice traffic which are prone to congestion - PE-CE > links and where SP's network spans over capacity scarce or expensive > regions... One example, if GK is not used and calls are made directly > between two CEs across the network, there is basically no bandwidth > admission mechanism to regulate the call request... If EF bandwidth is > allocated for 100 calls, when the 101st call comes in, EF would police > across all voice packets of all calls hence packet drops may occur (the ash > draft using rsvp signalling may resolve this issue). In cases such as > these, smaller payload size may help minimize the frame loss ratio while > bandwidth efficiency may then be achieved via header compression... These > are just a couple of reasons I would like to voice support the two Ash drafts > . Let me see if I understand this. If you have 101 calls you have some (misguided) notion that you drop less with tiny payloads and lots of overhead. If you had large payloads the same link would hold 120-150 calls depending on how large the payload was. Next question - is your notion of drop more with larger payloads only applicable to ATM when packet shredding is being done rather than discarding entire frames? Don't all modern ATM switches support PPD? If this is an ATM only issue and furthermore an old ATM switch issue its probably not one for the IETF to address. The way things have been explained to me is an attempt is made to keep no more than about 30% of the bandwidth on a link for EF (or pick a number) and leave the rest for IP. The actual EF reservation might be 40% to 70% of the link so if you went to 101 calls and only 100 fit, IP would be squeezed out of some more bandwidth than you'd like it to. Are you talking about EF on an IP or MPLS diffserv network or a VC on an ATM network or TDM where you have to reserve exactly what you expect to use and get hammerred if you use ever so slightly more? This is what has been recommended in the diff-serv and MPLS WGs almost since the diff-serv WG started. The technique is certainly no secret. A few people at SPs have hinted that their employer may consider the fact that they are using it to be some sort of secret. Curtis From owner-mpls@UU.NET Wed Feb 19 11:27:06 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00548 for ; Wed, 19 Feb 2003 11:27:06 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocsw20935 for ; Wed, 19 Feb 2003 16:30:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocsw20241; Wed, 19 Feb 2003 16:30:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQocsv24412 for mpls-outgoing; Wed, 19 Feb 2003 16:29:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocsv24396 for ; Wed, 19 Feb 2003 16:29:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocsv02258 for ; Wed, 19 Feb 2003 16:29:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocsv20133 for ; Wed, 19 Feb 2003 16:29:05 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocsv20124 for ; Wed, 19 Feb 2003 16:29:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JGT2JR012410 for ; Wed, 19 Feb 2003 11:29:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA01329 for ; Wed, 19 Feb 2003 11:29:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JGT2w04054 for mpls@uu.net; Wed, 19 Feb 2003 11:29:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocsv24298 for ; Wed, 19 Feb 2003 16:26:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocsv14552 for ; Wed, 19 Feb 2003 16:25:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocsv17422 for ; Wed, 19 Feb 2003 16:25:34 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocsv17418 for ; Wed, 19 Feb 2003 16:25:33 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA78592; Wed, 19 Feb 2003 11:24:42 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302191624.LAA78592@workhorse.fictitious.org> To: "Ash, Gerald R (Jerry), ALABS" cc: curtis@fictitious.org, "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" , "Dave Cooper" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Wed, 19 Feb 2003 10:29:06 EST." <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com> Date: Wed, 19 Feb 2003 11:24:41 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com> , "Ash, Gerald R (Jerry), ALABS" writes: > Curtis, > > >I think the SPs should speak as to whether the bandwidth inefficiency > >of 30 byte payloads or the potential to lose a packet with a 200 byte > >is a greater problem. > > Both are important issues, but if you read the first few sentences of http:// > ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt you'll see > that bandwidth efficiency plays a major role in the motivation for the propos > ed capability. Further, the packet sizes quoted in the I-D are typical for V > oIP in SP networks, as Raymond noted. Also, VoIP header compression (cRTP, f > or example) is in use in SP networks on a link by link basis to address the b > andwidth efficiency issue. 30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes 62% overhead 30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes 21% overhead 200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes 19% overhead 300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes 14% overhead No header compression and larger frames seems to be the winner as far as efficiency goes even if you could compress the header to 8 bytes. > The proposal in the I-Ds is to extend VoIP header compression on an end-to-en > d basis, in an MPLS context. > > Your suggestions for muxing voice calls into larger packets connote a PSTN/TD > M-like model. Some people actually think that the TDM model is pretty effici > ent for voice, however, VoIP is another matter, and has issues for larger pac > kets, e.g., increased e2e delay, etc. You don't mux calls, you collect the frames of a single call and introduce some assembly delay. Audio compression techniques typcially do a good job of silence suppression and vary in the amount of data they send. Even the best (that produce reasonable quality audio) consume up to 64 kbit/sec when someone is actively talking and near nothing on silence. What would you consider the average transmission rate for compressed audio? Somewhere around 16-32 kbit/sec? To assemble a 300 byte packet at 64 kbit/sec you need under 40 msec, 200 msec gets you 25 msec. If you set a queueing delay point (as recommended all over the place for RTP) of 50 msec, you'll get packets over 300 bytes, and probably an average of well over 200 bytes. > Jerry Please correct me if I'm wrong but your drafts seem to require end2end MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since you are providing new RSVP/TE objects the assumption seems to be RSVP/TE MPLS edge to edge. If traffic engineering is done within regions as can be done with current RTP/UDP/IP/MPLS regardless of whether LDP is also used, that works fine and scales extremely well. E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to scale well in a single provider and is almost certain to become a severe problem crossing SP boundaries. Curtis From owner-mpls@UU.NET Wed Feb 19 12:33:26 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02439 for ; Wed, 19 Feb 2003 12:33:25 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocta23576 for ; Wed, 19 Feb 2003 17:37:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocta22593; Wed, 19 Feb 2003 17:36:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQocta18261 for mpls-outgoing; Wed, 19 Feb 2003 17:35:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocta18251 for ; Wed, 19 Feb 2003 17:35:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocta20602 for ; Wed, 19 Feb 2003 17:35:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocta23944 for ; Wed, 19 Feb 2003 17:35:46 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocta23936 for ; Wed, 19 Feb 2003 17:35:45 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1JHZgNh017615 for ; Wed, 19 Feb 2003 12:35:43 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA07522 for ; Wed, 19 Feb 2003 12:35:42 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JHZf109879 for mpls@uu.net; Wed, 19 Feb 2003 12:35:41 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocrb25314 for ; Wed, 19 Feb 2003 04:50:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocrb25590 for ; Wed, 19 Feb 2003 04:50:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocrb24816 for ; Wed, 19 Feb 2003 04:50:33 GMT Received: from smtp1.phx.gblx.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQocrb24776 for ; Wed, 19 Feb 2003 04:50:33 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1J4oPW18806; Tue, 18 Feb 2003 21:50:25 -0700 (MST) Received: from unknown-228-phx.globalcrossing.com(64.213.82.228), claiming to be "GBLX.net" via SMTP by smtp1.phx.gblx.net, id smtpdAAAa.aORK; Tue Feb 18 21:50:22 2003 Message-ID: <3E530D05.8080202@GBLX.net> Date: Tue, 18 Feb 2003 20:50:13 -0800 From: Dave Cooper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: raymond zhang , "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , George Swallow , Loa Andersson , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression References: <200302190348.WAA76199@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: >In message <5.1.0.14.0.20030218154944.0283e668@delta.info.net>, raymond zhang w >rites: > > >>Regarding payload size, firstly the voice frame size varies with the ITU >>codecs selected on the CPE. For example, G.729a has 10ms per voice >>sampling frame and one could configure to stuff either two or three frames >>per VoIP packet... Hence 20 to 30 byte payload. Larger payload size may >>present an issue in terms of loss, esp for a global network since loss of >>one packet would result in multiple voice frame losses. >> >>As for vendors, I'd say any CPE vendors should have this capability built in. >>.. >> >> > > >I think the SPs should speak as to whether the bandwidth inefficiency >of 30 byte payloads or the potential to lose a packet with a 200 byte >is a greater problem. All of the SP I've spoken to that are doing > > Bandwidth inefficiency is a much greater problem. >VOIP are using diffserv EF service or otherwise insuring that voice >traffic is rarely if ever dropped. > Correct. > >Curtis > > > > > From owner-mpls@UU.NET Wed Feb 19 13:07:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03541 for ; Wed, 19 Feb 2003 13:07:01 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctc25369 for ; Wed, 19 Feb 2003 18:10:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoctc24791; Wed, 19 Feb 2003 18:10:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQoctc08907 for mpls-outgoing; Wed, 19 Feb 2003 18:09:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoctc08901 for ; Wed, 19 Feb 2003 18:09:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoctc16111 for ; Wed, 19 Feb 2003 18:09:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctc23634 for ; Wed, 19 Feb 2003 18:09:06 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoctc23616 for ; Wed, 19 Feb 2003 18:09:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JI92JR018623 for ; Wed, 19 Feb 2003 13:09:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA10377 for ; Wed, 19 Feb 2003 13:09:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JI92m13653 for mpls@uu.net; Wed, 19 Feb 2003 13:09:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoctc08624 for ; Wed, 19 Feb 2003 18:07:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoctc02226 for ; Wed, 19 Feb 2003 18:07:35 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctc21246 for ; Wed, 19 Feb 2003 18:07:35 GMT Received: from kcmso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQoctc21241 for ; Wed, 19 Feb 2003 18:07:34 GMT Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1JHwV9t019574 for ; Wed, 19 Feb 2003 12:07:34 -0600 (CST) Received: from OCCLUST01EVS1.ugd.att.com (135.71.164.7) by attrh1i.attrh.att.com (6.5.019) id 3E46A8A9000F3A11; Wed, 19 Feb 2003 13:07:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression Date: Wed, 19 Feb 2003 13:07:30 -0500 Message-ID: Thread-Topic: E2E VoIP over MPLS ('VoMPLS') Header Compression Thread-Index: AcLYM4rgO2fAbGYAThW6MbTqlQIy5AADd0yw From: "GOODE, B (Bur), ALABS" To: , "Ash, Gerald R (Jerry), ALABS" Cc: "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA03541 We (AT&T) and Raymond (Infonet) clearly stated that we were talking about G.729 at 8 Kb/s. Curtis responds with an example of G.711 using 64 Kb/s. We cannot afford more than 30 ms packetization delay in our delay budget. 20ms would be preferable References to 200-300 byte packets is just absurd. Bur > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, February 19, 2003 11:25 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; George Swallow; > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > Dave Cooper > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > In message > <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com> > , "Ash, Gerald R (Jerry), ALABS" writes: > > Curtis, > > > > >I think the SPs should speak as to whether the bandwidth > inefficiency > > >of 30 byte payloads or the potential to lose a packet with > a 200 byte > > >is a greater problem. > > > > Both are important issues, but if you read the first few > sentences of http:// > > > ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00. > txt you'll see > > that bandwidth efficiency plays a major role in the > motivation for the propos > > ed capability. Further, the packet sizes quoted in the I-D > are typical for V > > oIP in SP networks, as Raymond noted. Also, VoIP header > compression (cRTP, f > > or example) is in use in SP networks on a link by link > basis to address the b > > andwidth efficiency issue. > > > 30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes 62% overhead > 30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes 21% overhead > 200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes 19% overhead > 300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes 14% overhead > > No header compression and larger frames seems to be the winner as far > as efficiency goes even if you could compress the header to 8 bytes. > > > The proposal in the I-Ds is to extend VoIP header > compression on an end-to-en > > d basis, in an MPLS context. > > > > Your suggestions for muxing voice calls into larger packets > connote a PSTN/TD > > M-like model. Some people actually think that the TDM > model is pretty effici > > ent for voice, however, VoIP is another matter, and has > issues for larger pac > > kets, e.g., increased e2e delay, etc. > > You don't mux calls, you collect the frames of a single call and > introduce some assembly delay. > > Audio compression techniques typcially do a good job of silence > suppression and vary in the amount of data they send. Even the best > (that produce reasonable quality audio) consume up to 64 kbit/sec when > someone is actively talking and near nothing on silence. What would > you consider the average transmission rate for compressed audio? > Somewhere around 16-32 kbit/sec? > > To assemble a 300 byte packet at 64 kbit/sec you need under 40 msec, > 200 msec gets you 25 msec. If you set a queueing delay point (as > recommended all over the place for RTP) of 50 msec, you'll get packets > over 300 bytes, and probably an average of well over 200 bytes. > > > Jerry > > Please correct me if I'm wrong but your drafts seem to require end2end > MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since > you are providing new RSVP/TE objects the assumption seems to be > RSVP/TE MPLS edge to edge. If traffic engineering is done within > regions as can be done with current RTP/UDP/IP/MPLS regardless of > whether LDP is also used, that works fine and scales extremely well. > E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to > scale well in a single provider and is almost certain to become a > severe problem crossing SP boundaries. > > Curtis > From owner-mpls@UU.NET Wed Feb 19 13:26:47 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02440 for ; Wed, 19 Feb 2003 12:33:25 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocta23595 for ; Wed, 19 Feb 2003 17:37:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocta22562; Wed, 19 Feb 2003 17:36:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQocta18260 for mpls-outgoing; Wed, 19 Feb 2003 17:35:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocta18249 for ; Wed, 19 Feb 2003 17:35:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocta20184 for ; Wed, 19 Feb 2003 17:35:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocta21614 for ; Wed, 19 Feb 2003 17:35:42 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocta21590 for ; Wed, 19 Feb 2003 17:35:41 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JHZYJR016560 for ; Wed, 19 Feb 2003 12:35:38 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA07513 for ; Wed, 19 Feb 2003 12:35:33 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JHZXZ09875 for mpls@uu.net; Wed, 19 Feb 2003 12:35:33 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocrb25314 for ; Wed, 19 Feb 2003 04:50:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocrb25590 for ; Wed, 19 Feb 2003 04:50:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocrb24816 for ; Wed, 19 Feb 2003 04:50:33 GMT Received: from smtp1.phx.gblx.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQocrb24776 for ; Wed, 19 Feb 2003 04:50:33 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1J4oPW18806; Tue, 18 Feb 2003 21:50:25 -0700 (MST) Received: from unknown-228-phx.globalcrossing.com(64.213.82.228), claiming to be "GBLX.net" via SMTP by smtp1.phx.gblx.net, id smtpdAAAa.aORK; Tue Feb 18 21:50:22 2003 Message-ID: <3E530D05.8080202@GBLX.net> Date: Tue, 18 Feb 2003 20:50:13 -0800 From: Dave Cooper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: raymond zhang , "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , George Swallow , Loa Andersson , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression References: <200302190348.WAA76199@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: >In message <5.1.0.14.0.20030218154944.0283e668@delta.info.net>, raymond zhang w >rites: > > >>Regarding payload size, firstly the voice frame size varies with the ITU >>codecs selected on the CPE. For example, G.729a has 10ms per voice >>sampling frame and one could configure to stuff either two or three frames >>per VoIP packet... Hence 20 to 30 byte payload. Larger payload size may >>present an issue in terms of loss, esp for a global network since loss of >>one packet would result in multiple voice frame losses. >> >>As for vendors, I'd say any CPE vendors should have this capability built in. >>.. >> >> > > >I think the SPs should speak as to whether the bandwidth inefficiency >of 30 byte payloads or the potential to lose a packet with a 200 byte >is a greater problem. All of the SP I've spoken to that are doing > > Bandwidth inefficiency is a much greater problem. >VOIP are using diffserv EF service or otherwise insuring that voice >traffic is rarely if ever dropped. > Correct. > >Curtis > > > > > From owner-mpls@UU.NET Wed Feb 19 13:49:37 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04673 for ; Wed, 19 Feb 2003 13:49:35 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctf15050 for ; Wed, 19 Feb 2003 18:53:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoctf14472; Wed, 19 Feb 2003 18:52:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQoctf13196 for mpls-outgoing; Wed, 19 Feb 2003 18:52:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoctf13186 for ; Wed, 19 Feb 2003 18:52:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoctf04371 for ; Wed, 19 Feb 2003 18:52:11 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctf00132 for ; Wed, 19 Feb 2003 18:52:11 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoctf00122 for ; Wed, 19 Feb 2003 18:52:10 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JIq7JR021566 for ; Wed, 19 Feb 2003 13:52:08 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14283 for ; Wed, 19 Feb 2003 13:52:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JIq7c17884 for mpls@uu.net; Wed, 19 Feb 2003 13:52:07 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocte11851 for ; Wed, 19 Feb 2003 18:40:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocte14635 for ; Wed, 19 Feb 2003 18:39:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocte00070 for ; Wed, 19 Feb 2003 18:39:17 GMT Received: from snmisout03.secarch.gblxint.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail03.globalcrossing.com [64.208.159.231]) id QQocte00060 for ; Wed, 19 Feb 2003 18:39:16 GMT Received: from snmisout03.secarch.gblxint.com (localhost [127.0.0.1]) by snmisout03.secarch.gblxint.com (8.11.0/8.11.0) with ESMTP id h1JIdFm25666 for ; Wed, 19 Feb 2003 13:39:15 -0500 (EST) Received: from snnyroch03.east.globalcrossing.com (snnyroch03.ams.gblxint.com [10.60.16.183]) by snmisout03.secarch.gblxint.com (8.11.0/8.11.0) with ESMTP id h1JIdBL25642; Wed, 19 Feb 2003 13:39:11 -0500 (EST) Received: from exnarocims1.ams.gblxint.com (exnarocims1.ams.gblxint.com [10.60.19.42]) by snnyroch03.east.globalcrossing.com (8.9.3/8.9.3) with ESMTP id NAA15019; Wed, 19 Feb 2003 13:39:07 -0500 (EST) Received: by exnarocims1.ams.gblxint.com with Internet Mail Service (5.5.2653.19) id <1NKHSHK5>; Wed, 19 Feb 2003 13:39:10 -0500 Message-ID: <81BF85F8C018D511B44A00508BB8B4790500A9CD@exnarocmbx1.ams.gblxint.com> From: "Uzelac, Adam" To: "'GOODE, B (Bur), ALABS'" , curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" Cc: raymond zhang , "MPLS@UU.net" , George Swallow , Loa Andersson Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression Date: Wed, 19 Feb 2003 13:39:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > 30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes 62% overhead > 30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes 21% overhead > 200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes 19% overhead > 300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes 14% overhead I am afraid there is some confusion on this one. The 200-300 bytes probably included the RTP/UDP/IP headers as well. Bandwidth Calculations G.711 Packetization Delay (in ms) 20 Payload Speed (in bits per second) 64,000 Payload (in bytes) 160 RTP (in bytes) 12 UDP (in bytes) 8 IP (in bytes) 20 Total Packet Size (in bytes) 200 BUT the issue still stands - Using the G.723.1 coder (which produces 24 byte frames every 30 milliseconds), each packet would have only 24 bytes of data to 40 bytes of header. Thus, the header would be 67% of the entire packet. The bigger the payload, the better, with the understood impact should packet loss occur. Reduce the ratio by increasing the payload and don't drop any packets on the floor! -Adam Uzelac -----Original Message----- From: GOODE, B (Bur), ALABS [mailto:bgoode@att.com] Sent: Wednesday, February 19, 2003 1:08 PM To: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS Cc: raymond zhang; MPLS@UU.net; George Swallow; Loa Andersson Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression We (AT&T) and Raymond (Infonet) clearly stated that we were talking about G.729 at 8 Kb/s. Curtis responds with an example of G.711 using 64 Kb/s. We cannot afford more than 30 ms packetization delay in our delay budget. 20ms would be preferable References to 200-300 byte packets is just absurd. Bur > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, February 19, 2003 11:25 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; George Swallow; > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > Dave Cooper > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > In message > <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com> > , "Ash, Gerald R (Jerry), ALABS" writes: > > Curtis, > > > > >I think the SPs should speak as to whether the bandwidth > inefficiency > > >of 30 byte payloads or the potential to lose a packet with > a 200 byte > > >is a greater problem. > > > > Both are important issues, but if you read the first few > sentences of http:// > > > ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00. > txt you'll see > > that bandwidth efficiency plays a major role in the > motivation for the propos > > ed capability. Further, the packet sizes quoted in the I-D > are typical for V > > oIP in SP networks, as Raymond noted. Also, VoIP header > compression (cRTP, f > > or example) is in use in SP networks on a link by link > basis to address the b > > andwidth efficiency issue. > > > 30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes 62% overhead > 30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes 21% overhead > 200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes 19% overhead > 300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes 14% overhead > > No header compression and larger frames seems to be the winner as far > as efficiency goes even if you could compress the header to 8 bytes. > > > The proposal in the I-Ds is to extend VoIP header > compression on an end-to-en > > d basis, in an MPLS context. > > > > Your suggestions for muxing voice calls into larger packets > connote a PSTN/TD > > M-like model. Some people actually think that the TDM > model is pretty effici > > ent for voice, however, VoIP is another matter, and has > issues for larger pac > > kets, e.g., increased e2e delay, etc. > > You don't mux calls, you collect the frames of a single call and > introduce some assembly delay. > > Audio compression techniques typcially do a good job of silence > suppression and vary in the amount of data they send. Even the best > (that produce reasonable quality audio) consume up to 64 kbit/sec when > someone is actively talking and near nothing on silence. What would > you consider the average transmission rate for compressed audio? > Somewhere around 16-32 kbit/sec? > > To assemble a 300 byte packet at 64 kbit/sec you need under 40 msec, > 200 msec gets you 25 msec. If you set a queueing delay point (as > recommended all over the place for RTP) of 50 msec, you'll get packets > over 300 bytes, and probably an average of well over 200 bytes. > > > Jerry > > Please correct me if I'm wrong but your drafts seem to require end2end > MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since > you are providing new RSVP/TE objects the assumption seems to be > RSVP/TE MPLS edge to edge. If traffic engineering is done within > regions as can be done with current RTP/UDP/IP/MPLS regardless of > whether LDP is also used, that works fine and scales extremely well. > E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to > scale well in a single provider and is almost certain to become a > severe problem crossing SP boundaries. > > Curtis > From owner-mpls@UU.NET Wed Feb 19 14:45:48 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06511 for ; Wed, 19 Feb 2003 14:45:48 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctj25022 for ; Wed, 19 Feb 2003 19:49:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoctj24705; Wed, 19 Feb 2003 19:49:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQoctj06173 for mpls-outgoing; Wed, 19 Feb 2003 19:48:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoctj06168 for ; Wed, 19 Feb 2003 19:48:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoctj01618 for ; Wed, 19 Feb 2003 19:48:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctj21203 for ; Wed, 19 Feb 2003 19:48:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoctj21197 for ; Wed, 19 Feb 2003 19:48:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JJm2JR027241 for ; Wed, 19 Feb 2003 14:48:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18888 for ; Wed, 19 Feb 2003 14:48:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JJm2k23183 for mpls@uu.net; Wed, 19 Feb 2003 14:48:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoctj06117 for ; Wed, 19 Feb 2003 19:47:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoctj26220 for ; Wed, 19 Feb 2003 19:46:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctj16893 for ; Wed, 19 Feb 2003 19:46:49 GMT Received: from fido.nc.rr.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu57-28-045.nc.rr.com [66.57.28.45]) id QQoctj16871 for ; Wed, 19 Feb 2003 19:46:48 GMT Received: from fido.nc.rr.com (fido.nc.rr.com [127.0.0.1]) by fido.nc.rr.com (8.12.5/8.12.5) with ESMTP id h1JJkkjB026537; Wed, 19 Feb 2003 14:46:46 -0500 Received: from localhost (jboyle@localhost) by fido.nc.rr.com (8.12.5/8.12.5/Submit) with ESMTP id h1JJkkbq026533; Wed, 19 Feb 2003 14:46:46 -0500 X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs Date: Wed, 19 Feb 2003 14:46:46 -0500 (EST) From: Jim Boyle X-X-Sender: jboyle@fido.nc.rr.com To: Matthew Meyer cc: mpls@UU.NET Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-Reply-To: <20030219082128.GG7943@gblx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk First, great draft - I like this concept. While a flag might be just the right thing for this particular application, I wonder if it might be good to try to broaden soft preemption technique to include other polite preemptions. These might include the following indicators o) your LSP is being prempted on the indicated link (draft covers) o) your LSP should be rerouted, this node is shutting down o) your LSP should be rerouted, this link is being taken out of service o) your LSP should be rerouted away from this node (administrative/CLI) o) your LSP should be rerouted away from this link (administrative/CLI) You can somewhat do some of these by changing metrics and waiting, but just was wondering if something more general might be useful. Also, with Diffserv TE, not sure that one can assume that a preemption necessarily "implies exhausted bandwidth at the affected priority level *and greater*" (section 5), but local implementations can do as they please I suppose. regards, Jim From owner-mpls@UU.NET Wed Feb 19 14:54:19 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06863 for ; Wed, 19 Feb 2003 14:54:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctj01494 for ; Wed, 19 Feb 2003 19:58:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoctj00994; Wed, 19 Feb 2003 19:57:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQoctj07023 for mpls-outgoing; Wed, 19 Feb 2003 19:57:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoctj07007 for ; Wed, 19 Feb 2003 19:57:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoctj28058 for ; Wed, 19 Feb 2003 19:56:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctj28558 for ; Wed, 19 Feb 2003 19:56:58 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoctj28548 for ; Wed, 19 Feb 2003 19:56:57 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JJusJR028115 for ; Wed, 19 Feb 2003 14:56:54 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA19685 for ; Wed, 19 Feb 2003 14:56:53 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JJurk25204 for mpls@uu.net; Wed, 19 Feb 2003 14:56:53 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoctj06649 for ; Wed, 19 Feb 2003 19:53:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoctj15243 for ; Wed, 19 Feb 2003 19:52:58 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctj26130 for ; Wed, 19 Feb 2003 19:52:57 GMT Received: from gull.mail.pas.earthlink.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gull.mail.pas.earthlink.net [207.217.120.84]) id QQoctj26119 for ; Wed, 19 Feb 2003 19:52:57 GMT Received: from dialup-64.157.70.221.dial1.weehawken1.level3.net ([64.157.70.221] helo=jhand) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18laGx-0006jT-00; Wed, 19 Feb 2003 11:52:52 -0800 From: "Jim Hand" To: , "Ash, Gerald R \(Jerry\), ALABS" Cc: "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B \(Bur\), ALABS" , "Dave Cooper" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression Date: Wed, 19 Feb 2003 14:51:42 -0500 Message-ID: <001001c2d850$57c1d7e0$3a785b87@mt.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200302191624.LAA78592@workhorse.fictitious.org> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit A 50ms queuing point with a G.711 codec will yield packets over 300 bytes. A 50ms queuing point with G.729x codecs will yield packets under 50 bytes. With G.729x with no connection muxing 200-300 byte payload sizes yield 200-300ms delays. This is why I had been assuming, apparently along with some others, that you were talking about connection muxing. Jim Hand > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, February 19, 2003 11:25 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; George Swallow; > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > Dave Cooper > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > In message > <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com> > , "Ash, Gerald R (Jerry), ALABS" writes: > > Curtis, > > > > >I think the SPs should speak as to whether the bandwidth > inefficiency > > >of 30 byte payloads or the potential to lose a packet with > a 200 byte > > >is a greater problem. > > > > Both are important issues, but if you read the first few > sentences of http:// > > > ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00. > txt you'll see > > that bandwidth efficiency plays a major role in the > motivation for the propos > > ed capability. Further, the packet sizes quoted in the I-D > are typical for V > > oIP in SP networks, as Raymond noted. Also, VoIP header > compression (cRTP, f > > or example) is in use in SP networks on a link by link > basis to address the b > > andwidth efficiency issue. > > > 30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes 62% overhead > 30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes 21% overhead > 200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes 19% overhead > 300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes 14% overhead > > No header compression and larger frames seems to be the winner as far > as efficiency goes even if you could compress the header to 8 bytes. > > > The proposal in the I-Ds is to extend VoIP header > compression on an end-to-en > > d basis, in an MPLS context. > > > > Your suggestions for muxing voice calls into larger packets > connote a PSTN/TD > > M-like model. Some people actually think that the TDM > model is pretty effici > > ent for voice, however, VoIP is another matter, and has > issues for larger pac > > kets, e.g., increased e2e delay, etc. > > You don't mux calls, you collect the frames of a single call and > introduce some assembly delay. > > Audio compression techniques typcially do a good job of silence > suppression and vary in the amount of data they send. Even the best > (that produce reasonable quality audio) consume up to 64 kbit/sec when > someone is actively talking and near nothing on silence. What would > you consider the average transmission rate for compressed audio? > Somewhere around 16-32 kbit/sec? > > To assemble a 300 byte packet at 64 kbit/sec you need under 40 msec, > 200 msec gets you 25 msec. If you set a queueing delay point (as > recommended all over the place for RTP) of 50 msec, you'll get packets > over 300 bytes, and probably an average of well over 200 bytes. > > > Jerry > > Please correct me if I'm wrong but your drafts seem to require end2end > MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since > you are providing new RSVP/TE objects the assumption seems to be > RSVP/TE MPLS edge to edge. If traffic engineering is done within > regions as can be done with current RTP/UDP/IP/MPLS regardless of > whether LDP is also used, that works fine and scales extremely well. > E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to > scale well in a single provider and is almost certain to become a > severe problem crossing SP boundaries. > > Curtis > From owner-mpls@UU.NET Wed Feb 19 15:13:31 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07433 for ; Wed, 19 Feb 2003 15:13:29 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctl27119 for ; Wed, 19 Feb 2003 20:17:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoctl26336; Wed, 19 Feb 2003 20:16:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQoctl27428 for mpls-outgoing; Wed, 19 Feb 2003 20:16:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoctl27423 for ; Wed, 19 Feb 2003 20:16:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoctl12377 for ; Wed, 19 Feb 2003 20:15:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctl24050 for ; Wed, 19 Feb 2003 20:15:05 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoctl23991 for ; Wed, 19 Feb 2003 20:15:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1JKF2Nh028682 for ; Wed, 19 Feb 2003 15:15:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA21246 for ; Wed, 19 Feb 2003 15:15:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JKF2v28478 for mpls@uu.net; Wed, 19 Feb 2003 15:15:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoctk26955 for ; Wed, 19 Feb 2003 20:13:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoctk23606 for ; Wed, 19 Feb 2003 20:13:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctk18828 for ; Wed, 19 Feb 2003 20:13:30 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoctk18807 for ; Wed, 19 Feb 2003 20:13:29 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA80281; Wed, 19 Feb 2003 15:14:04 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302192014.PAA80281@workhorse.fictitious.org> To: "GOODE, B (Bur), ALABS" cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Wed, 19 Feb 2003 13:07:30 EST." Date: Wed, 19 Feb 2003 15:14:03 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "GOODE, B (Bur), ALABS" writes: > We (AT&T) and Raymond (Infonet) clearly stated that we were talking > about G.729 at 8 Kb/s. Curtis responds with an example of G.711 using > 64 Kb/s. We cannot afford more than 30 ms packetization delay in our > delay budget. 20ms would be preferable References to 200-300 byte > packets is just absurd. > > Bur Bur, Thanks for the clarification. btw- Even G.722 is 24 to 32 kbit/s. All of these encoding seem to sample at 20 msec. At least doubling up to 40 msec would be reasonable and very simple. I can understand if you don't want to do that. Please read on. AFAIK G.729 is used for cell phone only and there are good reasons to send very low bandwidths and small packets over the airways. Even if you did G.729 end to end, you're not going to do RSVP/TE signaling from cell phone to cell phone or cell phone to POTS handset. (Please correct me if I'm wrong about that). If you are doing G.729 end to end, and really want 20-30 msec, then I suppose you really do have to either 1) mux at the gateway or 2) increase the delay a bit, 3) live with tiny payloads. [Aside: If the RTT on a cellular link is as high as 100-200 msec (each end of a call), fussing over another 20-50 msec in the core does not seem to me like it should be such a big deal, but that's also not my decision.] Even if you are going to go G.729 end to end (voice gateway to voice gateway), you certainly won't be doing per call RSVP/TE signaling (correct me if I'm wrong). It will be at most one RSVP/TE tunnel gateway to gateway. If so, you can keep the small delay budget and mux except in the rare case of one call per gateway pair. If there are that many gateways that one call per gateway pair is common, it is extremely unlikely E2E RSVP/TE signaling is going to scale. If the number of gateways is much smaller, then multiplexing becomes feasible in principle and can even reduce the delay down to 10-20 msec while keeping payloads large. This leads to the question - if multiplexing is feasible in principle is it practical. RTP itself doesn't supports multiplexing except by means of channels. The number of channels and mapping of channels could be mapped using SDP and a new SDP "a=" attribute. If you don't like SDP or would prefer not to use it, you'd need some other protocol to maintain the mapping of channels to calls. I'm sure this is different from your current encapsulation but so is VO/MPLS with header compression and it might be something that Infonet might be a lot better off doing than trying to create end2end RSVP/TE sessions. If you are really are going to pursue this sort of design, then it would be helpful to know how scalable RSVP/TE would need to be and how you plan to maintain scalable RSVP/TE signaling. Hierarchical will only get you so far. You might want to consider just compressing the RTP/UDP headers, yeilding as little as 24 byte overhead (IP+4) instead of 40 (IP+UDP_RTP). This would eliminate the reliance on E2E RSVP/TE. btw- I sincerely thank you for replying. Too many SPs are too silent publicly about what they want to do, making IETF work harder. Regards, Curtis ps - [aside: any thoughts on AMR and AMR-WB rather than G.729? 23kbit/s for AMR-WB except during congestion. Larger packet sizes might actually releive some of the cell site congestion and the 100-200 msec delays though I understand rfc3095 can address this to a large extent.] From owner-mpls@UU.NET Wed Feb 19 16:19:54 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09051 for ; Wed, 19 Feb 2003 16:19:54 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctp20226 for ; Wed, 19 Feb 2003 21:23:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoctp19742; Wed, 19 Feb 2003 21:23:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQoctp21243 for mpls-outgoing; Wed, 19 Feb 2003 21:23:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoctp21237 for ; Wed, 19 Feb 2003 21:23:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoctp14603 for ; Wed, 19 Feb 2003 21:22:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctp17744 for ; Wed, 19 Feb 2003 21:22:06 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoctp17733 for ; Wed, 19 Feb 2003 21:22:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1JLM2Nh003159 for ; Wed, 19 Feb 2003 16:22:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA27375 for ; Wed, 19 Feb 2003 16:22:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JLM2l04656 for mpls@uu.net; Wed, 19 Feb 2003 16:22:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoctp21039 for ; Wed, 19 Feb 2003 21:20:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoctp15162 for ; Wed, 19 Feb 2003 21:20:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctp03377 for ; Wed, 19 Feb 2003 21:20:15 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoctp03347 for ; Wed, 19 Feb 2003 21:20:14 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA80453; Wed, 19 Feb 2003 16:20:44 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302192120.QAA80453@workhorse.fictitious.org> To: "Jim Hand" cc: curtis@fictitious.org, "Ash, Gerald R \(Jerry\), ALABS" , "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B \(Bur\), ALABS" , "Dave Cooper" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Wed, 19 Feb 2003 14:51:42 EST." <001001c2d850$57c1d7e0$3a785b87@mt.att.com> Date: Wed, 19 Feb 2003 16:20:44 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <001001c2d850$57c1d7e0$3a785b87@mt.att.com>, "Jim Hand" writes: > A 50ms queuing point with a G.711 codec will yield packets over 300 byt > es. > A 50ms queuing point with G.729x codecs will yield packets under 50 bytes. > With G.729x with no connection muxing 200-300 byte payload sizes yield > 200-300ms delays. > > This is why I had been assuming, apparently along with some others, > that you were talking about connection muxing. > > Jim Hand I wasn't before but you are correct. 200-300ms delays would be intolerable and you would have to resort to muxing for reasonable efficiencies. 40 msec queueing point and RTP/UDP header compression only might be a reasonable interim. Curtis From owner-mpls@UU.NET Wed Feb 19 16:40:28 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09677 for ; Wed, 19 Feb 2003 16:40:28 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctq29067 for ; Wed, 19 Feb 2003 21:44:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoctq28481; Wed, 19 Feb 2003 21:43:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQoctq22642 for mpls-outgoing; Wed, 19 Feb 2003 21:43:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoctq22637 for ; Wed, 19 Feb 2003 21:43:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoctq01483 for ; Wed, 19 Feb 2003 21:42:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctq26714 for ; Wed, 19 Feb 2003 21:42:06 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoctq26707 for ; Wed, 19 Feb 2003 21:42:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JLg3JR005693 for ; Wed, 19 Feb 2003 16:42:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA29161 for ; Wed, 19 Feb 2003 16:42:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JLg2Y07146 for mpls@uu.net; Wed, 19 Feb 2003 16:42:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoctq22521 for ; Wed, 19 Feb 2003 21:40:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoctq14010 for ; Wed, 19 Feb 2003 21:38:51 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctq23852 for ; Wed, 19 Feb 2003 21:38:50 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoctq23839 for ; Wed, 19 Feb 2003 21:38:49 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA80671; Wed, 19 Feb 2003 16:39:27 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302192139.QAA80671@workhorse.fictitious.org> To: Jim Boyle cc: Matthew Meyer , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-reply-to: Your message of "Wed, 19 Feb 2003 14:46:46 EST." Date: Wed, 19 Feb 2003 16:39:27 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , Jim Boyle writes: > > First, great draft - I like this concept. > > While a flag might be just the right thing for this particular > application, I wonder if it might be good to try to broaden > soft preemption technique to include other polite preemptions. > > These might include the following indicators > > o) your LSP is being prempted on the indicated link (draft covers) > o) your LSP should be rerouted, this node is shutting down > o) your LSP should be rerouted, this link is being taken out of > service > o) your LSP should be rerouted away from this node (administrative/CLI) > o) your LSP should be rerouted away from this link (administrative/CLI) > > You can somewhat do some of these by changing metrics and waiting, but > just was wondering if something more general might be useful. Why couldn't you just use the same bit and allow soft preemption on link shut, reload, CLI adminstrative without encoding the reason? Since these are all CLI initiated, it wouldn't hurt to delay. Alternately, the soft preempt on anything using a specific resource could be done. Link bundle lost a member might also qualify as a reason for soft preemption for implementations of link bundling that can trasnparently more flows to other members of the bundle. > Also, with Diffserv TE, not sure that one can assume that a preemption > necessarily "implies exhausted bandwidth at the affected priority > level *and greater*" (section 5), but local implementations can do > as they please I suppose. Agreed. The "and greater" should be dropped. > regards, > > Jim Thanks, Curtis From owner-mpls@UU.NET Wed Feb 19 18:17:42 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12389 for ; Wed, 19 Feb 2003 18:17:41 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctx02678 for ; Wed, 19 Feb 2003 23:21:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoctx02305; Wed, 19 Feb 2003 23:21:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQoctx07623 for mpls-outgoing; Wed, 19 Feb 2003 23:20:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoctx07615 for ; Wed, 19 Feb 2003 23:20:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoctx28899 for ; Wed, 19 Feb 2003 23:20:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctx01179 for ; Wed, 19 Feb 2003 23:20:06 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoctx01166 for ; Wed, 19 Feb 2003 23:20:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1JNK2Nh009154 for ; Wed, 19 Feb 2003 18:20:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA07011 for ; Wed, 19 Feb 2003 18:20:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JNK2g14822 for mpls@uu.net; Wed, 19 Feb 2003 18:20:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoctx07502 for ; Wed, 19 Feb 2003 23:18:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoctx09384 for ; Wed, 19 Feb 2003 23:17:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctx29138 for ; Wed, 19 Feb 2003 23:17:34 GMT Received: from fido.nc.rr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu57-28-045.nc.rr.com [66.57.28.45]) id QQoctx29129 for ; Wed, 19 Feb 2003 23:17:34 GMT Received: from fido.nc.rr.com (fido.nc.rr.com [127.0.0.1]) by fido.nc.rr.com (8.12.5/8.12.5) with ESMTP id h1JNHOjB026901; Wed, 19 Feb 2003 18:17:24 -0500 Received: from localhost (jboyle@localhost) by fido.nc.rr.com (8.12.5/8.12.5/Submit) with ESMTP id h1JNHMbp026897; Wed, 19 Feb 2003 18:17:23 -0500 X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs Date: Wed, 19 Feb 2003 18:17:22 -0500 (EST) From: Jim Boyle X-X-Sender: jboyle@fido.nc.rr.com To: Curtis Villamizar cc: Matthew Meyer , Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-Reply-To: <200302192139.QAA80671@workhorse.fictitious.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 19 Feb 2003, Curtis Villamizar wrote: > > In message , Jim Boyle > writes: > > > > First, great draft - I like this concept. > > > > While a flag might be just the right thing for this particular > > application, I wonder if it might be good to try to broaden > > soft preemption technique to include other polite preemptions. > > > > These might include the following indicators > > > > o) your LSP is being prempted on the indicated link (draft covers) > > o) your LSP should be rerouted, this node is shutting down > > o) your LSP should be rerouted, this link is being taken out of > > service > > o) your LSP should be rerouted away from this node (administrative/CLI) > > o) your LSP should be rerouted away from this link (administrative/CLI) > > > > You can somewhat do some of these by changing metrics and waiting, but > > just was wondering if something more general might be useful. > > Why couldn't you just use the same bit and allow soft preemption on > link shut, reload, CLI adminstrative without encoding the reason? > Since these are all CLI initiated, it wouldn't hurt to delay. > Alternately, the soft preempt on anything using a specific resource > could be done. you could, but the path head could create more meaningful log message if the reason were known, Just floating an idea here. The flag is definitely "lighter" protocol wise, > > Link bundle lost a member might also qualify as a reason for soft > preemption for implementations of link bundling that can trasnparently > more flows to other members of the bundle. > > > Also, with Diffserv TE, not sure that one can assume that a preemption > > necessarily "implies exhausted bandwidth at the affected priority > > level *and greater*" (section 5), but local implementations can do > > as they please I suppose. > > Agreed. The "and greater" should be dropped. > > > regards, > > > > Jim > > Thanks, > > Curtis > From owner-mpls@UU.NET Wed Feb 19 18:27:37 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12675 for ; Wed, 19 Feb 2003 18:27:36 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocty13101 for ; Wed, 19 Feb 2003 23:31:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocty12289; Wed, 19 Feb 2003 23:30:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQocty08558 for mpls-outgoing; Wed, 19 Feb 2003 23:30:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocty08549 for ; Wed, 19 Feb 2003 23:30:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocty29388 for ; Wed, 19 Feb 2003 23:30:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocty15295 for ; Wed, 19 Feb 2003 23:30:05 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocty15276 for ; Wed, 19 Feb 2003 23:30:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1JNU2Nh009600 for ; Wed, 19 Feb 2003 18:30:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA07739 for ; Wed, 19 Feb 2003 18:30:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1JNU1017310 for mpls@uu.net; Wed, 19 Feb 2003 18:30:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoctx08467 for ; Wed, 19 Feb 2003 23:28:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoctx23352 for ; Wed, 19 Feb 2003 23:28:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctx09357 for ; Wed, 19 Feb 2003 23:28:08 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoctx09319 for ; Wed, 19 Feb 2003 23:28:07 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA81728; Wed, 19 Feb 2003 18:28:36 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302192328.SAA81728@workhorse.fictitious.org> To: "Jim Hand" cc: curtis@fictitious.org, "Ash, Gerald R \(Jerry\), ALABS" , "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B \(Bur\), ALABS" , "Dave Cooper" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS In-reply-to: Your message of "Wed, 19 Feb 2003 17:37:20 EST." <001901c2d869$8863c200$3a785b87@mt.att.com> Date: Wed, 19 Feb 2003 18:28:36 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <001901c2d869$8863c200$3a785b87@mt.att.com>, "Jim Hand" writes: > Also, neither draft requires end-to-end MPLS between VoIP endpoints. One of > the drafts > (http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt) > requires MPLS between the compressor and decompressor. The other > (http://ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt )oes > not require MPLS all the way between compressor and decompressor. Neither > draft requires that the compressor and decompressor also be VoIP endpoints. > > Thanks, > Jim Hand By end to end I meant compression device to compression device. I did say gateway to gateway which might imply VOIP device. The argument I was making was that if the compression device is very far toward the edge of the network, then the number of LSPs explodes. If the compression device is moved closer to the core of the network such that a full mesh of RSVP/TE LSPs are feasible, then opportunity for multiplexing is enormous. If you are going to burden the CPU at the "compression device" why not have it multiplex rather than header compress and get huge improvement in encapulation efficiency rather than relatively small improvement in encapsulation efficiency. This also makes it feasible to more the compression closer to the edge and maybe into the VOIP gear rather than a router concentrating VOIP gear traffic. Thanks again, Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Wednesday, February 19, 2003 11:25 AM > > To: Ash, Gerald R (Jerry), ALABS > > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; George Swallow; > > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > > Dave Cooper > > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > > Please correct me if I'm wrong but your drafts seem to require end2end > > MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since > > you are providing new RSVP/TE objects the assumption seems to be > > RSVP/TE MPLS edge to edge. If traffic engineering is done within > > regions as can be done with current RTP/UDP/IP/MPLS regardless of > > whether LDP is also used, that works fine and scales extremely well. > > E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to > > scale well in a single provider and is almost certain to become a > > severe problem crossing SP boundaries. > > > > Curtis From owner-mpls@UU.NET Wed Feb 19 19:15:27 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13706 for ; Wed, 19 Feb 2003 19:15:27 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocub28788 for ; Thu, 20 Feb 2003 00:19:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocub28167; Thu, 20 Feb 2003 00:18:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQocub01074 for mpls-outgoing; Thu, 20 Feb 2003 00:18:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocub01059 for ; Thu, 20 Feb 2003 00:18:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocub15423 for ; Thu, 20 Feb 2003 00:18:01 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocub22634 for ; Thu, 20 Feb 2003 00:18:00 GMT Received: from smtp1.phx.gblx.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQocub22621 for ; Thu, 20 Feb 2003 00:17:59 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1K0HxH17671; Wed, 19 Feb 2003 17:17:59 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAAf0aWEI; Wed Feb 19 17:17:51 2003 Received: (from mmeyer@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) id RAA14982; Wed, 19 Feb 2003 17:17:51 -0700 (MST) Date: Wed, 19 Feb 2003 17:17:50 -0700 From: "Matthew R. Meyer" To: Jim Boyle Cc: Matthew Meyer , mpls@UU.NET Subject: Re: draft-meyer-mpls-soft-preemption-00.txt Message-ID: <20030220001750.GE11833@gblx.net> References: <20030219082128.GG7943@gblx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Thus spake Jim Boyle (jboyle@pdnets.com): | |First, great draft - I like this concept. Thanks for your comments Jim. |While a flag might be just the right thing for this particular |application, I wonder if it might be good to try to broaden |soft preemption technique to include other polite preemptions. | |These might include the following indicators | |o) your LSP is being prempted on the indicated link (draft covers) |o) your LSP should be rerouted, this node is shutting down |o) your LSP should be rerouted, this link is being taken out of | service |o) your LSP should be rerouted away from this node (administrative/CLI) |o) your LSP should be rerouted away from this link (administrative/CLI) All very interesting ideas. We could add as well: o) Your LSP should be rerouted away from this SRLG (administrative/CLI) (just a flag) I don't see a problem with adding some more flags to convey administrative events though I do have healthy fear of proto-bloat. I welcome more comments on this subject. |You can somewhat do some of these by changing metrics and waiting, but |just was wondering if something more general might be useful. I think there are cases like zero-BW LSPs that still need to be handled where flooding a new zeroed IGP TLVs wouldn't help. |Also, with Diffserv TE, not sure that one can assume that a preemption |necessarily "implies exhausted bandwidth at the affected priority |level *and greater*" (section 5), but local implementations can do |as they please I suppose. Yes, I guess we need to be more specific there. This document assumed independent Diffserv & TE deployments as opposed to Diffserv-TE. Thanks, Matthew From owner-mpls@UU.NET Wed Feb 19 19:58:56 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14411 for ; Wed, 19 Feb 2003 19:58:56 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocue16117 for ; Thu, 20 Feb 2003 01:02:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocue15758; Thu, 20 Feb 2003 01:02:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQocue14950 for mpls-outgoing; Thu, 20 Feb 2003 01:02:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocue14649 for ; Thu, 20 Feb 2003 01:02:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocue12698 for ; Thu, 20 Feb 2003 01:01:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocue14546 for ; Thu, 20 Feb 2003 01:01:19 GMT Received: from pfwhqs1.ncr.disa.mil by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mtahqs3.ncr.disa.mil [164.117.144.157]) id QQocue14540 for ; Thu, 20 Feb 2003 01:01:19 GMT Received: from mtahqs3.ncr.disa.mil by pfwhqs1.ncr.disa.mil via smtpd (for cmr0.ash.ops.us.uu.net [198.5.241.38]) with SMTP; 20 Feb 2003 00:55:10 UT Received: by mtahqs3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 20:04:08 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4D2F@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'Curtis Villamizar '" , "'Jim Boyle '" Cc: "'Matthew Meyer '" , "'mpls@UU.NET '" Subject: RE: draft-meyer-mpls-soft-preemption-00.txt Date: Wed, 19 Feb 2003 20:00:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi all, The draft is interesting. I wonder if this concept can be implemented to transport critial traffic for customers in the MPLS network. Thanks, An Nguyen -----Original Message----- From: Curtis Villamizar To: Jim Boyle Cc: Matthew Meyer; mpls@UU.NET Sent: 2/19/03 4:39 PM Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In message , Jim Boyle writes: > > First, great draft - I like this concept. > > While a flag might be just the right thing for this particular > application, I wonder if it might be good to try to broaden > soft preemption technique to include other polite preemptions. > > These might include the following indicators > > o) your LSP is being prempted on the indicated link (draft covers) > o) your LSP should be rerouted, this node is shutting down > o) your LSP should be rerouted, this link is being taken out of > service > o) your LSP should be rerouted away from this node (administrative/CLI) > o) your LSP should be rerouted away from this link (administrative/CLI) > > You can somewhat do some of these by changing metrics and waiting, but > just was wondering if something more general might be useful. Why couldn't you just use the same bit and allow soft preemption on link shut, reload, CLI adminstrative without encoding the reason? Since these are all CLI initiated, it wouldn't hurt to delay. Alternately, the soft preempt on anything using a specific resource could be done. Link bundle lost a member might also qualify as a reason for soft preemption for implementations of link bundling that can trasnparently more flows to other members of the bundle. > Also, with Diffserv TE, not sure that one can assume that a preemption > necessarily "implies exhausted bandwidth at the affected priority > level *and greater*" (section 5), but local implementations can do > as they please I suppose. Agreed. The "and greater" should be dropped. > regards, > > Jim Thanks, Curtis From owner-mpls@UU.NET Wed Feb 19 21:19:20 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15726 for ; Wed, 19 Feb 2003 21:19:20 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocuj15217 for ; Thu, 20 Feb 2003 02:23:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocuj14860; Thu, 20 Feb 2003 02:23:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQocuj17457 for mpls-outgoing; Thu, 20 Feb 2003 02:22:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocuj17450 for ; Thu, 20 Feb 2003 02:22:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocuj20848 for ; Thu, 20 Feb 2003 02:19:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocuj29242 for ; Thu, 20 Feb 2003 02:19:58 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQocuj29232 for ; Thu, 20 Feb 2003 02:19:57 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1K2JkS91673; Wed, 19 Feb 2003 18:19:47 -0800 (PST) (envelope-from ina@juniper.net) Date: Wed, 19 Feb 2003 18:19:46 -0800 (PST) From: Ina Minei To: "Nguyen, An" cc: "'Curtis Villamizar '" , "'Jim Boyle '" , "'Matthew Meyer '" , "'mpls@UU.NET '" Subject: RE: draft-meyer-mpls-soft-preemption-00.txt In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D02EF4D2F@emshqs1.ncr.disa.mil> Message-ID: <20030219181028.X29307@garnet.juniper.net> References: <7F18415E4D63CB45BB9B3A591F68D12D02EF4D2F@emshqs1.ncr.disa.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I am not sure what you mean by critical. If "critical" implies zero loss always, then the answer is no. Please note that this scheme relies on a timer to do hard preemption regardless of whether the head end managed to resignal the LSP or not.It is true that this timer can be user configurable, but note that in the scheme presented this can be done in a scalable fashion only at node level and not at LSP level (since the head end does not signal the amount of time at LSP setup time). The proposed scheme will be beneficial, but cannot offer any hard guarantees. Thanks, Ina On Wed, 19 Feb 2003, Nguyen, An wrote: > Hi all, > > The draft is interesting. I wonder if this concept can be implemented to > transport critial traffic for customers in the MPLS network. > > Thanks, > > An Nguyen > > -----Original Message----- > From: Curtis Villamizar > To: Jim Boyle > Cc: Matthew Meyer; mpls@UU.NET > Sent: 2/19/03 4:39 PM > Subject: Re: draft-meyer-mpls-soft-preemption-00.txt > > > In message , Jim > Boyle > writes: > > > > First, great draft - I like this concept. > > > > While a flag might be just the right thing for this particular > > application, I wonder if it might be good to try to broaden > > soft preemption technique to include other polite preemptions. > > > > These might include the following indicators > > > > o) your LSP is being prempted on the indicated link (draft covers) > > o) your LSP should be rerouted, this node is shutting down > > o) your LSP should be rerouted, this link is being taken out of > > service > > o) your LSP should be rerouted away from this node > (administrative/CLI) > > o) your LSP should be rerouted away from this link > (administrative/CLI) > > > > You can somewhat do some of these by changing metrics and waiting, but > > just was wondering if something more general might be useful. > > Why couldn't you just use the same bit and allow soft preemption on > link shut, reload, CLI adminstrative without encoding the reason? > Since these are all CLI initiated, it wouldn't hurt to delay. > Alternately, the soft preempt on anything using a specific resource > could be done. > > Link bundle lost a member might also qualify as a reason for soft > preemption for implementations of link bundling that can trasnparently > more flows to other members of the bundle. > > > Also, with Diffserv TE, not sure that one can assume that a preemption > > necessarily "implies exhausted bandwidth at the affected priority > > level *and greater*" (section 5), but local implementations can do > > as they please I suppose. > > Agreed. The "and greater" should be dropped. > > > regards, > > > > Jim > > Thanks, > > Curtis > > > From owner-mpls@UU.NET Wed Feb 19 22:07:59 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16877 for ; Wed, 19 Feb 2003 22:07:58 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocum04036 for ; Thu, 20 Feb 2003 03:11:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocum03627; Thu, 20 Feb 2003 03:11:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQocum09985 for mpls-outgoing; Thu, 20 Feb 2003 03:11:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocum09884 for ; Thu, 20 Feb 2003 03:11:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocum01620 for ; Thu, 20 Feb 2003 03:10:28 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocum17598 for ; Thu, 20 Feb 2003 03:10:27 GMT Received: from smtp1.phx.gblx.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQocum17593 for ; Thu, 20 Feb 2003 03:10:27 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1K3AQO02949; Wed, 19 Feb 2003 20:10:26 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAAsdaGRf; Wed Feb 19 20:10:18 2003 Received: (from mmeyer@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) id UAA15364; Wed, 19 Feb 2003 20:10:18 -0700 (MST) Date: Wed, 19 Feb 2003 20:10:18 -0700 From: "Matthew R. Meyer" To: Curtis Villamizar Cc: Jim Boyle , Matthew Meyer , mpls@UU.NET Subject: Re: draft-meyer-mpls-soft-preemption-00.txt Message-ID: <20030220031018.GF11833@gblx.net> References: <200302192139.QAA80671@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302192139.QAA80671@workhorse.fictitious.org> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Comments inline... Thus spake Curtis Villamizar (curtis@fictitious.org): | |In message , Jim Boyle |writes: |> |> First, great draft - I like this concept. |> |> While a flag might be just the right thing for this particular |> application, I wonder if it might be good to try to broaden |> soft preemption technique to include other polite preemptions. |> |> These might include the following indicators |> |> o) your LSP is being prempted on the indicated link (draft covers) |> o) your LSP should be rerouted, this node is shutting down |> o) your LSP should be rerouted, this link is being taken out of |> service |> o) your LSP should be rerouted away from this node (administrative/CLI) |> o) your LSP should be rerouted away from this link (administrative/CLI) |> |> You can somewhat do some of these by changing metrics and waiting, but |> just was wondering if something more general might be useful. | |Why couldn't you just use the same bit and allow soft preemption on |link shut, reload, Or OL bit set... |CLI administrative without encoding the reason? |Since these are all CLI initiated, it wouldn't hurt to delay. |Alternately, the soft preempt on anything using a specific resource |could be done. |Link bundle lost a member might also qualify as a reason for soft |preemption for implementations of link bundling that can transparently |more flows to other members of the bundle. I think there is value in conveying to the head-end the population category of the soft preemption (Single LSP|Link|Bundle Member|SRLG| Node). Doing so provides prompt, more accurate info for the head-end to use when trying to quickly find the new valid path for the first of (say) 30 arriving soft preemptions. .---,A .---,B | |---1--| |----- | |---2--| |----- `---' `---' HE Maint fe. Imagine we cause all LSPs transiting a node B to be soft preempted in prep for maintenance. HE A's LSPs all transited a certain circuit (1) to the maintenance node B, however there is a parallel circuit as well(2). Without the "node" flag, we might amend the HE TE-DB zeroing (1)s reservable BW (the circuit for which we were just soft preempted) when we should have zeroed out (2) as well. The result could be our soft preemption make before break sets up (or tries to) through the maintenance node despite being recently soft preempted off it.. Technically a HE need only receive the first LSP population oriented flag (Node|SRLG|etc) soft preemption to discover 1) what subset of locally originating LSPs need to be rerouted and 2) what links/nodes/ members need to be avoided. There is still a need for one-at-a-time straight soft preemption of course. |> Also, with Diffserv TE, not sure that one can assume that a preemption |> necessarily "implies exhausted bandwidth at the affected priority |> level *and greater*" (section 5), but local implementations can do |> as they please I suppose. | |Agreed. The "and greater" should be dropped. okay. Agreed. Thanks Matthew | |> regards, |> |> Jim | |Thanks, | |Curtis From owner-mpls@UU.NET Thu Feb 20 03:05:27 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03596 for ; Thu, 20 Feb 2003 03:05:26 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocvg26920 for ; Thu, 20 Feb 2003 08:09:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocvg26615; Thu, 20 Feb 2003 08:09:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQocvg03063 for mpls-outgoing; Thu, 20 Feb 2003 08:08:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocvg02975 for ; Thu, 20 Feb 2003 08:08:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocvg06795 for ; Thu, 20 Feb 2003 08:07:50 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocvg25442 for ; Thu, 20 Feb 2003 08:07:49 GMT Received: from web20708.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20708.mail.yahoo.com [216.136.226.181]) id QQocvg25432 for ; Thu, 20 Feb 2003 08:07:49 GMT Message-ID: <20030220080747.80712.qmail@web20708.mail.yahoo.com> Received: from [216.174.224.217] by web20708.mail.yahoo.com via HTTP; Thu, 20 Feb 2003 00:07:47 PST Date: Thu, 20 Feb 2003 00:07:47 -0800 (PST) From: Sameer K Subject: RE: Regarding Switching capability and GPID in OSPF-TE and GMPLS- RSVP To: Charles Chen , ccamp@ops.ietf.org, mpls@UU.NET In-Reply-To: <9D6D37E97A57D411BB7C00508BAE29C9045DDBC6@main.mahinetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Thanks for the clarification Charles. I understand that this is not an issue for overlay network model where the peering NEs at each individual layer (in our example, the routers) have an understanding of the "layer resources" and interfaces at the same layer. But does this argument stay valid for peering model as well? - Sameer --- Charles Chen wrote: > It is an interesting question to ask, but it may not > be an issue in the real > world. In your example, one can assume that a router > A would like to ask the > transport network to set up a PPP link dynamically > to a remote router B. > Let's put this in the overlay mode perspective, the > router A (edge device) > will request a connection to a core device (OXC). In > reality, the router A > has some prior knowledge or is driven by the traffic > engineering policy that > it wants to connect to the remote router B. At the > minimum, the router A has > to provide the information about the router B > (destination address in the > transport network), the path constraints and so on. > > It is not possible to build a network that provides > all possible application > level information. The above issue makes no > difference from that a user A > establishes a UDP connection in order to transmit > JPEG video over it to a > user B. The user A finds out later that the > receiving user B only supports > the MPEG coding scheme. Yes, it is a blocking model > but scalable. > > Charles > > > -----Original Message----- > > From: Sameer K [mailto:sameerdw@yahoo.com] > > Sent: Thursday, February 13, 2003 3:01 PM > > To: ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Regarding Switching capability and GPID > in OSPF-TE and > > GMPLS-RSVP > > > > > > Hello All, > > > > I have some questions regarding switching > capability > > descriptor, encoding type and GPID parameters, and > the > > correlation between the values signaled in > signaling > > request and the values advertised in OSPF TE LSAs. > > > > From the previous discussions, it appears that if > a > > data capable device has to establish LSP through a > > network of OXCs, the switching type requested > would be > > FSC, the encoding type would be SDH/SONET with > GPID > > being PPP (assuming that the data device that is > LSP > > ingress wants to send IP data over the LSP). Now, > the > > LSP will be established without any problem as > long as > > the destination node is advertising a switching > > capability FSC and the encoding type SONET/SDH for > all > > its interfaces. > > > > However, for the LSP to be of any use to ingress > node, > > the destination must be capable of terminating PPP > > (which in turn requires data capability on the > > incoming interface of egress node). The way to > ensure > > this would be to read GPID and then egress can > reject > > the LSP if it cannot support the GPID. > > > > However, what if destination is a multi-service > switch > > and bears certain interfaces that are FSC capable > and > > can terminate PPP as well (that is, support data > over > > FSC -if you will), other than the FSC only > interfaces. > > CSPF running at ingress can never tell the > difference > > between these (data over FSC type) interfaces and > > other (FSC only) interfaces and the LSP might end > up > > on an interface that cannot support PPP > termination. > > In such a case, even though the node supports PPP > at > > certain interfaces, the LSP will have to be > rejected. > > > > > > Now, if some "higher layer" information (PPP > > termination capability for this example), is > > advertised as a part of OSPF TE LSAs, the CSPF > running > > on the ingress node can pick up the correct > incoming > > interface on egress node based on the GPID > desired, > > thus reducing the probability of LSP failures. > > > > Would like to hear opinions. > > TIA > > - Sameer. > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Shopping - Send Flowers for Valentine's Day > > http://shopping.yahoo.com > > > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-mpls@UU.NET Thu Feb 20 03:13:18 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03859 for ; Thu, 20 Feb 2003 03:13:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocvh10822 for ; Thu, 20 Feb 2003 08:17:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocvh09962; Thu, 20 Feb 2003 08:16:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQocvh04634 for mpls-outgoing; Thu, 20 Feb 2003 08:16:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocvh04627 for ; Thu, 20 Feb 2003 08:16:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocvh06981 for ; Thu, 20 Feb 2003 08:15:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocvh19422 for ; Thu, 20 Feb 2003 08:15:52 GMT Received: from web20705.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web20705.mail.yahoo.com [216.136.226.178]) id QQocvh19411 for ; Thu, 20 Feb 2003 08:15:51 GMT Message-ID: <20030220081550.7962.qmail@web20705.mail.yahoo.com> Received: from [216.174.224.217] by web20705.mail.yahoo.com via HTTP; Thu, 20 Feb 2003 00:15:50 PST Date: Thu, 20 Feb 2003 00:15:50 -0800 (PST) From: Sameer K Subject: RFC 3471: IF ID specification WRT component link. To: ccamp@ops.ietf.org, mpls@UU.NET In-Reply-To: <9D6D37E97A57D411BB7C00508BAE29C9045DDBC6@main.mahinetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello All, From the RFC 3471 - GMPLS Signaling Functional Description, Section 9.1.1, it appears that there is no way for upstream node, to specify component links that are numbered, in the IF-ID HOP object. The TLV format for IF-ID Types 4 and 5 assumes that the component link is always un-numbered. Is this the way it was planned to be?. If yes, then what should IF-ID look like for numbered component link (which is a valid scenario per the Link Bundling draft). Or did I get it all wrong? TIA - Sameer __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-mpls@UU.NET Thu Feb 20 04:33:57 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05388 for ; Thu, 20 Feb 2003 04:33:57 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocvm14246 for ; Thu, 20 Feb 2003 09:37:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocvm13821; Thu, 20 Feb 2003 09:37:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQocvm28556 for mpls-outgoing; Thu, 20 Feb 2003 09:37:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocvm28546 for ; Thu, 20 Feb 2003 09:36:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocvm23358 for ; Thu, 20 Feb 2003 09:36:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocvm22616 for ; Thu, 20 Feb 2003 09:36:09 GMT Received: from mailhost.iitb.ac.in by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQocvm22579 for ; Thu, 20 Feb 2003 09:36:06 GMT Received: (qmail 26379 invoked from network); 20 Feb 2003 09:22:58 -0000 Received: from newsmtp.iitb.ac.in (144.16.108.201) by mailhost.iitb.ac.in with SMTP; 20 Feb 2003 09:22:58 -0000 Received: (qmail 12642 invoked from network); 20 Feb 2003 09:36:01 -0000 Received: from unknown (HELO EISODUS2) ([10.129.152.18]) (envelope-sender ) by smtp.iitb.ac.in (qmail-ldap-1.03) with SMTP for ; 20 Feb 2003 09:36:01 -0000 Date: Thu, 20 Feb 2003 15:00:29 +0530 From: Abhijit To: curtis@fictitious.org Cc: hand17@earthlink.net, gash@ems.att.com, zhangr@info.net, MPLS@UU.NET, swallow@cisco.com, loa.andersson@utfors.se, bgoode@att.com, cooper@GBLX.net X-Scanned: By Symantec Carrier Scan Server Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS Message-Id: <20030220150029.0000212f.gabhijit@ee.iitb.ac.in> In-Reply-To: <200302192328.SAA81728@workhorse.fictitious.org> References: <001901c2d869$8863c200$3a785b87@mt.att.com> <200302192328.SAA81728@workhorse.fictitious.org> Organization: Eisodus network X-Mailer: Sylpheed version 0.8.1claws5 Win32 (GTK+ 1.3.0; Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I remember reading some work done on Voice over MPLS directly without using RTP/UDP/IP overheads. Is that work going to be a part of MPLS WG? IMO, RTP/UDP/IP is a lot of overhead, compared to VoMPLS approach which actually serves the same purpose (atleast in bearer path) Regards, -abhijit. On Wed, 19 Feb 2003 18:28:36 -0500 Curtis Villamizar wrote: > > In message <001901c2d869$8863c200$3a785b87@mt.att.com>, "Jim Hand" writes: > > Also, neither draft requires end-to-end MPLS between VoIP endpoints. One of > > the drafts > > (http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt) > > requires MPLS between the compressor and decompressor. The other > > (http://ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt )oes > > not require MPLS all the way between compressor and decompressor. Neither > > draft requires that the compressor and decompressor also be VoIP endpoints. > > > > Thanks, > > Jim Hand > > > By end to end I meant compression device to compression device. I did > say gateway to gateway which might imply VOIP device. > > The argument I was making was that if the compression device is very > far toward the edge of the network, then the number of LSPs explodes. > If the compression device is moved closer to the core of the network > such that a full mesh of RSVP/TE LSPs are feasible, then opportunity > for multiplexing is enormous. > > If you are going to burden the CPU at the "compression device" why not > have it multiplex rather than header compress and get huge improvement > in encapulation efficiency rather than relatively small improvement in > encapsulation efficiency. This also makes it feasible to more the > compression closer to the edge and maybe into the VOIP gear rather > than a router concentrating VOIP gear traffic. > > Thanks again, > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Wednesday, February 19, 2003 11:25 AM > > > To: Ash, Gerald R (Jerry), ALABS > > > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; George Swallow; > > > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > > > Dave Cooper > > > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > > > > > Please correct me if I'm wrong but your drafts seem to require end2end > > > MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since > > > you are providing new RSVP/TE objects the assumption seems to be > > > RSVP/TE MPLS edge to edge. If traffic engineering is done within > > > regions as can be done with current RTP/UDP/IP/MPLS regardless of > > > whether LDP is also used, that works fine and scales extremely well. > > > E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to > > > scale well in a single provider and is almost certain to become a > > > severe problem crossing SP boundaries. > > > > > > Curtis -- "It's easier said than done." ... and if you don't believe it, try proving that it's easier done than said, and you'll see that "it's easier said that `it's easier done than said' than it is done", which really proves that "it's easier said than done". From owner-mpls@UU.NET Thu Feb 20 08:19:33 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12347 for ; Thu, 20 Feb 2003 08:19:32 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwb22578 for ; Thu, 20 Feb 2003 13:23:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwb21845; Thu, 20 Feb 2003 13:22:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwb27729 for mpls-outgoing; Thu, 20 Feb 2003 13:22:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwb27723 for ; Thu, 20 Feb 2003 13:22:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwb03206 for ; Thu, 20 Feb 2003 13:21:51 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwb20884 for ; Thu, 20 Feb 2003 13:21:50 GMT Received: from almso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQocwb20868 for ; Thu, 20 Feb 2003 13:21:49 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1KCX1j1005138 for ; Thu, 20 Feb 2003 08:21:49 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032) id 3DF6BD4E02A40761; Thu, 20 Feb 2003 08:21:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS Date: Thu, 20 Feb 2003 08:21:41 -0500 Message-ID: <28F05913385EAC43AF019413F674A01704CB873A@OCCLUST04EVS1.ugd.att.com> Thread-Topic: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS Thread-Index: AcLYw38yoFNkWcW7TBC6XBMAeggzggAHd3Ag From: "Ash, Gerald R (Jerry), ALABS" To: "Abhijit" Cc: "Ash, Gerald R (Jerry), ALABS" , , , , , , "GOODE, B (Bur), ALABS" , , "Hand, James C, ALABS" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA12347 > I remember reading some work done on Voice over MPLS directly > without using RTP/UDP/IP overheads. Is that work going to be > a part of MPLS WG? > IMO, RTP/UDP/IP is a lot of overhead, compared to VoMPLS > approach which actually serves the same purpose (at least in > bearer path) This issue was addressed in the context of a BOF ("Voice Over IP Over MPLS (vompls)") held at IETF-47, March 2000. There are meeting notes and slides to be found at http://ietf.org/proceedings/00mar/index.html. Antti Kankkunen (then with Integral Access) and I were the co-chairs. The disposition was rather complicated, but here's a quick summary. There were 2 parts to the BOF: One thrust was Voice over MPLS *without IP*, which the IETF rejected as not within the IETF charter. This was a push from Integral Access, which was later taken to the MPLS Forum, where an implementation agreement was eventually approved for this approach. The second thrust was VoIP over MPLS, where two proposals were made for RTP/UDP/IP header compression, the 'simple' approach from Swallow and Berger, and another more complicated approach from Berger. Both of these approaches were presented to the BoF and to the MPLS WG, and were both accepted by the MPLS WG for further development (as well as MPLS WG charter extension). However, the work on these drafts didn't continue, for unclear reasons, and they expired. Swallow's 'simple' approach is being brought back again in one of the current drafts http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt. Hope this helps. Thanks, Jerry Ash From owner-mpls@UU.NET Thu Feb 20 09:30:38 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15675 for ; Thu, 20 Feb 2003 09:30:38 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwg25866 for ; Thu, 20 Feb 2003 14:34:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwg25122; Thu, 20 Feb 2003 14:34:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwg21161 for mpls-outgoing; Thu, 20 Feb 2003 14:33:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocwg21153 for ; Thu, 20 Feb 2003 14:33:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwg10092 for ; Thu, 20 Feb 2003 14:33:15 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwg13684 for ; Thu, 20 Feb 2003 14:33:15 GMT Received: from sa.infonet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sa.infonet.com [192.157.130.21]) id QQocwg13665 for ; Thu, 20 Feb 2003 14:33:14 GMT Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id h1KEWkfs024713; Thu, 20 Feb 2003 14:32:46 GMT Received: from zhangr2.info.net (lasi254.us.info.net [204.140.71.254]) by delta.info.net with ESMTP id OAA10813; Thu, 20 Feb 2003 14:32:40 GMT Message-Id: <5.1.0.14.0.20030219124931.024f2be8@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Feb 2003 04:59:49 -0800 To: curtis@fictitious.org From: raymond zhang Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression Cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" In-Reply-To: <200302191546.KAA78386@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:46 AM 2/19/2003 -0500, Curtis Villamizar wrote: Hi Curtis, Sorry I went off-line yesterday... Pls see further comments in line below. >In message <5.1.0.14.0.20030218213848.03324f20@delta.info.net>, raymond >zhang w >rites: > > At 10:48 PM 2/18/2003 -0500, Curtis Villamizar wrote: > > Hi Curtis, > > > > >In message <5.1.0.14.0.20030218154944.0283e668@delta.info.net>, raymond > > >zhang w > > >rites: > > > > > > > > Regarding payload size, firstly the voice frame size varies with > the ITU > > > > codecs selected on the CPE. For example, G.729a has 10ms per voice > > > > sampling frame and one could configure to stuff either two or three > frame > > s > > > > per VoIP packet... Hence 20 to 30 byte payload. Larger payload > size may > > > > present an issue in terms of loss, esp for a global network since > loss of > > > > one packet would result in multiple voice frame losses. > > > > > > > > As for vendors, I'd say any CPE vendors should have this capability > > > built in. > > > > .. > > > > > > > > >I think the SPs should speak as to whether the bandwidth inefficiency > > >of 30 byte payloads or the potential to lose a packet with a 200 byte > > >is a greater problem. All of the SP I've spoken to that are doing > > >VOIP are using diffserv EF service or otherwise insuring that voice > > >traffic is rarely if ever dropped. > > > > Surely... bandwidth inefficiency is certainly of a great concern to > > SPs. In areas where ample capacity can absorb any kind of network > > abnormality, some SPs has choosen not to even have diffserve > provisioned at > > each HoP which would warrant larger payload size. There are two areas, > > where EF is essential to provide a consistent level of statistical > > performance targets for voice traffic which are prone to congestion - > PE-CE > > links and where SP's network spans over capacity scarce or expensive > > regions... One example, if GK is not used and calls are made directly > > between two CEs across the network, there is basically no bandwidth > > admission mechanism to regulate the call request... If EF bandwidth is > > allocated for 100 calls, when the 101st call comes in, EF would police > > across all voice packets of all calls hence packet drops may occur (the > ash > > draft using rsvp signalling may resolve this issue). In cases such as > > these, smaller payload size may help minimize the frame loss ratio while > > bandwidth efficiency may then be achieved via header compression... These > > are just a couple of reasons I would like to voice support the two Ash > drafts > > . > > >Let me see if I understand this. If you have 101 calls you have some >(misguided) notion that you drop less with tiny payloads and lots of >overhead. Good point...my brief description above is not the best example to illustrate this. However issue remains in such situations. Upper bounds in terms of delay and loss need to be maintained in a much stricter sense for such real-time class as voice... Also, as Bur and Jerry pointed out, a payload size of 20 to 30 bytes enables us to do that much better across the voice path in delay budget planning in terms of queue efficiency (per HoP delay and variance), esp across the lower speed local-access links at lower sub-T1/E1 rates in an integrated data/voice environment. It may be more pronounced when the voice path spans across multiple continents with low speed last mile connections. >If you had large payloads the same link would hold 120-150 calls >depending on how large the payload was. You meant muxing voice frames from multiple calls into one packet ? Now I understand a bit what you are referring to, altho not all customer locations have same number of concurrent calls, many remote locations with very small # of concurrent calls. That means we would either have voice packets with variable frame-sizes on EF queues or stuff more voice frames from the same call into one packet ? >Next question - is your notion of drop more with larger payloads only >applicable to ATM when packet shredding is being done rather than >discarding entire frames? Don't all modern ATM switches support PPD? >If this is an ATM only issue and furthermore an old ATM switch issue >its probably not one for the IETF to address. No. It is over a MPLS packet network >The way things have been explained to me is an attempt is made to keep >no more than about 30% of the bandwidth on a link for EF (or pick a >number) and leave the rest for IP. The actual EF reservation might be >40% to 70% of the link so if you went to 101 calls and only 100 fit, >IP would be squeezed out of some more bandwidth than you'd like it to. A larger EF allocation on an egress interface may starve the rest of the data queues... That's why there is upper bound for EF allocation. Of course, the higher the link speed, the higher EF bandwidth can be allocated (e.g. local-access link). In addition, EF traffic is policed which will not erode into bandwidth space allocated for other classes. >Are you talking about EF on an IP or MPLS diffserv network or a VC on >an ATM network or TDM where you have to reserve exactly what you >expect to use and get hammerred if you use ever so slightly more? EF on MPLS diffserv network... >This is what has been recommended in the diff-serv and MPLS WGs almost >since the diff-serv WG started. The technique is certainly no secret. >A few people at SPs have hinted that their employer may consider the >fact that they are using it to be some sort of secret. >Curtis From owner-mpls@UU.NET Thu Feb 20 09:32:35 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15731 for ; Thu, 20 Feb 2003 09:32:35 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwg19367 for ; Thu, 20 Feb 2003 14:36:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwg18378; Thu, 20 Feb 2003 14:35:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwg21212 for mpls-outgoing; Thu, 20 Feb 2003 14:35:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwg21204 for ; Thu, 20 Feb 2003 14:35:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwg17336 for ; Thu, 20 Feb 2003 14:35:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwg16772 for ; Thu, 20 Feb 2003 14:35:03 GMT Received: from pfwhqs1.ncr.disa.mil by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mtahqs3.ncr.disa.mil [164.117.144.157]) id QQocwg16741 for ; Thu, 20 Feb 2003 14:35:02 GMT Received: from mtahqs3.ncr.disa.mil by pfwhqs1.ncr.disa.mil via smtpd (for cmr1.ash.ops.us.uu.net [198.5.241.39]) with SMTP; 20 Feb 2003 14:28:52 UT Received: by mtahqs3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 09:37:53 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4D31@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'Ina Minei'" Cc: "'Curtis Villamizar '" , "'Jim Boyle '" , "'Matthew Meyer '" , "'mpls@UU.NET '" , "Nguyen, An" Subject: RE: draft-meyer-mpls-soft-preemption-00.txt Date: Thu, 20 Feb 2003 09:33:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Ina, Sorry I didn't define what "critical" means. What I meant was "authorized emergency preparedness" traffic for Federal, state, and local. I am interested in how this critical traffic can be reliably routed in times of network congestion or crises. Thanks, An -----Original Message----- From: Ina Minei [mailto:ina@juniper.net] Sent: Wednesday, February 19, 2003 9:20 PM To: Nguyen, An Cc: 'Curtis Villamizar '; 'Jim Boyle '; 'Matthew Meyer '; 'mpls@UU.NET ' Subject: RE: draft-meyer-mpls-soft-preemption-00.txt I am not sure what you mean by critical. If "critical" implies zero loss always, then the answer is no. Please note that this scheme relies on a timer to do hard preemption regardless of whether the head end managed to resignal the LSP or not.It is true that this timer can be user configurable, but note that in the scheme presented this can be done in a scalable fashion only at node level and not at LSP level (since the head end does not signal the amount of time at LSP setup time). The proposed scheme will be beneficial, but cannot offer any hard guarantees. Thanks, Ina On Wed, 19 Feb 2003, Nguyen, An wrote: > Hi all, > > The draft is interesting. I wonder if this concept can be implemented to > transport critial traffic for customers in the MPLS network. > > Thanks, > > An Nguyen > > -----Original Message----- > From: Curtis Villamizar > To: Jim Boyle > Cc: Matthew Meyer; mpls@UU.NET > Sent: 2/19/03 4:39 PM > Subject: Re: draft-meyer-mpls-soft-preemption-00.txt > > > In message , Jim > Boyle > writes: > > > > First, great draft - I like this concept. > > > > While a flag might be just the right thing for this particular > > application, I wonder if it might be good to try to broaden > > soft preemption technique to include other polite preemptions. > > > > These might include the following indicators > > > > o) your LSP is being prempted on the indicated link (draft covers) > > o) your LSP should be rerouted, this node is shutting down > > o) your LSP should be rerouted, this link is being taken out of > > service > > o) your LSP should be rerouted away from this node > (administrative/CLI) > > o) your LSP should be rerouted away from this link > (administrative/CLI) > > > > You can somewhat do some of these by changing metrics and waiting, but > > just was wondering if something more general might be useful. > > Why couldn't you just use the same bit and allow soft preemption on > link shut, reload, CLI adminstrative without encoding the reason? > Since these are all CLI initiated, it wouldn't hurt to delay. > Alternately, the soft preempt on anything using a specific resource > could be done. > > Link bundle lost a member might also qualify as a reason for soft > preemption for implementations of link bundling that can trasnparently > more flows to other members of the bundle. > > > Also, with Diffserv TE, not sure that one can assume that a preemption > > necessarily "implies exhausted bandwidth at the affected priority > > level *and greater*" (section 5), but local implementations can do > > as they please I suppose. > > Agreed. The "and greater" should be dropped. > > > regards, > > > > Jim > > Thanks, > > Curtis > > > From owner-mpls@UU.NET Thu Feb 20 09:52:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16260 for ; Thu, 20 Feb 2003 09:52:54 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwh01614 for ; Thu, 20 Feb 2003 14:56:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwh00754; Thu, 20 Feb 2003 14:56:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwh22977 for mpls-outgoing; Thu, 20 Feb 2003 14:55:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwh22971 for ; Thu, 20 Feb 2003 14:55:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwh27872 for ; Thu, 20 Feb 2003 14:55:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwh18405 for ; Thu, 20 Feb 2003 14:55:23 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocwh18383 for ; Thu, 20 Feb 2003 14:55:22 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KEtKNh017303 for ; Thu, 20 Feb 2003 09:55:20 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA23042 for ; Thu, 20 Feb 2003 09:55:19 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KEtJO08306 for mpls@uu.net; Thu, 20 Feb 2003 09:55:19 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoctu15598 for ; Wed, 19 Feb 2003 22:40:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoctu25020 for ; Wed, 19 Feb 2003 22:39:36 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctu27349 for ; Wed, 19 Feb 2003 22:39:36 GMT Received: from gamma.isi.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gamma.isi.edu [128.9.144.145]) id QQoctu27338 for ; Wed, 19 Feb 2003 22:39:35 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h1JMdWD13193; Wed, 19 Feb 2003 14:39:32 -0800 (PST) Message-Id: <200302192239.h1JMdWD13193@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3479 on Fault Tolerance for the Label Distribution Protocol (LDP) Cc: rfc-editor@rfc-editor.org, mpls@UU.NET From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 19 Feb 2003 14:39:32 -0800 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3479 Title: Fault Tolerance for the Label Distribution Protocol (LDP) Author(s): A. Farrel, Ed. Status: Standards Track Date: February 2003 Mailbox: afarrel@movaz.com Pages: 52 Characters: 115778 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ldp-ft-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3479.txt Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. 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.echo 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030219143739.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3479 --OtherAccess Content-Type: Message/External-body; name="rfc3479.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030219143739.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Feb 20 09:54:08 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16290 for ; Thu, 20 Feb 2003 09:54:08 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwh23006 for ; Thu, 20 Feb 2003 14:57:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwh20172; Thu, 20 Feb 2003 14:56:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwh22980 for mpls-outgoing; Thu, 20 Feb 2003 14:55:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwh22972 for ; Thu, 20 Feb 2003 14:55:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwh28370 for ; Thu, 20 Feb 2003 14:55:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwh18830 for ; Thu, 20 Feb 2003 14:55:41 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocwh18820 for ; Thu, 20 Feb 2003 14:55:40 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KEtcNh017315 for ; Thu, 20 Feb 2003 09:55:38 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA23063 for ; Thu, 20 Feb 2003 09:55:37 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KEtbb08320 for mpls@uu.net; Thu, 20 Feb 2003 09:55:37 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoctu15501 for ; Wed, 19 Feb 2003 22:37:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoctu18924 for ; Wed, 19 Feb 2003 22:37:28 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctu25268 for ; Wed, 19 Feb 2003 22:37:27 GMT Received: from gamma.isi.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gamma.isi.edu [128.9.144.145]) id QQoctu25246 for ; Wed, 19 Feb 2003 22:37:26 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h1JMbKD12193; Wed, 19 Feb 2003 14:37:20 -0800 (PST) Message-Id: <200302192237.h1JMbKD12193@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3478 on Graceful Restart Mechanism for Label Distribution Protocol Cc: rfc-editor@rfc-editor.org, mpls@UU.NET From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 19 Feb 2003 14:37:20 -0800 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3478 Title: Graceful Restart Mechanism for Label Distribution Protocol Author(s): M. Leelanivas, Y. Rekhter, R. Aggarwal Status: Standards Track Date: February 2003 Mailbox: manoj@juniper.net, yakov@juniper.net, rahul@redback.com Pages: 12 Characters: 29248 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ldp-restart-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3478.txt This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. 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.echo 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030219143515.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3478 --OtherAccess Content-Type: Message/External-body; name="rfc3478.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030219143515.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Feb 20 09:54:10 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16301 for ; Thu, 20 Feb 2003 09:54:10 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwh22105 for ; Thu, 20 Feb 2003 14:57:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwh21344; Thu, 20 Feb 2003 14:57:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwh23172 for mpls-outgoing; Thu, 20 Feb 2003 14:56:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwh23167 for ; Thu, 20 Feb 2003 14:56:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocwh28708 for ; Thu, 20 Feb 2003 14:55:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwh29906 for ; Thu, 20 Feb 2003 14:55:53 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocwh29874 for ; Thu, 20 Feb 2003 14:55:51 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KEtmJR022571 for ; Thu, 20 Feb 2003 09:55:49 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA23075 for ; Thu, 20 Feb 2003 09:55:48 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KEtmc08328 for mpls@uu.net; Thu, 20 Feb 2003 09:55:48 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocvx05803 for ; Thu, 20 Feb 2003 12:23:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocvx07245 for ; Thu, 20 Feb 2003 12:22:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocvx14746 for ; Thu, 20 Feb 2003 12:22:33 GMT Received: from nausicaa.coritel.it by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [193.205.242.5]) id QQocvx14730 for ; Thu, 20 Feb 2003 12:22:32 GMT Received: from hertz (host22-170.pool8173.interbusiness.it [81.73.170.22]) by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id h1KCMdx00984 for ; Thu, 20 Feb 2003 13:22:40 +0100 Message-ID: <000401c2d8da$f2933900$92256497@coritel> From: "Roberto Albanese" To: "MPLS WG" Subject: Error Code Info Date: Wed, 19 Feb 2003 19:28:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, can anyone solve my doubts, please? I'd like to implement a link-failure functionality in a MPLS architecture using RSVP. I'd like to do this using a PathErr message i forward towards the SENDER node of the LSP. In this PathErr i put the only information: link-failure event occurred to LSP. I saw that there is an ERROR_SPEC Object with error code and values i can use, but i haven't found any proposal about what error code to use. Have you any? Is there a standard error code i haven't seen? What error code could i use? If there is not even one proposed i can use only an unassigned/private error code. What are the private error codes i can use? Thanks in advance for your kind answer Roberto Albanese From owner-mpls@UU.NET Thu Feb 20 10:19:52 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17246 for ; Thu, 20 Feb 2003 10:19:51 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwj24444 for ; Thu, 20 Feb 2003 15:23:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwj23645; Thu, 20 Feb 2003 15:23:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwj14186 for mpls-outgoing; Thu, 20 Feb 2003 15:22:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwj14136 for ; Thu, 20 Feb 2003 15:22:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwj16599 for ; Thu, 20 Feb 2003 15:22:13 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocwb00281 for ; Thu, 20 Feb 2003 13:27:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KDR3JR017151 for ; Thu, 20 Feb 2003 08:27:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA17308 for ; Thu, 20 Feb 2003 08:27:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KDR2303591 for mpls@uu.net; Thu, 20 Feb 2003 08:27:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwb27880 for ; Thu, 20 Feb 2003 13:25:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocwb09359 for ; Thu, 20 Feb 2003 13:25:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwb16050 for ; Thu, 20 Feb 2003 13:25:16 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocwb16025 for ; Thu, 20 Feb 2003 13:25:15 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id IAA85330; Thu, 20 Feb 2003 08:25:32 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302201325.IAA85330@workhorse.fictitious.org> To: Abhijit cc: curtis@fictitious.org, hand17@earthlink.net, gash@ems.att.com, zhangr@info.net, MPLS@UU.NET, swallow@cisco.com, loa.andersson@utfors.se, bgoode@att.com, cooper@GBLX.net Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS In-reply-to: Your message of "Thu, 20 Feb 2003 15:00:29 +0530." <20030220150029.0000212f.gabhijit@ee.iitb.ac.in> Date: Thu, 20 Feb 2003 08:25:32 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20030220150029.0000212f.gabhijit@ee.iitb.ac.in>, Abhijit writes: > > I remember reading some work done on Voice over MPLS directly without using R > TP/UDP/IP overheads. Is that work going to be a part of MPLS WG? > IMO, RTP/UDP/IP is a lot of overhead, compared to VoMPLS approach which actua > lly serves the same purpose (atleast in bearer path) > > Regards, > > -abhijit. That work died a long time ago because it required that e2e (or encaps device to encaps device) LSPs be used. MPLS RSVP/TE (or LDP) is **NOT** an end2end virtual circuit technology. RSVP/TE is a traffic engineering tool. It has so far been successfully very applied to traffic engineering localized to SP core or SP regions. With the addition of GMPLS it becomes a bit of a carrier's swiss army knife, supporting dynamic traffic engineering over optical and TDM but deployment of GMPLS may be a ways off. The reason I'm objecting to the drafts that were offerred is that they also required e2e (compression device to compression device) RSVP/TE LSPs and as a result may be impractical (ie: doomed to the same fate of the prior voice/MPLS effort). Ideally some scheme that allowed end users to encapsulate very efficiently but also met carrier needs would be best. That idealized goal doesn't seem feasible. For the end user (for example, using voice over IP from PC to PC) adding delay and increasing packet size seems the only feasible option. For the carrier, multiplexing streams from a gateway seems to me to be a more attractive solution than a special encapsulation between gateways that requires an e2e (do I need to repeat the disclaimer on e2e again) RSVP/TE LSP to work. Curtis ps - end2end in this sort of context (MPLS, RSVP/TE or LDP) is always assumed to mean at most edge of the carrier's network, not end user. This is because end user to end user in an MPLS discussion is so absurd that it can't possibly be intended as part of the discussion. E2e is assumed to mean the edge of whatever is being discussed, the edge is the voice compression/encaps gateways in this context. From owner-mpls@UU.NET Thu Feb 20 10:21:44 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17405 for ; Thu, 20 Feb 2003 10:21:44 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwj08767 for ; Thu, 20 Feb 2003 15:25:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwj08076; Thu, 20 Feb 2003 15:25:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwj14236 for mpls-outgoing; Thu, 20 Feb 2003 15:24:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwj14226 for ; Thu, 20 Feb 2003 15:24:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwj22629 for ; Thu, 20 Feb 2003 15:24:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwj02700 for ; Thu, 20 Feb 2003 15:24:07 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocwj02692 for ; Thu, 20 Feb 2003 15:24:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KFO4Nh019031 for ; Thu, 20 Feb 2003 10:24:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25483 for ; Thu, 20 Feb 2003 10:24:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KFO3L12070 for mpls@uu.net; Thu, 20 Feb 2003 10:24:03 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwj13982 for ; Thu, 20 Feb 2003 15:21:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocwj13738 for ; Thu, 20 Feb 2003 15:21:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwj03871 for ; Thu, 20 Feb 2003 15:21:17 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocwj03856 for ; Thu, 20 Feb 2003 15:21:16 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA86722; Thu, 20 Feb 2003 10:21:40 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302201521.KAA86722@workhorse.fictitious.org> To: "Jim Hand" cc: curtis@fictitious.org, "'Ash, Gerald R \(Jerry\), ALABS'" , "'raymond zhang'" , "'MPLS@UU.net'" , "'George Swallow'" , "'Loa Andersson'" , "'GOODE, B \(Bur\), ALABS'" , "'Dave Cooper'" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS In-reply-to: Your message of "Wed, 19 Feb 2003 23:05:20 EST." <000001c2d8f0$d5941e80$3a785b87@mt.att.com> Date: Thu, 20 Feb 2003 10:21:40 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <000001c2d8f0$d5941e80$3a785b87@mt.att.com>, "Jim Hand" writes: > In many VoIP services I am working with, the most important place for > bandwidth efficiency is on the access link between the customer premise and > the provider edge. There is limited opportunity at the customer premise for > connection muxing, because of the limited number of connections. So I think > it would be necessary to do compression on the access link in many cases > anyway. That is where the RTP/UDP/IP header compression can be utilized. Either Casner's older RFC specifically for PPP or the newer one (rfc3095) specifically for cellular. > You could then do connection muxing inside the Service Provider's netwo > rk. > But in order to do the connection muxing, you would likely have to > decompress the packets first (perhaps there might be some way around this). > This would require a place in the network where you would have to do both > compression/decompresion and connection muxing/demuxing. That's a lot of > load at some aggregation points in the network. With the end-to-end > compression, we were hoping to push the compression load out toward the > edges, where there are more boxes to apply to the compression load, and > avoid it altogether within the SP transport network. Right. You can't possibly do MPLS RSVP/TE from the customer edge all the way to the other customer edge, so voice/MPLS is an immediate non-starter. The aggregation router will need to decompress headers and forward. If and only if backbone bandwidth is a pressing issue does any header compression or multiplexing need to be done in the backbone. Alternately you need a compression over IP that doesn't require e2e RSVP/TE MPLS (for some large value of e2e). > Thanks, > Jim What the SPs probably could really use for the access circuit bandwidth problem is the RTP/UDP/IP header compression done on the line cards rather than sent to the route processor (to be handled by the onboard macintosh as one person at an ISP used to like to say when 680x0 was the processor on his routers). I'm probably not the first person to think of that, but I don't know that anyone has done it yet. Curtis From owner-mpls@UU.NET Thu Feb 20 11:02:27 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19105 for ; Thu, 20 Feb 2003 11:02:27 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwm12411 for ; Thu, 20 Feb 2003 16:06:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwm11472; Thu, 20 Feb 2003 16:05:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwm05241 for mpls-outgoing; Thu, 20 Feb 2003 16:05:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocwm05231 for ; Thu, 20 Feb 2003 16:05:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwm04156 for ; Thu, 20 Feb 2003 16:04:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwm04464 for ; Thu, 20 Feb 2003 16:04:07 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocwm04403 for ; Thu, 20 Feb 2003 16:04:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KG43JR027624 for ; Thu, 20 Feb 2003 11:04:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA29026 for ; Thu, 20 Feb 2003 11:04:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KG42s17694 for mpls@uu.net; Thu, 20 Feb 2003 11:04:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwm27964 for ; Thu, 20 Feb 2003 16:02:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwm21238 for ; Thu, 20 Feb 2003 16:01:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwm00258 for ; Thu, 20 Feb 2003 16:01:15 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocwm00035 for ; Thu, 20 Feb 2003 16:01:07 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA86841; Thu, 20 Feb 2003 11:01:17 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302201601.LAA86841@workhorse.fictitious.org> To: raymond zhang cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Thu, 20 Feb 2003 04:59:49 PST." <5.1.0.14.0.20030219124931.024f2be8@delta.info.net> Date: Thu, 20 Feb 2003 11:01:17 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk Raymond, I trimmed out part of your response. In message <5.1.0.14.0.20030219124931.024f2be8@delta.info.net>, raymond zhang w rites: > > Good point...my brief description above is not the best example to > illustrate this. However issue remains in such situations. Upper bounds > in terms of delay and loss need to be maintained in a much stricter sense > for such real-time class as voice... Also, as Bur and Jerry pointed out, a > payload size of 20 to 30 bytes enables us to do that much better across the > voice path in delay budget planning in terms of queue efficiency (per HoP > delay and variance), esp across the lower speed local-access links at lower > sub-T1/E1 rates in an integrated data/voice environment. It may be more > pronounced when the voice path spans across multiple continents with low > speed last mile connections. Tiny payload is needed for queue efficiency is a myth left over from the ATM days. It is simply not true. Lose overhead and queues are smaller. Do some delay variation buffering and jitter is a total non-issue. This is like the IP vs ATM discussions of the mid-1990s. > >If you had large payloads the same link would hold 120-150 calls > >depending on how large the payload was. > > You meant muxing voice frames from multiple calls into one packet ? Now I > understand a bit what you are referring to, altho not all customer > locations have same number of concurrent calls, many remote locations with > very small # of concurrent calls. That means we would either have voice > packets with variable frame-sizes on EF queues or stuff more voice frames > from the same call into one packet ? No I meant increasing payload to 200 bytes to decrease overhead so that there was 50% more payload capacity on the same link. > >The way things have been explained to me is an attempt is made to keep > >no more than about 30% of the bandwidth on a link for EF (or pick a > >number) and leave the rest for IP. The actual EF reservation might be > >40% to 70% of the link so if you went to 101 calls and only 100 fit, > >IP would be squeezed out of some more bandwidth than you'd like it to. > > A larger EF allocation on an egress interface may starve the rest of the > data queues... That's why there is upper bound for EF allocation. Of > course, the higher the link speed, the higher EF bandwidth can be allocated > (e.g. local-access link). In addition, EF traffic is policed which will > not erode into bandwidth space allocated for other classes. This is what the ISPs are doing. TCP is compressible and some 95-98% of Internet traffic is TCP, much of it large enough flows to compress in the event of congestion. This is what ISPs are doing. They could favor SLA traffic over non-SLA traffic (at least one way) but it hasn't become a practical problem for most ISPs to the point where they've bothered to do so. For the most part backbone links are sufficiently overprovisioned to absorb the variation in traffic load without special queueing except for the EF service. Some of the aggregation links (regional) might be a little more problematic for some SPs. The statement that EF traffic is policed in this case is for the most part not accurate. SPs would like the VOIP gear to have limits on calls going out but most (all?) don't. Failing that SPs would like to be able to use policing but it is impractical. Ideally, VOIP would use LSPs with different EXP and setup/resv priority with a bandwidth allocation that reflected the traffic volume being offered. Currently, the only practical way to get the bandwidth allocation right or close to right is either configured based on history (usually close to right, but some argue maybe not close enough) or based on filtered measurements (and the filters may need some work here). Measuring the bandwidth allows the LSPs to be rerouted but does not handle the case were the bandwidth is no where to be found and the VOIP equipment needs to block calls. So far the practical answer has been to ignore that case and ask VOIP gear for a configured limit on calls. There is some work on adaptive bandwidth techniques were the payload itself is changed (lower bandwidth encoding) when congestion is detected (some level of loss occurs). An interesting change that any VOIP gear could make without any changes to standards would be to move the playout point ahead in time by 10-50 msec as congestion is detected. In the absense of congestion, you'd have tiny packets and as small a delay as practical. On the onset of congestion, you'd have small loss and a switch from 30 msec to 40 msec playout delay. The improvement for G.709 would be from 30/(30+40) to 40/(40+40) percent of the bandwidth being used for payload (43% to 50%). You would immediately get 16+% more capacity for a 10 msec additional delay. If congestion persists, you can push this all the way to 80 msec, and get 55% more traffic over the same link. If you could also just compress the RTP and UDP headers (yielding 24 byte overhead rather than 40), this could become quite viable (55-76% payload for 30-80 msec). If the network becomes congested, it certainly makes more sense to relax the delay criteria than to introduce loss. Curtis From owner-mpls@UU.NET Thu Feb 20 11:13:10 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19708 for ; Thu, 20 Feb 2003 11:13:10 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwn05495 for ; Thu, 20 Feb 2003 16:16:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwn04809; Thu, 20 Feb 2003 16:16:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwn07709 for mpls-outgoing; Thu, 20 Feb 2003 16:16:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocwn07692 for ; Thu, 20 Feb 2003 16:16:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwn20263 for ; Thu, 20 Feb 2003 16:15:22 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwn24535 for ; Thu, 20 Feb 2003 16:15:21 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocwn24515 for ; Thu, 20 Feb 2003 16:15:21 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KGFINh022218 for ; Thu, 20 Feb 2003 11:15:18 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA29868 for ; Thu, 20 Feb 2003 11:15:18 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KGFIx19854 for mpls@uu.net; Thu, 20 Feb 2003 11:15:18 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwm07124 for ; Thu, 20 Feb 2003 16:14:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwm12637 for ; Thu, 20 Feb 2003 16:13:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwm21779 for ; Thu, 20 Feb 2003 16:13:43 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocwm21753 for ; Thu, 20 Feb 2003 16:13:42 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA86892; Thu, 20 Feb 2003 11:09:30 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302201609.LAA86892@workhorse.fictitious.org> To: raymond zhang cc: "Uzelac, Adam" , "'GOODE, B (Bur), ALABS'" , curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , George Swallow , Loa Andersson Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Thu, 20 Feb 2003 05:32:11 PST." <5.1.0.14.0.20030220051410.07cccaf8@delta.info.net> Date: Thu, 20 Feb 2003 11:09:30 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.1.0.14.0.20030220051410.07cccaf8@delta.info.net>, raymond zhang w rites: > Hi Uzelac, > > > At 01:39 PM 2/19/2003 -0500, Uzelac, Adam wrote: > > > 30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes 62% overhead > > > 30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes 21% overhead > > > 200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes 19% overhead > > > 300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes 14% overhead > > > >I am afraid there is some confusion on this one. The 200-300 bytes probably > >included the RTP/UDP/IP headers as well. > > > >Bandwidth Calculations G.711 > >Packetization Delay (in ms) 20 > >Payload Speed (in bits per second) 64,000 > >Payload (in bytes) 160 > >RTP (in bytes) 12 > >UDP (in bytes) 8 > >IP (in bytes) 20 > >Total Packet Size (in bytes) 200 > > > >BUT the issue still stands - Using the G.723.1 coder (which produces 24 byte > >frames > >every 30 milliseconds), each packet would have only 24 bytes of data to 40 > >bytes of header. > >Thus, the header would be 67% of the entire packet. The bigger the payload, > >the better, with the understood impact should packet loss occur. Reduce the > >ratio by increasing the payload and don't drop any packets on the floor! > > Surely if you could maintain 0% or near 0% packet loss ratio over all voice > paths (e2e) during busy hour, tho upper bound delay limit becomes > increasingly difficult to meet esp for inter-continental calls (worsened by > longer propagation delay) in which paths include the low speed CE-PE links... > > Regards, > Raymond Raymond, For every SP I've spoken to, and most have "I" in front of the "SP", loss in the backbone for voice is effectively held to very near absolute zero. Any variation in demand is absorbed first by the fact that they are somewhat overprovisioned, and second by taking some resources from IP through preferred queueing of the VOIP traffic. If you are now talking about CE-PE links, you've changed the problem statement. For this problem, the best solution might be to put the existing RTP/UDP/IP/PPP header compression on the PE line cards rather than in the route processor to solve bottlenecks there. That's a practical problem, not a standards issue. Curtis From owner-mpls@UU.NET Thu Feb 20 11:15:41 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19845 for ; Thu, 20 Feb 2003 11:15:40 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwn03749 for ; Thu, 20 Feb 2003 16:19:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwn02645; Thu, 20 Feb 2003 16:18:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwn07743 for mpls-outgoing; Thu, 20 Feb 2003 16:17:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocwn07732 for ; Thu, 20 Feb 2003 16:17:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwn16645 for ; Thu, 20 Feb 2003 16:16:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwn25822 for ; Thu, 20 Feb 2003 16:16:08 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocwn25777 for ; Thu, 20 Feb 2003 16:16:08 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KGG4JR028553 for ; Thu, 20 Feb 2003 11:16:05 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA29931 for ; Thu, 20 Feb 2003 11:16:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KGG4k20108 for mpls@uu.net; Thu, 20 Feb 2003 11:16:04 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwm07112 for ; Thu, 20 Feb 2003 16:14:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwm24550 for ; Thu, 20 Feb 2003 16:13:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwm26113 for ; Thu, 20 Feb 2003 16:13:33 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocwm26087 for ; Thu, 20 Feb 2003 16:13:32 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA86922; Thu, 20 Feb 2003 11:13:49 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302201613.LAA86922@workhorse.fictitious.org> To: "Nguyen, An" cc: "'Ina Minei'" , "'Curtis Villamizar '" , "'Jim Boyle '" , "'Matthew Meyer '" , "'mpls@UU.NET '" Reply-To: curtis@fictitious.org Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-reply-to: Your message of "Thu, 20 Feb 2003 09:33:49 EST." <7F18415E4D63CB45BB9B3A591F68D12D02EF4D31@emshqs1.ncr.disa.mil> Date: Thu, 20 Feb 2003 11:13:49 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <7F18415E4D63CB45BB9B3A591F68D12D02EF4D31@emshqs1.ncr.disa.mil>, "Ng uyen, An" writes: > Ina, > > Sorry I didn't define what "critical" means. What I meant was "authorized > emergency preparedness" traffic for Federal, state, and local. I am > interested in how this critical traffic can be reliably routed in times of > network congestion or crises. > > Thanks, > > An As a practical matter, I don't think there would be other traffic that would be preempting "authorized emergency preparedness" traffic for Federal, state, and local. The soft preemption helps the traffic which is being preempted. AFAIK "authorized emergency preparedness" traffic is not being selectively signaled and queued at all in ISP networks. Curtis From owner-mpls@UU.NET Thu Feb 20 11:56:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21247 for ; Thu, 20 Feb 2003 11:56:53 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwq26639 for ; Thu, 20 Feb 2003 17:00:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwq26015; Thu, 20 Feb 2003 17:00:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwp11443 for mpls-outgoing; Thu, 20 Feb 2003 16:59:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwp11438 for ; Thu, 20 Feb 2003 16:59:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocwp22537 for ; Thu, 20 Feb 2003 16:59:32 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwp25082 for ; Thu, 20 Feb 2003 16:59:31 GMT Received: from mailserver1.opnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserver1.opnet.com [12.145.55.23]) id QQocwp25073 for ; Thu, 20 Feb 2003 16:59:31 GMT Received: from wtn10216.opnet.com (wtn10216.opnet.com [172.16.10.216]) by mailserver1.opnet.com (8.12.6/8.12.6) with ESMTP id h1KGxL6R007282; Thu, 20 Feb 2003 11:59:21 -0500 (EST) Message-Id: <5.0.0.25.2.20030220115522.00a70cb0@mailserver.opnet.com> X-Sender: skalra@mailserver.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 20 Feb 2003 12:03:26 -0500 To: rfc-editor@rfc-editor.org, Internet-Drafts@ietf.org From: Sachin Kalra Subject: Mails from "rfc-editor" and "Internet-Drafts" Cc: mpls@UU.NET In-Reply-To: <200302192239.h1JMdWD13193@gamma.isi.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_172332210==_.ALT" X-MailScanner: Found to be clean Sender: owner-mpls@UU.NET Precedence: bulk --=====================_172332210==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear MPLS Community: Since last few months, all of the emails that come from 'rfc-editor@rfc-editor.org' and 'Internet-Drafts@ietf.org' appears to be "Virus Infected". If this is true, then either they should fix the mails before sending them out or 'mpls@UU.NET' Mail server should filter out the infected mails. Just a little thought. Thanks, Sachin Kalra At 02:39 PM 2/19/03 -0800, rfc-editor@rfc-editor.org wrote: >Warning: This message has had one or more attachments removed >Warning: (not named). >Warning: Please read the "VirusWarning.txt" attachment(s) for more >information. > > {Virus} RFC 3479 on Fault Tolerance for the Label Distribution Protocol > (LDP) >A new Request for Comments is now available in online RFC libraries. > > > RFC 3479 > > Title: Fault Tolerance for the Label Distribution > Protocol (LDP) > Author(s): A. Farrel, Ed. > Status: Standards Track > Date: February 2003 > Mailbox: afarrel@movaz.com > Pages: 52 > Characters: 115778 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-mpls-ldp-ft-06.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3479.txt > > >Multiprotocol Label Switching (MPLS) systems will be used >in core networks where system downtime must be kept to an >absolute minimum. Many MPLS Label Switching Routers >(LSRs) may, therefore, exploit Fault Tolerant (FT) >hardware or software to provide high availability of the >core networks. > >The details of how FT is achieved for the various >components of an FT LSR, including Label Distribution >Protocol (LDP), the switching hardware and TCP, are >implementation specific. This document identifies issues >in the LDP specification in RFC 3036, "LDP Specification", >that make it difficult to implement an FT LSR using the >current LDP protocols, and defines enhancements to the >LDP specification to ease such FT LSR implementations. > >The issues and extensions described here are equally >applicable to RFC 3212, "Constraint-Based LSP Setup Using >LDP" (CR-LDP). > >This document is a product of the Multiprotocol Label Switching >Working Group of the IETF. > >This is now a Proposed Standard Protocol. > >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.echo >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 > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. >This is a message from the MailScanner E-Mail Virus Protection Service >---------------------------------------------------------------------- >The original e-mail attachment "msg-20929-502.msg" >was believed to be infected by a virus and has been replaced by this warning >message. > >If you wish to receive a copy of the *infected* attachment, please >e-mail helpdesk and include the whole of this message >in your request. Alternatively, you can call them, with >the contents of this message to hand when you call. > >At Thu Feb 20 11:36:32 2003 the virus scanner said: > External message bodies cannot be scanned and are removed > >Note to Help Desk: Look on MailScanner on Mailserver1 in >/var/spool/MailScanner/quarantine/20030220 (message h1KGaS6Q000942). >-- >Postmaster >Mailscanner thanks transtec Computers for their support >This is a message from the MailScanner E-Mail Virus Protection Service >---------------------------------------------------------------------- >The original e-mail attachment "rfc3479.txt" >was believed to be infected by a virus and has been replaced by this warning >message. > >If you wish to receive a copy of the *infected* attachment, please >e-mail helpdesk and include the whole of this message >in your request. Alternatively, you can call them, with >the contents of this message to hand when you call. > >At Thu Feb 20 11:36:32 2003 the virus scanner said: > External message bodies cannot be scanned and are removed > >Note to Help Desk: Look on MailScanner on Mailserver1 in >/var/spool/MailScanner/quarantine/20030220 (message h1KGaS6Q000942). >-- >Postmaster >Mailscanner thanks transtec Computers for their support --=====================_172332210==_.ALT Content-Type: text/html; charset="us-ascii" Dear MPLS Community:

Since last few months, all of the emails that come from 'rfc-editor@rfc-editor.org' and 'Internet-Drafts@ietf.org' appears to be "Virus Infected".

If this is true, then either they should fix the mails before sending them out or 'mpls@UU.NET' Mail server should filter out the infected mails.

Just a little thought.
Thanks,
Sachin Kalra



At 02:39 PM 2/19/03 -0800, rfc-editor@rfc-editor.org wrote:
Warning: This message has had one or more attachments removed
Warning: (not named).
Warning: Please read the "VirusWarning.txt" attachment(s) for more information.

 {Virus} RFC 3479 on Fault Tolerance for the Label Distribution Protocol (LDP)
A new Request for Comments is now available in online RFC libraries.


        RFC 3479

        Title:      Fault Tolerance for the Label Distribution
                    Protocol (LDP)
        Author(s):  A. Farrel, Ed.
        Status:     Standards Track
        Date:       February 2003
        Mailbox:    afarrel@movaz.com
        Pages:      52
        Characters: 115778
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-mpls-ldp-ft-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3479.txt


Multiprotocol Label Switching (MPLS) systems will be used
in core networks where system downtime must be kept to an
absolute minimum.  Many MPLS Label Switching Routers
(LSRs) may, therefore, exploit Fault Tolerant (FT)
hardware or software to provide high availability of the
core networks.

The details of how FT is achieved for the various
components of an FT LSR, including Label Distribution
Protocol (LDP), the switching hardware and TCP, are
implementation specific.  This document identifies issues
in the LDP specification in RFC 3036, "LDP Specification",
that make it difficult to implement an FT LSR using the
current LDP protocols, and defines enhancements to the
LDP specification to ease such FT LSR implementations.

The issues and extensions described here are equally
applicable to RFC 3212, "Constraint-Based LSP Setup Using
LDP" (CR-LDP).

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.

This is now a Proposed Standard Protocol.

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

...

Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "msg-20929-502.msg"
was believed to be infected by a virus and has been replaced by this warning
message.

If you wish to receive a copy of the *infected* attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Thu Feb 20 11:36:32 2003 the virus scanner said:
   External message bodies cannot be scanned and are removed

Note to Help Desk: Look on MailScanner on Mailserver1 in /var/spool/MailScanner/quarantine/20030220 (message h1KGaS6Q000942).
--
Postmaster
Mailscanner thanks transtec Computers for their support
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "rfc3479.txt"
was believed to be infected by a virus and has been replaced by this warning
message.

If you wish to receive a copy of the *infected* attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Thu Feb 20 11:36:32 2003 the virus scanner said:
   External message bodies cannot be scanned and are removed

Note to Help Desk: Look on MailScanner on Mailserver1 in /var/spool/MailScanner/quarantine/20030220 (message h1KGaS6Q000942).
--
Postmaster
Mailscanner thanks transtec Computers for their support
--=====================_172332210==_.ALT-- From owner-mpls@UU.NET Thu Feb 20 12:23:57 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22086 for ; Thu, 20 Feb 2003 12:23:57 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwr27936 for ; Thu, 20 Feb 2003 17:27:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwr27535; Thu, 20 Feb 2003 17:27:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwr02243 for mpls-outgoing; Thu, 20 Feb 2003 17:27:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwr02238 for ; Thu, 20 Feb 2003 17:27:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwr29396 for ; Thu, 20 Feb 2003 17:26:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwr02785 for ; Thu, 20 Feb 2003 17:26:05 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQocwr02755 for ; Thu, 20 Feb 2003 17:26:02 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12695 for ; Thu, 20 Feb 2003 12:26:00 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26206 for ; Thu, 20 Feb 2003 12:26:01 -0500 (EST) Message-ID: <3E550FB2.3060900@marconi.com> Date: Thu, 20 Feb 2003 12:26:10 -0500 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF MPLS List Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS References: <200302201521.KAA86722@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > You can't possibly do MPLS RSVP/TE from the customer edge all the way > to the other customer edge, so voice/MPLS is an immediate non-starter. If used in the context of voice-through-internet, then yes. But it may still be useful within a voice carrier. Think of how voice carriers currently run their voice circuits over ATM. You don't have an ATM circuit going all the way to your home. If carriers want to eventually merge their voice and data infrastructures, then voice-over- MPLS sounds like something they may want. But I don't think there's any need for the IETF to get involved in such development, since the only IP-related component would be managing the LSP itself, and existing protocols are adequate for that task. -- David From owner-mpls@UU.NET Thu Feb 20 12:48:36 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22814 for ; Thu, 20 Feb 2003 12:48:35 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwt08157 for ; Thu, 20 Feb 2003 17:52:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwt07466; Thu, 20 Feb 2003 17:52:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwt03945 for mpls-outgoing; Thu, 20 Feb 2003 17:51:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwt03936 for ; Thu, 20 Feb 2003 17:51:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwt17119 for ; Thu, 20 Feb 2003 17:51:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwt06349 for ; Thu, 20 Feb 2003 17:51:11 GMT Received: from sa.infonet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sa.infonet.com [192.157.130.21]) id QQocwt06336 for ; Thu, 20 Feb 2003 17:51:10 GMT Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id h1KHnSfs027067; Thu, 20 Feb 2003 17:49:28 GMT Received: from zhangr2.info.net (lasi254.us.info.net [204.140.71.254]) by delta.info.net with ESMTP id RAA14465; Thu, 20 Feb 2003 17:49:19 GMT Message-Id: <5.1.0.14.0.20030220084042.02556418@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Feb 2003 09:44:20 -0800 To: curtis@fictitious.org From: raymond zhang Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression Cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" In-Reply-To: <200302201601.LAA86841@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Thanks for the response and see some further comments in line... Based upon discussions we have thus far including your response to my comments in response to Uzelac's email, maybe I should make some clarifications first which may help my understanding of your input as well in any further discussions: The environment in which I am referring to is a global IP/MPLS packet-based network spanning all major and sub-continents where it is not always possible to get ample bandwidth (over-provisioning) economically (very expensive in fact)... The issues of delay or packet loss do not normally present problems at all as you pointed out, in some continental or national networks of ISPs or SPs but to offer similar level of integrated services (voice/data) for customers with world-wide locations, it is in these remote regions and over last mile local loops that we spend a bit more efforts on to optimize. On low speed local-loops (PE-CE links), IP/UDP/RTP compressions is needed. I think we both agree on that. As for PE doing the comp/depcomp, I'd like to hear a bit more from the Vendors... My experience has been that hardware based compression at PE levels on the edge of the network with large # of aggregating diffserve-enabled customer links presents complexity that may become unmanageable to SPs and with amount of edge features already processed through hardware, would adding compression/decompression be even feasible ? Besides, the upgrade path may be very costly for these line cards which maybe deployed in large numbers across the global network as we add new feature sets/hardware capabilities. So I am not in favor of it as an option for PE level routers. Therefore the concept of distributing compression/decompression into CE levels, not in the network appeals in a great deal. If PE is not doing the comp/decomp, then the compressed path needs to be e2e... Further comments in lines .... Regards, Raymond At 11:01 AM 2/20/2003 -0500, Curtis Villamizar wrote: >Raymond, > >I trimmed out part of your response. > >In message <5.1.0.14.0.20030219124931.024f2be8@delta.info.net>, raymond >zhang w >rites: > > > > Good point...my brief description above is not the best example to > > illustrate this. However issue remains in such situations. Upper bounds > > in terms of delay and loss need to be maintained in a much stricter sense > > for such real-time class as voice... Also, as Bur and Jerry pointed > out, a > > payload size of 20 to 30 bytes enables us to do that much better across > the > > voice path in delay budget planning in terms of queue efficiency (per HoP > > delay and variance), esp across the lower speed local-access links at > lower > > sub-T1/E1 rates in an integrated data/voice environment. It may be more > > pronounced when the voice path spans across multiple continents with low > > speed last mile connections. > >Tiny payload is needed for queue efficiency is a myth left over from >the ATM days. It is simply not true. I think there are two aspects in this... Firstly traffic flows with constant packet size would improve queue efficiency (M/D/1) and smaller packet payload would reduce delay across low speed links (not an issue once again in areas of network with large pipes since no or little qeueuing) which is required as part of the budge delay planning. The voice quality is provided on a per path basis not just over segments of the path inside SP's major portion of the backbone. ( I don't mean to spur another around of discussions on ATM vs. IP at all ! I thought issues are well understood by now). >Lose overhead and queues are smaller. Do some delay variation >buffering and jitter is a total non-issue. > >This is like the IP vs ATM discussions of the mid-1990s. > > > >If you had large payloads the same link would hold 120-150 calls > > >depending on how large the payload was. > > > > You meant muxing voice frames from multiple calls into one packet ? Now I > > understand a bit what you are referring to, altho not all customer > > locations have same number of concurrent calls, many remote locations with > > very small # of concurrent calls. That means we would either have voice > > packets with variable frame-sizes on EF queues or stuff more voice frames > > from the same call into one packet ? > >No I meant increasing payload to 200 bytes to decrease overhead so >that there was 50% more payload capacity on the same link. So if not muxing voice frames from multiple calls between same pair of GWs, would then stuff more voice frames of the same call into the RTP payload ? If CE is the gateway (oftentimes it is in today environment), then as mentioned before larger packet payload would present delay issues in queuing/serialization over low speed local loops. I don't think PE is the right place to do that this. > > >The way things have been explained to me is an attempt is made to keep > > >no more than about 30% of the bandwidth on a link for EF (or pick a > > >number) and leave the rest for IP. The actual EF reservation might be > > >40% to 70% of the link so if you went to 101 calls and only 100 fit, > > >IP would be squeezed out of some more bandwidth than you'd like it to. > > > > A larger EF allocation on an egress interface may starve the rest of the > > data queues... That's why there is upper bound for EF allocation. Of > > course, the higher the link speed, the higher EF bandwidth can be > allocated > > (e.g. local-access link). In addition, EF traffic is policed which will > > not erode into bandwidth space allocated for other classes. > >This is what the ISPs are doing. TCP is compressible and some 95-98% >of Internet traffic is TCP, much of it large enough flows to compress >in the event of congestion. > >This is what ISPs are doing. They could favor SLA traffic over >non-SLA traffic (at least one way) but it hasn't become a practical >problem for most ISPs to the point where they've bothered to do so. > >For the most part backbone links are sufficiently overprovisioned to >absorb the variation in traffic load without special queueing except >for the EF service. Some of the aggregation links (regional) might be >a little more problematic for some SPs. >The statement that EF traffic is policed in this case is for the most >part not accurate. But it is, at least over the CE-PE link. >SPs would like the VOIP gear to have limits on >calls going out but most (all?) don't. Failing that SPs would like to >be able to use policing but it is impractical. Ideally, VOIP would >use LSPs with different EXP and setup/resv priority with a bandwidth >allocation that But on the edge (CE-PE links) and inside network, voice traffic is treated via strict priority over other types of traffic which would begin to starve other classes of traffic should its resource occupation exceeds a threshold (varies with link speed)... You would need CAC on this which there is not one over a MPLS/IP packet backbone... TE LSP only signals the reservation, not CACing. > reflected the traffic volume being offered. Right... We have to understand the per-class (traffic type) traffic mix in the network for primary path placements planning. But it is somewhat difficult when over-provisioning is not a good option in some areas of the networks and during node/link events. >Currently, the only practical way to get the bandwidth allocation >right or close to right is either configured based on history (usually >close to right, but some argue maybe not close enough) or based on >filtered measurements (and the filters may need some work here). >Measuring the bandwidth allows the LSPs to be rerouted but does not >handle the case were the bandwidth is no where to be found and the >VOIP equipment needs to block calls. So far the practical answer has >been to ignore that case and ask VOIP gear for a configured limit on >calls. > >There is some work on adaptive bandwidth techniques were the payload >itself is changed (lower bandwidth encoding) when congestion is >detected (some level of loss occurs). An interesting change that any >VOIP gear could make without any changes to standards would be to move >the playout point ahead in time by 10-50 msec as congestion is >detected. In the absense of congestion, you'd have tiny packets and >as small a delay as practical. On the onset of congestion, you'd have >small loss and a switch from 30 msec to 40 msec playout delay. The >improvement for G.709 would be from 30/(30+40) to 40/(40+40) percent >of the bandwidth being used for payload (43% to 50%). You would >immediately get 16+% more capacity for a 10 msec additional delay. If >congestion persists, you can push this all the way to 80 msec, and get >55% more traffic over the same link. If you could also just compress >the RTP and UDP headers (yielding 24 byte overhead rather than 40), >this could become quite viable (55-76% payload for 30-80 msec). If >the network becomes congested, it certainly makes more sense to relax >the delay criteria than to introduce loss. > >Curtis From owner-mpls@UU.NET Thu Feb 20 13:06:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23441 for ; Thu, 20 Feb 2003 13:06:01 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwu14074 for ; Thu, 20 Feb 2003 18:09:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwu13623; Thu, 20 Feb 2003 18:09:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwu23176 for mpls-outgoing; Thu, 20 Feb 2003 18:09:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwu23171 for ; Thu, 20 Feb 2003 18:08:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwu13859 for ; Thu, 20 Feb 2003 18:07:52 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwu03939 for ; Thu, 20 Feb 2003 18:07:51 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe15.law9.hotmail.com [64.4.8.119]) id QQocwu03933 for ; Thu, 20 Feb 2003 18:07:51 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Feb 2003 10:07:50 -0800 X-Originating-IP: [210.214.123.210] From: "john smith" To: "IETF MPLS List" References: <200302201521.KAA86722@workhorse.fictitious.org> <3E550FB2.3060900@marconi.com> Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-EndMPLS Date: Thu, 20 Feb 2003 23:56:52 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 20 Feb 2003 18:07:50.0328 (UTC) FILETIME=[FAF86B80:01C2D90A] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > > > You can't possibly do MPLS RSVP/TE from the customer edge all the way > > to the other customer edge, so voice/MPLS is an immediate non-starter. > SS7 :-) doesnt come tell your telephone.... From owner-mpls@UU.NET Thu Feb 20 13:10:24 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23715 for ; Thu, 20 Feb 2003 13:10:24 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwu10199 for ; Thu, 20 Feb 2003 18:14:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwu09937; Thu, 20 Feb 2003 18:14:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwu24202 for mpls-outgoing; Thu, 20 Feb 2003 18:13:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwu24195 for ; Thu, 20 Feb 2003 18:13:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwu02287 for ; Thu, 20 Feb 2003 18:13:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwu09184 for ; Thu, 20 Feb 2003 18:13:13 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQocwu09162 for ; Thu, 20 Feb 2003 18:13:12 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1KID2S34535; Thu, 20 Feb 2003 10:13:02 -0800 (PST) (envelope-from ina@juniper.net) Date: Thu, 20 Feb 2003 10:13:02 -0800 (PST) From: Ina Minei To: Curtis Villamizar cc: "Nguyen, An" , "'Jim Boyle '" , "'Matthew Meyer '" , "'mpls@UU.NET '" Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-Reply-To: <200302201613.LAA86922@workhorse.fictitious.org> Message-ID: <20030220101031.J43335@garnet.juniper.net> References: <200302201613.LAA86922@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > > As a practical matter, I don't think there would be other traffic that > would be preempting "authorized emergency preparedness" traffic for > Federal, state, and local. Agreed. However, think of the scenario where you want to move away traffic from particular links for a maintenance window. In that case, even this high priority LSP would have to be preempted. Ina > > The soft preemption helps the traffic which is being preempted. > > AFAIK "authorized emergency preparedness" traffic is not being > selectively signaled and queued at all in ISP networks. > > Curtis > From owner-mpls@UU.NET Thu Feb 20 13:13:22 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23826 for ; Thu, 20 Feb 2003 13:13:22 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwv27231 for ; Thu, 20 Feb 2003 18:17:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwv26651; Thu, 20 Feb 2003 18:16:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwv24729 for mpls-outgoing; Thu, 20 Feb 2003 18:16:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwv24713 for ; Thu, 20 Feb 2003 18:16:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwu05562 for ; Thu, 20 Feb 2003 18:14:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwu10078 for ; Thu, 20 Feb 2003 18:14:09 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocwu10042 for ; Thu, 20 Feb 2003 18:14:08 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KIE5Nh028839 for ; Thu, 20 Feb 2003 13:14:05 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA09761 for ; Thu, 20 Feb 2003 13:14:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KIE4803284 for mpls@uu.net; Thu, 20 Feb 2003 13:14:04 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocwu24146 for ; Thu, 20 Feb 2003 18:12:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocwu28760 for ; Thu, 20 Feb 2003 18:12:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwu19764 for ; Thu, 20 Feb 2003 18:12:14 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocwu19188 for ; Thu, 20 Feb 2003 18:11:59 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA88539; Thu, 20 Feb 2003 13:12:18 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302201812.NAA88539@workhorse.fictitious.org> To: David Charlap cc: IETF MPLS List Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS In-reply-to: Your message of "Thu, 20 Feb 2003 12:26:10 EST." <3E550FB2.3060900@marconi.com> Date: Thu, 20 Feb 2003 13:12:18 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E550FB2.3060900@marconi.com>, David Charlap writes: > Curtis Villamizar wrote: > > > > You can't possibly do MPLS RSVP/TE from the customer edge all the way > > to the other customer edge, so voice/MPLS is an immediate non-starter. > > If used in the context of voice-through-internet, then yes. You are completely igoring the context of this statement which was if you try to solve the problem CE to CE then voice/MPLS is a non-starter. So I guesss we agree. > But it may still be useful within a voice carrier. Think of how voice > carriers currently run their voice circuits over ATM. You don't have an > ATM circuit going all the way to your home. If carriers want to > eventually merge their voice and data infrastructures, then voice-over- > MPLS sounds like something they may want. So we're back to ATM again (why doesn't that surprise me), and specifically ATM used in the metros. :-) f so, the CE-PE-...-PE-CE described in the draft just applies within a metro and so CE-PE-...-PE-CE is really incorrect. It might just be that the applicability is seriously overstated in the draft. > But I don't think there's any need for the IETF to get involved in such > development, since the only IP-related component would be managing the > LSP itself, and existing protocols are adequate for that task. > > -- David What we are gradually establishing is that the practical scope of this work is much more limited than the internet-draft would imply. Given the state scope of the internet-draft, the technique it is presenting is inpractical at best if not infeasible. It would seem from this thread that for certain problems, like CE-PE link, and PE to PE across an entire SP (rather than just within a metro), there are better solutions. If this is a technology that for practical reasons is applicable only for the metro but would in fact be useful for the metro, just have the internet-draft say that and move on either accepting it acknowledging its limited applicability or not accepting it. Curtis From owner-mpls@UU.NET Thu Feb 20 13:19:24 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24005 for ; Thu, 20 Feb 2003 13:19:24 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwv26530 for ; Thu, 20 Feb 2003 18:23:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwv25748; Thu, 20 Feb 2003 18:22:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwv25351 for mpls-outgoing; Thu, 20 Feb 2003 18:22:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwv25342 for ; Thu, 20 Feb 2003 18:22:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQocwv29498 for ; Thu, 20 Feb 2003 18:21:09 GMT Received: from sa.infonet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sa.infonet.com [192.157.130.21]) id QQocwg28165 for ; Thu, 20 Feb 2003 14:40:19 GMT Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id h1KEdPfs002668; Thu, 20 Feb 2003 14:39:25 GMT Received: from zhangr2.info.net (lasi254.us.info.net [204.140.71.254]) by delta.info.net with ESMTP id OAA10946; Thu, 20 Feb 2003 14:39:23 GMT Message-Id: <5.1.0.14.0.20030220051410.07cccaf8@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Feb 2003 05:32:11 -0800 To: "Uzelac, Adam" , "'GOODE, B (Bur), ALABS'" , curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" From: raymond zhang Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression Cc: "MPLS@UU.net" , George Swallow , Loa Andersson In-Reply-To: <81BF85F8C018D511B44A00508BB8B4790500A9CD@exnarocmbx1.ams.g blxint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Uzelac, At 01:39 PM 2/19/2003 -0500, Uzelac, Adam wrote: > > 30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes 62% overhead > > 30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes 21% overhead > > 200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes 19% overhead > > 300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes 14% overhead > >I am afraid there is some confusion on this one. The 200-300 bytes probably >included the RTP/UDP/IP headers as well. > >Bandwidth Calculations G.711 >Packetization Delay (in ms) 20 >Payload Speed (in bits per second) 64,000 >Payload (in bytes) 160 >RTP (in bytes) 12 >UDP (in bytes) 8 >IP (in bytes) 20 >Total Packet Size (in bytes) 200 > >BUT the issue still stands - Using the G.723.1 coder (which produces 24 byte >frames >every 30 milliseconds), each packet would have only 24 bytes of data to 40 >bytes of header. >Thus, the header would be 67% of the entire packet. The bigger the payload, >the better, with the understood impact should packet loss occur. Reduce the >ratio by increasing the payload and don't drop any packets on the floor! Surely if you could maintain 0% or near 0% packet loss ratio over all voice paths (e2e) during busy hour, tho upper bound delay limit becomes increasingly difficult to meet esp for inter-continental calls (worsened by longer propagation delay) in which paths include the low speed CE-PE links... Regards, Raymond >-Adam Uzelac > >-----Original Message----- >From: GOODE, B (Bur), ALABS [mailto:bgoode@att.com] >Sent: Wednesday, February 19, 2003 1:08 PM >To: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS >Cc: raymond zhang; MPLS@UU.net; George Swallow; Loa Andersson >Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression > > >We (AT&T) and Raymond (Infonet) clearly stated that we were talking >about G.729 at 8 Kb/s. Curtis responds with an example of G.711 using >64 Kb/s. We cannot afford more than 30 ms packetization delay in our >delay budget. 20ms would be preferable References to 200-300 byte >packets is just absurd. > >Bur > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Wednesday, February 19, 2003 11:25 AM > > To: Ash, Gerald R (Jerry), ALABS > > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; George Swallow; > > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > > Dave Cooper > > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > > > > > In message > > <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com> > > , "Ash, Gerald R (Jerry), ALABS" writes: > > > Curtis, > > > > > > >I think the SPs should speak as to whether the bandwidth > > inefficiency > > > >of 30 byte payloads or the potential to lose a packet with > > a 200 byte > > > >is a greater problem. > > > > > > Both are important issues, but if you read the first few > > sentences of http:// > > > > > ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00. > > txt you'll see > > > that bandwidth efficiency plays a major role in the > > motivation for the propos > > > ed capability. Further, the packet sizes quoted in the I-D > > are typical for V > > > oIP in SP networks, as Raymond noted. Also, VoIP header > > compression (cRTP, f > > > or example) is in use in SP networks on a link by link > > basis to address the b > > > andwidth efficiency issue. > > > > > > 30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes 62% overhead > > 30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes 21% overhead > > 200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes 19% overhead > > 300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes 14% overhead > > > > No header compression and larger frames seems to be the winner as far > > as efficiency goes even if you could compress the header to 8 bytes. > > > > > The proposal in the I-Ds is to extend VoIP header > > compression on an end-to-en > > > d basis, in an MPLS context. > > > > > > Your suggestions for muxing voice calls into larger packets > > connote a PSTN/TD > > > M-like model. Some people actually think that the TDM > > model is pretty effici > > > ent for voice, however, VoIP is another matter, and has > > issues for larger pac > > > kets, e.g., increased e2e delay, etc. > > > > You don't mux calls, you collect the frames of a single call and > > introduce some assembly delay. > > > > Audio compression techniques typcially do a good job of silence > > suppression and vary in the amount of data they send. Even the best > > (that produce reasonable quality audio) consume up to 64 kbit/sec when > > someone is actively talking and near nothing on silence. What would > > you consider the average transmission rate for compressed audio? > > Somewhere around 16-32 kbit/sec? > > > > To assemble a 300 byte packet at 64 kbit/sec you need under 40 msec, > > 200 msec gets you 25 msec. If you set a queueing delay point (as > > recommended all over the place for RTP) of 50 msec, you'll get packets > > over 300 bytes, and probably an average of well over 200 bytes. > > > > > Jerry > > > > Please correct me if I'm wrong but your drafts seem to require end2end > > MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since > > you are providing new RSVP/TE objects the assumption seems to be > > RSVP/TE MPLS edge to edge. If traffic engineering is done within > > regions as can be done with current RTP/UDP/IP/MPLS regardless of > > whether LDP is also used, that works fine and scales extremely well. > > E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to > > scale well in a single provider and is almost certain to become a > > severe problem crossing SP boundaries. > > > > Curtis > > From owner-mpls@UU.NET Thu Feb 20 14:35:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26787 for ; Thu, 20 Feb 2003 14:35:17 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxa21857 for ; Thu, 20 Feb 2003 19:39:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocxa21206; Thu, 20 Feb 2003 19:38:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQocxa19757 for mpls-outgoing; Thu, 20 Feb 2003 19:38:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocxa19748 for ; Thu, 20 Feb 2003 19:38:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocxa02646 for ; Thu, 20 Feb 2003 19:38:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxa07954 for ; Thu, 20 Feb 2003 19:38:05 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocxa07925 for ; Thu, 20 Feb 2003 19:38:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KJc2Nh004014 for ; Thu, 20 Feb 2003 14:38:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA17395 for ; Thu, 20 Feb 2003 14:38:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KJc1b11450 for mpls@uu.net; Thu, 20 Feb 2003 14:38:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocxa19709 for ; Thu, 20 Feb 2003 19:36:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocxa23343 for ; Thu, 20 Feb 2003 19:34:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxa17344 for ; Thu, 20 Feb 2003 19:34:59 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocxa17312 for ; Thu, 20 Feb 2003 19:34:57 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA88963; Thu, 20 Feb 2003 14:35:14 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302201935.OAA88963@workhorse.fictitious.org> To: raymond zhang cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Thu, 20 Feb 2003 09:44:20 PST." <5.1.0.14.0.20030220084042.02556418@delta.info.net> Date: Thu, 20 Feb 2003 14:35:14 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.1.0.14.0.20030220084042.02556418@delta.info.net>, raymond zhang w rites: > Curtis, > > Thanks for the response and see some further comments in line... Based > upon discussions we have thus far including your response to my comments in > response to Uzelac's email, maybe I should make some clarifications first > which may help my understanding of your input as well in any further > discussions: > > The environment in which I am referring to is a global IP/MPLS packet-based > network spanning all major and sub-continents where it is not always > possible to get ample bandwidth (over-provisioning) economically (very > expensive in fact)... The issues of delay or packet loss do not normally > present problems at all as you pointed out, in some continental or national > networks of ISPs or SPs but to offer similar level of integrated services > (voice/data) for customers with world-wide locations, it is in these remote > regions and over last mile local loops that we spend a bit more efforts on > to optimize. > > On low speed local-loops (PE-CE links), IP/UDP/RTP compressions is > needed. I think we both agree on that. As for PE doing the comp/depcomp, > I'd like to hear a bit more from the Vendors... My experience has been > that hardware based compression at PE levels on the edge of the network > with large # of aggregating diffserve-enabled customer links presents > complexity that may become unmanageable to SPs and with amount of edge > features already processed through hardware, would adding > compression/decompression be even feasible ? Besides, the upgrade > path may be very costly for these line cards which maybe deployed in large > numbers across the global network as we add new feature sets/hardware > capabilities. So I am not in favor of it as an option for PE level > routers. Therefore the concept of distributing compression/decompression > into CE levels, not in the network appeals in a great deal. If PE is not > doing the comp/decomp, then the compressed path needs to be e2e... > > Further comments in lines .... > > Regards, > Raymond The applicability statement part of this is embedded in the draft itself, rather than following a requirement document. You are citing PE-CE as the primary problem. Others have cited PE to PE within the metro. If the problem is PE-CE, lets stick with that problem. If PE-CE is the problem you are trying to solve, then RTP/UDP/IP/PPP compression should do wonders. I agree with you entirely that the current practical problem there is that the PE can't handle the comp/depcomp at anywhere close to line rate on even relatively slow interfaces. The PPS rate for these tinygrams is enormous. (Of course making them bigger would help reduce the PPS rate in addition to improving the encaps efficiency). At one packet per 30 msec, you have 30 pps. At 8kbit/s a T1 holds not quite 200 of these if the PPP encaps was 4 bytes or less. Times 200 calls you have 6000 pps. Nothing at all for a line card, but not many of these will start to swamp a route processor if that is how the comp/decomp is implemented. Putting the compression in the CE might on the onset sound appealing. If you think you have problems with the PE handling the comp/decomp, wait til you try to bring up a full mesh of LSPs to all the CE for this sort of scale of global networks. No sense trading one practical limitation for another of much more enormous magnitude. If there is a huge number of CE then at some point you'll have to partition the network to make this continue to work. If so you might get CE to some voice/VOIP aggregation box/gateway and have these terminate the LSPs and do comp/decomp, then communicate among themselves. This is likely to be a huge comp/decomp load. You can concentrate the comp/decomp at some specialized processor or try to do the processing on the line cards (which may mean new line cards). If a CE is supporting on the order of at least 100 (to 200 if encaps efficiency can be improved), then muxing might be easier on the PE router. For example, separating 300 pps of 600 byte packets is likely to be a lot easier (even if 6000 pps are sent out) than compressing and decompressing 6000pps and would add zero delay. Either way, moving processing to the PE line card seems essential. I'm just trying to come up with something that will actually work. Regards, Curtis ps - wrt queueing and serialization delay. 30bytes into a T1 incurs a serialization delay of 240bits/1.5mbits or 0.16 msec. 200 bytes is 1 msec serialization. If CE means customer handset then we're e2e MPLS becomes completely absurd so I think it should be safe so assume at least T1 and it not you get delay. With serialization times on the order of 1 msec edge and these days under a microsecond in cores, the queueing argument has never held water for priority queued traffic that is not congested. That's a moot point for a single flow if you have to hold the playout time for 200 msec to get 200 bytes packets because that is already an excessive delay. For multiplexing, the argument against large packets based on serialization and queueing simply doesn't hold up. We're not talking IP over barbed wire in the third world, right? Its at least T1? > >Tiny payload is needed for queue efficiency is a myth left over from > >the ATM days. It is simply not true. > > I think there are two aspects in this... Firstly traffic flows with > constant packet size would improve queue efficiency (M/D/1) and smaller > packet payload would reduce delay across low speed links (not an issue once > again in areas of network with large pipes since no or little qeueuing) > which is required as part of the budge delay planning. The voice quality > is provided on a per path basis not just over segments of the path inside > SP's major portion of the backbone. ( I don't mean to spur another around > of discussions on ATM vs. IP at all ! I thought issues are well understood > by now). From owner-mpls@UU.NET Thu Feb 20 14:46:15 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27187 for ; Thu, 20 Feb 2003 14:46:15 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxb26869 for ; Thu, 20 Feb 2003 19:50:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocxb26372; Thu, 20 Feb 2003 19:49:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQocxb20979 for mpls-outgoing; Thu, 20 Feb 2003 19:49:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocxb20966 for ; Thu, 20 Feb 2003 19:49:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocxb15541 for ; Thu, 20 Feb 2003 19:49:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxb25569 for ; Thu, 20 Feb 2003 19:49:06 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocxb25554 for ; Thu, 20 Feb 2003 19:49:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KJn3Nh004682 for ; Thu, 20 Feb 2003 14:49:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18442 for ; Thu, 20 Feb 2003 14:49:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KJn2913475 for mpls@uu.net; Thu, 20 Feb 2003 14:49:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocxb20883 for ; Thu, 20 Feb 2003 19:46:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocxb29134 for ; Thu, 20 Feb 2003 19:46:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxb22089 for ; Thu, 20 Feb 2003 19:46:30 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQocxb22073 for ; Thu, 20 Feb 2003 19:46:29 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA89030; Thu, 20 Feb 2003 14:46:32 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302201946.OAA89030@workhorse.fictitious.org> To: Ina Minei cc: Curtis Villamizar , "Nguyen, An" , "'Jim Boyle '" , "'Matthew Meyer '" , "'mpls@UU.NET '" Reply-To: curtis@fictitious.org Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-reply-to: Your message of "Thu, 20 Feb 2003 10:13:02 PST." <20030220101031.J43335@garnet.juniper.net> Date: Thu, 20 Feb 2003 14:46:31 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20030220101031.J43335@garnet.juniper.net>, Ina Minei writes: > > > > > As a practical matter, I don't think there would be other traffic that > > would be preempting "authorized emergency preparedness" traffic for > > Federal, state, and local. > > Agreed. However, think of the scenario where you want to move away > traffic from particular links for a maintenance window. In that case, even > this high priority LSP would have to be preempted. > > Ina That's make-before-break rerouting. If you do it right, increase metric, reset LSPs if reroute timers are long or set an admin-color and set exclude-admin-color on the LSPs (just leave them set that way). You can name the admin-color "maintenance". No preemption occurs. The LSPs just voluntarily move off the link, then you shut the idle link down. Requires that your routers do make-before-break correctly and that your operational staff is sufficiently clued in. Curtis From owner-mpls@UU.NET Thu Feb 20 14:56:31 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27479 for ; Thu, 20 Feb 2003 14:56:30 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxc09371 for ; Thu, 20 Feb 2003 20:00:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocxc08874; Thu, 20 Feb 2003 20:00:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQocxb21894 for mpls-outgoing; Thu, 20 Feb 2003 19:59:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocxb21884 for ; Thu, 20 Feb 2003 19:59:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQocxb07100 for ; Thu, 20 Feb 2003 19:58:56 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxb19368 for ; Thu, 20 Feb 2003 19:58:55 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.38.212.174]) id QQocxb19353 for ; Thu, 20 Feb 2003 19:58:55 GMT Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id h1KJwrd04311 for ; Thu, 20 Feb 2003 14:58:53 -0500 (EST) Message-Id: <200302201958.h1KJwrd04311@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: mpls@UU.NET Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-reply-to: Your message of "Wed, 19 Feb 2003 20:10:18 MST." <20030220031018.GF11833@gblx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Feb 2003 14:57:44 -0500 Sender: owner-mpls@UU.NET Precedence: bulk > |In message , Jim Boyle > |writes: > |> > |> First, great draft - I like this concept. > |> > |> While a flag might be just the right thing for this particular > |> application, I wonder if it might be good to try to broaden > |> soft preemption technique to include other polite preemptions. > |> > |> These might include the following indicators > |> > |> o) your LSP is being prempted on the indicated link (draft covers) > |> o) your LSP should be rerouted, this node is shutting down > |> o) your LSP should be rerouted, this link is being taken out of > |> service > |> o) your LSP should be rerouted away from this node (administrative/CLI) > |> o) your LSP should be rerouted away from this link (administrative/CLI) > |> > |> You can somewhat do some of these by changing metrics and waiting, but > |> just was wondering if something more general might be useful. > | > |Why couldn't you just use the same bit and allow soft preemption on > |link shut, reload, > > Or OL bit set... > > |CLI administrative without encoding the reason? > |Since these are all CLI initiated, it wouldn't hurt to delay. > |Alternately, the soft preempt on anything using a specific resource > |could be done. > |Link bundle lost a member might also qualify as a reason for soft > |preemption for implementations of link bundling that can transparently > |more flows to other members of the bundle. > > I think there is value in conveying to the head-end the population > category of the soft preemption (Single LSP|Link|Bundle Member|SRLG| > Node). Doing so provides prompt, more accurate info for the head-end > to use when trying to quickly find the new valid path for the first > of (say) 30 arriving soft preemptions. > > .---,A .---,B > | |---1--| |----- > | |---2--| |----- > `---' `---' > HE Maint > > fe. Imagine we cause all LSPs transiting a node B to be soft preempted > in prep for maintenance. HE A's LSPs all transited a certain circuit (1) > to the maintenance node B, however there is a parallel circuit as well(2). > Without the "node" flag, we might amend the HE TE-DB zeroing (1)s > reservable BW (the circuit for which we were just soft preempted) > when we should have zeroed out (2) as well. The result could be our > soft preemption make before break sets up (or tries to) through the > maintenance node despite being recently soft preempted off it.. > > Technically a HE need only receive the first LSP population oriented > flag (Node|SRLG|etc) soft preemption to discover 1) what subset of > locally originating LSPs need to be rerouted and 2) what links/nodes/ > members need to be avoided. There is still a need for one-at-a-time > straight soft preemption of course. > I like the original soft preemption idea in the draft as it stands now. But I have my doubts about the extensions discussed in this e-mail thread. When planning an admin link or node shutdown, it is probably a better idea to indicate that via the IGP (through a metric change or announcing the available bandwidth as 0). If you do it via RSVP signaling as discussed here, the HE routers getting the notification now have two pieces of information: the TE-DB tells them the link/node is still available and a good choice for a path while RSVP tells them don't go there. So now they've got to trust what RSVP tells them (for how long???) and reroute. Other nodes in the network that didn't route any lsp through the node that goes down now see that there's plenty of bandwidth through it. They weren't notified by RSVP it's going down. So they might "optimize" their lsp's and use that node now. This seems like a somewhat messy situation. To avoid problems you would have to give indication of link/node shutdown via RSVP and the IGP at approximately the same time. But why do that when you can get the job done via IGP alone and without extra protocol extensions? In the "higher priority lsp preempts lower priority lsp" scenario of the draft, soft preemption via RSVP works better because you will get link bandwidth usage updates via the IGP relatively quickly at the same time. Markus From owner-mpls@UU.NET Thu Feb 20 20:11:15 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05533 for ; Thu, 20 Feb 2003 20:11:15 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxx04485 for ; Fri, 21 Feb 2003 01:15:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocxw04116; Fri, 21 Feb 2003 01:14:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQocxw06467 for mpls-outgoing; Fri, 21 Feb 2003 01:14:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQocxw06462 for ; Fri, 21 Feb 2003 01:14:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocxw02544 for ; Fri, 21 Feb 2003 01:14:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxw05395 for ; Fri, 21 Feb 2003 01:14:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQocxw05384 for ; Fri, 21 Feb 2003 01:14:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1L1E2JR029646 for ; Thu, 20 Feb 2003 20:14:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA12119 for ; Thu, 20 Feb 2003 20:14:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1L1E2802675 for mpls@uu.net; Thu, 20 Feb 2003 20:14:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocxw06434 for ; Fri, 21 Feb 2003 01:13:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocxw21878 for ; Fri, 21 Feb 2003 01:13:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocxw04809 for ; Fri, 21 Feb 2003 01:13:23 GMT Received: from fido.nc.rr.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu57-28-045.nc.rr.com [66.57.28.45]) id QQocxw04804 for ; Fri, 21 Feb 2003 01:13:23 GMT Received: from fido.nc.rr.com (fido.nc.rr.com [127.0.0.1]) by fido.nc.rr.com (8.12.5/8.12.5) with ESMTP id h1L1DDjB031412; Thu, 20 Feb 2003 20:13:14 -0500 Received: from localhost (jboyle@localhost) by fido.nc.rr.com (8.12.5/8.12.5/Submit) with ESMTP id h1L1D6lS031408; Thu, 20 Feb 2003 20:13:07 -0500 X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs Date: Thu, 20 Feb 2003 20:13:06 -0500 (EST) From: Jim Boyle X-X-Sender: jboyle@fido.nc.rr.com To: Markus Jork cc: mpls@UU.NET Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-Reply-To: <200302201958.h1KJwrd04311@mailhost.avici.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Yeah, maybe lean and clean is better here. On Thu, 20 Feb 2003, Markus Jork wrote: > > |In message , Jim Boyle > > |writes: > > |> > > |> First, great draft - I like this concept. > > |> > > |> While a flag might be just the right thing for this particular > > |> application, I wonder if it might be good to try to broaden > > |> soft preemption technique to include other polite preemptions. > > |> > > |> These might include the following indicators > > |> > > |> o) your LSP is being prempted on the indicated link (draft covers) > > |> o) your LSP should be rerouted, this node is shutting down > > |> o) your LSP should be rerouted, this link is being taken out of > > |> service > > |> o) your LSP should be rerouted away from this node (administrative/CLI) > > |> o) your LSP should be rerouted away from this link (administrative/CLI) > > |> > > |> You can somewhat do some of these by changing metrics and waiting, but > > |> just was wondering if something more general might be useful. > > | > > |Why couldn't you just use the same bit and allow soft preemption on > > |link shut, reload, > > > > Or OL bit set... > > > > |CLI administrative without encoding the reason? > > |Since these are all CLI initiated, it wouldn't hurt to delay. > > |Alternately, the soft preempt on anything using a specific resource > > |could be done. > > |Link bundle lost a member might also qualify as a reason for soft > > |preemption for implementations of link bundling that can transparently > > |more flows to other members of the bundle. > > > > I think there is value in conveying to the head-end the population > > category of the soft preemption (Single LSP|Link|Bundle Member|SRLG| > > Node). Doing so provides prompt, more accurate info for the head-end > > to use when trying to quickly find the new valid path for the first > > of (say) 30 arriving soft preemptions. > > > > .---,A .---,B > > | |---1--| |----- > > | |---2--| |----- > > `---' `---' > > HE Maint > > > > fe. Imagine we cause all LSPs transiting a node B to be soft preempted > > in prep for maintenance. HE A's LSPs all transited a certain circuit (1) > > to the maintenance node B, however there is a parallel circuit as well(2). > > Without the "node" flag, we might amend the HE TE-DB zeroing (1)s > > reservable BW (the circuit for which we were just soft preempted) > > when we should have zeroed out (2) as well. The result could be our > > soft preemption make before break sets up (or tries to) through the > > maintenance node despite being recently soft preempted off it.. > > > > Technically a HE need only receive the first LSP population oriented > > flag (Node|SRLG|etc) soft preemption to discover 1) what subset of > > locally originating LSPs need to be rerouted and 2) what links/nodes/ > > members need to be avoided. There is still a need for one-at-a-time > > straight soft preemption of course. > > > > I like the original soft preemption idea in the draft as it stands now. > But I have my doubts about the extensions discussed in this e-mail thread. > When planning an admin link or node shutdown, it is probably a better > idea to indicate that via the IGP (through a metric change or announcing > the available bandwidth as 0). > If you do it via RSVP signaling as discussed here, the HE routers > getting the notification now have two pieces of information: the TE-DB > tells them the link/node is still available and a good choice for > a path while RSVP tells them don't go there. So now they've got to > trust what RSVP tells them (for how long???) and reroute. > Other nodes in the network that didn't route any lsp through the > node that goes down now see that there's plenty of bandwidth > through it. They weren't notified by RSVP it's going down. So they > might "optimize" their lsp's and use that node now. > This seems like a somewhat messy situation. > > To avoid problems you would have to give indication of link/node > shutdown via RSVP and the IGP at approximately the same time. > But why do that when you can get the job done via IGP alone and > without extra protocol extensions? > > In the "higher priority lsp preempts lower priority lsp" scenario > of the draft, soft preemption via RSVP works better because you > will get link bandwidth usage updates via the IGP relatively quickly > at the same time. > > Markus > > From owner-mpls@UU.NET Thu Feb 20 21:34:37 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06828 for ; Thu, 20 Feb 2003 21:34:36 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQocwh22526; Thu, 20 Feb 2003 14:57:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQocwh23214 for mpls-outgoing; Thu, 20 Feb 2003 14:57:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQocwh23178 for ; Thu, 20 Feb 2003 14:56:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwh23811 for ; Thu, 20 Feb 2003 14:55:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwh18580 for ; Thu, 20 Feb 2003 14:55:31 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQocwh18565 for ; Thu, 20 Feb 2003 14:55:30 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KEtRNh017309 for ; Thu, 20 Feb 2003 09:55:28 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA23053 for ; Thu, 20 Feb 2003 09:55:27 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1KEtRT08313 for mpls@uu.net; Thu, 20 Feb 2003 09:55:27 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoctv17035 for ; Wed, 19 Feb 2003 22:53:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoctv15863 for ; Wed, 19 Feb 2003 22:53:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoctv26541 for ; Wed, 19 Feb 2003 22:53:23 GMT Received: from pintail.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pintail.mail.pas.earthlink.net [207.217.120.122]) id QQoctv26529 for ; Wed, 19 Feb 2003 22:53:23 GMT Received: from dialup-65.59.102.14.dial1.weehawken1.level3.net ([65.59.102.14] helo=jhand) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ld5X-0001tN-00; Wed, 19 Feb 2003 14:53:16 -0800 From: "Jim Hand" To: , "Ash, Gerald R \(Jerry\), ALABS" Cc: "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B \(Bur\), ALABS" , "Dave Cooper" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS Date: Wed, 19 Feb 2003 17:37:20 -0500 Message-ID: <001901c2d869$8863c200$3a785b87@mt.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200302191624.LAA78592@workhorse.fictitious.org> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Also, neither draft requires end-to-end MPLS between VoIP endpoints. One of the drafts (http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt) requires MPLS between the compressor and decompressor. The other (http://ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt )oes not require MPLS all the way between compressor and decompressor. Neither draft requires that the compressor and decompressor also be VoIP endpoints. Thanks, Jim Hand > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, February 19, 2003 11:25 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; George Swallow; > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > Dave Cooper > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > Please correct me if I'm wrong but your drafts seem to require end2end > MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since > you are providing new RSVP/TE objects the assumption seems to be > RSVP/TE MPLS edge to edge. If traffic engineering is done within > regions as can be done with current RTP/UDP/IP/MPLS regardless of > whether LDP is also used, that works fine and scales extremely well. > E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to > scale well in a single provider and is almost certain to become a > severe problem crossing SP boundaries. > > Curtis > From owner-mpls@UU.NET Fri Feb 21 09:30:37 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01384 for ; Fri, 21 Feb 2003 09:30:37 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoczy01643 for ; Fri, 21 Feb 2003 14:34:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoczy01151; Fri, 21 Feb 2003 14:34:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQoczy03966 for mpls-outgoing; Fri, 21 Feb 2003 14:33:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoczy03956 for ; Fri, 21 Feb 2003 14:33:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoczy22336 for ; Fri, 21 Feb 2003 14:33:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoczy00204 for ; Fri, 21 Feb 2003 14:33:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoczy00184 for ; Fri, 21 Feb 2003 14:33:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LEX2JR021647 for ; Fri, 21 Feb 2003 09:33:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18567 for ; Fri, 21 Feb 2003 09:33:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1LEX2H09545 for mpls@uu.net; Fri, 21 Feb 2003 09:33:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoczy03921 for ; Fri, 21 Feb 2003 14:31:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoczy14344 for ; Fri, 21 Feb 2003 14:30:14 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoczy14685 for ; Fri, 21 Feb 2003 14:30:14 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoczy14673 for ; Fri, 21 Feb 2003 14:30:13 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA95009; Fri, 21 Feb 2003 09:30:22 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302211430.JAA95009@workhorse.fictitious.org> To: "Jim Hand" cc: curtis@fictitious.org, "Ash, Gerald R \(Jerry\), ALABS" , "raymond zhang" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B \(Bur\), ALABS" , "Dave Cooper" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS In-reply-to: Your message of "Wed, 19 Feb 2003 17:37:20 EST." <001901c2d869$8863c200$3a785b87@mt.att.com> Date: Fri, 21 Feb 2003 09:30:22 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <001901c2d869$8863c200$3a785b87@mt.att.com>, "Jim Hand" writes: > Also, neither draft requires end-to-end MPLS between VoIP endpoints. One of > the drafts > (http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt) > requires MPLS between the compressor and decompressor. The other > (http://ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt )oes > not require MPLS all the way between compressor and decompressor. Neither > draft requires that the compressor and decompressor also be VoIP endpoints. > > Thanks, > Jim Hand Jim, I suppose you didn't read any of this thread where I said more than once that e2e means compressor to decompressor in this context since it couldn't possibly mean anything else and e2e is shorter to write. It is the only interpretation that makes any sense whatsoever so it is sufficiently unambiguous to carry on an email conversation. draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te mpls for the above definition of e2e which I hope I don't have to repeat with every email message. draft-ash-e2e-crtp-hdr-compress-00 requires either of two conditions. 1) e2e rsvp/te mpls (for the above definition of e2e), 2) every router along the way knows how to do compression and decompression. Case #2 is the one that SP are saying is impractical because the PE CPU is overloaded with too many PPS. Except for this practical matter case #2 is every bit as good a solution for the CE-PE links as rfc2508 over PPP links (with most CE-PE being PPP). Needless to say that makes case #2 completely absurd in the core (comp/decomp on oc192c interfaces). That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which requires e2e rsvp/te mpls plus requires every hop in the path to support comp/decomp making it even worse. Curtis > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > Sent: Wednesday, February 19, 2003 11:25 AM > > To: Ash, Gerald R (Jerry), ALABS > > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; George Swallow; > > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > > Dave Cooper > > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > > Please correct me if I'm wrong but your drafts seem to require end2end > > MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP. Since > > you are providing new RSVP/TE objects the assumption seems to be > > RSVP/TE MPLS edge to edge. If traffic engineering is done within > > regions as can be done with current RTP/UDP/IP/MPLS regardless of > > whether LDP is also used, that works fine and scales extremely well. > > E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to > > scale well in a single provider and is almost certain to become a > > severe problem crossing SP boundaries. > > > > Curtis > > > > From owner-mpls@UU.NET Fri Feb 21 11:58:48 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06854 for ; Fri, 21 Feb 2003 11:58:48 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodai13104 for ; Fri, 21 Feb 2003 17:02:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodai12075; Fri, 21 Feb 2003 17:01:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQodai02384 for mpls-outgoing; Fri, 21 Feb 2003 17:01:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodai02020 for ; Fri, 21 Feb 2003 17:01:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodai07323 for ; Fri, 21 Feb 2003 17:01:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodai11529 for ; Fri, 21 Feb 2003 17:01:06 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodai11511 for ; Fri, 21 Feb 2003 17:01:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1LH13Nh016400 for ; Fri, 21 Feb 2003 12:01:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA01013 for ; Fri, 21 Feb 2003 12:01:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1LH13d18129 for mpls@uu.net; Fri, 21 Feb 2003 12:01:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodah22100 for ; Fri, 21 Feb 2003 16:59:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodah27447 for ; Fri, 21 Feb 2003 16:58:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodah17864 for ; Fri, 21 Feb 2003 16:58:46 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodah17854 for ; Fri, 21 Feb 2003 16:58:45 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA96189; Fri, 21 Feb 2003 11:58:54 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302211658.LAA96189@workhorse.fictitious.org> To: "Jim Hand" cc: curtis@fictitious.org, "'Ash, Gerald R \(Jerry\), ALABS'" , "'raymond zhang'" , "'MPLS@UU.net'" , "'George Swallow'" , "'Loa Andersson'" , "'GOODE, B \(Bur\), ALABS'" , "'Dave Cooper'" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS In-reply-to: Your message of "Fri, 21 Feb 2003 10:56:00 EST." <000601c2d9c1$c03f88e0$3a785b87@mt.att.com> Date: Fri, 21 Feb 2003 11:58:54 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <000601c2d9c1$c03f88e0$3a785b87@mt.att.com>, "Jim Hand" writes: > Maybe we need to re-write draft-ash-e2e-crtp-hdr-compress-00 to clarify > . I > will look into this. > > This draft does require RSVP TE e2e over the MPLS part of the network, > but > it does not require that MPLS or RSVP TE be extended to CE's. And it does > not require that the original compressor and decompressor be attached to > MPLS. > > Also, it does require that routers other than MPLS "P" routers have the > ability to support compression and decompression. But that does not mean > that these routers will have to *perform* compression and decompression on > each compressed packet. Routers that support compressed packets on both > input links and output links should only have to perform a > decompression/compression cycle on a small fraction of the total number of > packets. Most compressed packets would be switched from input to output > without performing decompression and compression. > > Thanks, > Jim Jim, What we are trying to establish is if you are actually solving a practical problem Which has two parts. The first is identifying what problem it is you are trying to solve. The second is determining if what you are suggesting solved the problem. If the discussion so far is valid, the problem is CE-PE and the simple solution of just compressing on the CE and decompressing on the PE has a practical problem of overloading the PE. Having P routers support compression and decompression **is part of the current problem**. If the above paragraph is not valid for some reason, please start by telling us what problem you are trying to solve, then tell us why the techniques in these drafts solve the problem without creating a bigger problem elsewhere. Regards, Curtis From owner-mpls@UU.NET Fri Feb 21 12:45:57 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08603 for ; Fri, 21 Feb 2003 12:45:57 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodal06254 for ; Fri, 21 Feb 2003 17:49:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodal05658; Fri, 21 Feb 2003 17:49:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQodal14532 for mpls-outgoing; Fri, 21 Feb 2003 17:49:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodal14527 for ; Fri, 21 Feb 2003 17:49:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodal13331 for ; Fri, 21 Feb 2003 17:48:38 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodal24364 for ; Fri, 21 Feb 2003 17:48:37 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodal24355 for ; Fri, 21 Feb 2003 17:48:37 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LHmYJR005092 for ; Fri, 21 Feb 2003 12:48:34 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA04899 for ; Fri, 21 Feb 2003 12:48:33 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1LHmXW22172 for mpls@uu.net; Fri, 21 Feb 2003 12:48:33 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQocwi04084 for ; Thu, 20 Feb 2003 15:02:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocwi08995 for ; Thu, 20 Feb 2003 15:01:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocwi01602 for ; Thu, 20 Feb 2003 15:01:57 GMT Received: from scaup.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: scaup.mail.pas.earthlink.net [207.217.120.49]) id QQocwi01582 for ; Thu, 20 Feb 2003 15:01:57 GMT Received: from dialup-64.157.76.123.dial1.weehawken1.level3.net ([64.157.76.123] helo=jhand) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lsCf-0001Km-00; Thu, 20 Feb 2003 07:01:38 -0800 From: "Jim Hand" To: , "'Jim Hand'" Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , "'raymond zhang'" , "'MPLS@UU.net'" , "'George Swallow'" , "'Loa Andersson'" , "'GOODE, B \(Bur\), ALABS'" , "'Dave Cooper'" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS Date: Wed, 19 Feb 2003 23:05:20 -0500 Message-ID: <000001c2d8f0$d5941e80$3a785b87@mt.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200302192328.SAA81728@workhorse.fictitious.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In many VoIP services I am working with, the most important place for bandwidth efficiency is on the access link between the customer premise and the provider edge. There is limited opportunity at the customer premise for connection muxing, because of the limited number of connections. So I think it would be necessary to do compression on the access link in many cases anyway. You could then do connection muxing inside the Service Provider's network. But in order to do the connection muxing, you would likely have to decompress the packets first (perhaps there might be some way around this). This would require a place in the network where you would have to do both compression/decompresion and connection muxing/demuxing. That's a lot of load at some aggregation points in the network. With the end-to-end compression, we were hoping to push the compression load out toward the edges, where there are more boxes to apply to the compression load, and avoid it altogether within the SP transport network. Thanks, Jim > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Wednesday, February 19, 2003 6:29 PM > To: Jim Hand > Cc: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS; > raymond zhang; > MPLS@UU.net; George Swallow; Loa Andersson; GOODE, B (Bur), > ALABS; Dave > Cooper > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - > End-to-End MPLS > > > > In message <001901c2d869$8863c200$3a785b87@mt.att.com>, "Jim > Hand" writes: > > Also, neither draft requires end-to-end MPLS between VoIP > endpoints. One of > > the drafts > > > (http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-comp > ress-00.txt) > > requires MPLS between the compressor and decompressor. The other > > > (http://ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compre > ss-00.txt )oes > > not require MPLS all the way between compressor and > decompressor. Neither > > draft requires that the compressor and decompressor also be > VoIP endpoints. > > > > Thanks, > > Jim Hand > > > By end to end I meant compression device to compression device. I did > say gateway to gateway which might imply VOIP device. > > The argument I was making was that if the compression device is very > far toward the edge of the network, then the number of LSPs explodes. > If the compression device is moved closer to the core of the network > such that a full mesh of RSVP/TE LSPs are feasible, then opportunity > for multiplexing is enormous. > > If you are going to burden the CPU at the "compression device" why not > have it multiplex rather than header compress and get huge improvement > in encapulation efficiency rather than relatively small improvement in > encapsulation efficiency. This also makes it feasible to more the > compression closer to the edge and maybe into the VOIP gear rather > than a router concentrating VOIP gear traffic. > > Thanks again, > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Wednesday, February 19, 2003 11:25 AM > > > To: Ash, Gerald R (Jerry), ALABS > > > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; > George Swallow; > > > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > > > Dave Cooper > > > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > > > > > Please correct me if I'm wrong but your drafts seem to > require end2end > > > MPLS where RTP/UDP/IP/MPLS normally requires just end2end > IP. Since > > > you are providing new RSVP/TE objects the assumption seems to be > > > RSVP/TE MPLS edge to edge. If traffic engineering is done within > > > regions as can be done with current RTP/UDP/IP/MPLS regardless of > > > whether LDP is also used, that works fine and scales > extremely well. > > > E2E RSVP/TE MPLS all the way to each peice of VOIP gear > is unlikely to > > > scale well in a single provider and is almost certain to become a > > > severe problem crossing SP boundaries. > > > > > > Curtis From owner-mpls@UU.NET Fri Feb 21 12:47:17 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08728 for ; Fri, 21 Feb 2003 12:47:17 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodal27334 for ; Fri, 21 Feb 2003 17:51:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodal25917; Fri, 21 Feb 2003 17:50:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQodal14553 for mpls-outgoing; Fri, 21 Feb 2003 17:49:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodal14540 for ; Fri, 21 Feb 2003 17:49:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodal02061 for ; Fri, 21 Feb 2003 17:49:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodal24638 for ; Fri, 21 Feb 2003 17:49:01 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodal24602 for ; Fri, 21 Feb 2003 17:49:01 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LHmwJR005118 for ; Fri, 21 Feb 2003 12:48:58 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA04944 for ; Fri, 21 Feb 2003 12:48:57 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1LHmvA22176 for mpls@uu.net; Fri, 21 Feb 2003 12:48:57 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQocye22072 for ; Fri, 21 Feb 2003 03:09:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQocye29535 for ; Fri, 21 Feb 2003 03:09:00 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQocye19442 for ; Fri, 21 Feb 2003 03:08:59 GMT Received: from smtp1.phx.gblx.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQocye19420 for ; Fri, 21 Feb 2003 03:08:59 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1L38w024455; Thu, 20 Feb 2003 20:08:58 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAAKcaaVV; Thu Feb 20 20:08:57 2003 Received: (from mmeyer@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) id UAA19934; Thu, 20 Feb 2003 20:08:57 -0700 (MST) Date: Thu, 20 Feb 2003 20:08:57 -0700 From: Matthew Meyer To: Markus Jork Cc: mpls@UU.NET Subject: Re: draft-meyer-mpls-soft-preemption-00.txt Message-ID: <20030221030857.GJ18082@gblx.net> References: <20030220031018.GF11833@gblx.net> <200302201958.h1KJwrd04311@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302201958.h1KJwrd04311@mailhost.avici.com> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Comments in line. Thus spake Markus Jork (mjork@avici.com): |I like the original soft preemption idea in the draft as it stands now. I think there have been some strong arguments to leave it as is. |But I have my doubts about the extensions discussed in this e-mail thread. |When planning an admin link or node shutdown, it is probably a better |idea to indicate that via the IGP (through a metric change or announcing |the available bandwidth as 0). While I agree with you that it is perhaps more appropriately accomplished in the IGP, I don't believe the IGP has all the needed mechanisms. Cranking the metric & setting/flooding available reserveable BW at 0 is not enough. Even if you soft preempt as well, you still have 0BW LSPs or explicitly routed LSPs or disparate backups that need to be forced to forget this link. Currently SPs are forced to remove configuration parameters if we want to drive some types of tunnels off a link. At minimum what is missing is a (for lack of a better term) link 'OL bit', and some handy almost crontab-able maintenance commands from the vendors. I wonder if there are any providers on this list that agree. |If you do it via RSVP signaling as discussed here, the HE routers |getting the notification now have two pieces of information: the TE-DB |tells them the link/node is still available and a good choice for |a path while RSVP tells them don't go there. So now they've got to |trust what RSVP tells them (for how long???) and reroute. |Other nodes in the network that didn't route any lsp through the |node that goes down now see that there's plenty of bandwidth |through it. They weren't notified by RSVP it's going down. So they |might "optimize" their lsp's and use that node now. |This seems like a somewhat messy situation. I imagine it could be maneuvered cleanly if the head ends set a timer. The next IGP update (which would have been delayed since it as cli triggered) would overwrite the local tweaked working copy. Really, I am kind of on the fence on these extra flags and where they might belong. I think the discussion is beneficial though. |To avoid problems you would have to give indication of link/node |shutdown via RSVP and the IGP at approximately the same time. I don't agree, see above timer comment. |But why do that when you can get the job done via IGP alone and |without extra protocol extensions? I think the IGP can only do half the job right now, still, maybe fixing the IGP would be a better approach even if the IP native crowd ends up with a redundant feature from their perspective. (They can set metric high for a nearly instant impact on all traffic flows). |In the "higher priority lsp preempts lower priority lsp" scenario |of the draft, soft preemption via RSVP works better because you |will get link bandwidth usage updates via the IGP relatively quickly |at the same time. Even if you don't get your IGP update quickly, you can make assumptions about the preempting link about how much capacity for that preempted priority is left and fudge your working copy until your next TE TLV arrives to overwrite it with a more accurate accounting. Thank you for your comments. Matthew From owner-mpls@UU.NET Fri Feb 21 12:48:40 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08871 for ; Fri, 21 Feb 2003 12:48:40 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodal00230 for ; Fri, 21 Feb 2003 17:52:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodal29063; Fri, 21 Feb 2003 17:52:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQodal14612 for mpls-outgoing; Fri, 21 Feb 2003 17:51:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodal14574 for ; Fri, 21 Feb 2003 17:50:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodal00402 for ; Fri, 21 Feb 2003 17:50:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodal25889 for ; Fri, 21 Feb 2003 17:50:18 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodal25875 for ; Fri, 21 Feb 2003 17:50:17 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LHoEJR005208 for ; Fri, 21 Feb 2003 12:50:15 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA05066 for ; Fri, 21 Feb 2003 12:50:14 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1LHoEM22269 for mpls@uu.net; Fri, 21 Feb 2003 12:50:14 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodad28952 for ; Fri, 21 Feb 2003 15:57:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodad14031 for ; Fri, 21 Feb 2003 15:57:22 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodad21960 for ; Fri, 21 Feb 2003 15:57:21 GMT Received: from conure.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: conure.mail.pas.earthlink.net [207.217.120.54]) id QQodad21950 for ; Fri, 21 Feb 2003 15:57:21 GMT Received: from dialup-63.208.112.194.dial1.weehawken1.level3.net ([63.208.112.194] helo=jhand) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mFY1-0005ve-00; Fri, 21 Feb 2003 07:57:13 -0800 From: "Jim Hand" To: , "'Jim Hand'" Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , "'raymond zhang'" , "'MPLS@UU.net'" , "'George Swallow'" , "'Loa Andersson'" , "'GOODE, B \(Bur\), ALABS'" , "'Dave Cooper'" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS Date: Fri, 21 Feb 2003 10:56:00 -0500 Message-ID: <000601c2d9c1$c03f88e0$3a785b87@mt.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200302211430.JAA95009@workhorse.fictitious.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Maybe we need to re-write draft-ash-e2e-crtp-hdr-compress-00 to clarify. I will look into this. This draft does require RSVP TE e2e over the MPLS part of the network, but it does not require that MPLS or RSVP TE be extended to CE's. And it does not require that the original compressor and decompressor be attached to MPLS. Also, it does require that routers other than MPLS "P" routers have the ability to support compression and decompression. But that does not mean that these routers will have to *perform* compression and decompression on each compressed packet. Routers that support compressed packets on both input links and output links should only have to perform a decompression/compression cycle on a small fraction of the total number of packets. Most compressed packets would be switched from input to output without performing decompression and compression. Thanks, Jim > draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te mpls for the > above definition of e2e which I hope I don't have to repeat with every > email message. > > draft-ash-e2e-crtp-hdr-compress-00 requires either of two conditions. > 1) e2e rsvp/te mpls (for the above definition of e2e), 2) every router > along the way knows how to do compression and decompression. > > Case #2 is the one that SP are saying is impractical because the PE > CPU is overloaded with too many PPS. Except for this practical matter > case #2 is every bit as good a solution for the CE-PE links as rfc2508 > over PPP links (with most CE-PE being PPP). Needless to say that > makes case #2 completely absurd in the core (comp/decomp on oc192c > interfaces). > > That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e > rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which > requires e2e rsvp/te mpls plus requires every hop in the path to > support comp/decomp making it even worse. > > Curtis > > > > > -----Original Message----- > > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > Sent: Wednesday, February 19, 2003 11:25 AM > > > To: Ash, Gerald R (Jerry), ALABS > > > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; > George Swallow; > > > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > > > Dave Cooper > > > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > > > > > > > > Please correct me if I'm wrong but your drafts seem to > require end2end > > > MPLS where RTP/UDP/IP/MPLS normally requires just end2end > IP. Since > > > you are providing new RSVP/TE objects the assumption seems to be > > > RSVP/TE MPLS edge to edge. If traffic engineering is done within > > > regions as can be done with current RTP/UDP/IP/MPLS regardless of > > > whether LDP is also used, that works fine and scales > extremely well. > > > E2E RSVP/TE MPLS all the way to each peice of VOIP gear > is unlikely to > > > scale well in a single provider and is almost certain to become a > > > severe problem crossing SP boundaries. > > > > > > Curtis > > > > > > > From owner-mpls@UU.NET Fri Feb 21 13:27:46 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10015 for ; Fri, 21 Feb 2003 13:27:46 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodao09960 for ; Fri, 21 Feb 2003 18:31:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodao09072; Fri, 21 Feb 2003 18:31:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQodao06535 for mpls-outgoing; Fri, 21 Feb 2003 18:30:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodao06530 for ; Fri, 21 Feb 2003 18:30:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodao17718 for ; Fri, 21 Feb 2003 18:30:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodao07080 for ; Fri, 21 Feb 2003 18:30:05 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodao07045 for ; Fri, 21 Feb 2003 18:30:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LIU2JR007605 for ; Fri, 21 Feb 2003 13:30:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA08524 for ; Fri, 21 Feb 2003 13:30:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1LIU1f28202 for mpls@uu.net; Fri, 21 Feb 2003 13:30:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodan06427 for ; Fri, 21 Feb 2003 18:27:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodan07873 for ; Fri, 21 Feb 2003 18:26:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodan03774 for ; Fri, 21 Feb 2003 18:26:22 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodan03757 for ; Fri, 21 Feb 2003 18:26:21 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA96781; Fri, 21 Feb 2003 13:26:26 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302211826.NAA96781@workhorse.fictitious.org> To: "Jim Hand" cc: curtis@fictitious.org, "'Ash, Gerald R \(Jerry\), ALABS'" , "'raymond zhang'" , "'MPLS@UU.net'" , "'George Swallow'" , "'Loa Andersson'" , "'GOODE, B \(Bur\), ALABS'" , "'Dave Cooper'" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS In-reply-to: Your message of "Wed, 19 Feb 2003 23:05:20 EST." <000001c2d8f0$d5941e80$3a785b87@mt.att.com> Date: Fri, 21 Feb 2003 13:26:26 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <000001c2d8f0$d5941e80$3a785b87@mt.att.com>, "Jim Hand" writes: > In many VoIP services I am working with, the most important place for > bandwidth efficiency is on the access link between the customer premise and > the provider edge. There is limited opportunity at the customer premise for > connection muxing, because of the limited number of connections. So I think > it would be necessary to do compression on the access link in many cases > anyway. What is the range of bandwidths of the CE-PE links? It we are talking at least 80 kbit/sec links, then you can mux 10 calls to the PE for 300 byte packets. Pulling apart the packets might be easier than header twiddling. Pulling them apart and remuxing into large packets might also be easier than header twiddling. The practical problem here is entirely the CPU on the PE. > You could then do connection muxing inside the Service Provider's netwo > rk. > But in order to do the connection muxing, you would likely have to > decompress the packets first (perhaps there might be some way around this). > This would require a place in the network where you would have to do both > compression/decompresion and connection muxing/demuxing. That's a lot of > load at some aggregation points in the network. With the end-to-end > compression, we were hoping to push the compression load out toward the > edges, where there are more boxes to apply to the compression load, and > avoid it altogether within the SP transport network. > > Thanks, > Jim Jim, Doing the compression at the edges would be the most sensible. Unfortunately edge to edge (which is also compression to compression in this case) RSVP-TE is unlikely to scale to the very large number of CE. Even PE to PE is unlikely. If you have the PE or P do decompresion we've already established that the PE gets overloaded. Therefore, RTP/UDP header compression, leaving the IP header intact, seems to make more sense. It only gets efficiency up from 30/70 to 30/54. Beyond that doing an adaptive encoding that moves the playout point might be worth considering. At 80 msec rather than 30 msec, efficiency would then be 80/104 with RTP/UDP compression. Its the SP's call whether increasing delay only in times of congestion but maintaining near zero loss would be an attractive tradeoff. Beyond 100 msec you may discourage some callers also reducing congestion but due to a noticable drop in service quality (which might no longer be an attractive tradeoff). The benefit is that the PE/P are not required to do anything. To do RTP/UDP header compression e2e, you need some form of signaling to setup. This might be worth pursuing. If you can get the PE to do RTP/UDP/IP header comp/decomp this would further improve the CE-PE but lose the gain in the core. If you could also get the PE to do RTP/UDP comp/decomp on the core side, this would further improve the situation in the core. This is a lot to ask the PE to do and in many cases would require that you replace the PE which one SP already ruled out. Curtis From owner-mpls@UU.NET Fri Feb 21 13:36:01 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10194 for ; Fri, 21 Feb 2003 13:36:01 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodao24861 for ; Fri, 21 Feb 2003 18:39:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodao16303; Fri, 21 Feb 2003 18:34:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQodao06835 for mpls-outgoing; Fri, 21 Feb 2003 18:34:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodao06827 for ; Fri, 21 Feb 2003 18:34:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodao01517 for ; Fri, 21 Feb 2003 18:34:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodao10925 for ; Fri, 21 Feb 2003 18:34:06 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodao10919 for ; Fri, 21 Feb 2003 18:34:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LIY3JR007857 for ; Fri, 21 Feb 2003 13:34:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA08870 for ; Fri, 21 Feb 2003 13:34:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1LIY3d28462 for mpls@uu.net; Fri, 21 Feb 2003 13:34:03 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodao06712 for ; Fri, 21 Feb 2003 18:32:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodao27690 for ; Fri, 21 Feb 2003 18:31:29 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodao08221 for ; Fri, 21 Feb 2003 18:31:29 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodao08203 for ; Fri, 21 Feb 2003 18:31:28 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA96914; Fri, 21 Feb 2003 13:31:33 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302211831.NAA96914@workhorse.fictitious.org> To: Matthew Meyer cc: Markus Jork , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: draft-meyer-mpls-soft-preemption-00.txt In-reply-to: Your message of "Thu, 20 Feb 2003 20:08:57 MST." <20030221030857.GJ18082@gblx.net> Date: Fri, 21 Feb 2003 13:31:33 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20030221030857.GJ18082@gblx.net>, Matthew Meyer writes: > Comments in line. > > Thus spake Markus Jork (mjork@avici.com): > > |I like the original soft preemption idea in the draft as it stands now. > > I think there have been some strong arguments to leave it as is. > > |But I have my doubts about the extensions discussed in this e-mail thread. > |When planning an admin link or node shutdown, it is probably a better > |idea to indicate that via the IGP (through a metric change or announcing > |the available bandwidth as 0). > > While I agree with you that it is perhaps more appropriately > accomplished in the IGP, I don't believe the IGP has all > the needed mechanisms. > > Cranking the metric & setting/flooding available reserveable BW > at 0 is not enough. Even if you soft preempt as well, you still > have 0BW LSPs or explicitly routed LSPs or disparate backups that > need to be forced to forget this link. Currently SPs are forced > to remove configuration parameters if we want to drive some types > of tunnels off a link. Keeping a admin-color (aka admin-group) and naming it "maintenance" and always configuring exclude-admin-color maintenance to your LSPs does solve this problem easily. Just advertise the link with "admin-color maintenance" and the LSPs should go away rather quickly. This is just a good operations trick/practice to have handy. Increasing the IGP cost keeps the non-MPLS packets away. Curtis From owner-mpls@UU.NET Fri Feb 21 17:57:24 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17729 for ; Fri, 21 Feb 2003 17:57:24 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodbg10927 for ; Fri, 21 Feb 2003 23:01:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodbg10285; Fri, 21 Feb 2003 23:00:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQodbg15101 for mpls-outgoing; Fri, 21 Feb 2003 23:00:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodbg14809 for ; Fri, 21 Feb 2003 23:00:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodbg28726 for ; Fri, 21 Feb 2003 23:00:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodbg13469 for ; Fri, 21 Feb 2003 23:00:08 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodbg13447 for ; Fri, 21 Feb 2003 23:00:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LN03JR025300 for ; Fri, 21 Feb 2003 18:00:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA01106 for ; Fri, 21 Feb 2003 18:00:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1LN03916542 for mpls@uu.net; Fri, 21 Feb 2003 18:00:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodbf11527 for ; Fri, 21 Feb 2003 22:58:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodbf21711 for ; Fri, 21 Feb 2003 22:58:27 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodbf11626 for ; Fri, 21 Feb 2003 22:58:27 GMT Received: from hawk.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hawk.mail.pas.earthlink.net [207.217.120.22]) id QQodbf11618 for ; Fri, 21 Feb 2003 22:58:26 GMT Received: from dialup-65.59.107.53.dial1.weehawken1.level3.net ([65.59.107.53] helo=jhand) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mM7X-0000Pd-00; Fri, 21 Feb 2003 14:58:19 -0800 From: "Jim Hand" To: , "'Jim Hand'" Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , "'raymond zhang'" , "'MPLS@UU.net'" , "'George Swallow'" , "'Loa Andersson'" , "'GOODE, B \(Bur\), ALABS'" , "'Dave Cooper'" Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS Date: Fri, 21 Feb 2003 17:56:45 -0500 Message-ID: <002101c2d9fc$8a3350c0$3a785b87@mt.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200302211658.LAA96189@workhorse.fictitious.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Friday, February 21, 2003 11:59 AM > > Jim, > > What we are trying to establish is if you are actually solving a > practical problem Which has two parts. The first is identifying what > problem it is you are trying to solve. The second is determining if > what you are suggesting solved the problem. > > If the discussion so far is valid, the problem is CE-PE and the simple > solution of just compressing on the CE and decompressing on the PE has > a practical problem of overloading the PE. Having P routers support > compression and decompression **is part of the current problem**. Neither of the drafts require P routers to support compression and decompression. > > If the above paragraph is not valid for some reason, please start by > telling us what problem you are trying to solve, then tell us why the > techniques in these drafts solve the problem without creating a bigger > problem elsewhere. A problem statement/requirements document will be submitted for discussion on the list. > > Regards, > > Curtis From owner-mpls@UU.NET Fri Feb 21 18:32:06 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18294 for ; Fri, 21 Feb 2003 18:32:06 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodbi15901 for ; Fri, 21 Feb 2003 23:35:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodbi15155; Fri, 21 Feb 2003 23:35:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQodbi03015 for mpls-outgoing; Fri, 21 Feb 2003 23:34:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodbi03007 for ; Fri, 21 Feb 2003 23:34:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodbi15463 for ; Fri, 21 Feb 2003 23:33:53 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodbi13992 for ; Fri, 21 Feb 2003 23:33:53 GMT Received: from smtp1.phx.gblx.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQodbi13970 for ; Fri, 21 Feb 2003 23:33:52 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id h1LNXp400813; Fri, 21 Feb 2003 16:33:51 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAARuaWIb; Fri Feb 21 16:33:49 2003 Received: (from mmeyer@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) id QAA23209; Fri, 21 Feb 2003 16:33:49 -0700 (MST) Date: Fri, 21 Feb 2003 16:33:49 -0700 From: "Matthew R. Meyer" To: Curtis Villamizar Cc: Matthew Meyer , Markus Jork , mpls@UU.NET Subject: Re: draft-meyer-mpls-soft-preemption-00.txt Message-ID: <20030221233348.GR18082@gblx.net> References: <20030221030857.GJ18082@gblx.net> <200302211831.NAA96914@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302211831.NAA96914@workhorse.fictitious.org> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Thus spake Curtis Villamizar (curtis@fictitious.org): |> While I agree with you that it is perhaps more appropriately |> accomplished in the IGP, I don't believe the IGP has all |> the needed mechanisms. |> |> Cranking the metric & setting/flooding available reserveable BW |> at 0 is not enough. Even if you soft preempt as well, you still |> have 0BW LSPs or explicitly routed LSPs or disparate backups that |> need to be forced to forget this link. Currently SPs are forced |> to remove configuration parameters if we want to drive some types |> of tunnels off a link. | |Keeping a admin-color (aka admin-group) and naming it "maintenance" |and always configuring exclude-admin-color maintenance to your LSPs |does solve this problem easily. Just advertise the link with |"admin-color maintenance" and the LSPs should go away rather quickly. | |This is just a good operations trick/practice to have handy. |Increasing the IGP cost keeps the non-MPLS packets away. | |Curtis This handles it in two steps and is not as clean as leaving the config in place and setting a maintenance oriented command. It is somewhat annoying that this solution requires alteration of configured metric, a process which is typically tightly controlled in many large operations organizations as, at very least, a matter of principal. A number of providers choose to fail the IGP adjacency by mis-config of the link authentication though this may not act consistent between vendors and in relation to various tunnel types (I know, talk to the vendors, matt) - anyway metrics don't need to be messed with this way. Using this method provides no warning time though. IMO link OL bit would be more precisely what was needed though I willing to take this sub-thread off line. Matthew From owner-mpls@UU.NET Sun Feb 23 12:42:56 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10334 for ; Sun, 23 Feb 2003 12:42:55 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodhv22563 for ; Sun, 23 Feb 2003 17:46:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodhv22267; Sun, 23 Feb 2003 17:46:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQodhv26535 for mpls-outgoing; Sun, 23 Feb 2003 17:46:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodhv26391 for ; Sun, 23 Feb 2003 17:46:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodhv14000 for ; Sun, 23 Feb 2003 17:45:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodhv21687 for ; Sun, 23 Feb 2003 17:45:54 GMT Received: from maile.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maile.telia.com [194.22.190.16]) id QQodhv21681 for ; Sun, 23 Feb 2003 17:45:53 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maile.telia.com (8.12.5/8.12.5) with ESMTP id h1NHjpT5022011; Sun, 23 Feb 2003 18:45:51 +0100 (CET) X-Original-Recipient: MPLS@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1NHjo205433; Sun, 23 Feb 2003 18:45:50 +0100 (CET) Message-ID: <3E5907CF.8050006@pi.se> Date: Sun, 23 Feb 2003 18:41:35 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Hand CC: curtis@fictitious.org, "'Ash, Gerald R (Jerry), ALABS'" , "'raymond zhang'" , "'MPLS@UU.net'" , "'George Swallow'" , "'Loa Andersson'" , "'GOODE, B (Bur), ALABS'" , "'Dave Cooper'" Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS References: <000601c2d9c1$c03f88e0$3a785b87@mt.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, it wouldn't be hard to make the point based on this discussion that I tried to make when this discussion just started. I seems like a good idea to split the docs into two 1. problem and requirments 2. the solution I can't really escape the impression that what is going on here is that one is looking into the solution to try to find out what the requirments really were. /Loa Jim Hand wrote: > Maybe we need to re-write draft-ash-e2e-crtp-hdr-compress-00 to clarify. I >will look into this. > > This draft does require RSVP TE e2e over the MPLS part of the network, but >it does not require that MPLS or RSVP TE be extended to CE's. And it does >not require that the original compressor and decompressor be attached to >MPLS. > > Also, it does require that routers other than MPLS "P" routers have the >ability to support compression and decompression. But that does not mean >that these routers will have to *perform* compression and decompression on >each compressed packet. Routers that support compressed packets on both >input links and output links should only have to perform a >decompression/compression cycle on a small fraction of the total number of >packets. Most compressed packets would be switched from input to output >without performing decompression and compression. > >Thanks, >Jim > > > >>draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te mpls for the >>above definition of e2e which I hope I don't have to repeat with every >>email message. >> >>draft-ash-e2e-crtp-hdr-compress-00 requires either of two conditions. >>1) e2e rsvp/te mpls (for the above definition of e2e), 2) every router >>along the way knows how to do compression and decompression. >> >>Case #2 is the one that SP are saying is impractical because the PE >>CPU is overloaded with too many PPS. Except for this practical matter >>case #2 is every bit as good a solution for the CE-PE links as rfc2508 >>over PPP links (with most CE-PE being PPP). Needless to say that >>makes case #2 completely absurd in the core (comp/decomp on oc192c >>interfaces). >> >>That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e >>rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which >>requires e2e rsvp/te mpls plus requires every hop in the path to >>support comp/decomp making it even worse. >> >>Curtis >> >> >> >> >>>>-----Original Message----- >>>>From: Curtis Villamizar [mailto:curtis@fictitious.org] >>>>Sent: Wednesday, February 19, 2003 11:25 AM >>>>To: Ash, Gerald R (Jerry), ALABS >>>>Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; >>>> >>>> >>George Swallow; >> >> >>>>Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; >>>>Dave Cooper >>>>Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression >>>> >>>> >>>>Please correct me if I'm wrong but your drafts seem to >>>> >>>> >>require end2end >> >> >>>>MPLS where RTP/UDP/IP/MPLS normally requires just end2end >>>> >>>> >>IP. Since >> >> >>>>you are providing new RSVP/TE objects the assumption seems to be >>>>RSVP/TE MPLS edge to edge. If traffic engineering is done within >>>>regions as can be done with current RTP/UDP/IP/MPLS regardless of >>>>whether LDP is also used, that works fine and scales >>>> >>>> >>extremely well. >> >> >>>>E2E RSVP/TE MPLS all the way to each peice of VOIP gear >>>> >>>> >>is unlikely to >> >> >>>>scale well in a single provider and is almost certain to become a >>>>severe problem crossing SP boundaries. >>>> >>>>Curtis >>>> >>>> >>>> >>> >>> > > > > > From owner-mpls@UU.NET Sun Feb 23 13:14:18 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10784 for ; Sun, 23 Feb 2003 13:14:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodhx20945 for ; Sun, 23 Feb 2003 18:18:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodhx20250; Sun, 23 Feb 2003 18:17:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQodhx17349 for mpls-outgoing; Sun, 23 Feb 2003 18:17:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodhx17344 for ; Sun, 23 Feb 2003 18:17:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodhx05321 for ; Sun, 23 Feb 2003 18:17:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodhx07143 for ; Sun, 23 Feb 2003 18:17:05 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodhx07133 for ; Sun, 23 Feb 2003 18:17:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1NIH2JR007952 for ; Sun, 23 Feb 2003 13:17:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA25270 for ; Sun, 23 Feb 2003 13:17:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1NIH1j08752 for mpls@uu.net; Sun, 23 Feb 2003 13:17:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodhx17125 for ; Sun, 23 Feb 2003 18:15:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodhx02798 for ; Sun, 23 Feb 2003 18:15:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodhx07263 for ; Sun, 23 Feb 2003 18:15:38 GMT Received: from kcmso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQodhx07256 for ; Sun, 23 Feb 2003 18:15:37 GMT Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1NIFDWM029847 for ; Sun, 23 Feb 2003 12:15:36 -0600 (CST) Received: from OCCLUST01EVS1.ugd.att.com (135.71.164.6) by attrh1i.attrh.att.com (6.5.019) id 3E54F1550004327C; Sun, 23 Feb 2003 13:15:32 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-EndMPLS Date: Sun, 23 Feb 2003 13:15:34 -0500 Message-ID: Thread-Topic: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-EndMPLS Thread-Index: AcLbZUlSIAfT7zFlS8i13Kf6BvePaQAAK3Gw From: "GOODE, B (Bur), ALABS" To: "Loa Andersson" , "Jim Hand" Cc: "Ash, Gerald R (Jerry), ALABS" , "raymond zhang" , "MPLS@UU.net" , "George Swallow" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA10784 Loa, we started with a problem and a statement of requirements. In the beginning, we discussed the problem and the requirements with George Swallow and Dave Oran 18 months ago. At that time, there was no IETF process for documenting the problem and the requirements. We started working on potential solutions months after we defined the problem and requirements. When we felt we had a couple of potential solutions, we submitted them as IDs. Three months after we submitted the drafts, and 17 months after the first problem statement and identification of the requirements, you came along and demanded that we write a requirements document. So we wrote a requirements document, which we have just submitted to the internet drafts editor. Loa, you should ask yourself, are you trying to be objective? Bur > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Sunday, February 23, 2003 12:42 PM > To: Jim Hand > Cc: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS; 'raymond > zhang'; 'MPLS@UU.net'; 'George Swallow'; 'Loa Andersson'; GOODE, B > (Bur), ALABS; 'Dave Cooper' > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - > End-to-EndMPLS > > > All, > > it wouldn't be hard to make the point based on this discussion that I > tried to > make when this discussion just started. > > I seems like a good idea to split the docs into two > > 1. problem and requirments > 2. the solution > > I can't really escape the impression that what is going on > here is that > one is > looking into the solution to try to find out what the > requirments really > were. > > /Loa > > Jim Hand wrote: > > > Maybe we need to re-write > draft-ash-e2e-crtp-hdr-compress-00 to clarify. I > >will look into this. > > > > This draft does require RSVP TE e2e over the MPLS part > of the network, but > >it does not require that MPLS or RSVP TE be extended to > CE's. And it does > >not require that the original compressor and decompressor be > attached to > >MPLS. > > > > Also, it does require that routers other than MPLS "P" > routers have the > >ability to support compression and decompression. But that > does not mean > >that these routers will have to *perform* compression and > decompression on > >each compressed packet. Routers that support compressed > packets on both > >input links and output links should only have to perform a > >decompression/compression cycle on a small fraction of the > total number of > >packets. Most compressed packets would be switched from > input to output > >without performing decompression and compression. > > > >Thanks, > >Jim > > > > > > > >>draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te > mpls for the > >>above definition of e2e which I hope I don't have to repeat > with every > >>email message. > >> > >>draft-ash-e2e-crtp-hdr-compress-00 requires either of two > conditions. > >>1) e2e rsvp/te mpls (for the above definition of e2e), 2) > every router > >>along the way knows how to do compression and decompression. > >> > >>Case #2 is the one that SP are saying is impractical because the PE > >>CPU is overloaded with too many PPS. Except for this > practical matter > >>case #2 is every bit as good a solution for the CE-PE links > as rfc2508 > >>over PPP links (with most CE-PE being PPP). Needless to say that > >>makes case #2 completely absurd in the core (comp/decomp on oc192c > >>interfaces). > >> > >>That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e > >>rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which > >>requires e2e rsvp/te mpls plus requires every hop in the path to > >>support comp/decomp making it even worse. > >> > >>Curtis > >> > >> > >> > >> > >>>>-----Original Message----- > >>>>From: Curtis Villamizar [mailto:curtis@fictitious.org] > >>>>Sent: Wednesday, February 19, 2003 11:25 AM > >>>>To: Ash, Gerald R (Jerry), ALABS > >>>>Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; > >>>> > >>>> > >>George Swallow; > >> > >> > >>>>Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; > >>>>Dave Cooper > >>>>Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression > >>>> > >>>> > >>>>Please correct me if I'm wrong but your drafts seem to > >>>> > >>>> > >>require end2end > >> > >> > >>>>MPLS where RTP/UDP/IP/MPLS normally requires just end2end > >>>> > >>>> > >>IP. Since > >> > >> > >>>>you are providing new RSVP/TE objects the assumption seems to be > >>>>RSVP/TE MPLS edge to edge. If traffic engineering is done within > >>>>regions as can be done with current RTP/UDP/IP/MPLS regardless of > >>>>whether LDP is also used, that works fine and scales > >>>> > >>>> > >>extremely well. > >> > >> > >>>>E2E RSVP/TE MPLS all the way to each peice of VOIP gear > >>>> > >>>> > >>is unlikely to > >> > >> > >>>>scale well in a single provider and is almost certain to become a > >>>>severe problem crossing SP boundaries. > >>>> > >>>>Curtis > >>>> > >>>> > >>>> > >>> > >>> > > > > > > > > > > > > > From owner-mpls@UU.NET Sun Feb 23 13:43:27 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11025 for ; Sun, 23 Feb 2003 13:43:27 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodhz16913 for ; Sun, 23 Feb 2003 18:47:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodhz16160; Sun, 23 Feb 2003 18:46:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQodhz19649 for mpls-outgoing; Sun, 23 Feb 2003 18:46:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodhz19644 for ; Sun, 23 Feb 2003 18:46:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodhz12748 for ; Sun, 23 Feb 2003 18:46:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodhz03670 for ; Sun, 23 Feb 2003 18:46:23 GMT Received: from mailg.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailg.telia.com [194.22.194.26]) id QQodhz03650 for ; Sun, 23 Feb 2003 18:46:22 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.5/8.12.5) with ESMTP id h1NIkBh9016298; Sun, 23 Feb 2003 19:46:12 +0100 (CET) X-Original-Recipient: MPLS@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1NIkB225359; Sun, 23 Feb 2003 19:46:11 +0100 (CET) Message-ID: <3E5915EF.7090003@pi.se> Date: Sun, 23 Feb 2003 19:41:51 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "GOODE, B (Bur), ALABS" CC: Jim Hand , "Ash, Gerald R (Jerry), ALABS" , raymond zhang , "MPLS@UU.net" , George Swallow Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-EndMPLS References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bur, no I don't think I've have a problem with the objectvity, but other may have their own judgement :) 1. I asked Jerry if there where any requirements and problem statement - was pointed to less than ten lines in one of the drafts - at that point I SUGGESTED that it is a good idea, there is is no "coming along and requiring" - I was (and am) very explicit on that this is not a required process. I'm not going to mandate (or even being very push on that you do this "my way") - though I should have the freedom to state what I think a good way of doing it. No? 2. It is only about two weeks since Jerry proposed that this is made an mpls wg work. As he said himself there has been some uncertainties of where this work should go. It was the proposal that made me "come along", not the 17 months. 3. Now I learn that the documents I've asked for exist. Great! 17 months would have made them dated, so they would have to be republished, but not that hard! 4. ... and that a requirement has been submitted. Great :) Sorry I've not seen that one yet, but will be looking for it as it comes through the ID publishing process :). If it is already out, could you please point me to it! The previous mail was based on the fact that I was not aware of that requirment draft. How could I've been? And that Jim suggested that some re-work is needed. 5. Could it be that what I want to achieve is a well documented situation for something I think could be useful? /Loa GOODE, B (Bur), ALABS wrote: >Loa, we started with a problem and a statement of requirements. In the >beginning, we discussed the problem and the requirements with George >Swallow and Dave Oran 18 months ago. At that time, there was no IETF >process for documenting the problem and the requirements. We started >working on potential solutions months after we defined the problem and >requirements. When we felt we had a couple of potential solutions, we >submitted them as IDs. Three months after we submitted the drafts, and >17 months after the first problem statement and identification of the >requirements, you came along and demanded that we write a requirements >document. So we wrote a requirements document, which we have just >submitted to the internet drafts editor. > >Loa, you should ask yourself, are you trying to be objective? > >Bur > > > >>-----Original Message----- >>From: Loa Andersson [mailto:loa@pi.se] >>Sent: Sunday, February 23, 2003 12:42 PM >>To: Jim Hand >>Cc: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS; 'raymond >>zhang'; 'MPLS@UU.net'; 'George Swallow'; 'Loa Andersson'; GOODE, B >>(Bur), ALABS; 'Dave Cooper' >>Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression - >>End-to-EndMPLS >> >> >>All, >> >>it wouldn't be hard to make the point based on this discussion that I >>tried to >>make when this discussion just started. >> >>I seems like a good idea to split the docs into two >> >>1. problem and requirments >>2. the solution >> >>I can't really escape the impression that what is going on >>here is that >>one is >>looking into the solution to try to find out what the >>requirments really >>were. >> >>/Loa >> >>Jim Hand wrote: >> >> >> >>> Maybe we need to re-write >>> >>> >>draft-ash-e2e-crtp-hdr-compress-00 to clarify. I >> >> >>>will look into this. >>> >>> This draft does require RSVP TE e2e over the MPLS part >>> >>> >>of the network, but >> >> >>>it does not require that MPLS or RSVP TE be extended to >>> >>> >>CE's. And it does >> >> >>>not require that the original compressor and decompressor be >>> >>> >>attached to >> >> >>>MPLS. >>> >>> Also, it does require that routers other than MPLS "P" >>> >>> >>routers have the >> >> >>>ability to support compression and decompression. But that >>> >>> >>does not mean >> >> >>>that these routers will have to *perform* compression and >>> >>> >>decompression on >> >> >>>each compressed packet. Routers that support compressed >>> >>> >>packets on both >> >> >>>input links and output links should only have to perform a >>>decompression/compression cycle on a small fraction of the >>> >>> >>total number of >> >> >>>packets. Most compressed packets would be switched from >>> >>> >>input to output >> >> >>>without performing decompression and compression. >>> >>>Thanks, >>>Jim >>> >>> >>> >>> >>> >>>>draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te >>>> >>>> >>mpls for the >> >> >>>>above definition of e2e which I hope I don't have to repeat >>>> >>>> >>with every >> >> >>>>email message. >>>> >>>>draft-ash-e2e-crtp-hdr-compress-00 requires either of two >>>> >>>> >>conditions. >> >> >>>>1) e2e rsvp/te mpls (for the above definition of e2e), 2) >>>> >>>> >>every router >> >> >>>>along the way knows how to do compression and decompression. >>>> >>>>Case #2 is the one that SP are saying is impractical because the PE >>>>CPU is overloaded with too many PPS. Except for this >>>> >>>> >>practical matter >> >> >>>>case #2 is every bit as good a solution for the CE-PE links >>>> >>>> >>as rfc2508 >> >> >>>>over PPP links (with most CE-PE being PPP). Needless to say that >>>>makes case #2 completely absurd in the core (comp/decomp on oc192c >>>>interfaces). >>>> >>>>That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e >>>>rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which >>>>requires e2e rsvp/te mpls plus requires every hop in the path to >>>>support comp/decomp making it even worse. >>>> >>>>Curtis >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>-----Original Message----- >>>>>>From: Curtis Villamizar [mailto:curtis@fictitious.org] >>>>>>Sent: Wednesday, February 19, 2003 11:25 AM >>>>>>To: Ash, Gerald R (Jerry), ALABS >>>>>>Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; >>>>>> >>>>>> >>>>>> >>>>>> >>>>George Swallow; >>>> >>>> >>>> >>>> >>>>>>Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS; >>>>>>Dave Cooper >>>>>>Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression >>>>>> >>>>>> >>>>>>Please correct me if I'm wrong but your drafts seem to >>>>>> >>>>>> >>>>>> >>>>>> >>>>require end2end >>>> >>>> >>>> >>>> >>>>>>MPLS where RTP/UDP/IP/MPLS normally requires just end2end >>>>>> >>>>>> >>>>>> >>>>>> >>>>IP. Since >>>> >>>> >>>> >>>> >>>>>>you are providing new RSVP/TE objects the assumption seems to be >>>>>>RSVP/TE MPLS edge to edge. If traffic engineering is done within >>>>>>regions as can be done with current RTP/UDP/IP/MPLS regardless of >>>>>>whether LDP is also used, that works fine and scales >>>>>> >>>>>> >>>>>> >>>>>> >>>>extremely well. >>>> >>>> >>>> >>>> >>>>>>E2E RSVP/TE MPLS all the way to each peice of VOIP gear >>>>>> >>>>>> >>>>>> >>>>>> >>>>is unlikely to >>>> >>>> >>>> >>>> >>>>>>scale well in a single provider and is almost certain to become a >>>>>>severe problem crossing SP boundaries. >>>>>> >>>>>>Curtis >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>> >> >> >> > > > > From owner-mpls@UU.NET Mon Feb 24 03:39:58 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04788 for ; Mon, 24 Feb 2003 03:39:57 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkc02000 for ; Mon, 24 Feb 2003 08:43:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodkc01635; Mon, 24 Feb 2003 08:43:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQodkc13701 for mpls-outgoing; Mon, 24 Feb 2003 08:43:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodkc13694 for ; Mon, 24 Feb 2003 08:43:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodkc14382 for ; Mon, 24 Feb 2003 08:42:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkc01166 for ; Mon, 24 Feb 2003 08:42:56 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQodkc01151 for ; Mon, 24 Feb 2003 08:42:56 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1O8gtS89085; Mon, 24 Feb 2003 00:42:55 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h1O8gtK14052; Mon, 24 Feb 2003 00:42:55 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 24 Feb 2003 00:42:54 -0800 (PST) From: Kireeti Kompella To: Curtis Villamizar cc: "MPLS@UU.net" Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-Reply-To: <200302190348.WAA76199@workhorse.fictitious.org> Message-ID: <20030224003710.O14037@kummer.juniper.net> References: <200302190348.WAA76199@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, On Tue, 18 Feb 2003, Curtis Villamizar wrote: > I think the SPs should speak as to whether the bandwidth inefficiency > of 30 byte payloads or the potential to lose a packet with a 200 byte > is a greater problem. Two questions (more probably to others than to you): a) what is the relative bandwidth of voice? (i.e., if voice accounts for <10% of a link's capacity, it may not be worth worrying about even a 100% overhead); and b) if a 30 byte voice packet got dropped, would you expect that 6 other voice packets that were temporally close would escape the hatchet? I.e., how big really is the penalty of a 200 byte packet? Kireeti. From owner-mpls@UU.NET Mon Feb 24 05:56:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07545 for ; Mon, 24 Feb 2003 05:56:40 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkm14778 for ; Mon, 24 Feb 2003 11:00:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodkm14183; Mon, 24 Feb 2003 11:00:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQodkm26428 for mpls-outgoing; Mon, 24 Feb 2003 11:00:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodkl26357 for ; Mon, 24 Feb 2003 10:59:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodkl05407 for ; Mon, 24 Feb 2003 10:59:51 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkl13639 for ; Mon, 24 Feb 2003 10:59:51 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQodkl13635 for ; Mon, 24 Feb 2003 10:59:50 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1OAxiS93811; Mon, 24 Feb 2003 02:59:44 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h1OAxi714597; Mon, 24 Feb 2003 02:59:44 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 24 Feb 2003 02:59:44 -0800 (PST) From: Kireeti Kompella To: Bob Braden cc: rsvp@ISI.EDU, "" , "" , "" Subject: Re: IANA Considerations for RSVP In-Reply-To: <200301222140.VAA00937@gra.isi.edu> Message-ID: <20030224024020.N14571@kummer.juniper.net> References: <200301222140.VAA00937@gra.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Bob, On Wed, 22 Jan 2003, Bob Braden wrote: > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. To come back to your email, I should say that I am happy that someone else is also concerned about this. > 3. The IANA Considerations draft should be published as an RFC, > perhaps after updating. Scant hours from the cut-off, I just submitted an ID (rsvp-change) that is basically new IANA Considerations for RSVP. This is intended to get the discussion rolling. I would suggest to folks who intend to take part in such a discussion to read Bob and Lixia's document at http://www.isi.edu/rsvp/DOCUMENTS/IANAconsider.txt . > (A) How to handle requests for RSVP assignments for > extensions developed outside IETF? > > Here is my suggestion: > > For all assignments of numbers for extensions defined > in non-IETF standards bodies, the IANA should use > assignment names (e.g., object names) that are prefixed > with the name of the responsible standards body. For > example, the "SPIFFY_SESSION" object would become > "ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION", > etc., object. Not addressed in the rsvp-change ID, but should be. > (B) What policies should be imposed? The rsvp-change ID suggests three sets of spaces: Standards Action (a standards track RFC is needed); Expert Review (used as the moral equivalent of Experimental code points); and Private Use (no registration). > (C) What are the appropriate documentation requirements? A lengthy discussion on the IETF mailing list still hasn't enlightened me as to what "IETF Consensus" means. Thus, the suggestion in the rsvp-change ID is to use the "Standards Action" designation for code points whose specification one cares about. Kireeti. From owner-mpls@UU.NET Mon Feb 24 06:49:00 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09346 for ; Mon, 24 Feb 2003 06:49:00 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkp29127 for ; Mon, 24 Feb 2003 11:52:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodkp28669; Mon, 24 Feb 2003 11:52:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQodkp17195 for mpls-outgoing; Mon, 24 Feb 2003 11:52:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodkp17170 for ; Mon, 24 Feb 2003 11:52:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodkp09091 for ; Mon, 24 Feb 2003 11:52:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkp07426 for ; Mon, 24 Feb 2003 11:52:08 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodkp07313 for ; Mon, 24 Feb 2003 11:52:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OBq1Nh006463 for ; Mon, 24 Feb 2003 06:52:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA00404 for ; Mon, 24 Feb 2003 06:52:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1OBq1n27285 for mpls@uu.net; Mon, 24 Feb 2003 06:52:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodkp17105 for ; Mon, 24 Feb 2003 11:50:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodkp03459 for ; Mon, 24 Feb 2003 11:50:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkp04091 for ; Mon, 24 Feb 2003 11:50:04 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQodkp04062 for ; Mon, 24 Feb 2003 11:50:03 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09032; Mon, 24 Feb 2003 06:46:09 -0500 (EST) Message-Id: <200302241146.GAA09032@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: iptel@ietf.org, mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-brandner-enum-uri-01.txt Date: Mon, 24 Feb 2003 06:46:09 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The 'enum:' URI scheme Author(s) : R. Brandner, L. Conroy, R. Stastny Filename : draft-brandner-enum-uri-01.txt Pages : 6 Date : 2003-2-21 This document specifies the enum: URI scheme. This URI is intended for use where a resource address can be returned by evaluating the URI value using the ENUM DDDS application. Syntactically, it uses a subset of the format defined for the tel: URI scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brandner-enum-uri-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-brandner-enum-uri-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-21161217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enum-uri-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-brandner-enum-uri-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-21161217.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Feb 24 06:55:24 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09573 for ; Mon, 24 Feb 2003 06:55:23 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkp17743 for ; Mon, 24 Feb 2003 11:59:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodkp05224; Mon, 24 Feb 2003 11:51:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQodkp17115 for mpls-outgoing; Mon, 24 Feb 2003 11:50:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodkp17107 for ; Mon, 24 Feb 2003 11:50:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodkp03469 for ; Mon, 24 Feb 2003 11:50:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkp26564 for ; Mon, 24 Feb 2003 11:50:05 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodkp26560 for ; Mon, 24 Feb 2003 11:50:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1OBo2JR007391 for ; Mon, 24 Feb 2003 06:50:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA00294 for ; Mon, 24 Feb 2003 06:50:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1OBo2E27161 for mpls@uu.net; Mon, 24 Feb 2003 06:50:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodkp17070 for ; Mon, 24 Feb 2003 11:49:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodkp26011 for ; Mon, 24 Feb 2003 11:49:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkp02999 for ; Mon, 24 Feb 2003 11:49:03 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQodkp02888 for ; Mon, 24 Feb 2003 11:48:58 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08794; Mon, 24 Feb 2003 06:45:04 -0500 (EST) Message-Id: <200302241145.GAA08794@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt Date: Mon, 24 Feb 2003 06:45:04 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF Extensions to Support Multi-Area Traffic Engineering Author(s) : D. Cheng Filename : draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt Pages : 7 Date : 2003-2-21 The [MULTI-AREA] introduces a set of mechanisms that could be used to construct LSPs that span multiple IS-IS/OSPF areas, where one scenario is to allow the head-end LSR to compute the path all the way to the ABR in the tail-end area. This document proposes some new OSPF extensions that can be used in supporting that scenario, i.e., by leaking some of the useful information from individual areas to others, the constraint-based routing at the head-end LSR of LSPs in OSPF networks with multiple areas can be optimized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cheng-ccamp-ospf-multiarea-te-extensions-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-cheng-ccamp-ospf-multiarea-te-extensions-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-21161106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-21161106.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Feb 24 08:58:21 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14728 for ; Mon, 24 Feb 2003 08:58:21 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodky07245 for ; Mon, 24 Feb 2003 14:02:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodky06680; Mon, 24 Feb 2003 14:01:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQodky13115 for mpls-outgoing; Mon, 24 Feb 2003 14:01:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodky12922 for ; Mon, 24 Feb 2003 14:01:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodky26068 for ; Mon, 24 Feb 2003 14:01:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodky06504 for ; Mon, 24 Feb 2003 14:01:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodky06482 for ; Mon, 24 Feb 2003 14:01:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1OE13JR011815 for ; Mon, 24 Feb 2003 09:01:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA05589 for ; Mon, 24 Feb 2003 09:01:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1OE13M05662 for mpls@uu.net; Mon, 24 Feb 2003 09:01:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodkx06067 for ; Mon, 24 Feb 2003 13:59:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodkx07366 for ; Mon, 24 Feb 2003 13:59:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodkx06374 for ; Mon, 24 Feb 2003 13:59:03 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodkx06370 for ; Mon, 24 Feb 2003 13:59:02 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id IAA09118; Mon, 24 Feb 2003 08:58:43 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302241358.IAA09118@workhorse.fictitious.org> To: Kireeti Kompella cc: Curtis Villamizar , "MPLS@UU.net" Reply-To: curtis@fictitious.org Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression In-reply-to: Your message of "Mon, 24 Feb 2003 00:42:54 PST." <20030224003710.O14037@kummer.juniper.net> Date: Mon, 24 Feb 2003 08:58:43 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20030224003710.O14037@kummer.juniper.net>, Kireeti Kompella writes: > Hi Curtis, > > On Tue, 18 Feb 2003, Curtis Villamizar wrote: > > > I think the SPs should speak as to whether the bandwidth inefficiency > > of 30 byte payloads or the potential to lose a packet with a 200 byte > > is a greater problem. > > Two questions (more probably to others than to you): > a) what is the relative bandwidth of voice? > (i.e., if voice accounts for <10% of a link's capacity, it > may not be worth worrying about even a 100% overhead); and > b) if a 30 byte voice packet got dropped, would you expect that > 6 other voice packets that were temporally close would escape > the hatchet? I.e., how big really is the penalty of a 200 byte > packet? > > Kireeti. I'm looking forward to seeing a review of the requirements doc. Actually not really. But it will be more sane than the current requirements moving target. Curtis From owner-mpls@UU.NET Mon Feb 24 14:06:07 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22844 for ; Mon, 24 Feb 2003 14:06:06 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodls03600 for ; Mon, 24 Feb 2003 19:09:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodls02878; Mon, 24 Feb 2003 19:09:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQodls18940 for mpls-outgoing; Mon, 24 Feb 2003 19:09:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodls18911 for ; Mon, 24 Feb 2003 19:08:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodls24376 for ; Mon, 24 Feb 2003 19:08:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodls12073 for ; Mon, 24 Feb 2003 19:08:05 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodls12063 for ; Mon, 24 Feb 2003 19:08:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OJ82Nh029571 for ; Mon, 24 Feb 2003 14:08:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA02146 for ; Mon, 24 Feb 2003 14:08:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1OJ82U23535 for mpls@uu.net; Mon, 24 Feb 2003 14:08:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodls18646 for ; Mon, 24 Feb 2003 19:06:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodls13570 for ; Mon, 24 Feb 2003 19:04:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodls08748 for ; Mon, 24 Feb 2003 19:04:00 GMT Received: from rooster.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hen.cisco.com [64.102.19.198]) id QQodls08724 for ; Mon, 24 Feb 2003 19:03:59 GMT Received: from CPIGNATA-W2K.cisco.com (dhcp-64-102-51-204.cisco.com [64.102.51.204]) by rooster.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h1OJ3w012900; Mon, 24 Feb 2003 14:03:58 -0500 (EST) Message-Id: <4.3.2.7.2.20030224121326.01e90df0@rooster> X-Sender: cpignata@rooster X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 14:03:57 -0500 To: mpls@UU.NET From: "Carlos M. Pignataro" Subject: Comments regarding draft-nadeau-mpls-lc-if-mib-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello, Please find below a couple of comments on the mplsLcAtmMIB: 1. Having an operational status for the Control VC would be useful, something like: mplsLcAtmCtrlVcOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), up(2), oamdown(3), lowerlayerdown(4), otherdown(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This is the operational status of the control VC". 2. It may also be useful to include ATM OAM F5 end-to-end cell generation/looping in the control VCs. Something along these lines: mplsLcAtmCtrlVcOamLoop {enable disable} /* Loop OAM F5 cells */ mplsLcAtmCtrlVcOamGenerate {enable disable} /* Generate OAM F5 cells */ mplsLcAtmCtrlVcOamFreq {INTEGER} /* OAM F5 cells frequency */ mplsLcAtmCtrlVcOamUpCnt {INTEGER} /* OAM F5 cells count to UP */ mplsLcAtmCtrlVcOamDnCnt {INTEGER} /* OAM F5 cells count to Down */ mplsLcAtmCtrlVcOamRetryFreq {INTEGER} /* OAM F5 cells retry frequency */ IMPORTS Integer32 FROM SNMPv2-SMI mplsLcAtmCtrlVcOamLoop OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If set to true(0), indicates that ATM OAM F5 end-to-end loopback cells arriving in the control VC will be looped back." DEFVAL { false } ::= { mplsLcAtmIfConfEntry X } mplsLcAtmCtrlVcOamGenerate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If set to true(0), indicates that ATM OAM F5 end-to-end loopback cells will be generated on the control VC, and control VC failures will be detected using this method." DEFVAL { false } ::= { mplsLcAtmIfConfEntry X } mplsLcAtmCtrlVcOamFreq OBJECT-TYPE SYNTAX Integer32 (0..600) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the time delay in seconds between transmitting oam loopback cells. This value is only meaningful if mplsLcAtmCtrlVcOamGenerate is set to true, and should be zero otherwise." DEFVAL { 0 } ::= { mplsLcAtmIfConfEntry X } mplsLcAtmCtrlVcOamUpCnt OBJECT-TYPE SYNTAX Integer32 (1..600) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the number of consecutive end-to-end F5 OAM loopback cell responses that must be received to change the control VC connection state to up. This value is only meaningful if mplsLcAtmCtrlVcOamGenerate is set to true." DEFVAL { 3 } ::= { mplsLcAtmIfConfEntry X } mplsLcAtmCtrlVcOamDnCnt OBJECT-TYPE SYNTAX Integer32 (1..600) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the number of consecutive end-to-end F5 OAM loopback cell responses that are not received to change the control VC connection state to down. This value is only meaningful if mplsLcAtmCtrlVcOamGenerate is set to true." DEFVAL { 5 } ::= { mplsLcAtmIfConfEntry X } mplsLcAtmCtrlVcOamRetryFreq OBJECT-TYPE SYNTAX Integer32 (1..1000) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the time delay in seconds between transmitting end-to-end F5 OAM loopback cells when a change in the up/down state of the control VC is being verified." This value is only meaningful if mplsLcAtmCtrlVcOamGenerate is set to true, and should be zero otherwise." DEFVAL { 1 } ::= { mplsLcAtmIfConfEntry X } 3. Since channel (VC) resources are scarce in LC-ATM, it may also be useful for operator to know the available number of virtual circuit resources on the LC-ATM, adding a mplsLcAtmAvailVc object. Regards, Carlos. ================================================================= | Carlos Pignataro - CCIE 4619 cisco Systems, Inc. | Escalation RTP | cpignata@cisco.com || || | +1 919 392 7428 - office .||. .||. | +1 919 345 3028 - mobile .||||. .||||. | +1 919 392 6470 - fax .:||||||||:.:||||||||:. | 7025 Kit Creek Road, PO Box 14987 Are you Ready ? | Research Triangle Park, NC 27709 ================================================================= From owner-mpls@UU.NET Mon Feb 24 15:38:36 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25785 for ; Mon, 24 Feb 2003 15:38:36 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodly19216 for ; Mon, 24 Feb 2003 20:42:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodly18183; Mon, 24 Feb 2003 20:41:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQodly15072 for mpls-outgoing; Mon, 24 Feb 2003 20:41:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodly15049 for ; Mon, 24 Feb 2003 20:41:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodly00066 for ; Mon, 24 Feb 2003 20:41:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodly17637 for ; Mon, 24 Feb 2003 20:41:05 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodly17624 for ; Mon, 24 Feb 2003 20:41:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OKf2Nh005381 for ; Mon, 24 Feb 2003 15:41:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA11611 for ; Mon, 24 Feb 2003 15:41:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1OKf1L29638 for mpls@uu.net; Mon, 24 Feb 2003 15:41:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodly14839 for ; Mon, 24 Feb 2003 20:39:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodly01670 for ; Mon, 24 Feb 2003 20:39:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodly16376 for ; Mon, 24 Feb 2003 20:39:08 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodly16366 for ; Mon, 24 Feb 2003 20:39:07 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OKd5Nh005245 for ; Mon, 24 Feb 2003 15:39:06 -0500 (EST) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA11428 for ; Mon, 24 Feb 2003 15:39:05 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA14373 for ; Mon, 24 Feb 2003 15:39:05 -0500 (EST) Message-Id: <200302242039.PAA14373@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: MPLS Agenda items Date: Mon, 24 Feb 2003 15:39:05 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk A number of you have already submitted agenda items. If you want time and have not, please do so by Thursday. Thanks, ///George ====================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Feb 24 19:03:25 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00829 for ; Mon, 24 Feb 2003 19:03:25 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm28656 for ; Tue, 25 Feb 2003 00:07:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodmm27984; Tue, 25 Feb 2003 00:06:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQodmm12796 for mpls-outgoing; Tue, 25 Feb 2003 00:06:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodmm12786 for ; Tue, 25 Feb 2003 00:06:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodmm25259 for ; Tue, 25 Feb 2003 00:06:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm27413 for ; Tue, 25 Feb 2003 00:06:05 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodmm27395 for ; Tue, 25 Feb 2003 00:06:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1P061JR022863 for ; Mon, 24 Feb 2003 19:06:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27346 for ; Mon, 24 Feb 2003 19:06:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1P061H12187 for mpls@uu.net; Mon, 24 Feb 2003 19:06:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodmm12238 for ; Tue, 25 Feb 2003 00:04:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodmm20146 for ; Tue, 25 Feb 2003 00:04:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm26146 for ; Tue, 25 Feb 2003 00:04:21 GMT Received: from halt-in.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: halt-in.cisco.com [171.70.144.185]) id QQodmm26121 for ; Tue, 25 Feb 2003 00:04:20 GMT Received: from cisco.com (144.254.74.60) by halt-in.cisco.com with ESMTP; 24 Feb 2003 16:04:20 -0800 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1P02agB009563; Tue, 25 Feb 2003 01:02:36 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn1-343.cisco.com [10.21.97.87]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA14344; Tue, 25 Feb 2003 01:04:11 +0100 (MET) Message-Id: <4.3.2.7.2.20030224114132.03b7d790@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 11:51:17 -0500 To: curtis@fictitious.org From: Jean Philippe Vasseur Subject: Re: draft-meyer-mpls-soft-preemption-00.txt Cc: Matthew Meyer , mpls@UU.NET In-Reply-To: <200302181928.OAA72985@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_133986312==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_133986312==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Curtis, At 14:28 18/02/2003 -0500, Curtis Villamizar wrote: >In message <20030218001433.GS10825@gblx.net>, Matthew Meyer writes: > > Folks, > > > > There have been some off line conversations showing interest > > regarding this draft. Would anyone be willing to comment on- > > list? > > > > Matthew > > > >As one of the offliners I'd like to say that this is much needed. >Every ISP that we talk to regards preemption as a hole in the MPLS >protocols that if utilized renders make-before-break and fast-reroute >ineffective. Soft preemption fixes that. > >I also support using the RRO as described in the draft. It is the >best way to accomplish soft preemption. It is saying exactly what is >happenning, namely that the LSP is still up but it is about to go >down so do something top avoid having bits dropped. Thanks for your feed-back >The one thing I would add is some object or bit somewhere that >indicates that the ingress is capable of understanding and acting on >the "Preemption pending" bit. If the midpoint where the preemption >occurs knows that the ingress is capable of dealing with the >"Preemption pending" bit, it can do a soft preemption. If not, then >the midpoint might as well do a hard preemption, because the older >ingress does not understand the "Preemption pending" bit and will >ignore it. Right, but see, we added the "soft preempted desired" that solves this issue: 4.1. SESSION-ATTRIBUTES Flags To explicitly signal the desire for a TE LSP to benefit from the soft preemption mechanism (and so not to be 'hard' preempted), the following new flag of the SESSION-ATTRIBUTE object (for both the C-Type 1 and 7) is defined: Soft preempted desired: 0x40 This allows to limit the overbooking ratio since the mid-point preempting node will only soft preempt the TE LSP having this bit set. This way, soft preempted TE LSPs will be limited to TE LSPs originated by HE which are compliant with this draft and that do explicitly require soft preemption. >Non-broken midpoint LSRs already have to pass on changes to the "Local >protection available" and "Local protection in use" bits back to the >ingress. Non-broken ingress LSRs already have to (or should) act upon >changes to the "Local protection available" and "Local protection in >use" bits. Adding a "Preemption pending" bit to the same bitmask >poses no additional scaling issues for existing non-broken routers. Right >There might be some partially broken implementations that currently >don't look at "RRO IPv4/IPv6 Sub-Object Flags" and don't pass along >changes to it or act on it but they have to be fixed to support >existing fast-reroute related capabilities. Correct. Thanks. JP. >Curtis --=====================_133986312==_.ALT Content-Type: text/html; charset="us-ascii" Hi Curtis,

At 14:28 18/02/2003 -0500, Curtis Villamizar wrote:

In message <20030218001433.GS10825@gblx.net>, Matthew Meyer writes:
> Folks,
>
> There have been some off line conversations showing interest
> regarding this draft.  Would anyone be willing to comment on-
> list?
>
> Matthew



As one of the offliners I'd like to say that this is much needed.
Every ISP that we talk to regards preemption as a hole in the MPLS
protocols that if utilized renders make-before-break and fast-reroute
ineffective.  Soft preemption fixes that.

I also support using the RRO as described in the draft.  It is the
best way to accomplish soft preemption.  It is saying exactly what is
happenning, namely that the LSP is still up but it is about to go
down so do something top avoid having bits dropped.

Thanks for your feed-back

The one thing I would add is some object or bit somewhere that
indicates that the ingress is capable of understanding and acting on
the "Preemption pending" bit.  If the midpoint where the preemption
occurs knows that the ingress is capable of dealing with the
"Preemption pending" bit, it can do a soft preemption.  If not, then
the midpoint might as well do a hard preemption, because the older
ingress does not understand the "Preemption pending" bit and will
ignore it.

Right, but see, we added the "soft preempted desired" that solves this issue:

4.1. SESSION-ATTRIBUTES Flags
 
To explicitly signal the desire for a TE LSP to benefit from the soft
preemption mechanism (and so not to be 'hard' preempted), the following
new flag of the SESSION-ATTRIBUTE object (for both the C-Type 1 and 7)
is defined:
               
Soft preempted desired:  0x40 

This allows to limit the overbooking ratio since the mid-point preempting node will only soft preempt the TE LSP having this bit set.

This way, soft preempted TE LSPs will be limited to TE LSPs originated by HE which are compliant with this draft and that do explicitly require soft preemption.

Non-broken midpoint LSRs already have to pass on changes to the "Local
protection available" and "Local protection in use" bits back to the
ingress.  Non-broken ingress LSRs already have to (or should) act upon
changes to the "Local protection available" and "Local protection in
use" bits.  Adding a "Preemption pending" bit to the same bitmask
poses no additional scaling issues for existing non-broken routers.

Right

There might be some partially broken implementations that currently
don't look at "RRO IPv4/IPv6 Sub-Object Flags" and don't pass along
changes to it or act on it but they have to be fixed to support
existing fast-reroute related capabilities.

Correct.

Thanks.

JP.

Curtis
--=====================_133986312==_.ALT-- From owner-mpls@UU.NET Mon Feb 24 19:03:38 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00843 for ; Mon, 24 Feb 2003 19:03:38 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm13301 for ; Tue, 25 Feb 2003 00:07:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodmm12295; Tue, 25 Feb 2003 00:06:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQodmm12791 for mpls-outgoing; Tue, 25 Feb 2003 00:06:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodmm12785 for ; Tue, 25 Feb 2003 00:06:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodmm25324 for ; Tue, 25 Feb 2003 00:06:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm15365 for ; Tue, 25 Feb 2003 00:06:06 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodmm15336 for ; Tue, 25 Feb 2003 00:06:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1P062Nh016316 for ; Mon, 24 Feb 2003 19:06:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27350 for ; Mon, 24 Feb 2003 19:06:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1P061S12198 for mpls@uu.net; Mon, 24 Feb 2003 19:06:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodmm12204 for ; Tue, 25 Feb 2003 00:04:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodmm20155 for ; Tue, 25 Feb 2003 00:04:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm26148 for ; Tue, 25 Feb 2003 00:04:21 GMT Received: from halt-in.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: halt-in.cisco.com [171.70.144.185]) id QQodmm26131 for ; Tue, 25 Feb 2003 00:04:20 GMT Received: from cisco.com (144.254.74.60) by halt-in.cisco.com with ESMTP; 24 Feb 2003 16:04:23 -0800 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1P02emi009569; Tue, 25 Feb 2003 01:02:40 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn1-343.cisco.com [10.21.97.87]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA14347; Tue, 25 Feb 2003 01:04:14 +0100 (MET) Message-Id: <4.3.2.7.2.20030224121332.03b9da78@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 12:14:08 -0500 To: curtis@fictitious.org From: Jean Philippe Vasseur Subject: Re: draft-meyer-mpls-soft-preemption-00.txt Cc: Ina Minei , Curtis Villamizar , "Nguyen, An" , "'Jim Boyle '" , "'Matthew Meyer '" , "'mpls@UU.NET '" In-Reply-To: <200302201946.OAA89030@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 14:46 20/02/2003 -0500, Curtis Villamizar wrote: >In message <20030220101031.J43335@garnet.juniper.net>, Ina Minei writes: > > > > > > > > As a practical matter, I don't think there would be other traffic that > > > would be preempting "authorized emergency preparedness" traffic for > > > Federal, state, and local. > > > > Agreed. However, think of the scenario where you want to move away > > traffic from particular links for a maintenance window. In that case, even > > this high priority LSP would have to be preempted. > > > > Ina > > >That's make-before-break rerouting. If you do it right, increase >metric, reset LSPs if reroute timers are long or set an admin-color >and set exclude-admin-color on the LSPs (just leave them set that >way). You can name the admin-color "maintenance". No preemption >occurs. The LSPs just voluntarily move off the link, then you shut >the idle link down. Requires that your routers do make-before-break >correctly and that your operational staff is sufficiently clued in. Agreed. JP. >Curtis From owner-mpls@UU.NET Mon Feb 24 19:09:18 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00995 for ; Mon, 24 Feb 2003 19:09:17 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm23990 for ; Tue, 25 Feb 2003 00:13:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodmm22568; Tue, 25 Feb 2003 00:12:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQodmm14353 for mpls-outgoing; Tue, 25 Feb 2003 00:11:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodmm14328 for ; Tue, 25 Feb 2003 00:11:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodmm07719 for ; Tue, 25 Feb 2003 00:11:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm28364 for ; Tue, 25 Feb 2003 00:07:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodmm28343 for ; Tue, 25 Feb 2003 00:07:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1P072JR022892 for ; Mon, 24 Feb 2003 19:07:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27413 for ; Mon, 24 Feb 2003 19:07:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1P072Y12245 for mpls@uu.net; Mon, 24 Feb 2003 19:07:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodmm12501 for ; Tue, 25 Feb 2003 00:05:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodmm16780 for ; Tue, 25 Feb 2003 00:04:59 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm10879 for ; Tue, 25 Feb 2003 00:04:59 GMT Received: from halt-in.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: halt-in.cisco.com [171.70.144.185]) id QQodmm10869 for ; Tue, 25 Feb 2003 00:04:58 GMT Received: from cisco.com (144.254.74.60) by halt-in.cisco.com with ESMTP; 24 Feb 2003 16:05:02 -0800 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1P03ISW009695; Tue, 25 Feb 2003 01:03:19 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn1-343.cisco.com [10.21.97.87]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA14428; Tue, 25 Feb 2003 01:04:54 +0100 (MET) Message-Id: <4.3.2.7.2.20030224115339.039830f8@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 12:24:29 -0500 To: Jim Boyle From: Jean Philippe Vasseur Subject: Re: draft-meyer-mpls-soft-preemption-00.txt Cc: Matthew Meyer , mpls@UU.NET In-Reply-To: References: <20030219082128.GG7943@gblx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Jim, At 14:46 19/02/2003 -0500, Jim Boyle wrote: >First, great draft - I like this concept. > >While a flag might be just the right thing for this particular >application, I wonder if it might be good to try to broaden >soft preemption technique to include other polite preemptions. > >These might include the following indicators > >o) your LSP is being prempted on the indicated link (draft covers) >o) your LSP should be rerouted, this node is shutting down >o) your LSP should be rerouted, this link is being taken out of > service >o) your LSP should be rerouted away from this node (administrative/CLI) >o) your LSP should be rerouted away from this link (administrative/CLI) Well one can generate exactly the same sequence of event, setting up the RRO Preemption pending flag (of course, that does not provide the preemption root cause to the HE). By the way, there are a bunch of existing alternatives to handle those scenarios: (1) Just flood an IGP LSA/LSP update: - with the link down for link maintenance, - with MAXAGE LSA (OSPF) or OL bit set (ISIS) for node maintenance (2) increase the TE metric to MAX (3) use affinities and make sure the HE LSR treat those events in a non disruptive fashion with a make before break. >You can somewhat do some of these by changing metrics and waiting, but >just was wondering if something more general might be useful. > >Also, with Diffserv TE, not sure that one can assume that a preemption >necessarily "implies exhausted bandwidth at the affected priority >level *and greater*" (section 5), but local implementations can do >as they please I suppose. Right. JP. >regards, > >Jim From owner-mpls@UU.NET Mon Feb 24 23:25:40 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05775 for ; Mon, 24 Feb 2003 23:25:40 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodmm23125; Tue, 25 Feb 2003 00:10:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQodmm13182 for mpls-outgoing; Tue, 25 Feb 2003 00:09:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodmm13060 for ; Tue, 25 Feb 2003 00:08:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodmm26316 for ; Tue, 25 Feb 2003 00:08:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm18262 for ; Tue, 25 Feb 2003 00:08:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodmm18240 for ; Tue, 25 Feb 2003 00:08:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1P082JR022917 for ; Mon, 24 Feb 2003 19:08:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27464 for ; Mon, 24 Feb 2003 19:08:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1P082U12290 for mpls@uu.net; Mon, 24 Feb 2003 19:08:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodmm12708 for ; Tue, 25 Feb 2003 00:06:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodmm22953 for ; Tue, 25 Feb 2003 00:05:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodmm14519 for ; Tue, 25 Feb 2003 00:05:18 GMT Received: from halt-in.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: halt-in.cisco.com [171.70.144.185]) id QQodmm14508 for ; Tue, 25 Feb 2003 00:05:17 GMT Received: from cisco.com (144.254.74.60) by halt-in.cisco.com with ESMTP; 24 Feb 2003 16:05:21 -0800 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1P03blc009739; Tue, 25 Feb 2003 01:03:37 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn1-343.cisco.com [10.21.97.87]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA14479; Tue, 25 Feb 2003 01:05:12 +0100 (MET) Message-Id: <4.3.2.7.2.20030224120104.03ba08e0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 12:08:18 -0500 To: "Nguyen, An" From: Jean Philippe Vasseur Subject: RE: draft-meyer-mpls-soft-preemption-00.txt Cc: "'Curtis Villamizar '" , "'Jim Boyle '" , "'Matthew Meyer '" , "'mpls@UU.NET '" In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D02EF4D2F@emshqs1.ncr.disa. mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 20:00 19/02/2003 -0500, Nguyen, An wrote: >Hi all, > >The draft is interesting. Thanks. >I wonder if this concept can be implemented to >transport critial traffic for customers in the MPLS network. Well I'm not sure to exactly see your point here but yes you could see this bit as a new TE LSP properties: the fact that the TE LSP could be soft preempted as opposed to hard preempted with the current existing scheme. For instance, a TE LSP carrying critical traffic could have the following properties: Local protection desired: 0x01 Bandwidth protection desired: 0x08 Node protection desired: 0x10 Soft preempted desired: 0x40 JP. >Thanks, > >An Nguyen > >-----Original Message----- >From: Curtis Villamizar >To: Jim Boyle >Cc: Matthew Meyer; mpls@UU.NET >Sent: 2/19/03 4:39 PM >Subject: Re: draft-meyer-mpls-soft-preemption-00.txt > > >In message , Jim >Boyle >writes: > > > > First, great draft - I like this concept. > > > > While a flag might be just the right thing for this particular > > application, I wonder if it might be good to try to broaden > > soft preemption technique to include other polite preemptions. > > > > These might include the following indicators > > > > o) your LSP is being prempted on the indicated link (draft covers) > > o) your LSP should be rerouted, this node is shutting down > > o) your LSP should be rerouted, this link is being taken out of > > service > > o) your LSP should be rerouted away from this node >(administrative/CLI) > > o) your LSP should be rerouted away from this link >(administrative/CLI) > > > > You can somewhat do some of these by changing metrics and waiting, but > > just was wondering if something more general might be useful. > >Why couldn't you just use the same bit and allow soft preemption on >link shut, reload, CLI adminstrative without encoding the reason? >Since these are all CLI initiated, it wouldn't hurt to delay. >Alternately, the soft preempt on anything using a specific resource >could be done. > >Link bundle lost a member might also qualify as a reason for soft >preemption for implementations of link bundling that can trasnparently >more flows to other members of the bundle. > > > Also, with Diffserv TE, not sure that one can assume that a preemption > > necessarily "implies exhausted bandwidth at the affected priority > > level *and greater*" (section 5), but local implementations can do > > as they please I suppose. > >Agreed. The "and greater" should be dropped. > > > regards, > > > > Jim > >Thanks, > >Curtis From owner-mpls@UU.NET Tue Feb 25 06:55:40 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25501 for ; Tue, 25 Feb 2003 06:55:40 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodoh24137 for ; Tue, 25 Feb 2003 11:52:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodoh23803; Tue, 25 Feb 2003 11:52:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQodoh29023 for mpls-outgoing; Tue, 25 Feb 2003 11:51:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodoh29018 for ; Tue, 25 Feb 2003 11:51:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodoh16467 for ; Tue, 25 Feb 2003 11:51:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodoh27297 for ; Tue, 25 Feb 2003 11:51:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodoh27289 for ; Tue, 25 Feb 2003 11:51:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1PBp2JR010179 for ; Tue, 25 Feb 2003 06:51:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA28980 for ; Tue, 25 Feb 2003 06:51:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1PBp2g24267 for mpls@uu.net; Tue, 25 Feb 2003 06:51:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodoh28827 for ; Tue, 25 Feb 2003 11:49:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodoh00418 for ; Tue, 25 Feb 2003 11:49:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodoh20069 for ; Tue, 25 Feb 2003 11:49:33 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQodoh19727 for ; Tue, 25 Feb 2003 11:49:03 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24677; Tue, 25 Feb 2003 06:45:08 -0500 (EST) Message-Id: <200302251145.GAA24677@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-00.txt Date: Tue, 25 Feb 2003 06:45:08 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for End-to-End VoIP Header Compression Author(s) : J. Ash et al. Filename : draft-ash-e2e-voip-hdr-comp-rqmts-00.txt Pages : 0 Date : 2003-2-24 VoIP typically uses the encapsulation voice/RTP/UDP/IP/. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes. VoIP header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). This draft gives a problem statement and requirements for end-to-end VoIP header compression, possibly over MPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-e2e-voip-hdr-comp-rqmts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-24142323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-e2e-voip-hdr-comp-rqmts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-24142323.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Feb 25 13:33:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09870 for ; Tue, 25 Feb 2003 13:33:55 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodpi21445 for ; Tue, 25 Feb 2003 18:37:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodpi20933; Tue, 25 Feb 2003 18:37:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQodpi07795 for mpls-outgoing; Tue, 25 Feb 2003 18:37:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodpi07790 for ; Tue, 25 Feb 2003 18:36:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodpi27008 for ; Tue, 25 Feb 2003 18:36:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodpi19059 for ; Tue, 25 Feb 2003 18:36:06 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodpi19048 for ; Tue, 25 Feb 2003 18:36:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1PIa2Nh022139 for ; Tue, 25 Feb 2003 13:36:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA01249 for ; Tue, 25 Feb 2003 13:36:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1PIa2Q15275 for mpls@uu.net; Tue, 25 Feb 2003 13:36:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodpi07541 for ; Tue, 25 Feb 2003 18:34:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodpi14266 for ; Tue, 25 Feb 2003 18:33:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodpi17831 for ; Tue, 25 Feb 2003 18:33:23 GMT Received: from halt-in.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: halt-in.cisco.com [171.70.144.185]) id QQodpi17817 for ; Tue, 25 Feb 2003 18:33:22 GMT Received: from cisco.com (144.254.74.60) by halt-in.cisco.com with ESMTP; 25 Feb 2003 10:33:14 -0800 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1PIVghM018989; Tue, 25 Feb 2003 19:31:42 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com (sjc-vpn3-23.cisco.com [10.21.64.23]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA04256; Tue, 25 Feb 2003 19:33:18 +0100 (MET) Message-Id: <4.3.2.7.2.20030225132521.03b74a58@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Feb 2003 13:33:16 -0500 To: mpls@UU.NET From: Jean Philippe Vasseur Subject: FYI: http://www.ietf.org/internet-drafts/draft-vasseur-mpls-nodeid-subobject -00.txt Cc: zali@cisco.com, Siva Sivabalan , raymond_Zhang@infonet.com, te-wg@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, Just to let you know that we recently published http://www.ietf.org/internet-drafts/draft-vasseur-mpls-nodeid-subobject-00.txt. This draft just defines a very simple extension (basically a new flag in the IPv4 /IPv6 RRO sub-object) that allows to use MPLS TE Fast Reroute to protect against the link/node failure in the context of inter-area and inter-AS TE. Regarding inter-AS TE, this was clearly a requirement as per draft-zhang-mpls-interas-te-req, so I cc the TE WG here. Any comment is as usual very welcome. Thanks. JP. From owner-mpls@UU.NET Tue Feb 25 15:50:53 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15505 for ; Tue, 25 Feb 2003 15:50:53 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodpr08311 for ; Tue, 25 Feb 2003 20:54:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodpr07779; Tue, 25 Feb 2003 20:54:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQodpr25402 for mpls-outgoing; Tue, 25 Feb 2003 20:54:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodpr25397 for ; Tue, 25 Feb 2003 20:54:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodpr05375 for ; Tue, 25 Feb 2003 20:53:38 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodpr06673 for ; Tue, 25 Feb 2003 20:53:36 GMT Received: from almso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQodpr06661 for ; Tue, 25 Feb 2003 20:53:35 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1PKUXYO026585 for ; Tue, 25 Feb 2003 15:53:26 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.032) id 3E58FF2800142E15; Tue, 25 Feb 2003 15:52:56 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: E2E VoIP Header Compression Date: Tue, 25 Feb 2003 15:52:59 -0500 Message-ID: <28F05913385EAC43AF019413F674A01704CB8756@OCCLUST04EVS1.ugd.att.com> Thread-Topic: E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-EndMPLS Thread-Index: AcLba9wgUtozpqzXTHeXnorCmb0y5gBoyWOw From: "Ash, Gerald R (Jerry), ALABS" To: "Loa Andersson" , "GOODE, B (Bur), ALABS" Cc: "Ash, Gerald R (Jerry), ALABS" , "Jim Hand" , "raymond zhang" , "MPLS@UU.net" , "George Swallow" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA15505 Bur> a requirements document has been submitted. Loa> Great :) I've not seen that one yet, but will be looking for Loa> it as it comes through the ID publishing process. It just got published at http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-00.txt. Comments welcome. Thanks, Jerry Ash From owner-mpls@UU.NET Tue Feb 25 18:18:10 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21964 for ; Tue, 25 Feb 2003 18:18:09 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodqb23461 for ; Tue, 25 Feb 2003 23:22:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodqb22599; Tue, 25 Feb 2003 23:21:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQodqb01872 for mpls-outgoing; Tue, 25 Feb 2003 23:21:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodqb01867 for ; Tue, 25 Feb 2003 23:21:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodqb18532 for ; Tue, 25 Feb 2003 23:20:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodqb19191 for ; Tue, 25 Feb 2003 23:19:59 GMT Received: from kcmso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQodqb19173 for ; Tue, 25 Feb 2003 23:19:58 GMT Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1PNGtWU027411 for ; Tue, 25 Feb 2003 17:19:58 -0600 (CST) Received: from OCCLUST02EVS1.ugd.att.com (135.71.164.8) by attrh1i.attrh.att.com (6.5.019) id 3E54F1550007FDEF; Tue, 25 Feb 2003 18:19:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Tue, 25 Feb 2003 18:19:55 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA612@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLUIZxSKbwl+0r0RAiQ4XSYlRZL4QJAJQkA From: "Brungard, Deborah A, ALABS" To: , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA21964 Loa, (I included ccamp as I was not sure everyone is on the mpls list) The draft does not include any reference to liaisons (inputs from other standards groups). Will there be a separate process for liaisons or this draft will be extended to include? It would be useful (especially for other standards groups) to have clarification on how liaisons are input to a WG, generation of responses, and process required to coordinate work/initiate work within a working group in relation to other standards groups. On section 2.2.2 problem statement review, and in other steps where decisions are taken, it would help to clarify if say that the decision (e.g., 'no action') plus the basis for the decision be posted to the Area/WG mailing list within a specified time period. Thanks, Deborah -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, February 14, 2003 6:44 AM Subject: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS and GMPLS Change Process Author(s) : L. Andersson Filename : draft-andersson-mpls-g-chng-proc-00.txt Pages : 11 Date : 2003-2-13 This memo describes the process through which individuals, working groups and external standards bodies can influence the development of MPLS and GMPLS standards. With respect to standardization, this process means that (G)MPLS extensions and changes can be done through the IETF only, the body that created the (G)MPLS technology. The IETF will not publish a (G)MPLS technology extension RFC outside of the processes described here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-andersson-mpls-g-chng-proc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-mpls@UU.NET Tue Feb 25 18:37:22 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22476 for ; Tue, 25 Feb 2003 18:37:22 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodqc08413 for ; Tue, 25 Feb 2003 23:41:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodqc07344; Tue, 25 Feb 2003 23:40:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQodqc02925 for mpls-outgoing; Tue, 25 Feb 2003 23:40:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodqc02918 for ; Tue, 25 Feb 2003 23:40:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodqc15744 for ; Tue, 25 Feb 2003 23:39:29 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodqc06044 for ; Tue, 25 Feb 2003 23:39:28 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQodqc06021 for ; Tue, 25 Feb 2003 23:39:27 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1PNdQS20982; Tue, 25 Feb 2003 15:39:26 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h1PNdQD22332; Tue, 25 Feb 2003 15:39:26 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 25 Feb 2003 15:39:26 -0800 (PST) From: Kireeti Kompella To: "Brungard, Deborah A, ALABS" cc: mpls@UU.NET, "" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-Reply-To: <2FEC2C81634CDB4C9F191943ACCDC624079AA612@OCCLUST02EVS1.ugd.att.com> Message-ID: <20030225153004.J22280@kummer.juniper.net> References: <2FEC2C81634CDB4C9F191943ACCDC624079AA612@OCCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Deborah, On Tue, 25 Feb 2003, Brungard, Deborah A, ALABS wrote: > The draft does not include any reference to liaisons (inputs from other > standards groups). Will there be a separate process for liaisons or > this draft will be extended to include? It would be useful (especially > for other standards groups) to have clarification on how liaisons are > input to a WG, generation of responses, and process required to > coordinate work/initiate work within a working group in relation to > other standards groups. Good point. CCAMP has received liaison statements in the past and we haven't really responded to them -- in fact, I am not even sure that there is a written process to handle liaison statements, nor a well defined return channel. Since this draft is about writing down processes, we should (a) figure out how liaisons are handled; and (b) write that down as well. Ron and I will have a pow-wow with the ADs and figure this out. > On section 2.2.2 problem statement review, and in other steps where > decisions are taken, it would help to clarify if say that the decision > (e.g., 'no action') plus the basis for the decision be posted to the > Area/WG mailing list within a specified time period. Another good idea -- in line with the "new IETF with better visibility and accountability" thrust. Kireeti. From owner-mpls@UU.NET Tue Feb 25 19:52:52 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23675 for ; Tue, 25 Feb 2003 19:52:52 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodqh24259 for ; Wed, 26 Feb 2003 00:56:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodqh23686; Wed, 26 Feb 2003 00:56:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQodqh27367 for mpls-outgoing; Wed, 26 Feb 2003 00:56:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodqh27355 for ; Wed, 26 Feb 2003 00:56:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodqh20816 for ; Wed, 26 Feb 2003 00:55:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodqh22632 for ; Wed, 26 Feb 2003 00:55:40 GMT Received: from mailf.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailf.telia.com [194.22.194.25]) id QQodqh22619 for ; Wed, 26 Feb 2003 00:55:39 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailf.telia.com (8.12.5/8.12.5) with ESMTP id h1Q0tZ9m005667; Wed, 26 Feb 2003 01:55:35 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h70n2fls31o888.telia.com [213.64.120.70]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1Q0tZ216249; Wed, 26 Feb 2003 01:55:35 +0100 (CET) Message-ID: <3E5C0F82.1010504@pi.se> Date: Wed, 26 Feb 2003 01:51:14 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <2FEC2C81634CDB4C9F191943ACCDC624079AA612@OCCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Deborah, the non-mentioning of the liasions are quite intentionally, since we thought that the liasion process is quite well described, understood and used. Later communications have brought to our attention that this assumption is not entirely true. However, my take is that the liasions and the change-process address two orthogonal issues. The liasion addreses how information is exchanged between IETF and other organisations, this could be anything from general info on latest development to specifics that one of the organisations sees as useful for the other to be aware of. It is below my current horizon if the liasion process needs to be defined in more detail and in a draft ov its own, I guess I* in general and Harald in particular could have a view on this. The change-process on the other hand addresses a specific issue, how propsed new work for the (g)mpls technology is accepted or rejected. This is something I feel more comfortable to discuss than the IETF realtionships to other organisations. In my mind there is no overlap between those two processes, the change process in no way changes or affects the liasions, and the liasions is not the format to bring new work into the IETF (in this case the (g)mpls) working groups. IETF working groups work with Internet Drafts, either individual drafts or working group drafts. I'm not entirely clear on if something that leaves one organisation as a liasion could be received by the IETF as an Internet Draft, all other things equal. However once it reaches the IETF, it will become an ID and published as such. In the other direction I think it is clear if IETF or one of its working groups want to communicate with another organisation, we will have to go through the liasion process, that involves some approval on the iesg level. We do this out of respect for how those organisations has told us they want this type of communication to be handled and what format to use. What we do in the change process, is basically that we give the same level of information on what is our process to accept/reject new work and specifies input format to that process, declare that as long as we get the input in that format we will in a timely fashion act on this input, and also ask others to respect how our processes work. I also agree on that if we can clarify and make more precise on how decisions are taken, documented and communicated, though we need to remember that everything that is a decision in this meaning will be taken by the iesg. Again I'm under the impression that there is a quite well understood and used way of taking, documenting and communicating iesg decision. You might be right that when it comes to wg chairs and ADs and the responsibility to communicate (iesg) decision relating to the working group in general and the people the made the proposal in particular, the change-process could very well state something. Hope this clarifies at least some of the issues! /Loa Brungard, Deborah A, ALABS wrote: >Loa, >(I included ccamp as I was not sure everyone is on the mpls list) > >The draft does not include any reference to liaisons (inputs from other standards groups). Will there be a separate process for liaisons or this draft will be extended to include? It would be useful (especially for other standards groups) to have clarification on how liaisons are input to a WG, generation of responses, and process required to coordinate work/initiate work within a working group in relation to other standards groups. > >On section 2.2.2 problem statement review, and in other steps where decisions are taken, it would help to clarify if say that the decision (e.g., 'no action') plus the basis for the decision be posted to the Area/WG mailing list within a specified time period. > >Thanks, >Deborah > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Friday, February 14, 2003 6:44 AM >Subject: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : MPLS and GMPLS Change Process > Author(s) : L. Andersson > Filename : draft-andersson-mpls-g-chng-proc-00.txt > Pages : 11 > Date : 2003-2-13 > >This memo describes the process through which individuals, working >groups and external standards bodies can influence the development of >MPLS and GMPLS standards. With respect to standardization, this >process means that (G)MPLS extensions and changes can be done through >the IETF only, the body that created the (G)MPLS technology. The >IETF will not publish a (G)MPLS technology extension RFC outside of >the processes described here. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-andersson-mpls-g-chng-proc-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > > From owner-mpls@UU.NET Wed Feb 26 08:28:40 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03692 for ; Wed, 26 Feb 2003 08:28:40 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsg18387 for ; Wed, 26 Feb 2003 13:32:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodsg17895; Wed, 26 Feb 2003 13:32:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQodsg18945 for mpls-outgoing; Wed, 26 Feb 2003 13:31:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodsg18938 for ; Wed, 26 Feb 2003 13:31:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodsf19476 for ; Wed, 26 Feb 2003 13:28:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsf17072 for ; Wed, 26 Feb 2003 13:28:44 GMT Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQodsf17052 for ; Wed, 26 Feb 2003 13:28:43 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.12.6/8.12.2) id h1Q9TI05002373; Wed, 26 Feb 2003 04:29:18 -0500 (EST) Date: Wed, 26 Feb 2003 04:29:18 -0500 (EST) From: Scott Bradner Message-Id: <200302260929.h1Q9TI05002373@newdev.harvard.edu> To: ccamp@ops.ietf.org, dbrungard@att.com, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-Reply-To: <2FEC2C81634CDB4C9F191943ACCDC624079AA612@OCCLUST02EVS1.ugd.att.com> Sender: owner-mpls@UU.NET Precedence: bulk this ID was brought up in a meeting I am at in the ITU - there is some concern about it - I have asked that people with concerns please send their concerns in. Scott From owner-mpls@UU.NET Wed Feb 26 08:28:58 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03719 for ; Wed, 26 Feb 2003 08:28:58 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsg24247 for ; Wed, 26 Feb 2003 13:32:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodsg23400; Wed, 26 Feb 2003 13:32:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQodsg18948 for mpls-outgoing; Wed, 26 Feb 2003 13:31:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodsg18939 for ; Wed, 26 Feb 2003 13:31:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodsf19496 for ; Wed, 26 Feb 2003 13:28:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsf17093 for ; Wed, 26 Feb 2003 13:28:45 GMT Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQodsf17075 for ; Wed, 26 Feb 2003 13:28:44 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.12.6/8.12.2) id h1Q9j9GB002436; Wed, 26 Feb 2003 04:45:09 -0500 (EST) Date: Wed, 26 Feb 2003 04:45:09 -0500 (EST) From: Scott Bradner Message-Id: <200302260945.h1Q9j9GB002436@newdev.harvard.edu> To: dbrungard@att.com, kireeti@juniper.net Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Cc: ccamp@ops.ietf.org, mpls@UU.NET In-Reply-To: <20030225153004.J22280@kummer.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk >.Good point. CCAMP has received liaison statements in the past and > we haven't really responded to them - this was pointed out to me (again) this week :-) we (the IETF) need to work out a reliable way to respond to liaison statements Scott From owner-mpls@UU.NET Wed Feb 26 08:42:17 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04075 for ; Wed, 26 Feb 2003 08:42:17 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsh21609 for ; Wed, 26 Feb 2003 13:46:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodsg16871; Wed, 26 Feb 2003 13:43:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQodsg19699 for mpls-outgoing; Wed, 26 Feb 2003 13:43:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodsg19691 for ; Wed, 26 Feb 2003 13:43:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodsg08138 for ; Wed, 26 Feb 2003 13:40:11 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsg03729 for ; Wed, 26 Feb 2003 13:40:10 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodsg03694 for ; Wed, 26 Feb 2003 13:40:09 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1QDe3Nh009496 for ; Wed, 26 Feb 2003 08:40:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA03730 for ; Wed, 26 Feb 2003 08:40:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1QDe3208465 for mpls@uu.net; Wed, 26 Feb 2003 08:40:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodqa01102 for ; Tue, 25 Feb 2003 23:12:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodqa09089 for ; Tue, 25 Feb 2003 23:11:11 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodqa09088 for ; Tue, 25 Feb 2003 23:11:11 GMT Received: from gamma.isi.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gamma.isi.edu [128.9.144.145]) id QQodqa09071 for ; Tue, 25 Feb 2003 23:11:10 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h1PNB3D23881; Tue, 25 Feb 2003 15:11:03 -0800 (PST) Message-Id: <200302252311.h1PNB3D23881@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3468 on The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols Cc: rfc-editor@rfc-editor.org, mpls@UU.NET From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 25 Feb 2003 15:11:03 -0800 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3468 Title: The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols Author(s): L. Andersson, G. Swallow Status: Informational Date: February 2003 Mailbox: loa@pi.se, swallow@cisco.com Pages: 11 Characters: 22072 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-andersson-mpls-sig-decision-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3468.txt This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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.echo 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030225150815.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3468 --OtherAccess Content-Type: Message/External-body; name="rfc3468.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030225150815.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Feb 26 08:43:10 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04091 for ; Wed, 26 Feb 2003 08:43:09 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsh13601 for ; Wed, 26 Feb 2003 13:47:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodsg04806; Wed, 26 Feb 2003 13:41:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQodsg19468 for mpls-outgoing; Wed, 26 Feb 2003 13:40:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodsg19461 for ; Wed, 26 Feb 2003 13:40:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodsg14445 for ; Wed, 26 Feb 2003 13:40:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsg03901 for ; Wed, 26 Feb 2003 13:40:18 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodsg03893 for ; Wed, 26 Feb 2003 13:40:18 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1QDeFNh009516 for ; Wed, 26 Feb 2003 08:40:15 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA03740 for ; Wed, 26 Feb 2003 08:40:15 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1QDeFm08514 for mpls@uu.net; Wed, 26 Feb 2003 08:40:15 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodqb01694 for ; Tue, 25 Feb 2003 23:20:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodqb04242 for ; Tue, 25 Feb 2003 23:19:56 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodqb19069 for ; Tue, 25 Feb 2003 23:19:55 GMT Received: from gamma.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gamma.isi.edu [128.9.144.145]) id QQodqb19037 for ; Tue, 25 Feb 2003 23:19:54 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h1PNJpD28453; Tue, 25 Feb 2003 15:19:51 -0800 (PST) Message-Id: <200302252319.h1PNJpD28453@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3480 on Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) Cc: rfc-editor@rfc-editor.org, mpls@UU.NET From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 25 Feb 2003 15:19:51 -0800 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3480 Title: Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) Author(s): K. Kompella, Y. Rekhter, A. Kullberg Status: Standards Track Date: February 2003 Mailbox: kireeti@juniper.net, yakov@juniper.net, akullber@netplane.com Pages: 8 Characters: 17076 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-crldp-unnum-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3480.txt Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. 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.echo 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030225151730.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3480 --OtherAccess Content-Type: Message/External-body; name="rfc3480.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030225151730.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Feb 26 08:59:11 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04606 for ; Wed, 26 Feb 2003 08:59:11 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsi13021 for ; Wed, 26 Feb 2003 14:02:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodsi10483; Wed, 26 Feb 2003 14:01:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQodsi25392 for mpls-outgoing; Wed, 26 Feb 2003 14:01:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodsi25174 for ; Wed, 26 Feb 2003 14:01:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodsi18896 for ; Wed, 26 Feb 2003 14:00:35 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsi27903 for ; Wed, 26 Feb 2003 14:00:34 GMT Received: from almso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQodsi27891 for ; Wed, 26 Feb 2003 14:00:34 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1QCGjkD023039 for ; Wed, 26 Feb 2003 09:00:33 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032) id 3E58FF28001B3190; Wed, 26 Feb 2003 09:00:03 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Wed, 26 Feb 2003 09:00:05 -0500 Message-ID: <28F05913385EAC43AF019413F674A01704A177CF@OCCLUST04EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLdei7OCiKqDIIjQ0SYJfNrsPJQbQAHvIog From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" , "Loa Andersson" , "Scott Bradner" , "Brungard, Deborah A, ALABS" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04606 Loa> Could you do me a favor and have a look at: Loa> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt Scott> this ID was brought up in a meeting I am at in the ITU - there Scott> is some concern about it - I have asked that people with Scott> concerns please send their concerns in. The requirements decision processes in the I-D should give some weight to the 'strength' of the requirements source and proponents. E.g., a concern was raised in a recent discussion on the iesg@ietf.org email-list "RE: Last Call: CR-LDP extensions for ASON to Informational", where GMPLS/ASON requirements were put forward by ITU-T, with many SPs as proponents, but did not get adequate attention or evaluation, and were perhaps even rejected out of hand. The unfortunate consequence of this outcome is that now 2 'GMPLS/ASON signaling' (RSVP-TE) standards have emerged, perhaps with interoperability issues. The decision steps in the I-D are quite vague, and it is unclear that these will do much to rectify this concern, e.g.: In Section 2.2.2 "The MPLS and CCAMP working group chairs in conjunction with the Area Directors will determine if the particular problems raised ... should be evaluated by a working group... based on the mailing list discussion." In Section 2.2.4 "The rewg will evaluate the problem statement ID and based on the evaluation make a recommendation to the IESG/IAB." Nothing is said as to criteria applied to the 'mailing list discussion' (could be dominated by one loud person with a particular view), or how the 'rewg will evaluate the problem statement'. The decision process appears to remain the status quo, i.e., 'rough consensus', wherein a small oligarchy of ADs, WG chairs, and perhaps a few SMEs appear to decide (especially problematic in 'no response' decision, as stated above). Additional teeth could put in place to give a more comprehensive review/decision process to overcome these identified problems, e.g.,: a. for certain categories of problem statements/requirements, put a 'design team' in place to evaluate/recommend a course of action. b. problem statements signed onto by a >threshold # of SPs/vendors could have such 'design team' evaluation. Jerry Ash From owner-mpls@UU.NET Wed Feb 26 10:44:18 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12635 for ; Wed, 26 Feb 2003 10:44:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsp25965 for ; Wed, 26 Feb 2003 15:48:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodsp25191; Wed, 26 Feb 2003 15:47:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQodsp06781 for mpls-outgoing; Wed, 26 Feb 2003 15:47:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodsp06776 for ; Wed, 26 Feb 2003 15:47:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodsp12618 for ; Wed, 26 Feb 2003 15:45:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodsp11048 for ; Wed, 26 Feb 2003 15:45:22 GMT Received: from sa.infonet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sa.infonet.com [192.157.130.21]) id QQodsp11040 for ; Wed, 26 Feb 2003 15:45:22 GMT Received: from delta.info.net (delta.info.net [192.237.125.34]) by sa.infonet.com with ESMTP id h1QFijsS018681; Wed, 26 Feb 2003 15:44:45 GMT Received: from zhangr2.info.net (lasi254.us.info.net [204.140.71.254]) by delta.info.net with ESMTP id PAA20770; Wed, 26 Feb 2003 15:44:37 GMT Message-Id: <5.1.0.14.0.20030225234030.02e23998@delta.info.net> X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Feb 2003 23:43:15 -0800 To: curtis@fictitious.org From: raymond zhang Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression Cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" , "MPLS@UU.net" , "George Swallow" , "Loa Andersson" , "GOODE, B (Bur), ALABS" , "Hand, James C, ALABS" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, Sorry for the delayed response... >I'm just trying to come up with something that will actually work. Surely, this is indeed the final objective and do very much appreciate your initiating a thread of discussions as engaging as this in helping to further clarify and bring focus on the nature of the issues/problems... A bit more comments in lines below. Regards, Raymond At 02:35 PM 2/20/2003 -0500, Curtis Villamizar wrote: >In message <5.1.0.14.0.20030220084042.02556418@delta.info.net>, raymond >zhang w >rites: > > Curtis, > > > > Thanks for the response and see some further comments in line... Based > > upon discussions we have thus far including your response to my > comments in > > response to Uzelac's email, maybe I should make some clarifications first > > which may help my understanding of your input as well in any further > > discussions: > > > > The environment in which I am referring to is a global IP/MPLS > packet-based > > network spanning all major and sub-continents where it is not always > > possible to get ample bandwidth (over-provisioning) economically (very > > expensive in fact)... The issues of delay or packet loss do not normally > > present problems at all as you pointed out, in some continental or > national > > networks of ISPs or SPs but to offer similar level of integrated services > > (voice/data) for customers with world-wide locations, it is in these > remote > > regions and over last mile local loops that we spend a bit more efforts on > > to optimize. > > > > On low speed local-loops (PE-CE links), IP/UDP/RTP compressions is > > needed. I think we both agree on that. As for PE doing the comp/depcomp, > > I'd like to hear a bit more from the Vendors... My experience has been > > that hardware based compression at PE levels on the edge of the network > > with large # of aggregating diffserve-enabled customer links presents > > complexity that may become unmanageable to SPs and with amount of edge > > features already processed through hardware, would adding > > compression/decompression be even feasible ? Besides, the upgrade > > path may be very costly for these line cards which maybe deployed in > large > > numbers across the global network as we add new feature sets/hardware > > capabilities. So I am not in favor of it as an option for PE level > > routers. Therefore the concept of distributing compression/decompression > > into CE levels, not in the network appeals in a great deal. If PE is not > > doing the comp/decomp, then the compressed path needs to be e2e... > > > > Further comments in lines .... > > > > Regards, > > Raymond > > >The applicability statement part of this is embedded in the draft >itself, rather than following a requirement document. There will be a requirements draft per Loa's suggestion and in fact it is already submitted. >You are citing PE-CE as the primary problem. Others have cited PE to >PE within the metro. > >If the problem is PE-CE, lets stick with that problem. The problems exist in both cases... >If PE-CE is the problem you are trying to solve, then RTP/UDP/IP/PPP >compression should do wonders. I agree with you entirely that the >current practical problem there is that the PE can't handle the >comp/depcomp at anywhere close to line rate on even relatively slow >interfaces. The PPS rate for these tinygrams is enormous. (Of course >making them bigger would help reduce the PPS rate in addition to >improving the encaps efficiency). > >At one packet per 30 msec, you have 30 pps. At 8kbit/s a T1 holds not >quite 200 of these if the PPP encaps was 4 bytes or less. Times 200 >calls you have 6000 pps. Nothing at all for a line card, but not many >of these will start to swamp a route processor if that is how the >comp/decomp is implemented. > >Putting the compression in the CE might on the onset sound appealing. >If you think you have problems with the PE handling the comp/decomp, >wait til you try to bring up a full mesh of LSPs to all the CE for >this sort of scale of global networks. No sense trading one practical >limitation for another of much more enormous magnitude. Well, thus far in our discussion, we have established that we need at least comp/dcomp over PE-CE link. Then we discussed the infeasibility of having PE to do comp/dcomp, upon which I come to that the other option would carrie compressed VoIP packets over the entire path across the network and do comp/decomp outside of the network, for example, at the CE or a large aggregation box ( in a voice access only environment and not part of the IGP plane of SP's network). But we would in this case be dealing with comp/decomp distributed throughout the network instead of being at the aggregating PEs. Namely, the amount of meshing may be much smaller at the CE level since they are customer specific. This would be further reduced since not every call occupies its unique virtual connection. Calls between the same pair of gateways may be aggregated onto the same e2e LSP if LSP is used as an e2e path. Then the meshing on the PE could be limited to a set of aggregating or hierarchical LSPs among much smaller # of PEs (comparing to # of connected CEs to all PEs) (also since not every customer has locations in every PoP around the world which may ease the aggregation load on the PE level LSPs)... So this is not a trade at the same scale. Nonetheless, as you pointed out, the scaling issues will worsen (may still be manageable depending the degree of the mesh) from provisioning to tunnel maintenance (setup/teardown due to link/interface events, e.g.) as number of customer sites increase. I wonder what your thoughts are on the other Ash draft (file:///D:/onnet-data/out/IPbackbone/ietf/avt/draft-ash-e2e-crtp-hdr-compress-00.txt) where LSP does not get extended down to the CE, instead RSVP-TE tunnels are built between PEs, yet PE may only spend the first cycle just to establish the context state and then do not spend cycles to do comp/decomp for subsequent ip/udp/rtp compressed packets ? >If there is a huge number of CE then at some point you'll have to >partition the network to make this continue to work. If so you might >get CE to some voice/VOIP aggregation box/gateway and have these >terminate the LSPs and do comp/decomp, then communicate among >themselves. This is likely to be a huge comp/decomp load. You can >concentrate the comp/decomp at some specialized processor or try to do >the processing on the line cards (which may mean new line cards). Could be an option but preferably not on the direct diffserve path into the network, in other words, placed behind the CEs, for example... >If a CE is supporting on the order of at least 100 (to 200 if encaps >efficiency can be improved), then muxing might be easier on the PE >router. For example, separating 300 pps of 600 byte packets is likely >to be a lot easier (even if 6000 pps are sent out) than compressing >and decompressing 6000pps and would add zero delay. Either way, >moving processing to the PE line card seems essential. >I'm just trying to come up with something that will actually work. > >Regards, > >Curtis > >ps - wrt queueing and serialization delay. 30bytes into a T1 incurs a >serialization delay of 240bits/1.5mbits or 0.16 msec. 200 bytes is 1 >msec serialization. If CE means customer handset then we're e2e MPLS >becomes completely absurd so I think it should be safe so assume at >least T1 and it not you get delay. With serialization times on the >order of 1 msec edge and these days under a microsecond in cores, the >queueing argument has never held water for priority queued traffic >that is not congested. > >That's a moot point for a single flow if you have to hold the playout >time for 200 msec to get 200 bytes packets because that is already an >excessive delay. For multiplexing, the argument against large packets >based on serialization and queueing simply doesn't hold up. > >We're not talking IP over barbed wire in the third world, right? Its >at least T1? Well, sub-T1/E1 are quite common as well... > > >Tiny payload is needed for queue efficiency is a myth left over from > > >the ATM days. It is simply not true. > > > > I think there are two aspects in this... Firstly traffic flows with > > constant packet size would improve queue efficiency (M/D/1) and smaller > > packet payload would reduce delay across low speed links (not an issue > once > > again in areas of network with large pipes since no or little qeueuing) > > which is required as part of the budge delay planning. The voice quality > > is provided on a per path basis not just over segments of the path inside > > SP's major portion of the backbone. ( I don't mean to spur another > around > > of discussions on ATM vs. IP at all ! I thought issues are well understood > > by now). From owner-mpls@UU.NET Wed Feb 26 15:53:16 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24740 for ; Wed, 26 Feb 2003 15:53:16 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodtj27245 for ; Wed, 26 Feb 2003 20:57:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodtj25781; Wed, 26 Feb 2003 20:56:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQodtj01030 for mpls-outgoing; Wed, 26 Feb 2003 20:56:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodtj01013 for ; Wed, 26 Feb 2003 20:56:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodtj28051 for ; Wed, 26 Feb 2003 20:55:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodtj14776 for ; Wed, 26 Feb 2003 20:55:06 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodtj14761 for ; Wed, 26 Feb 2003 20:55:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1QKt2JR027040 for ; Wed, 26 Feb 2003 15:55:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA11268 for ; Wed, 26 Feb 2003 15:55:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1QKt2C04506 for mpls@uu.net; Wed, 26 Feb 2003 15:55:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodtj00844 for ; Wed, 26 Feb 2003 20:53:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodtj25040 for ; Wed, 26 Feb 2003 20:53:19 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodtj18999 for ; Wed, 26 Feb 2003 20:53:18 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQodtj18981 for ; Wed, 26 Feb 2003 20:53:18 GMT Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1QKrG56003608; Wed, 26 Feb 2003 12:53:16 -0800 (PST) Received: from cisco.com (sjc-vpn1-561.cisco.com [10.21.98.49]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AEJ86811; Wed, 26 Feb 2003 12:36:39 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Wed, 26 Feb 2003 15:53:13 -0500 Date: Wed, 26 Feb 2003 15:53:13 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030226205313.GS2604@sbrim-w2k> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET References: <200302260945.h1Q9j9GB002436@newdev.harvard.edu> <3E5D0FFF.6040407@pi.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5D0FFF.6040407@pi.se> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Feb 26, 2003 08:05:35PM +0100, Loa Andersson allegedly wrote: > We need to document the (g)mpls-change process, most of this is in the > current draft. The concerns I've seen so far is on how and what could > be accepted as input to the process, that should be easily solvable. > > We need to doucment the ietf way of responding to liasions. > > It is my immediate reaction that this do not really belong in the same > document, if for no other reasons, at least for practical reasons. If > there is a strong motive to put them in the same document, I can live > with that. They don't. The change process is specific to a particular protocol group. Liaisons are an IETF-wide issue. I think if we want to send a liaison to another group, the AD just sends e-mail, and archives it on ietf.org. That's just an administrative matter, nothing we even need a draft for. Incoming liaisons take a little more policy but not much. We want them archived, so just saying "submit a draft" isn't good enough. I'm afraid we need to provide mailto:ietf-liaisons@ietf.org, and yet another folder on the web pages. All ADs get to hear about all incoming liaisons, and if they think it's appropriate for one of their WGs they forward it. Done? But this shouldn't be discussed on these lists anyway :-) From owner-mpls@UU.NET Wed Feb 26 17:19:09 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29379 for ; Wed, 26 Feb 2003 17:19:08 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodtp00237 for ; Wed, 26 Feb 2003 22:23:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodtp29375; Wed, 26 Feb 2003 22:22:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQodtp14782 for mpls-outgoing; Wed, 26 Feb 2003 22:22:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodtp14770 for ; Wed, 26 Feb 2003 22:21:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodtp27303 for ; Wed, 26 Feb 2003 22:21:39 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodtp17892 for ; Wed, 26 Feb 2003 22:21:38 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQodtp17883 for ; Wed, 26 Feb 2003 22:21:38 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1QMLak18807; Wed, 26 Feb 2003 17:21:36 -0500 (EST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [192.11.157.209]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA19961; Wed, 26 Feb 2003 16:21:33 -0600 (CST) Message-ID: <3E5D3DE6.FB77D6B8@lucent.com> Date: Wed, 26 Feb 2003 15:21:26 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <200302260945.h1Q9j9GB002436@newdev.harvard.edu> <3E5D0FFF.6040407@pi.se> <20030226205313.GS2604@sbrim-w2k> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, draft-andersson-mpls-g-chng-proc-00.txt seems to be addressed at a noble goal of bringing some order to new applications and extensions of the (G)MPLS protocols. However, as Deborah, Kireeti, and Scott have observed, the way it is written it seems to hinder rather than help the process of collaborating with other Standards Developement Organizations(SDOs) and doesn't provide a good way to deal with and respond to liaison statements, which is the avenue by which many of these requests will arrive from other SDOs. It speaks well for the protocols that others will find applications of them beyond the scope for which they were originally designed, and even outside the scope of areas addressed by the IETF. The document as written creates impediments to the ability to apply, and extend as necessary, these protocols to new problem spaces. I think it would be a far better goal to promote the reuse and widest application of these protocols, and to try to enable these new applications through a process that keeps some order to the applications and extensions of the protocols. As noted, biggest flaw seems to be the way in which the document deals with new applications or requirements identified by external standards organizations. In addition to not recognizing that this information may come to IETF via liaison statements, the document seems not to consider the fact that there may be a valid application that is outside of the scope of IETF (and in the scope of another standards development organization) to which the (G)MPLS protocols may be applied, and for which the (G)MPLS protocols may require extension. By insisting that every possible extension be done internally in IETF, the IETF either (1) Extends the scope of its work without bound; or (2) Needlessly restricts the application of its protocols. Neither one of these is good for IETF or for the Standards Development community at large. One reality that this draft fails to recognize is that, while IETF may be able to say "no" to standardizing something proposed by an individual, it does not have the ability (or the right) to say "no" to something proposed by another Standards Development Organization. As a practical matter, the IETF is not the only place where something can be standardized. If the IETF creates impediments to applying IETF protocols to the application space of another standards development organization, there is really nothing that the IETF can do to prevent that the other organization standardizes something themselves. The result would tend to be a proliferation of (G)MPLS "like" protocols instead of a coherent suite of protocols with broad applicability. This result would not be good for the IETF or the industry in general. A better approach would be for the IETF to PROMOTE the use of its protocols for new applications, and, when another Standards Development Organization wishes to apply (G)MPLS protocols to an application domain outside of the scope of IETF, that IETF will (1) assist with the development of any necessary extensions; and (2) to facilitate documentation of such new applications and extensions in a central place (e.g., by informational RFC, even for extensions that are developed outside of IETF) and to insure that code points are assigned in a coherent manner through IANA to avoid collisions where different extensions may use the same code points to indicate different things. I think that this could lay the groundwork for a much more constructive collaborative relationship between the IETF and other Standards Development Organizations than the draft as it stands. The difference in flavor for what I am proposing is that IETF should try to position itself as a Clearinghouse for (G)MPLS protocol extensions rather than as a Gatekeeper for (G)MPLS protcol extensions. What I have included below are some specific proposed text changes to try to change the flavor of the current draft to try to accomplish this. One final question regarding the applicability of this draft: The sub-IP area is still classified as a temporary area, and it seems that this particular procedure that will not be valid as written if remaining sub-IP work is returned to the "native" IETF areas. I don't have any specific suggestion as to how to solve this problem. My specific text proposals follow below. Regards, Steve Specific text proposals are as follows: ======================================================================= Abstract Original Text: This memo describes the process through which individuals, working groups and external standards bodies can influence the development of MPLS and GMPLS standards. With respect to standardization, this process means that (G)MPLS extensions and changes can be done through the IETF only, the body that created the (G)MPLS technology. The IETF will not publish a (G)MPLS technology extension RFC outside of the processes described here. _______________________________________________________________________ Proposed New Text: This memo describes the process through which individuals, working groups and external standards bodies can influence the development of MPLS and GMPLS standards. MPLS and GMPLS technology has attracted the interest of individuals and other Standards Development Organizations (SDOs) to apply and, where necessary, extend the protocols to cover problems and application spaces beyond those for which the protocols were originally designed. This speaks well for the architecture of the protocols that they can find such widespread application, and it is highly desirable to find ways to reuse and extend existing protocols rather than inventing new protocols to address these other problem areas. The challange going forward is to find ways to maximize the opportunities for reuse of these protocols, while trying to maintain architectural integrity of the protocols themselves. This draft outlines a proposal for such a process. ========================================================================== Terminology: Add: problem statement liaison a formal liaison statement from another Standards Development Organization (SDO) that initiates the discussion on extending the (G)MPLS protocols. This liaison will generally include a detailed problem description and a set of requirements that the (G)MPLS protocols need to meet to solve the problem. Such a liaison statement may contain a draft or approved document from the originating standards organization that characterizes the problem, indicating the level of agreement or approval that such a document has acheived in the originating organization. Supplement existing definition: requirement evaluating working group (rewg) - in the process descreibed below, the Working Group charged with the task of evaluating a certain problem statement and a certain set of requirements is termed the rewg. The focus of this group is somewhat different for the cases described here based on whether the problem statement and requirements came from an individual or another Standards Development Organization (SDO): in the individual case, the group may focus on assessing the validity of the requirements. In the case of a problem statement or requirements coming from an SDO, the other SDO may already have decided that the problem statement and requirements are valid for their application space, so the focus is directed more toward evaluation of whether IETF should be involved in developing the solution to that problem. ========================================================================== Section 2.1 Overview The existing diagram should be labeled "Procedure for initiation of New Applications and/or Extensions to (G)MPLS Protocols by Individuals". Even for individuals, there seems to be a missing "shortcut" from the document procedure. It seems to be assumed that we have already developed complete, perfect solutions to everything within the current charter, and not allow for the possibility that there is some missing element or overlooked requirement that may require a (G)MPLS extension that is within the current charter. This may require a line directly from the "review by wg chairs and ad's" box to the "IETF WG process" box to indicate the path taken where the problem statement is considered to fall entirely within the current charter. An additional diagram should be included labeled "Procedure for initiation of New Applications and/or Extensions to (G)MPLS protocols by other Standards Development Organizations (SDOs)" +---------+ |problem | |statement|<--------------------------------------------- Originating |liaison | SDO | +---------+ ^ | |discusson | | |on mailing | | Vlist | | +---------+ | | |review by| NACK | | +-|WG chairs|--------------+ | | | | and ADs | | | | | +---------+ | | | | |request IESG/IAB | | | | |to appoint rewg | | | | |and charter | | | | Vreq eval | +-------------------+ | | | +---------+ +-------->|liaison indicating | | | | |IESG/IAB | +-------->|out of scope or |----->| | | |decision | | +---->|interest for IETF | | | | +---------+ | | +-------------------+ | | | |rewg chartered | | | | | |to work on | | | | | Vproblem statement | | +-------------------+ | | | +---------+ NACK | | |liaison explaining | | | +>|rewg req |--------------+ | |how problem can be |----->| | +-| eval |----------------------->|solved with | | | | +---------+ no change reqd | |existing protocol | | | | | | | +-------------------+ | | | | | ACK | | | | | +------------------------------+ | | | V | | | | | +---------+ | v | | | |AD review| | +-------------------+ | | | +---------+ | |liaison accepting |------+ | | |request to IESG/ | |new work item | | | |IAB to approve | +-------------------+ | | Vcharter changes | ^ | | +---------+ NACK | | +------------+ | | |IESG/IAB |------------------+ | | Externally | | | |decision |----------------------------+ | Developed |<---+ | +---------+ ACK | Solution | | |wg chartered to +------------+ | |work solution | | V v | +---------+ +------------+ +-|IETF WG |----/ /----> stds track RFC | IANA code | |process | | points | +---------+ +------------+ ^ | | v solutions info RFC ID ========================================================================= Section 2.2 - Change title to: 2.2. Changes or Extensions to (G)MPLS Protocols Initiated by Individuals could also consider deleting item 4 of 2.2.4 since new section 2.3 is proposed to handle proposals from other SDOs. item 4 of 2.2.4 would only be valid in the case of an individual proposing a new problem to be solved by extending (G)MPLS protocols that IETF decides would be better addressed in another standards group. IETF could send a liaison to the other group with the suggested problem. This case may not be important enough to spell out explicitly in the document. ========================================================================= Add new section 2.3: 2.3. Changes or Extensions to (G)MPLS Protocols Initated at the request of another Standards Development Organization (SDO) 2.3.1. Initiating changes or extensions to (G)MPLS Protocols If a Standards Development Organization (SDO) wishes to apply the (G)MPLS protocols to a new application problem space, or sees a need to extend the (G)MPLS protocols to support the requirements for that new application, they may inform the IETF in one of the following manners: - An internet draft may be produced explaining the problem they are trying to solve and, if applicable, why the existing (G)MPLS protocols must be extended to address this problem. A note from the authors should be sent to the relevant mailing lists to initiate discussion. - An SDO (particularly those SDOs with whom ISOC/IETF have a formal relationship, e.g, see RFC 3356 or ITU-T A.sup3, and ITU-T Rec. A.4 regarding the relationship and communication method with ITU-T) may also be communicated via a formal liaison or communication statement. Such a statement is posted via a link from http://www.ietf.org/IESG/liaison.html and advertised by the iesg secretariat (who posts the incoming liaison) via the mailing list to initiate discussion. The mailing list to use should be Area mailing list and, if known, the WG mailing list for the WG that will likely be the requirement evaluation working group. In the case of discussion initiated from an incoming liaison statement, the liaison may be addressed to a specific Area or Working Group and notification should me made to the indicated mailing lists accordingly. Note concerning work initiated as a result of a liaison statement: Often a liaison statement that indicates that it is for action will indicated a deadline. The ADs and WG chairs should be diligent to make sure that a reply liaison is generated by the requested date, even if all that can be reported by that date is current status or a positive acknowledgement of receipt of the information. When the IETF chooses to undertake work as a result of an incoming liaison, regular reports of progress should be made via reply liaisons including anticipated time frames for completion of the work. In this way, the originating SDO can assess whether they can wait for an IETF solution or should pursue other avenues. 2.3.2. Problem statement review The MPLS and CCAMP working group chairs in conjunction with the Area Directors will determine if the particular problems raised in the Internet Draft or Incoming Liaison should be evaluated by a working group. This decision will be based on mailing list discussion. If the decision is that a requirement evaluation is warranted a decision is taken on which working group should act as requirement evaluation working group (rewg). In the case where the decision is that the IETF will proceed with further examination of these requirements, the originating SDO should be informed of this decision in a reply liaison. In the case where the decision is that the IETF will not proceed with further requirements evaluation, the "dustbin" which would have been the result for an individual submission is not an option for the case where the problem satement and requirements have already been accepted by another SDO. Since the other SDO has already accepted the problem statement and requirements, the likelihood is that this will lead to a standardized solution whether or not IETF chooses to be involved. At the same time, IETF has an interest in the long term integrity of the protocol, and can choose one of two options: - Even though the particular problem may be out of scope for IETF, participants may have insight which would assist in the solution to that problem. For the integrity of the protocol, it is certainly best if similar problems are solved in similar ways, and since the IETF should have the broadest view of all applications of the protocol, they are in a position to offer helpful advice to the other SDO about how to solve it. This information should be collected from the aforementioned email discussion and sent to the other SDO in a reply liaison. - The IETF is not in a position to offer any advice or insight as to how the problem can be solved. In this case, the IETF should indicate to the other SDO via a reply liaison that the IETF cannot help them with the problem, and it is up to the other SDO to define any solution. In either of case, the reply liaison to the originating SDO should encourage them to document their additional application or protocol extension via an informational RFC, (to keep the most complete possible library of extensions in one place), and to have any protocol code points assigned via IANA to insure that there are no cases where the same protocol code points might mean different things in the context of different extensions developed by different SDOs. This documentation would also enable the IETF to have a repository of extensions that would enable it and others to assess relationships between extensions. Any two extensions might: - be complementary and be usable at the same time - co-exist at the same time but it would make sense to only use one or the other at a time - not co-exist in an implementation but share a common base 2.3.3. Charter update If the chairs and the ADs both feel that the particular problems should be added to the MPLS or the CCAMP Working Group charter the ADs will propose specific charter modificiations for the Working Group to the IESG and the IAB. If the IESG and IAB approve of the charter changes the Working Group can then update its charter and start the work to study the requirements and the problems described in the Liaison statement. 2.3.4. Problem statement study The rewg will study the problem statement liaison statement and based on the evaluation, generate a response to the originating SDO and, if further work is to be undertaken within IETF, make such a recommendation to the IESG/IAB. The recommendation may be: 1 that no extensions to the (G)MPLS protocols are needed since the problem can be solved by the protocols as they exist. In this case, the WG chairs shall coordinate generating a liaison statement back to the originating SDO explaining how their problem can be solved with the current protocols. 2 that there is no interest in extending this protocol in IETF. Note that in the individual submission case (section 2.2.4) IETF is in the position to decide not to continue the work. However, in the case of work initiated due to a liaison from another SDO, the other SDO has already decided that there is a problem for which a standardized solution should be pursued. If IETF decides at this point not to pursue a standardized solution to the problem proposed by the incoming liaisons, a reply liaison is needed at this point with the same information content as discussed in section 2.3.2 if the ADs and WG chairs had decided not to pursue a standardized solution within IETF. In cases 1 and 2, IETF will not publish a standards track RFC to address the problem. However, should the originating SDO standardize its own solution, IETF will facilitate documenting that extension via an informational RFC and assignment of code points via IANA so that there is no conflict between this extension and those that may arise from other sources. 3 that the problem is of interest to IETF and the IETF is interested in developing extensions to the (G)MPLS protocols to address the problem. If the problem falls within the current charter, the normal WG process can be followed at this point. A reply liaison should be generated to the originating SDO indicating IETFs intent to accept the work and pursue a solution. If the problem requires extensions to the charter of the appropriate working group and the ADs agree, the proposal will be brought before the IESG and the IAB. If the IESG (with IAB advice) agrees that the task should be added to that particular charter then the rewg can work on it with the aim of adopting a final set of requirements to be forwarded to the working group that will handle the specification of the protocol changes. If the ADs or IESG/IAB do not agree to the charter extensions, a reply liaison should be sent to the originating SDO as in item 2 above. If a charter revision is agreed, a liaison should be sent to the originating SDO informing them of the revised charter and the intent to pursue the work. The rewg will study and clarify the requirements, merging them with others if warranted. The resulting requirements should be verified with the originating SDO via liaison, or other method is appropriate for that SDO. With concurrence from the originating SDO, the result is published as a requirements RFC. When the IESG approves publication of the requirements RFC it will add it as a new task to the protocol specifying Working Group charter. The protocol specifying working group will then develop the modifications or extensions to the (G)MPLS protocols needed to fulfil the requirements. In the case that the originating liaison has indicated any work or progress in the originating SDO to develop a protocol solution, that work shall be taken into account by the protocol specifying working group. To the extent that sound decisions have been made by the originating SDO, this should be used as the basis for the work in IETF. If errors are found, these shall be brought to the attention of the originating SDO via a liaison statement. Every effort shall be made to make sure that either the protocol is developed in one place, or the results are aligned if two specifications cannot be avoided. ======================================================================== Section 4 (obviously): Add: RFC 3471 RFC 3472 RFC 3473 RFC 3477 RFC 3478 RFC 3479 RFC 3480 ======================================================================== References Add: [RFC3356] Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines. G. Fishman, S. Bradner. August 2002. From owner-mpls@UU.NET Wed Feb 26 17:22:15 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29607 for ; Wed, 26 Feb 2003 17:22:15 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodtc04698; Wed, 26 Feb 2003 19:10:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQodtc03924 for mpls-outgoing; Wed, 26 Feb 2003 19:10:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodtc03913 for ; Wed, 26 Feb 2003 19:10:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodtc05415 for ; Wed, 26 Feb 2003 19:10:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodtc04910 for ; Wed, 26 Feb 2003 19:10:10 GMT Received: from maild.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maild.telia.com [194.22.190.101]) id QQodtc04887 for ; Wed, 26 Feb 2003 19:10:09 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maild.telia.com (8.12.5/8.12.5) with ESMTP id h1QJ9wPZ004703; Wed, 26 Feb 2003 20:09:58 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1QJ9v216510; Wed, 26 Feb 2003 20:09:57 +0100 (CET) Message-ID: <3E5D0FFF.6040407@pi.se> Date: Wed, 26 Feb 2003 20:05:35 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Bradner CC: dbrungard@att.com, kireeti@juniper.net, ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <200302260945.h1Q9j9GB002436@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit this might be a candidate for the understatement of the month :) Scott Bradner wrote: >>.Good point. CCAMP has received liaison statements in the past and >>we haven't really responded to them - >> >> > >this was pointed out to me (again) this week :-) > >we (the IETF) need to work out a reliable way to respond to liaison >statements > >Scott > My understanding of where we are now in this discussion it could be summarized as: We need to document the (g)mpls-change process, most of this is in the current draft. The concerns I've seen so far is on how and what could be accepted as input to the process, that should be easily solvable. We need to doucment the ietf way of responding to liasions. It is my immediate reaction that this do not really belong in the same document, if for no other reasons, at least for practical reasons. If there is a strong motive to put them in the same document, I can live with that. It has been pointed out that - inter-organization information, requests, suggestions and communications are handled different by differnt organisations. I think we should view the (g)mpls change process as IETF internal, and that we need to add some text to explain how and when external documents sent to the ietf in other format than IDs could and should be taken into the (g)mpls change process. I will update the draft with some text addressing this, the darft won't be possible to re-publish until after the IETF in SF, however we have allocated time on the ccamp and mpls working group agendas for Ron to discuss the issues with this draft. I will have this text ready in good time before this presentation. /Loa From owner-mpls@UU.NET Wed Feb 26 19:19:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03639 for ; Wed, 26 Feb 2003 19:19:55 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodtx16198 for ; Thu, 27 Feb 2003 00:23:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodtx15657; Thu, 27 Feb 2003 00:23:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQodtx00797 for mpls-outgoing; Thu, 27 Feb 2003 00:23:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodtx00792 for ; Thu, 27 Feb 2003 00:23:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodtx08930 for ; Thu, 27 Feb 2003 00:22:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodtx22341 for ; Thu, 27 Feb 2003 00:22:08 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQodtx22330 for ; Thu, 27 Feb 2003 00:22:08 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1R0M6V23966 for ; Wed, 26 Feb 2003 19:22:06 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 01:22:01 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501062D7E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 01:22:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Liaisons are an IETF-wide issue. > YES. > I think if we want to send a liaison to another group, the AD just sends > e-mail, and archives it on ietf.org. That's just an administrative > matter, nothing we even need a draft for. > It is not always the AD who sends. It could be a WG. Or whole IETF. > Incoming liaisons take a little more policy but not much. We want them > archived, so just saying "submit a draft" isn't good enough. I'm afraid > we need to provide mailto:ietf-liaisons@ietf.org, and yet another folder > on the web pages. All ADs get to hear about all incoming liaisons, and > if they think it's appropriate for one of their WGs they forward it. > Done? > No of course NOT. Many Liasons will want an answer. So we need a process to follow up and to track if a timely response has been (or will be) send. > But this shouldn't be discussed on these lists anyway :-) > The general issue should not.... But the Liasons communication between ITU and CCAMP/MPLS has not been going smoothly so far (even though we had good intentions). Responses have not gone out in time (or in some cases at all). So in that respect some of it is relevant here. But possibly not to this specific document. Depends on how you look at things I guess. Bert From owner-mpls@UU.NET Thu Feb 27 03:55:50 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23121 for ; Thu, 27 Feb 2003 03:55:50 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvf09722 for ; Thu, 27 Feb 2003 08:59:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodvf08307; Thu, 27 Feb 2003 08:58:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQodvf03643 for mpls-outgoing; Thu, 27 Feb 2003 08:58:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodvf03636 for ; Thu, 27 Feb 2003 08:58:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodvf04620 for ; Thu, 27 Feb 2003 08:57:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvf06397 for ; Thu, 27 Feb 2003 08:57:20 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQodvf06376 for ; Thu, 27 Feb 2003 08:57:19 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1R8vIS29863; Thu, 27 Feb 2003 00:57:18 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h1R8vII28717; Thu, 27 Feb 2003 00:57:18 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 27 Feb 2003 00:57:18 -0800 (PST) From: Kireeti Kompella To: Stephen Trowbridge cc: ccamp@ops.ietf.org, "" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-Reply-To: <3E5D3DE6.FB77D6B8@lucent.com> Message-ID: <20030226235603.Y28581@kummer.juniper.net> References: <200302260945.h1Q9j9GB002436@newdev.harvard.edu> <3E5D0FFF.6040407@pi.se> <20030226205313.GS2604@sbrim-w2k> <3E5D3DE6.FB77D6B8@lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Steve, On Wed, 26 Feb 2003, Stephen Trowbridge wrote: > However, as Deborah, Kireeti, and Scott > have observed, the way it is written it seems to hinder rather than > help the process of collaborating with other Standards Developement > Organizations(SDOs) If this is the impression that my comments gave, I must have used the wrong words. The GMPLS change document is intended to help other SDOs understand the change process, and as such *help* collaboration. > and doesn't provide a good way to deal with and respond > to liaison statements, which is the avenue by which many of these > requests will arrive from other SDOs. This I agree with. But as Loa pointed out, it was not the intent of the gmpls change doc to address this issue -- that is the domain of a different document; and as several people have pointed out by now, the change document is very specific (a small set of WGs), whereas a liaison document should probably be much broader (IETF-wide). > The document as > written creates impediments to the ability to apply, and extend as > necessary, these protocols to new problem spaces. I don't see this at all. The IETF does have processes, for example, RFC 2026. So (I assume) does the ITU. Most would consider writing down a process for change, especially with the intent of maintaining architectural soundness, a Good Thing, not an impediment. Process does on occasion slow things down. Sometimes that is laudable -- deliberation vs haste; sometimes that is a price one pays in return for avoiding chaos. It takes longer for me to hang up my clothes rather than throw them on the floor -- but I opt to hang them up. > As noted, biggest flaw seems to be the way in which the document deals > with new applications or requirements identified by external standards > organizations. In addition to not recognizing that this information may > come to IETF via liaison statements, Let's take these one at a time. A liaison statement (LS) has not been heretofore a replacement for an ID. A LS of the form "we invite you to take part in such-and-such meeting" or "we would like to bring to your attention such-and-such work" are fine uses (in my opinion) for LSs. However, if an SDO thinks that x, y and z are requirements for protocol foo, communicating this solely via a liaison statement is not (again, IMO) the right approach. Requirements need to be discussed, possibly modified, and captured in some permanent form. There is a well established process in the IETF for that; introducing a new vehicle for that process is neither necessary nor appropriate, at least without a revision of 2026 that states this. It is not the intent of the gmpls change process to at the same time change the IETF's process and to update 2026. > the document seems not to consider > the fact that there may be a valid application that is outside of the > scope of IETF (and in the scope of another standards development > organization) to which the (G)MPLS protocols may be applied, and for > which the (G)MPLS protocols may require extension. Not at all true. > By insisting that > every possible extension be done internally in IETF, the IETF either > (1) Extends the scope of its work without bound; or (2) Needlessly > restricts the application of its protocols. Neither one of these is > good for IETF or for the Standards Development community at large. The reason for insisting that extensions be done in the IETF is: (a) the IETF developed the protocols, knows them best, and knows the bigger architectural picture in which they fit. A good example is the (unnecessary) deprecation of RSVP messages in a recent RFC. (b) when all is said and done, the IETF does own the protocols. It is instructive to harken back to how CCAMP took extraordinary pains *not* to change the SDH spec, nor even to give the impression of such a change. There was a clear recognition that SDH "belonged" to the ITU, and when representatives felt that there was "intrusion", even if unintended, CCAMP stepped back. There were two reasons for this: we recognized that we (as an SDO, not as individuals) didn't have the expertise; and we wanted to maintain cordial relations. > One reality that this draft fails to recognize is that, while IETF may > be able to say "no" to standardizing something proposed by an individual, > it does not have the ability (or the right) to say "no" to something > proposed by another Standards Development Organization. As a practical > matter, the IETF is not the only place where something can be standardized. I agree that the IETF cannot stop other SDOs from extending its protocols; it can (I believe) insist that such modified protocols use a new name to call out the differences. However, the problem that the change document addresses is not what other SDOs are doing, but what the IETF should be doing. As far as other SDOs are concerned, they can decide on their own to abide by the IETF's rules if they want, or to forge ahead on their own, at the risk (which they may consider worthwhile) of marring their relations with the IETF. > If the IETF creates impediments to applying IETF protocols to > the application space of another standards development organization, > there is really nothing that the IETF can do to prevent that the other > organization standardizes something themselves. The result would tend > to be a proliferation of (G)MPLS "like" protocols instead of a coherent > suite of protocols with broad applicability. This result would not be > good for the IETF or the industry in general. There is already a proliferation of GMPLS like protocols. The OIF has its own; the ITU is developing its own. It is not the intention of the change document to stop this, nor to create impediments. But there is the (fond!) hope that with such a change document in place, other SDOs will say -- "hey, instead of changing the protocols ourselves, there is this process whereby we can take our requirements to the IETF and get the experts who really know that protocol to change it to meet our needs." > A better approach would be for the IETF to PROMOTE the use of its > protocols for new applications Far be it for me to say what the IETF should or should not do. However, I personally don't think the IETF should promote its protocols. In the final analysis, the IETF is concerned with running (and promoting) the Internet. Any protocols it designs should have that as the end goal. > and, when another Standards Development > Organization wishes to apply (G)MPLS protocols to an application domain > outside of the scope of IETF, that IETF will (1) assist with the development > of any necessary extensions; and (2) to facilitate documentation of > such new applications and extensions in a central place (e.g., by > informational RFC, even for extensions that are developed outside of > IETF) and to insure that code points are assigned in a coherent manner > through IANA to avoid collisions where different extensions may use > the same code points to indicate different things. If the IETF is convinced that such extensions will in some way help to achieve its own goals AND will not hurt the protocol, the IETF can and should undertake the activity. If the extensions do not match the IETF's goals, but they don't hurt the protocol, there should be a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to yield the floor to some other SDO. > The difference in flavor for what I am proposing is that IETF should > try to position itself as a Clearinghouse for (G)MPLS protocol extensions > rather than as a Gatekeeper for (G)MPLS protcol extensions. The Gatekeeper function is for the case where the said extensions do hurt the protocol (in the eyes of the IETF). This is where the SDO can decide, as you point out, that it can do it on its own, but changes the name of the protocol so that innocent bystanders can tell the difference. Kireeti. From owner-mpls@UU.NET Thu Feb 27 04:07:44 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23452 for ; Thu, 27 Feb 2003 04:07:43 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvg02385 for ; Thu, 27 Feb 2003 09:11:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodvg28342; Thu, 27 Feb 2003 09:09:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQodvg22466 for mpls-outgoing; Thu, 27 Feb 2003 09:09:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodvg22457 for ; Thu, 27 Feb 2003 09:09:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodvg18727 for ; Thu, 27 Feb 2003 09:09:11 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvg10815 for ; Thu, 27 Feb 2003 09:09:08 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQodvg10791 for ; Thu, 27 Feb 2003 09:09:08 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1R997S30447; Thu, 27 Feb 2003 01:09:07 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h1R997J28752; Thu, 27 Feb 2003 01:09:07 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 27 Feb 2003 01:09:07 -0800 (PST) From: Kireeti Kompella To: "Wijnen, Bert (Bert)" cc: Scott W Brim , "" , "" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501062D7E@nl0006exch001u.nl.lucent.com> Message-ID: <20030227005743.X28581@kummer.juniper.net> References: <7D5D48D2CAA3D84C813F5B154F43B15501062D7E@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Bert, On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: > No of course NOT. Many Liasons will want an answer. > So we need a process to follow up and to track if a timely > response has been (or will be) send. Is the IETF process for replying to liaison statements (and of generating them) written down, say in some RFC? If so, could you send me a pointer? > But the Liasons communication between ITU and CCAMP/MPLS has not > been going smoothly so far (even though we had good intentions). > Responses have not gone out in time (or in some cases at all). I'll take full responsibility for that. Thanks, Kireeti. From owner-mpls@UU.NET Thu Feb 27 07:35:14 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26877 for ; Thu, 27 Feb 2003 07:35:13 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvu05625 for ; Thu, 27 Feb 2003 12:39:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodvu04707; Thu, 27 Feb 2003 12:38:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQodvu02494 for mpls-outgoing; Thu, 27 Feb 2003 12:38:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodvu02483 for ; Thu, 27 Feb 2003 12:38:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodvu28609 for ; Thu, 27 Feb 2003 12:37:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvu04675 for ; Thu, 27 Feb 2003 12:37:11 GMT Received: from mailc.telia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailc.telia.com [194.22.190.4]) id QQodvu04650 for ; Thu, 27 Feb 2003 12:37:09 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailc.telia.com (8.12.5/8.12.5) with ESMTP id h1RCb0dP024029; Thu, 27 Feb 2003 13:37:00 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1RCax223852; Thu, 27 Feb 2003 13:36:59 +0100 (CET) Message-ID: <3E5E0563.9060303@pi.se> Date: Thu, 27 Feb 2003 13:32:35 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kireeti Kompella CC: Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <200302260945.h1Q9j9GB002436@newdev.harvard.edu> <3E5D0FFF.6040407@pi.se> <20030226205313.GS2604@sbrim-w2k> <3E5D3DE6.FB77D6B8@lucent.com> <20030226235603.Y28581@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, thanks you captured most of my points and said it possibly more clearly and more polite than I would have. I just want to strengthen one of the points a bit. Chapter 2 bullet 4 says clearly > 4 that the problem is real and that they would be solved with exten- > sions to the (G)MPLS protocols, but that this for some reason is > not best done within the IETF, but some other organization. The > IETF might in such a case come to an agreement with this organiza- > tion to specify the protocol extensions and that these will be > described in a ID sent to the IETF for review and eventually be > published as an RFC. > > > > How this could be contrued as trying to stop other organizations from extending and improving the IETF protocols escapes my imagination, we even offer to put our expertise in for eview and makes it possible to use the IETF as a vehicle for publication- Further in testing Stephen logic on "you are not alone" - if I came to the absurd conclusion that I wanted to use Q.931 for label distribution and I failed to convince ITU that this was a good idea, would then ITU accept that the IETF or any other SDO published an extension to Q.931? Those arguments cuts both ways! Last, the IETF standards process works with IDs and RFCs, that one working group (or a coupel of them) should start working with another type of document (liasions) in that process is ... It would also take us to the point where we need to do the same thing with the prefered document from other SDOs. "You are not alone!" How would ITU react if I started sending IDs to them? I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs. /Loa Kireeti Kompella wrote: >Hi Steve, > >On Wed, 26 Feb 2003, Stephen Trowbridge wrote: > > > >>However, as Deborah, Kireeti, and Scott >>have observed, the way it is written it seems to hinder rather than >>help the process of collaborating with other Standards Developement >>Organizations(SDOs) >> >> > >If this is the impression that my comments gave, I must have used the >wrong words. The GMPLS change document is intended to help other SDOs >understand the change process, and as such *help* collaboration. > > > >>and doesn't provide a good way to deal with and respond >>to liaison statements, which is the avenue by which many of these >>requests will arrive from other SDOs. >> >> > >This I agree with. But as Loa pointed out, it was not the intent of >the gmpls change doc to address this issue -- that is the domain of >a different document; and as several people have pointed out by now, >the change document is very specific (a small set of WGs), whereas >a liaison document should probably be much broader (IETF-wide). > > > >>The document as >>written creates impediments to the ability to apply, and extend as >>necessary, these protocols to new problem spaces. >> >> > >I don't see this at all. The IETF does have processes, for example, >RFC 2026. So (I assume) does the ITU. Most would consider writing >down a process for change, especially with the intent of maintaining >architectural soundness, a Good Thing, not an impediment. Process >does on occasion slow things down. Sometimes that is laudable -- >deliberation vs haste; sometimes that is a price one pays in return >for avoiding chaos. It takes longer for me to hang up my clothes rather >than throw them on the floor -- but I opt to hang them up. > > > >>As noted, biggest flaw seems to be the way in which the document deals >>with new applications or requirements identified by external standards >>organizations. In addition to not recognizing that this information may >>come to IETF via liaison statements, >> >> > >Let's take these one at a time. A liaison statement (LS) has not been >heretofore a replacement for an ID. A LS of the form "we invite you >to take part in such-and-such meeting" or "we would like to bring to >your attention such-and-such work" are fine uses (in my opinion) for >LSs. However, if an SDO thinks that x, y and z are requirements for >protocol foo, communicating this solely via a liaison statement is not >(again, IMO) the right approach. Requirements need to be discussed, >possibly modified, and captured in some permanent form. There is a >well established process in the IETF for that; introducing a new >vehicle for that process is neither necessary nor appropriate, at >least without a revision of 2026 that states this. It is not the >intent of the gmpls change process to at the same time change the >IETF's process and to update 2026. > > > >>the document seems not to consider >>the fact that there may be a valid application that is outside of the >>scope of IETF (and in the scope of another standards development >>organization) to which the (G)MPLS protocols may be applied, and for >>which the (G)MPLS protocols may require extension. >> >> > >Not at all true. > > > >>By insisting that >>every possible extension be done internally in IETF, the IETF either >>(1) Extends the scope of its work without bound; or (2) Needlessly >>restricts the application of its protocols. Neither one of these is >>good for IETF or for the Standards Development community at large. >> >> > >The reason for insisting that extensions be done in the IETF is: >(a) the IETF developed the protocols, knows them best, and knows the > bigger architectural picture in which they fit. A good example > is the (unnecessary) deprecation of RSVP messages in a recent RFC. >(b) when all is said and done, the IETF does own the protocols. > >It is instructive to harken back to how CCAMP took extraordinary pains >*not* to change the SDH spec, nor even to give the impression of such a >change. There was a clear recognition that SDH "belonged" to the ITU, >and when representatives felt that there was "intrusion", even if >unintended, CCAMP stepped back. There were two reasons for this: we >recognized that we (as an SDO, not as individuals) didn't have the >expertise; and we wanted to maintain cordial relations. > > > >>One reality that this draft fails to recognize is that, while IETF may >>be able to say "no" to standardizing something proposed by an individual, >>it does not have the ability (or the right) to say "no" to something >>proposed by another Standards Development Organization. As a practical >>matter, the IETF is not the only place where something can be standardized. >> >> > >I agree that the IETF cannot stop other SDOs from extending its >protocols; it can (I believe) insist that such modified protocols use a >new name to call out the differences. > >However, the problem that the change document addresses is not what >other SDOs are doing, but what the IETF should be doing. As far as >other SDOs are concerned, they can decide on their own to abide by >the IETF's rules if they want, or to forge ahead on their own, at >the risk (which they may consider worthwhile) of marring their relations >with the IETF. > > > >>If the IETF creates impediments to applying IETF protocols to >>the application space of another standards development organization, >>there is really nothing that the IETF can do to prevent that the other >>organization standardizes something themselves. The result would tend >>to be a proliferation of (G)MPLS "like" protocols instead of a coherent >>suite of protocols with broad applicability. This result would not be >>good for the IETF or the industry in general. >> >> > >There is already a proliferation of GMPLS like protocols. The OIF >has its own; the ITU is developing its own. It is not the intention >of the change document to stop this, nor to create impediments. But >there is the (fond!) hope that with such a change document in place, >other SDOs will say -- "hey, instead of changing the protocols ourselves, >there is this process whereby we can take our requirements to the IETF >and get the experts who really know that protocol to change it to meet >our needs." > > > >>A better approach would be for the IETF to PROMOTE the use of its >>protocols for new applications >> >> > >Far be it for me to say what the IETF should or should not do. However, >I personally don't think the IETF should promote its protocols. In the >final analysis, the IETF is concerned with running (and promoting) the >Internet. Any protocols it designs should have that as the end goal. > > > >>and, when another Standards Development >>Organization wishes to apply (G)MPLS protocols to an application domain >>outside of the scope of IETF, that IETF will (1) assist with the development >>of any necessary extensions; and (2) to facilitate documentation of >>such new applications and extensions in a central place (e.g., by >>informational RFC, even for extensions that are developed outside of >>IETF) and to insure that code points are assigned in a coherent manner >>through IANA to avoid collisions where different extensions may use >>the same code points to indicate different things. >> >> > >If the IETF is convinced that such extensions will in some way help >to achieve its own goals AND will not hurt the protocol, the IETF can >and should undertake the activity. If the extensions do not match >the IETF's goals, but they don't hurt the protocol, there should be >a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to >yield the floor to some other SDO. > > > >>The difference in flavor for what I am proposing is that IETF should >>try to position itself as a Clearinghouse for (G)MPLS protocol extensions >>rather than as a Gatekeeper for (G)MPLS protcol extensions. >> >> > >The Gatekeeper function is for the case where the said extensions do >hurt the protocol (in the eyes of the IETF). This is where the SDO >can decide, as you point out, that it can do it on its own, but >changes the name of the protocol so that innocent bystanders can tell >the difference. > >Kireeti. > > > > From owner-mpls@UU.NET Thu Feb 27 07:49:06 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28174 for ; Thu, 27 Feb 2003 07:49:06 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvv23566 for ; Thu, 27 Feb 2003 12:52:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodvv21283; Thu, 27 Feb 2003 12:51:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQodvv03830 for mpls-outgoing; Thu, 27 Feb 2003 12:50:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodvv03820 for ; Thu, 27 Feb 2003 12:50:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodvv22205 for ; Thu, 27 Feb 2003 12:50:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvv20024 for ; Thu, 27 Feb 2003 12:50:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodvv19998 for ; Thu, 27 Feb 2003 12:50:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1RCo3JR010219 for ; Thu, 27 Feb 2003 07:50:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA28186 for ; Thu, 27 Feb 2003 07:50:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1RCo2n19915 for mpls@uu.net; Thu, 27 Feb 2003 07:50:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodvv03748 for ; Thu, 27 Feb 2003 12:49:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodvv18510 for ; Thu, 27 Feb 2003 12:47:52 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvv14670 for ; Thu, 27 Feb 2003 12:47:52 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQodvv14665 for ; Thu, 27 Feb 2003 12:47:51 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27425; Thu, 27 Feb 2003 07:43:53 -0500 (EST) Message-Id: <200302271243.HAA27425@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt Date: Thu, 27 Feb 2003 07:43:53 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Method to Setup LSP using VLAN Tag Switching Author(s) : T. Kawakami et al. Filename : draft-kawakami-mpls-lsp-vlan-00.txt Pages : 15 Date : 2003-2-26 This document describes a method to setup a Layer 2 tunnel over networks based on Ethernet technology. For this purpose, the ports of an Ethernet switch are configured to forward VLAN tag-labeled packets incoming from a certain port to another unambiguous port by using VLAN tag information. The Ethernet switches themselves are a part of the Label Switching Routers (LSRs), which distribute the VLAN tags using Label Distribution Protocol (LDP). To enable LDP to fulfil this function, an LDP extension is proposed. The introduced method simplifies the transport of Ethernet frames over wide area Ethernet networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kawakami-mpls-lsp-vlan-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kawakami-mpls-lsp-vlan-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160628.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Feb 27 07:49:08 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28189 for ; Thu, 27 Feb 2003 07:49:07 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvv25765 for ; Thu, 27 Feb 2003 12:53:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodvv22252; Thu, 27 Feb 2003 12:51:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQodvv03825 for mpls-outgoing; Thu, 27 Feb 2003 12:50:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodvv03819 for ; Thu, 27 Feb 2003 12:50:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodvv22203 for ; Thu, 27 Feb 2003 12:50:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvv20017 for ; Thu, 27 Feb 2003 12:50:06 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodvv19996 for ; Thu, 27 Feb 2003 12:50:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1RCo3JR010218 for ; Thu, 27 Feb 2003 07:50:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA28184 for ; Thu, 27 Feb 2003 07:50:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1RCo2G19909 for mpls@uu.net; Thu, 27 Feb 2003 07:50:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodvv03689 for ; Thu, 27 Feb 2003 12:48:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodvv27739 for ; Thu, 27 Feb 2003 12:48:31 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvv15128 for ; Thu, 27 Feb 2003 12:48:31 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQodvv15114 for ; Thu, 27 Feb 2003 12:48:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27616; Thu, 27 Feb 2003 07:44:33 -0500 (EST) Message-Id: <200302271244.HAA27616@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-yasukawa-mpls-p2mp-requirement-00.txt Date: Thu, 27 Feb 2003 07:44:32 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Point-to-Multipoint capability extension to MPLS Author(s) : S. Yasukawa, I. Inoue Filename : draft-yasukawa-mpls-p2mp-requirement-00.txt Pages : 17 Date : 2003-2-26 This document presents a set of requirements for Point-to-Multipoint (P2MP) capability extension to Multiprotocol Label Switching (MPLS). It identifies the functional and performance extensions required to realize Content Distribution Network (CDN) by MPLS technology. It also identifies functional extensions required to implement CDN/VoIP/VPN sevice convergence network. These extensions can be used to provide high performance and scalable broadband service network with MPLS technology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-requirement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yasukawa-mpls-p2mp-requirement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yasukawa-mpls-p2mp-requirement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yasukawa-mpls-p2mp-requirement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-yasukawa-mpls-p2mp-requirement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160753.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Feb 27 08:11:01 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29965 for ; Thu, 27 Feb 2003 08:11:00 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvw27994 for ; Thu, 27 Feb 2003 13:12:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodvw27243; Thu, 27 Feb 2003 13:12:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQodvw24266 for mpls-outgoing; Thu, 27 Feb 2003 13:12:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodvw24249 for ; Thu, 27 Feb 2003 13:12:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodvw26557 for ; Thu, 27 Feb 2003 13:11:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvw25382 for ; Thu, 27 Feb 2003 13:11:09 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQodvw25359 for ; Thu, 27 Feb 2003 13:11:08 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1RDAgb08272; Thu, 27 Feb 2003 08:10:42 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <17C6Y0Q1>; Thu, 27 Feb 2003 08:10:42 -0500 Message-ID: <710197BD5AF9D4119E4400508BCFA13604381507@zcard04u.ca.nortel.com> From: "Malcolm Betts" To: "'Loa Andersson'" Cc: Stephen Trowbridge , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 08:10:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE61.A0E63C74" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DE61.A0E63C74 Content-Type: text/plain Loa, the from the outside looking in the liaison process and the change process are closely coupled. The liaison process is described in ITU-T Recommendation A.4 and A.5 and in RFC 3356. The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on requirements agreed by the members of the Study Group (that originated the liaison). The change process being proposed requires that this official request from a SDO is converted into an individuals ID. The level of agreement in the SDO is therefore obscured, this process appears to be in conflict with RFC 3356. The problem is particularly acute when the requirements are to enable (or enhance) the management of a non IP network to support a non IP client. If my understanding of the draft is correct such requests would be rejected by the IETF. It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications. The IETF plays a key role in ensuring that the integrity of the base protocols is not compromised. Malcolm Betts Phone: +1 613 763 7860 (ESN 393) FAX: +1 613 763 6608 (ESN 393) email: betts01@nortelnetworks.com -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, February 27, 2003 7:33 AM To: Kireeti Kompella Cc: Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs. /Loa ------_=_NextPart_001_01C2DE61.A0E63C74 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Loa, the from the outside looking in the liaison = process and the change process are closely coupled.  The liaison = process is described in ITU-T Recommendation A.4 and A.5 and in RFC = 3356. 

The coupling occurs because the ITU uses the agreed = liaison process to communicate requests to modify IETF protocols based = on requirements agreed by the members of the Study Group (that = originated the liaison).  The change process being proposed = requires that this official request from a SDO is converted into an = individuals ID.  The level of agreement in the SDO is therefore = obscured, this process appears to be in conflict with RFC 3356.  = The problem is particularly acute when the requirements are to enable = (or enhance) the management of a non IP network to support a non IP = client.  If my understanding of the draft is correct such requests = would be rejected by the IETF.

It is clearly beneficial to the industry if the basic = IETF protocols can be extended to address such applications.  The = IETF plays a key role in ensuring that the integrity of the base = protocols is not compromised.

Malcolm Betts

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


-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, February 27, 2003 7:33 AM
To: Kireeti Kompella
Cc: Stephen Trowbridge; ccamp@ops.ietf.org; = mpls@UU.NET
Subject: Re: I-D = ACTION:draft-andersson-mpls-g-chng-proc-00.txt
<snip>

I think I've clearly pointed out the limited scope of = the change process, recognized that there is a orthogonal problem on = how we treats liasions coming into the ietf, that the liasion process = needs to be documented, and that we will add text to address the = limited intersection of the change-process and liasion process in order = to promote the cooperation with other SDOs.

/Loa

<snip>

------_=_NextPart_001_01C2DE61.A0E63C74-- From owner-mpls@UU.NET Thu Feb 27 08:22:56 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00703 for ; Thu, 27 Feb 2003 08:22:56 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvx18752 for ; Thu, 27 Feb 2003 13:26:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodvx15015; Thu, 27 Feb 2003 13:24:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQodvx25239 for mpls-outgoing; Thu, 27 Feb 2003 13:24:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodvx25229 for ; Thu, 27 Feb 2003 13:24:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodvx28903 for ; Thu, 27 Feb 2003 13:24:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvx23302 for ; Thu, 27 Feb 2003 13:24:09 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodvx23293 for ; Thu, 27 Feb 2003 13:24:08 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1RDO5Nh014394 for ; Thu, 27 Feb 2003 08:24:06 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA29859 for ; Thu, 27 Feb 2003 08:24:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1RDO5f24158 for mpls@uu.net; Thu, 27 Feb 2003 08:24:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodvx25208 for ; Thu, 27 Feb 2003 13:23:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodvx22231 for ; Thu, 27 Feb 2003 13:22:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvx22155 for ; Thu, 27 Feb 2003 13:22:36 GMT Received: from kcmso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQodvx22137 for ; Thu, 27 Feb 2003 13:22:36 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1RAwnmo016508 for ; Thu, 27 Feb 2003 07:22:35 -0600 (CST) Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.11) by attrh3i.attrh.att.com (6.5.032) id 3E58FF280025F721; Thu, 27 Feb 2003 08:22:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE63.4810FA95" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 08:22:31 -0500 Message-ID: <35BD167AAD17F34F84B265D79518556704072EC0@OCCLUST03EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLeYgoQS2XagnBvREmiUN3RLzR0/wAALulw From: "Lazer, Monica A, ALABS" To: "Malcolm Betts" , "Loa Andersson" Cc: "Stephen Trowbridge" , "Kireeti Kompella" , , Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2DE63.4810FA95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Loa, Kireeti, I agree with Malcolm.=20 Since this draft proposes a process change specifically dealing with requirements and problem statements, and since ITU uses the liaison process for this reason, the liaison process is very relevant to the changes proposed in this draft, and it is not an orthogonal problem. =20 =20 Monica A. Lazer Network Architecture and Reliability =20 908 234 8462 mlazer@att.com =20 -----Original Message----- From: Malcolm Betts [mailto:betts01@nortelnetworks.com] Sent: Thursday, February 27, 2003 8:11 AM To: 'Loa Andersson' Cc: Stephen Trowbridge; Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt =20 Loa, the from the outside looking in the liaison process and the change process are closely coupled. The liaison process is described in ITU-T Recommendation A.4 and A.5 and in RFC 3356. =20 The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on requirements agreed by the members of the Study Group (that originated the liaison). The change process being proposed requires that this official request from a SDO is converted into an individuals ID. The level of agreement in the SDO is therefore obscured, this process appears to be in conflict with RFC 3356. The problem is particularly acute when the requirements are to enable (or enhance) the management of a non IP network to support a non IP client. If my understanding of the draft is correct such requests would be rejected by the IETF. It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications. The IETF plays a key role in ensuring that the integrity of the base protocols is not compromised. Malcolm Betts=20 Phone: +1 613 763 7860 (ESN 393)=20 FAX: +1 613 763 6608 (ESN 393)=20 email: betts01@nortelnetworks.com=20 =20 -----Original Message-----=20 From: Loa Andersson [ mailto:loa@pi.se]=20 Sent: Thursday, February 27, 2003 7:33 AM=20 To: Kireeti Kompella=20 Cc: Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET=20 Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt=20 =20 I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs. /Loa=20 =20 ------_=_NextPart_001_01C2DE63.4810FA95 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Lo= a, Kireeti,

I = agree with Malcolm.

Si= nce this draft proposes a process change specifically dealing with requirements = and problem statements, and since ITU uses the liaison process for this = reason, the liaison process is very relevant to the changes proposed in this draft, = and it is not an orthogonal problem.

 

 

Monica A. = Lazer

Network Architecture and = Reliability

 

908 234 8462

mlazer@att.com

<= span class=3DEmailStyle16> 

-----Original Message-----
From: Malcolm Betts [mailto:betts01@nortelnetworks.com]
Sent: Thursday, February = 27, 2003 8:11 AM
To: 'Loa Andersson'
Cc: Stephen Trowbridge; = Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

 

Loa, the from the outside looking in the liaison process = and the change process are closely coupled.  The liaison process is = described in ITU-T Recommendation A.4 and A.5 and in RFC 3356.  <= /p>

The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on = requirements agreed by the members of the Study Group (that originated the = liaison).  The change process being proposed requires that this official request = from a SDO is converted into an individuals ID.  The level of agreement in = the SDO is therefore obscured, this process appears to be in conflict with = RFC 3356.  The problem is particularly acute when the requirements are = to enable (or enhance) the management of a non IP network to support a non = IP client.  If my understanding of the draft is correct such requests = would be rejected by the IETF.

It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications.  The IETF = plays a key role in ensuring that the integrity of the base protocols is not compromised.

Malcolm Betts

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

 <= /p>

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, February 27, 2003 7:33 = AM
To: Kireeti Kompella
Cc: Stephen Trowbridge; ccamp@ops.ietf.org; = mpls@UU.NET
Subject: Re: I-D = ACTION:draft-andersson-mpls-g-chng-proc-00.txt
<snip>

I think I've clearly pointed out the limited scope of the = change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be = documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation = with other SDOs.

/Loa <= /p>

<snip>

------_=_NextPart_001_01C2DE63.4810FA95-- From owner-mpls@UU.NET Thu Feb 27 10:44:13 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08661 for ; Thu, 27 Feb 2003 10:44:13 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwh23989 for ; Thu, 27 Feb 2003 15:48:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwh23274; Thu, 27 Feb 2003 15:47:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwh13354 for mpls-outgoing; Thu, 27 Feb 2003 15:47:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwh13349 for ; Thu, 27 Feb 2003 15:47:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodwh26661 for ; Thu, 27 Feb 2003 15:47:01 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwh14597 for ; Thu, 27 Feb 2003 15:47:00 GMT Received: from auemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQodwh14580 for ; Thu, 27 Feb 2003 15:47:00 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1RFkwm16797 for ; Thu, 27 Feb 2003 10:46:58 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 16:46:57 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501062F74@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , "Wijnen, Bert (Bert)" Cc: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 16:46:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Inline > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: donderdag 27 februari 2003 10:09 > To: Wijnen, Bert (Bert) > Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET > Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi Bert, > > On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: > > > No of course NOT. Many Liasons will want an answer. > > So we need a process to follow up and to track if a timely > > response has been (or will be) send. > > Is the IETF process for replying to liaison statements (and of > generating them) written down, say in some RFC? If so, could you > send me a pointer? > Unfortunately, I don't think the process for that has been defined. That is why I said that "we need a process..." We do not have it yet (I think... at least I do not know it either). I think we were all just hoping people would take responsibility and do the right things... but as we know that is how things fall through the cracks. > > But the Liasons communication between ITU and CCAMP/MPLS has not > > been going smoothly so far (even though we had good intentions). > > Responses have not gone out in time (or in some cases at all). > > I'll take full responsibility for that. > W.r.t. CCAMP I will share some of the responsibility too. I should also have kept a better eye on it. Bert > Thanks, > Kireeti. > From owner-mpls@UU.NET Thu Feb 27 11:17:07 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09942 for ; Thu, 27 Feb 2003 11:17:07 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwj12640 for ; Thu, 27 Feb 2003 16:20:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwj10037; Thu, 27 Feb 2003 16:19:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwj03695 for mpls-outgoing; Thu, 27 Feb 2003 16:19:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodwj03686 for ; Thu, 27 Feb 2003 16:19:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodwj04733 for ; Thu, 27 Feb 2003 16:17:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwj05662 for ; Thu, 27 Feb 2003 16:17:12 GMT Received: from almso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQodwj05633 for ; Thu, 27 Feb 2003 16:17:11 GMT Received: from attrh1i.attrh.att.com ([135.71.62.10]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1RGGiX1013784 for ; Thu, 27 Feb 2003 11:17:08 -0500 (EST) Received: from OCCLUST02EVS1.ugd.att.com (135.71.164.8) by attrh1i.attrh.att.com (6.5.019) id 3E5CD82C00018EA0; Thu, 27 Feb 2003 11:16:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 11:14:28 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA616@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLeeAn82m7VqakWTYGHUmbZbkGt6wAACQAw From: "Brungard, Deborah A, ALABS" To: "Wijnen, Bert (Bert)" , "Kireeti Kompella" Cc: "Scott W Brim" , , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09942 Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify. One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond: 1. simple thank you for the information 2. here's the answer/clarification based on current work 3. for a quick answer, at the meeting, have a breakout group to address a proposal 4. for new work, send a response saying we invite contributions to our future meetings to progress - if no contributions, not anything is done (yes we have done this too) - at the next meeting, send several proposals to the other group for their review I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process. Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)? Deborah -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, February 27, 2003 10:47 AM To: Kireeti Kompella; Wijnen, Bert (Bert) Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Inline > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: donderdag 27 februari 2003 10:09 > To: Wijnen, Bert (Bert) > Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET > Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi Bert, > > On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: > > > No of course NOT. Many Liasons will want an answer. > > So we need a process to follow up and to track if a timely > > response has been (or will be) send. > > Is the IETF process for replying to liaison statements (and of > generating them) written down, say in some RFC? If so, could you > send me a pointer? > Unfortunately, I don't think the process for that has been defined. That is why I said that "we need a process..." We do not have it yet (I think... at least I do not know it either). I think we were all just hoping people would take responsibility and do the right things... but as we know that is how things fall through the cracks. > > But the Liasons communication between ITU and CCAMP/MPLS has not > > been going smoothly so far (even though we had good intentions). > > Responses have not gone out in time (or in some cases at all). > > I'll take full responsibility for that. > W.r.t. CCAMP I will share some of the responsibility too. I should also have kept a better eye on it. Bert > Thanks, > Kireeti. > From owner-mpls@UU.NET Thu Feb 27 11:52:29 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11164 for ; Thu, 27 Feb 2003 11:52:29 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwl08172 for ; Thu, 27 Feb 2003 16:56:23 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwl07361; Thu, 27 Feb 2003 16:56:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwl06644 for mpls-outgoing; Thu, 27 Feb 2003 16:55:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodwl06629 for ; Thu, 27 Feb 2003 16:55:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodwl06727 for ; Thu, 27 Feb 2003 16:54:14 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwl05858 for ; Thu, 27 Feb 2003 16:54:14 GMT Received: from mail.pel.panasonic.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.pel.panasonic.de [194.162.191.12]) id QQodwl05834 for ; Thu, 27 Feb 2003 16:54:13 GMT Received: from mcomvelg (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HAZ000MF88CXK@panasonic.de> for mpls@UU.NET; Thu, 27 Feb 2003 17:53:01 +0100 (MET) Date: Thu, 27 Feb 2003 17:53:01 +0100 From: Genadi Velev Subject: draft-kawakami-mpls-lsp-vlan-00.txt In-reply-to: <200302271243.HAA27425@ietf.org> To: mpls@UU.NET Cc: vlan-mpls@panasonic.de Reply-to: velev@panasonic.de Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [ Mail was delivered through VPN PEL->MEI/AVCDC! ] [ Mail was delivered through VPN PEL->MEI/AVCDC! ] [ Mail was delivered through VPN PEL->MEI/AVCDC! ] [ Mail was delivered through VPN PEL->MEI/AVCDC! ] Hi all, A new draft was published today (please see below). Any feedback and comments are welcome, especially from those of you who are dealing with packet transport over wide area Ethernet networks. thanks, Genadi > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, February 27, 2003 1:44 PM > To: IETF-Announce: > Cc: mpls@UU.NET > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Method to Setup LSP using VLAN Tag Switching > Author(s) : T. Kawakami et al. > Filename : draft-kawakami-mpls-lsp-vlan-00.txt > Pages : 15 > Date : 2003-2-26 > > This document describes a method to setup a Layer 2 tunnel over > networks based on Ethernet technology. For this purpose, the ports of > an Ethernet switch are configured to forward VLAN tag-labeled packets > incoming from a certain port to another unambiguous port by using > VLAN tag information. The Ethernet switches themselves are a part of > the Label Switching Routers (LSRs), which distribute the VLAN tags > using Label Distribution Protocol (LDP). To enable LDP to fulfil this > function, an LDP extension is proposed. The introduced method > simplifies the transport of Ethernet frames over wide area Ethernet > networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-kawakami-mpls-lsp-vlan-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mpls@UU.NET Thu Feb 27 12:01:51 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11608 for ; Thu, 27 Feb 2003 12:01:50 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwm10482 for ; Thu, 27 Feb 2003 17:05:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwm08876; Thu, 27 Feb 2003 17:04:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwm24476 for mpls-outgoing; Thu, 27 Feb 2003 17:04:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwm24453 for ; Thu, 27 Feb 2003 17:04:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodwm22126 for ; Thu, 27 Feb 2003 17:04:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwm21307 for ; Thu, 27 Feb 2003 17:04:07 GMT Received: from maile.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maile.telia.com [194.22.190.16]) id QQodwm21295 for ; Thu, 27 Feb 2003 17:04:06 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maile.telia.com (8.12.5/8.12.5) with ESMTP id h1RH35Sa011790; Thu, 27 Feb 2003 18:03:05 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1RH35228839; Thu, 27 Feb 2003 18:03:05 +0100 (CET) Message-ID: <3E5E43C0.1040406@pi.se> Date: Thu, 27 Feb 2003 17:58:40 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <2FEC2C81634CDB4C9F191943ACCDC624079AA616@OCCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Deborah, I suggested earlier that we describe (short) in the draft how we will handle liasions comeing into the IETF with request for changes or requirments related to the (g)mpls protocols. It needs to be understood that the internal IETF process is specified for IDs, and in some way we need bridge that gap. IETF and its working groups modifies IDs, and I don't think it is good idea to start modifying liasions from other SDOs. That we define the liasion process so it becoes crips and clear, and if when we are doing find that it has an impact on the change process, we updte or re-organize the the documents at that time. Would that work? I guess that the answer is - yes, but only as much (little) as needed. /Loa Brungard, Deborah A, ALABS wrote: >Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify. > >One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond: >1. simple thank you for the information >2. here's the answer/clarification based on current work >3. for a quick answer, at the meeting, have a breakout group to address a proposal >4. for new work, send a response saying we invite contributions to our future meetings to progress > - if no contributions, not anything is done (yes we have done this too) > - at the next meeting, send several proposals to the other group for their review > >I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process. > >Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)? > >Deborah > > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Thursday, February 27, 2003 10:47 AM >To: Kireeti Kompella; Wijnen, Bert (Bert) >Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > >Inline > > > >>-----Original Message----- >>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>Sent: donderdag 27 februari 2003 10:09 >>To: Wijnen, Bert (Bert) >>Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt >> >> >>Hi Bert, >> >>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: >> >> >> >>>No of course NOT. Many Liasons will want an answer. >>>So we need a process to follow up and to track if a timely >>>response has been (or will be) send. >>> >>> >>Is the IETF process for replying to liaison statements (and of >>generating them) written down, say in some RFC? If so, could you >>send me a pointer? >> >> >> >Unfortunately, I don't think the process for that has been defined. >That is why I said that "we need a process..." >We do not have it yet (I think... at least I do not know it either). >I think we were all just hoping people would take responsibility and >do the right things... but as we know that is how things fall through >the cracks. > > > >>>But the Liasons communication between ITU and CCAMP/MPLS has not >>>been going smoothly so far (even though we had good intentions). >>>Responses have not gone out in time (or in some cases at all). >>> >>> >>I'll take full responsibility for that. >> >> >> >W.r.t. CCAMP I will share some of the responsibility too. I should >also have kept a better eye on it. > >Bert > > >>Thanks, >>Kireeti. >> >> >> > > > > > > From owner-mpls@UU.NET Thu Feb 27 12:22:07 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12532 for ; Thu, 27 Feb 2003 12:22:06 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwn03075 for ; Thu, 27 Feb 2003 17:25:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwn28530; Thu, 27 Feb 2003 17:23:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwn27467 for mpls-outgoing; Thu, 27 Feb 2003 17:22:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwn27450 for ; Thu, 27 Feb 2003 17:22:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodwn08158 for ; Thu, 27 Feb 2003 17:22:01 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwn12164 for ; Thu, 27 Feb 2003 17:22:00 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQodwn12146 for ; Thu, 27 Feb 2003 17:22:00 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1RHLwQ20862 for ; Thu, 27 Feb 2003 12:21:59 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <1HW0BA1W>; Thu, 27 Feb 2003 12:21:58 -0500 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA8366@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "Betts, Malcolm [SKY:Q870:EXCH]" , Loa Andersson Cc: Stephen Trowbridge , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 12:21:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE84.BB433B30" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DE84.BB433B30 Content-Type: text/plain; charset="iso-8859-1" Just putting in my two cents. I'd like to support aspects of the liaison process being included in the draft. Given the close coupling between the change and liaison processes, and the issues that triggered generation of the draft, I believe we should bite the bullet and work to establish a cohesive process now. It will be well worth the effort. In my view, not expending the time now will result in far more time spent later. I'd also like to express support for the proposed revisions provided by Steve Trowbridge, as I believe they increase the value of the draft by adding necessary clarifications and promoting a cooperative spirit to the entire endeavor. Eve Varma -----Original Message----- From: Malcolm Betts [mailto:betts01@nortelnetworks.com] Sent: Thursday, February 27, 2003 8:11 AM To: 'Loa Andersson' Cc: Stephen Trowbridge; Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Loa, the from the outside looking in the liaison process and the change process are closely coupled. The liaison process is described in ITU-T Recommendation A.4 and A.5 and in RFC 3356. The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on requirements agreed by the members of the Study Group (that originated the liaison). The change process being proposed requires that this official request from a SDO is converted into an individuals ID. The level of agreement in the SDO is therefore obscured, this process appears to be in conflict with RFC 3356. The problem is particularly acute when the requirements are to enable (or enhance) the management of a non IP network to support a non IP client. If my understanding of the draft is correct such requests would be rejected by the IETF. It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications. The IETF plays a key role in ensuring that the integrity of the base protocols is not compromised. Malcolm Betts Phone: +1 613 763 7860 (ESN 393) FAX: +1 613 763 6608 (ESN 393) email: betts01@nortelnetworks.com -----Original Message----- From: Loa Andersson [ mailto:loa@pi.se ] Sent: Thursday, February 27, 2003 7:33 AM To: Kireeti Kompella Cc: Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs. /Loa ------_=_NextPart_001_01C2DE84.BB433B30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Just=20 putting in my two cents.  I'd like to support aspects of the = liaison=20 process being included in the draft.  Given the close coupling = between=20 the
change=20 and liaison processes, and the issues that triggered = generation of=20 the draft, I believe we should bite the bullet and work to establish a = cohesive=20 process now.
It=20 will be well worth the effort.  In my view, not = expending=20 the time now will result in far more time spent=20 later.
 
I'd=20 also like to express support for the proposed = revisions provided by=20 Steve Trowbridge,  as I believe they increase the value = of the=20 draft by adding necessary clarifications and promoting a = cooperative spirit=20 to the entire endeavor.
 
Eve=20 Varma
 
=  

-----Original=20 Message-----
From: = Malcolm=20 Betts [mailto:betts01@nortelnetworks.com]
Sent: Thursday, February 27, = 2003 8:11=20 AM
To: 'Loa=20 Andersson'
Cc: = Stephen=20 Trowbridge; Kireeti Kompella; ccamp@ops.ietf.org; = mpls@UU.NET
Subject: RE: I-D=20 ACTION:draft-andersson-mpls-g-chng-proc-00.txt

 

Loa, the from the outside = looking in the=20 liaison process and the change process are closely coupled.  The = liaison=20 process is described in ITU-T Recommendation A.4 and A.5 and in RFC=20 3356. 

The coupling occurs because = the ITU uses=20 the agreed liaison process to communicate requests to modify IETF = protocols=20 based on requirements agreed by the members of the Study Group (that=20 originated the liaison).  The change process being proposed = requires that=20 this official request from a SDO is converted into an individuals = ID. =20 The level of agreement in the SDO is therefore obscured, this process = appears=20 to be in conflict with RFC 3356.  The problem is particularly = acute when=20 the requirements are to enable (or enhance) the management of a non = IP network=20 to support a non IP client.  If my understanding of the draft is = correct=20 such requests would be rejected by the IETF.

It is clearly beneficial to = the industry=20 if the basic IETF protocols can be extended to address such=20 applications.  The IETF plays a key role in ensuring that the = integrity=20 of the base protocols is not compromised.

Malcolm = Betts

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

 

-----Original=20 Message-----=20
From: Loa Andersson [mailto:loa@pi.se]
Sent: = Thursday, February=20 27, 2003 7:33 AM=20
To: Kireeti = Kompella
Cc: Stephen = Trowbridge;=20 ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: I-D=20 ACTION:draft-andersson-mpls-g-chng-proc-00.txt
<snip>

I think I've clearly pointed = out the=20 limited scope of the change process, recognized that there is a = orthogonal=20 problem on how we treats liasions coming into the ietf, that the = liasion=20 process needs to be documented, and that we will add text to address = the=20 limited intersection of the change-process and liasion process in = order to=20 promote the cooperation with other SDOs.

/Loa

<snip>

------_=_NextPart_001_01C2DE84.BB433B30-- From owner-mpls@UU.NET Thu Feb 27 12:29:09 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13009 for ; Thu, 27 Feb 2003 12:29:08 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwo15121 for ; Thu, 27 Feb 2003 17:33:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwo13406; Thu, 27 Feb 2003 17:32:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwo28253 for mpls-outgoing; Thu, 27 Feb 2003 17:31:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodwo28243 for ; Thu, 27 Feb 2003 17:31:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodwo22747 for ; Thu, 27 Feb 2003 17:31:20 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwo13119 for ; Thu, 27 Feb 2003 17:31:18 GMT Received: from w2ksjexg01.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.7.169.25]) id QQodwo13087 for ; Thu, 27 Feb 2003 17:31:18 GMT Received: from wntcsdexg01.csd.ciena.com ([10.34.31.31]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FN36Z658; Thu, 27 Feb 2003 09:31:00 -0800 Received: by webdev-llnt.oni.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 09:31:16 -0800 Message-ID: <2135200C183FD5119588009027DE572302836D53@webdev-owa.oni.com> From: "Ong, Lyndon" To: "'Loa Andersson'" , "Brungard, Deborah A, ALABS" Cc: "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 09:31:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can I ask a clarifying question regarding liaisons? The issue revolves around making extensions to GMPLS. Is it the view that such extensions must be generated through Internet Drafts, and cannot be through liaisons? It sounds like people may be assuming that liaisons are always providing background information or requesting information, when on occasion a liaison may be requesting a change or action. BTW, regarding responses to liaisons, the A-D may or may not be the proper source for a response, but the knowledge for putting together the response would typically reside within a particular WG, I believe. One problem is that you don't have the time within an IETF meeting to assign a "stuckie" (to use the new term) to write a response ;o) Cheers, Lyndon From owner-mpls@UU.NET Thu Feb 27 12:36:35 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13416 for ; Thu, 27 Feb 2003 12:36:35 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwo00127 for ; Thu, 27 Feb 2003 17:40:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwn06395; Thu, 27 Feb 2003 17:27:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwn27864 for mpls-outgoing; Thu, 27 Feb 2003 17:27:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwn27859 for ; Thu, 27 Feb 2003 17:27:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodwn29617 for ; Thu, 27 Feb 2003 17:27:15 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwn08785 for ; Thu, 27 Feb 2003 17:27:15 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodwn08769 for ; Thu, 27 Feb 2003 17:27:14 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1RHRBJR010485 for ; Thu, 27 Feb 2003 12:27:11 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA21383 for ; Thu, 27 Feb 2003 12:27:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1RHRAE12368 for mpls@uu.net; Thu, 27 Feb 2003 12:27:10 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodwn27620 for ; Thu, 27 Feb 2003 17:25:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodwn14450 for ; Thu, 27 Feb 2003 17:25:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwn15207 for ; Thu, 27 Feb 2003 17:25:35 GMT Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.54]) id QQodwn15202 for ; Thu, 27 Feb 2003 17:25:35 GMT Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1RHPN6N018199; Thu, 27 Feb 2003 09:25:23 -0800 (PST) Received: from cisco.com (sjc-vpn1-561.cisco.com [10.21.98.49]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AEK37136; Thu, 27 Feb 2003 09:08:34 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Thu, 27 Feb 2003 12:25:17 -0500 Date: Thu, 27 Feb 2003 12:25:16 -0500 From: Scott W Brim To: Loa Andersson Cc: "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030227172516.GJ2120@sbrim-w2k> Mail-Followup-To: Scott W Brim , Loa Andersson , "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET References: <2FEC2C81634CDB4C9F191943ACCDC624079AA616@OCCLUST02EVS1.ugd.att.com> <3E5E43C0.1040406@pi.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5E43C0.1040406@pi.se> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Loa, On Thu, Feb 27, 2003 05:58:40PM +0100, Loa Andersson allegedly wrote: > It needs to be understood that the internal IETF process is specified > for IDs, and in some way we need bridge that gap. IETF and its working > groups modifies IDs, and I don't think it is good idea to start > modifying liasions from other SDOs. But > Brungard, Deborah A, ALABS wrote: > >One comment on all of this from an ITU/T1X1 history, it is difficult > >to say apriori how a liaison will be processed. We do not have such a > >process either. Several ways exist to respond: > >1. simple thank you for the information > >2. here's the answer/clarification based on current work > >3. for a quick answer, at the meeting, have a breakout group to > > address a proposal > >4. for new work, send a response saying we invite contributions to > > our future meetings to progress > > - if no contributions, not anything is done (yes we have done this > > too) > > - at the next meeting, send several proposals to the other group > > for their review There is no incompatibility. Among a rich set of possible responses, bullet 4 covers what you were looking for above. From owner-mpls@UU.NET Thu Feb 27 12:41:15 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13556 for ; Thu, 27 Feb 2003 12:41:15 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwp05292 for ; Thu, 27 Feb 2003 17:45:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwo04449; Thu, 27 Feb 2003 17:44:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwo29421 for mpls-outgoing; Thu, 27 Feb 2003 17:44:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodwo29402 for ; Thu, 27 Feb 2003 17:44:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodwo18273 for ; Thu, 27 Feb 2003 17:44:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwo05112 for ; Thu, 27 Feb 2003 17:44:09 GMT Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodwo05082 for ; Thu, 27 Feb 2003 17:44:08 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1RHi6Nh010367 for ; Thu, 27 Feb 2003 12:44:06 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA22697 for ; Thu, 27 Feb 2003 12:44:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1RHi5216292 for mpls@uu.net; Thu, 27 Feb 2003 12:44:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodwo29031 for ; Thu, 27 Feb 2003 17:41:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodwo01535 for ; Thu, 27 Feb 2003 17:41:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwo01256 for ; Thu, 27 Feb 2003 17:41:05 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodwo01201 for ; Thu, 27 Feb 2003 17:41:03 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA34672; Thu, 27 Feb 2003 12:39:09 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302271739.MAA34672@workhorse.fictitious.org> To: "Wijnen, Bert (Bert)" cc: Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Thu, 27 Feb 2003 16:46:56 +0100." <7D5D48D2CAA3D84C813F5B154F43B15501062F74@nl0006exch001u.nl.lucent.com> Date: Thu, 27 Feb 2003 12:39:08 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <7D5D48D2CAA3D84C813F5B154F43B15501062F74@nl0006exch001u.nl.lucent.c om>, "Wijnen, Bert (Bert)" writes: > Inline > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: donderdag 27 februari 2003 10:09 > > To: Wijnen, Bert (Bert) > > Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET > > Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > > Hi Bert, > > > > On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: > > > > > No of course NOT. Many Liasons will want an answer. > > > So we need a process to follow up and to track if a timely > > > response has been (or will be) send. > > > > Is the IETF process for replying to liaison statements (and of > > generating them) written down, say in some RFC? If so, could you > > send me a pointer? > > > Unfortunately, I don't think the process for that has been defined. > That is why I said that "we need a process..." > We do not have it yet (I think... at least I do not know it either). > I think we were all just hoping people would take responsibility and > do the right things... but as we know that is how things fall through > the cracks. > > > > But the Liasons communication between ITU and CCAMP/MPLS has not > > > been going smoothly so far (even though we had good intentions). > > > Responses have not gone out in time (or in some cases at all). > > > > I'll take full responsibility for that. > > > W.r.t. CCAMP I will share some of the responsibility too. I should > also have kept a better eye on it. > > Bert > > Thanks, > > Kireeti. To be honest, I think there is a process. IETF recognizes individuals, not organizations. A liason may present a liason statement in an IETF meeting or send it to a WG (or other) mailing list but like any other type of organization the individual is recognized, not the organization. That same person is free to take impressions back to their organization. The IETF believes in running code and rough consensus. Too much standardization occurs without running code (and preferably also at least trial deployment) and too much gets standardized committee style and ends up not working (quite often protocols can't be deployed because they don't scale, often predicted but the standards body marched forward despite technical objections related to scaling). If the ITU wants to work that way fine. At least the IETF wants to make sure there are clear requirements before pursuing much effort toward standardization in advance of running and deployed code. The chng-proc draft clarifies this and puts procedure in place toward that end. It is also worth noting that if you have deployed code you have good evidence that there was a requirement and there should be empirical evicence related to the solution's ability to meet the requirement. Curtis From owner-mpls@UU.NET Thu Feb 27 12:42:21 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13600 for ; Thu, 27 Feb 2003 12:42:21 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwp07333 for ; Thu, 27 Feb 2003 17:46:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwp05883; Thu, 27 Feb 2003 17:45:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwo29430 for mpls-outgoing; Thu, 27 Feb 2003 17:44:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwo29425 for ; Thu, 27 Feb 2003 17:44:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodwo11116 for ; Thu, 27 Feb 2003 17:44:31 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwo29457 for ; Thu, 27 Feb 2003 17:44:31 GMT Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQodwo29444 for ; Thu, 27 Feb 2003 17:44:30 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/21/02) with ESMTP id CAA08842 for ; Fri, 28 Feb 2003 02:44:29 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp ([127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h1RHiSOO009054 for ; Fri, 28 Feb 2003 02:44:28 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.6/8.12.6) with ESMTP id h1RHiRFb016941 for ; Fri, 28 Feb 2003 02:44:27 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id CAA21562; Fri, 28 Feb 2003 02:44:26 +0900 (JST) Received: from barrister.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id CAA12010; Fri, 28 Feb 2003 02:44:25 +0900 (JST) Message-Id: <5.0.2.5.2.20030228024230.06268c70@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Fri, 28 Feb 2003 02:48:08 +0900 To: mpls@UU.NET From: Seisho Yasukawa Subject: Re: I-D ACTION:draft-yasukawa-mpls-p2mp-requirement-00.txt Cc: yasukawa.seisho@lab.ntt.co.jp, inoue.ichiro@lab.ntt.co.jp In-Reply-To: <200302271244.HAA27616@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hello everyone, Please find following draft. "Requirements for Point-to-Multipoint capability extension to MPLS" A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-requirement-00.txt We produce this draft to make P2MP target and requirement more clearly. We welcome any comments and feedbacks. Thanks Seisho From owner-mpls@UU.NET Thu Feb 27 12:59:19 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14106 for ; Thu, 27 Feb 2003 12:59:19 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwq23667 for ; Thu, 27 Feb 2003 18:03:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwq22668; Thu, 27 Feb 2003 18:02:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwq09853 for mpls-outgoing; Thu, 27 Feb 2003 18:02:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodwq08453 for ; Thu, 27 Feb 2003 18:02:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodwq06002 for ; Thu, 27 Feb 2003 18:01:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwq21314 for ; Thu, 27 Feb 2003 18:01:48 GMT Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQodwq21307 for ; Thu, 27 Feb 2003 18:01:47 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZGF02>; Thu, 27 Feb 2003 10:01:42 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972269@nimbus> From: John Drake To: "'Kireeti Kompella'" , Stephen Trowbridge Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 10:01:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, Extremely well reasoned and thoughtful. As I understand it, this document is intended to prevent the situation that just occured, in which the IETF published an RFC which detailed some changes to RSVP-TE (which had technical issues) without any review by the CCAMP or MPLS working groups, thereby explicitly appearing to endorse these changes. The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that the CCAMP working group wanted to work on the ASON extensions, so I am still puzzled as to why the authors of the ASON draft decided, after the Yokohama meeting, to progress the draft as an informational RFC rather than as a normal working group draft. Thanks, John ============================================================================ ==================================== "Minute takers were volunteered (Josh Broch and Eric Gray) Snipped... Osama Aboul-Magd presented status on his draft on ASON extensions to CR-LDP. He asked if the WG would accept this as a WG draft. Kireeti pointed out that there is a meta discussion on the issue of progressing both CR-LDP and RSVP-TE in the MPLS working group tomorrow and suggested that the discussion should be taken to the mailing list after that has been addressed. Snipped... Dimitri Papadimitriou discussed work on ASON extensions to RSVP-TE. He asked if the WG believes this to be valuable work and should eventually be put forward to the ITU. Kireeti talked about the need to work out the relationship with the ITU on these issues. Choy asked why the work does nt include call/connection information. Kireeti said that the functional specification should first capture the solution independent requirements. Stephen Trowbridge asked what further information the IETF requires. Dimitri and Kireeti answered the question in detail." ============================================================================ ==================================== > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, February 27, 2003 12:57 AM > To: Stephen Trowbridge > Cc: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi Steve, > > On Wed, 26 Feb 2003, Stephen Trowbridge wrote: > > > However, as Deborah, Kireeti, and Scott > > have observed, the way it is written it seems to hinder rather than > > help the process of collaborating with other Standards Developement > > Organizations(SDOs) > > If this is the impression that my comments gave, I must have used the > wrong words. The GMPLS change document is intended to help other SDOs > understand the change process, and as such *help* collaboration. > > > and doesn't provide a good way to deal with and respond > > to liaison statements, which is the avenue by which many of these > > requests will arrive from other SDOs. > > This I agree with. But as Loa pointed out, it was not the intent of > the gmpls change doc to address this issue -- that is the domain of > a different document; and as several people have pointed out by now, > the change document is very specific (a small set of WGs), whereas > a liaison document should probably be much broader (IETF-wide). > > > The document as > > written creates impediments to the ability to apply, and extend as > > necessary, these protocols to new problem spaces. > > I don't see this at all. The IETF does have processes, for example, > RFC 2026. So (I assume) does the ITU. Most would consider writing > down a process for change, especially with the intent of maintaining > architectural soundness, a Good Thing, not an impediment. Process > does on occasion slow things down. Sometimes that is laudable -- > deliberation vs haste; sometimes that is a price one pays in return > for avoiding chaos. It takes longer for me to hang up my > clothes rather > than throw them on the floor -- but I opt to hang them up. > > > As noted, biggest flaw seems to be the way in which the > document deals > > with new applications or requirements identified by > external standards > > organizations. In addition to not recognizing that this > information may > > come to IETF via liaison statements, > > Let's take these one at a time. A liaison statement (LS) has not been > heretofore a replacement for an ID. A LS of the form "we invite you > to take part in such-and-such meeting" or "we would like to bring to > your attention such-and-such work" are fine uses (in my opinion) for > LSs. However, if an SDO thinks that x, y and z are requirements for > protocol foo, communicating this solely via a liaison statement is not > (again, IMO) the right approach. Requirements need to be discussed, > possibly modified, and captured in some permanent form. There is a > well established process in the IETF for that; introducing a new > vehicle for that process is neither necessary nor appropriate, at > least without a revision of 2026 that states this. It is not the > intent of the gmpls change process to at the same time change the > IETF's process and to update 2026. > > > the document seems not to consider > > the fact that there may be a valid application that is > outside of the > > scope of IETF (and in the scope of another standards development > > organization) to which the (G)MPLS protocols may be applied, and for > > which the (G)MPLS protocols may require extension. > > Not at all true. > > > By insisting that > > every possible extension be done internally in IETF, the IETF either > > (1) Extends the scope of its work without bound; or (2) Needlessly > > restricts the application of its protocols. Neither one of these is > > good for IETF or for the Standards Development community at large. > > The reason for insisting that extensions be done in the IETF is: > (a) the IETF developed the protocols, knows them best, and knows the > bigger architectural picture in which they fit. A good example > is the (unnecessary) deprecation of RSVP messages in a recent RFC. > (b) when all is said and done, the IETF does own the protocols. > > It is instructive to harken back to how CCAMP took extraordinary pains > *not* to change the SDH spec, nor even to give the impression > of such a > change. There was a clear recognition that SDH "belonged" to the ITU, > and when representatives felt that there was "intrusion", even if > unintended, CCAMP stepped back. There were two reasons for this: we > recognized that we (as an SDO, not as individuals) didn't have the > expertise; and we wanted to maintain cordial relations. > > > One reality that this draft fails to recognize is that, > while IETF may > > be able to say "no" to standardizing something proposed by > an individual, > > it does not have the ability (or the right) to say "no" to something > > proposed by another Standards Development Organization. As > a practical > > matter, the IETF is not the only place where something can > be standardized. > > I agree that the IETF cannot stop other SDOs from extending its > protocols; it can (I believe) insist that such modified > protocols use a > new name to call out the differences. > > However, the problem that the change document addresses is not what > other SDOs are doing, but what the IETF should be doing. As far as > other SDOs are concerned, they can decide on their own to abide by > the IETF's rules if they want, or to forge ahead on their own, at > the risk (which they may consider worthwhile) of marring > their relations > with the IETF. > > > If the IETF creates impediments to applying IETF protocols to > > the application space of another standards development organization, > > there is really nothing that the IETF can do to prevent > that the other > > organization standardizes something themselves. The result > would tend > > to be a proliferation of (G)MPLS "like" protocols instead > of a coherent > > suite of protocols with broad applicability. This result > would not be > > good for the IETF or the industry in general. > > There is already a proliferation of GMPLS like protocols. The OIF > has its own; the ITU is developing its own. It is not the intention > of the change document to stop this, nor to create impediments. But > there is the (fond!) hope that with such a change document in place, > other SDOs will say -- "hey, instead of changing the > protocols ourselves, > there is this process whereby we can take our requirements to the IETF > and get the experts who really know that protocol to change it to meet > our needs." > > > A better approach would be for the IETF to PROMOTE the use of its > > protocols for new applications > > Far be it for me to say what the IETF should or should not > do. However, > I personally don't think the IETF should promote its > protocols. In the > final analysis, the IETF is concerned with running (and promoting) the > Internet. Any protocols it designs should have that as the end goal. > > > and, when another Standards Development > > Organization wishes to apply (G)MPLS protocols to an > application domain > > outside of the scope of IETF, that IETF will (1) assist > with the development > > of any necessary extensions; and (2) to facilitate documentation of > > such new applications and extensions in a central place (e.g., by > > informational RFC, even for extensions that are developed outside of > > IETF) and to insure that code points are assigned in a > coherent manner > > through IANA to avoid collisions where different extensions may use > > the same code points to indicate different things. > > If the IETF is convinced that such extensions will in some way help > to achieve its own goals AND will not hurt the protocol, the IETF can > and should undertake the activity. If the extensions do not match > the IETF's goals, but they don't hurt the protocol, there should be > a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to > yield the floor to some other SDO. > > > The difference in flavor for what I am proposing is that IETF should > > try to position itself as a Clearinghouse for (G)MPLS > protocol extensions > > rather than as a Gatekeeper for (G)MPLS protcol extensions. > > The Gatekeeper function is for the case where the said extensions do > hurt the protocol (in the eyes of the IETF). This is where the SDO > can decide, as you point out, that it can do it on its own, but > changes the name of the protocol so that innocent bystanders can tell > the difference. > > Kireeti. > From owner-mpls@UU.NET Thu Feb 27 13:01:04 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14205 for ; Thu, 27 Feb 2003 13:01:04 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodvx03818; Thu, 27 Feb 2003 13:16:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQodvx24822 for mpls-outgoing; Thu, 27 Feb 2003 13:16:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodvx24817 for ; Thu, 27 Feb 2003 13:16:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodvx24997 for ; Thu, 27 Feb 2003 13:16:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvx16473 for ; Thu, 27 Feb 2003 13:16:08 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodvx16446 for ; Thu, 27 Feb 2003 13:16:07 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1RDG4Nh014137 for ; Thu, 27 Feb 2003 08:16:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA29416 for ; Thu, 27 Feb 2003 08:16:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1RDG4223516 for mpls@uu.net; Thu, 27 Feb 2003 08:16:04 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodvw24337 for ; Thu, 27 Feb 2003 13:14:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodvw00616 for ; Thu, 27 Feb 2003 13:13:42 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodvw12895 for ; Thu, 27 Feb 2003 13:13:42 GMT Received: from sj-msg-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.54]) id QQodvw12873 for ; Thu, 27 Feb 2003 13:13:41 GMT Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1RDDc6N001454; Thu, 27 Feb 2003 05:13:38 -0800 (PST) Received: from cisco.com (sjc-vpn1-561.cisco.com [10.21.98.49]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AEK27114; Thu, 27 Feb 2003 04:56:54 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Thu, 27 Feb 2003 08:13:36 -0500 Date: Thu, 27 Feb 2003 08:13:36 -0500 From: Scott W Brim To: "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030227131336.GK2572@sbrim-w2k> Mail-Followup-To: Scott W Brim , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, mpls@UU.NET References: <7D5D48D2CAA3D84C813F5B154F43B15501062D7E@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501062D7E@nl0006exch001u.nl.lucent.com> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Feb 27, 2003 01:22:01AM +0100, Bert allegedly wrote: > > Liaisons are an IETF-wide issue. > > > YES. > > > I think if we want to send a liaison to another group, the AD just sends > > e-mail, and archives it on ietf.org. That's just an administrative > > matter, nothing we even need a draft for. > > > It is not always the AD who sends. It could be a WG. Or whole IETF. Liaisons can be *generated* anywhere, but should be *sent* through a predictable agent. Having the IETF Chair, or "the whole IETF", send a liaison is too general -- liaisons need to be more focused than that to be useful. Individual WGs could send individual liaisons but I believe the AD level would be better for the usual reasons, coordination, an integrative view, etc. > > Incoming liaisons take a little more policy but not much. We want them > > archived, so just saying "submit a draft" isn't good enough. I'm afraid > > we need to provide mailto:ietf-liaisons@ietf.org, and yet another folder > > on the web pages. All ADs get to hear about all incoming liaisons, and > > if they think it's appropriate for one of their WGs they forward it. > > Done? > > > No of course NOT. Many Liasons will want an answer. > So we need a process to follow up and to track if a timely > response has been (or will be) send. I do not believe any organization is obligated to reply to everything that requests a reply (just think about the spam you get). If the AD and/or one or more WGs find the liaison (and the idea of replying to it) interesting and useful, then they will reply. The process for keeping track of this is at the AD level. ..swb From owner-mpls@UU.NET Thu Feb 27 13:13:49 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14723 for ; Thu, 27 Feb 2003 13:13:49 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwr19655 for ; Thu, 27 Feb 2003 18:17:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwr18906; Thu, 27 Feb 2003 18:17:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwr20089 for mpls-outgoing; Thu, 27 Feb 2003 18:16:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodwr20082 for ; Thu, 27 Feb 2003 18:16:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodwr21963 for ; Thu, 27 Feb 2003 18:16:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwr13768 for ; Thu, 27 Feb 2003 18:16:41 GMT Received: from gwngate.homelinux.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ool-43547318.dyn.optonline.net [67.84.115.24]) id QQodwr13757 for ; Thu, 27 Feb 2003 18:16:41 GMT Received: from bigguy ([192.168.0.7] helo=ieee.org) by gwngate.homelinux.org with esmtp (Exim 3.35 #1 (Debian)) id 18oSa9-0001dv-00; Thu, 27 Feb 2003 13:16:33 -0500 Message-ID: <3E5E55FF.4030809@ieee.org> Date: Thu, 27 Feb 2003 13:16:31 -0500 From: George Newsome User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: John Drake CC: "'Kireeti Kompella'" , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <9D42C6E086250248810DCADA39CE7EFC972269@nimbus> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John Drake wrote: > Snipped... > > Stephen Trowbridge asked what further information the IETF requires. > > Dimitri and Kireeti answered the question in detail." > And the answer was ???? A pity that the detailed answer is apparently not minuted. George From owner-mpls@UU.NET Thu Feb 27 13:22:26 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15132 for ; Thu, 27 Feb 2003 13:22:26 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwr05373 for ; Thu, 27 Feb 2003 18:26:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwr03648; Thu, 27 Feb 2003 18:25:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwr20400 for mpls-outgoing; Thu, 27 Feb 2003 18:24:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwr20392 for ; Thu, 27 Feb 2003 18:24:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodwr25578 for ; Thu, 27 Feb 2003 18:24:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwr24192 for ; Thu, 27 Feb 2003 18:24:11 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodwr24178 for ; Thu, 27 Feb 2003 18:24:11 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1RIO8JR014280 for ; Thu, 27 Feb 2003 13:24:09 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA25868 for ; Thu, 27 Feb 2003 13:24:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1RIO8T21335 for mpls@uu.net; Thu, 27 Feb 2003 13:24:08 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwr20324 for ; Thu, 27 Feb 2003 18:22:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodwr17894 for ; Thu, 27 Feb 2003 18:22:23 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwr20005 for ; Thu, 27 Feb 2003 18:22:22 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodwr19989 for ; Thu, 27 Feb 2003 18:22:21 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA35035; Thu, 27 Feb 2003 13:20:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302271820.NAA35035@workhorse.fictitious.org> To: "Ong, Lyndon" cc: "'Loa Andersson'" , "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Thu, 27 Feb 2003 09:31:12 PST." <2135200C183FD5119588009027DE572302836D53@webdev-owa.oni.com> Date: Thu, 27 Feb 2003 13:20:24 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <2135200C183FD5119588009027DE572302836D53@webdev-owa.oni.com>, "Ong, Lyndon" writes: > Hi, > > Can I ask a clarifying question regarding liaisons? The > issue revolves around making extensions to GMPLS. Is > it the view that such extensions must be generated > through Internet Drafts, and cannot be through > liaisons? > > It sounds like people may be assuming that liaisons are > always providing background information or requesting > information, when on occasion a liaison may be requesting > a change or action. > > BTW, regarding responses to liaisons, the A-D may or may > not be the proper source for a response, but the knowledge > for putting together the response would typically reside > within a particular WG, I believe. One problem is that > you don't have the time within an IETF meeting to assign > a "stuckie" (to use the new term) to write a response ;o) > > Cheers, > > Lyndon The way you initiate action within the IETF is to submit an internet draft. The liason response from the IETF should simply be to send a copy of rfc2026 and invite participants of the other forum to participate in the IETF process. Curtis From owner-mpls@UU.NET Thu Feb 27 13:31:54 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15458 for ; Thu, 27 Feb 2003 13:31:54 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodws09353 for ; Thu, 27 Feb 2003 18:35:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodws08663; Thu, 27 Feb 2003 18:35:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQodws21149 for mpls-outgoing; Thu, 27 Feb 2003 18:35:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodws21133 for ; Thu, 27 Feb 2003 18:35:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodws25207 for ; Thu, 27 Feb 2003 18:34:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodws07432 for ; Thu, 27 Feb 2003 18:34:11 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQodws07426 for ; Thu, 27 Feb 2003 18:34:10 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1RIMn56013326; Thu, 27 Feb 2003 10:22:49 -0800 (PST) Message-Id: <200302271822.h1RIMn56013326@sj-msg-core-1.cisco.com> To: Loa Andersson cc: Kireeti Kompella , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of Thu, 27 Feb 2003 13:32:35 +0100. <3E5E0563.9060303@pi.se> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 27 Feb 2003 13:22:48 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk It seems to me that Loa's document simply describes how the IETF works. As such, I'm not sure it is even necessary. True, many people have noticed that the IETF is free to ignore the work of other standard organizations. True, the fact that a particular proposal is made by another standards organization does not even give the proposal any special weight in the IETF. I think these are good things, and the IETF should not make any changes in this respect. Hence I don't think Loa's draft (if it needs to exist) needs to change. Certainly the fact that some position is articulated in a "liaison statement" should not give it any special weight. The fact that some position is supported by "a threshold number of vendors and SPs" shouldn't give it any special weight either. From owner-mpls@UU.NET Thu Feb 27 13:40:30 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15787 for ; Thu, 27 Feb 2003 13:40:30 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodws24536 for ; Thu, 27 Feb 2003 18:44:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodws23304; Thu, 27 Feb 2003 18:43:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQodws21518 for mpls-outgoing; Thu, 27 Feb 2003 18:43:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodws21511 for ; Thu, 27 Feb 2003 18:43:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodws10512 for ; Thu, 27 Feb 2003 18:41:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodws20169 for ; Thu, 27 Feb 2003 18:41:52 GMT Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQodws20159 for ; Thu, 27 Feb 2003 18:41:51 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZGGDN>; Thu, 27 Feb 2003 10:41:46 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97226B@nimbus> From: John Drake To: "'George Newsome'" Cc: "'Kireeti Kompella'" , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 10:41:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk George, I didn't attend. Thanks, John > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Thursday, February 27, 2003 10:17 AM > To: John Drake > Cc: 'Kireeti Kompella'; Stephen Trowbridge; ccamp@ops.ietf.org; > mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > John Drake wrote: > > > > Snipped... > > > > Stephen Trowbridge asked what further information the IETF > requires. > > > > Dimitri and Kireeti answered the question in detail." > > > > > And the answer was ???? > > A pity that the detailed answer is apparently not minuted. > > George > From owner-mpls@UU.NET Thu Feb 27 14:03:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17201 for ; Thu, 27 Feb 2003 14:03:07 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwu22076 for ; Thu, 27 Feb 2003 19:07:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwu21268; Thu, 27 Feb 2003 19:06:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwu11505 for mpls-outgoing; Thu, 27 Feb 2003 19:06:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwu11500 for ; Thu, 27 Feb 2003 19:06:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodwu20687 for ; Thu, 27 Feb 2003 19:06:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwu28932 for ; Thu, 27 Feb 2003 19:06:06 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQodwu28912 for ; Thu, 27 Feb 2003 19:06:05 GMT Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1RJ64517815 for ; Thu, 27 Feb 2003 14:06:04 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 13:44:37 -0500 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA8370@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'erosen@cisco.com'" , Loa Andersson Cc: Kireeti Kompella , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 13:44:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, The conversation that's being stimulated from the draft gets to the crux of the issue I see with its current wording. The draft is being interpreted as simply describing the present IETF mode of operation. I didn't think that was supposed to be the intent. Eve -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Thursday, February 27, 2003 1:23 PM To: Loa Andersson Cc: Kireeti Kompella; Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt It seems to me that Loa's document simply describes how the IETF works. As such, I'm not sure it is even necessary. True, many people have noticed that the IETF is free to ignore the work of other standard organizations. True, the fact that a particular proposal is made by another standards organization does not even give the proposal any special weight in the IETF. I think these are good things, and the IETF should not make any changes in this respect. Hence I don't think Loa's draft (if it needs to exist) needs to change. Certainly the fact that some position is articulated in a "liaison statement" should not give it any special weight. The fact that some position is supported by "a threshold number of vendors and SPs" shouldn't give it any special weight either. From owner-mpls@UU.NET Thu Feb 27 14:15:42 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17532 for ; Thu, 27 Feb 2003 14:15:42 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwv14620 for ; Thu, 27 Feb 2003 19:19:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwv13512; Thu, 27 Feb 2003 19:18:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwv13238 for mpls-outgoing; Thu, 27 Feb 2003 19:18:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodwv13233 for ; Thu, 27 Feb 2003 19:18:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodwv12490 for ; Thu, 27 Feb 2003 19:18:09 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwv07066 for ; Thu, 27 Feb 2003 19:18:08 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodwv07051 for ; Thu, 27 Feb 2003 19:18:08 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1RJI5JR018212 for ; Thu, 27 Feb 2003 14:18:05 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01009 for ; Thu, 27 Feb 2003 14:18:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1RJI5W28360 for mpls@uu.net; Thu, 27 Feb 2003 14:18:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodwv13169 for ; Thu, 27 Feb 2003 19:16:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodwv01916 for ; Thu, 27 Feb 2003 19:16:13 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwv10513 for ; Thu, 27 Feb 2003 19:16:12 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodwv10481 for ; Thu, 27 Feb 2003 19:16:11 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA35772; Thu, 27 Feb 2003 14:14:23 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302271914.OAA35772@workhorse.fictitious.org> To: erosen@cisco.com cc: Loa Andersson , Kireeti Kompella , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Thu, 27 Feb 2003 13:22:48 EST." <200302271822.h1RIMn56013326@sj-msg-core-1.cisco.com> Date: Thu, 27 Feb 2003 14:14:22 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200302271822.h1RIMn56013326@sj-msg-core-1.cisco.com>, Eric Rosen wr ites: > > It seems to me that Loa's document simply describes how the IETF works. As > such, I'm not sure it is even necessary. > > True, many people have noticed that the IETF is free to ignore the work of > other standard organizations. True, the fact that a particular proposal is > made by another standards organization does not even give the proposal any > special weight in the IETF. > > I think these are good things, and the IETF should not make any changes in > this respect. Hence I don't think Loa's draft (if it needs to exist) needs > to change. > > Certainly the fact that some position is articulated in a "liaison > statement" should not give it any special weight. The fact that some > position is supported by "a threshold number of vendors and SPs" shouldn't > give it any special weight either. Eric, I completely agree with you but would like to make one clarification. The "number of vendors and SPs" should not be given any weight at all in toward the rough consensus criteria. However, implementation by vendors and deployment by SPs should be given strong consideration regarding whether there exists any "running code" and "independent interoperable implementations". The IETF shouldn't care who you think you are or who you work for if you don't show up with running code. This eliminates committee contributions such as study groups with a spec and no code or deployment (and sometimes no valid requirement). The number of internet-drafts that were not advanced due to not having concensus on a requirements statement is quite large. Few rejected on that grounds resurfaced later when a need became evident and extremely few resurfaced and were later implemented. Diffserv-TE is about the only set of drafts to get pushed back, resurface, and get implemented and this was not a liason work. Curtis From owner-mpls@UU.NET Thu Feb 27 17:17:49 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26198 for ; Thu, 27 Feb 2003 17:17:49 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxh13250 for ; Thu, 27 Feb 2003 22:21:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxh12238; Thu, 27 Feb 2003 22:21:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxh21315 for mpls-outgoing; Thu, 27 Feb 2003 22:20:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodxh21306 for ; Thu, 27 Feb 2003 22:20:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodxh07295 for ; Thu, 27 Feb 2003 22:20:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxh07835 for ; Thu, 27 Feb 2003 22:20:25 GMT Received: from almso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso2.att.com [192.128.166.71]) id QQodxh07822 for ; Thu, 27 Feb 2003 22:20:25 GMT Received: from attrh1i.attrh.att.com ([135.71.62.10]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1RMHXXA003222 for ; Thu, 27 Feb 2003 17:20:19 -0500 (EST) Received: from OCCLUST02EVS1.ugd.att.com (135.71.164.8) by attrh1i.attrh.att.com (6.5.019) id 3E5CD82C00023887; Thu, 27 Feb 2003 17:19:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 17:19:46 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC62406845A2D@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLeghuyx5kIjzOjQRWJi1Sg+b9jmQAF4v+Q From: "Brungard, Deborah A, ALABS" To: "Loa Andersson" Cc: "Wijnen, Bert (Bert)" , "Kireeti Kompella" , "Scott W Brim" , , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA26198 agree... I suggest the liaison process should be a separate document. And update this if it needs updating. For people outside of IETF or new to IETF, it is useful to have these process descriptions. And they are two different subjects (with common links). For Steve, Eve, etc, I think there are two (at least) discussions on-going (1) the liaison process (which will have the "hooks" to this document and vice versa), and (2) the "what if scenario" (for non-USA, this is our new shuttle terminology): how this document relates to if an sdo (or individual) works outside this process (info rfcs). It would be good (considering the discussion level) to add some clarification text to the chng proc draft. One option suggested by Kireeti "this is where the SDO can decide, as you point out, that it can do it on its own, but changes the name of the protocol so that innocent bystanders can tell the difference." The SDO protocol is not IETF (as this chng proc draft states) and not (G)MPLS. And as Kireeti suggested the assignments by IANA should distinguish. Another option, suggested by Steve, is that IETF should be a clearinghouse. And discussion is on-going on the interpretation of clearinghouse. Steve, your email may be mis-interpreted, e.g.: "A better approach would be for the IETF to PROMOTE the use of its protocols for new applications, and, when another Standards Development Organization wishes to apply (G)MPLS protocols to an application domain outside of the scope of IETF, that IETF will (1) assist with the development of any necessary extensions; and (2) to facilitate documentation of such new applications and extensions in a central place (e.g., by informational RFC, even for extensions that are developed outside of IETF) and to insure that code points are assigned in a coherent manner through IANA to avoid collisions where different extensions may use the same code points to indicate different things." I don't think you are requesting IETF to simply endorse another sdo's work without review (unless the interpretation of assist=review), and I am not so sure about the promotion either. In T1X1/ITU, just at this last meeting, many have voiced concern with new applications (suggested within the group) for GFP: PON, switched layer. The concern is on extending GFP beyond what it was designed. What if another forum decided to do switched GFP? And they liaisoned to ITU to incorporate the necessary extensions? Remember the difficulties we have with IEEE 10G WAN. It calls itself SDH, but it is not SDH (as we know SDH is more than just G.707). And it is already causing confusion among the innocent. And remember "SONET Lite". Here, in IETF, they have the same concern if the name GMPLS is used. GMPLS is more than just extensions. Some possibilities: at minimum, if IANA assignment is requested by a sdo, the name should at least distinguish it as non-IETF. And in the scope clarify it is outside of the IETF process. Or change the rfc name "informational" as it can be mis-interpreted. In ITU rec'ds, we have appendices which are informational, but they are part of the "ITU process" i.e. reviewed/agreed. Deborah -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, February 27, 2003 11:59 AM To: Brungard, Deborah A, ALABS Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Deborah, I suggested earlier that we describe (short) in the draft how we will handle liasions comeing into the IETF with request for changes or requirments related to the (g)mpls protocols. It needs to be understood that the internal IETF process is specified for IDs, and in some way we need bridge that gap. IETF and its working groups modifies IDs, and I don't think it is good idea to start modifying liasions from other SDOs. That we define the liasion process so it becoes crips and clear, and if when we are doing find that it has an impact on the change process, we updte or re-organize the the documents at that time. Would that work? I guess that the answer is - yes, but only as much (little) as needed. /Loa Brungard, Deborah A, ALABS wrote: >Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify. > >One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond: >1. simple thank you for the information >2. here's the answer/clarification based on current work >3. for a quick answer, at the meeting, have a breakout group to address a proposal >4. for new work, send a response saying we invite contributions to our future meetings to progress > - if no contributions, not anything is done (yes we have done this too) > - at the next meeting, send several proposals to the other group for their review > >I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process. > >Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)? > >Deborah > > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Thursday, February 27, 2003 10:47 AM >To: Kireeti Kompella; Wijnen, Bert (Bert) >Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > >Inline > > > >>-----Original Message----- >>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>Sent: donderdag 27 februari 2003 10:09 >>To: Wijnen, Bert (Bert) >>Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt >> >> >>Hi Bert, >> >>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: >> >> >> >>>No of course NOT. Many Liasons will want an answer. >>>So we need a process to follow up and to track if a timely >>>response has been (or will be) send. >>> >>> >>Is the IETF process for replying to liaison statements (and of >>generating them) written down, say in some RFC? If so, could you >>send me a pointer? >> >> >> >Unfortunately, I don't think the process for that has been defined. >That is why I said that "we need a process..." >We do not have it yet (I think... at least I do not know it either). >I think we were all just hoping people would take responsibility and >do the right things... but as we know that is how things fall through >the cracks. > > > >>>But the Liasons communication between ITU and CCAMP/MPLS has not >>>been going smoothly so far (even though we had good intentions). >>>Responses have not gone out in time (or in some cases at all). >>> >>> >>I'll take full responsibility for that. >> >> >> >W.r.t. CCAMP I will share some of the responsibility too. I should >also have kept a better eye on it. > >Bert > > >>Thanks, >>Kireeti. >> >> >> > > > > > > From owner-mpls@UU.NET Thu Feb 27 17:48:50 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26802 for ; Thu, 27 Feb 2003 17:48:50 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodwo16974; Thu, 27 Feb 2003 17:33:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQodwo28331 for mpls-outgoing; Thu, 27 Feb 2003 17:33:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodwo28313 for ; Thu, 27 Feb 2003 17:33:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodwo29371 for ; Thu, 27 Feb 2003 17:32:50 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodwo15097 for ; Thu, 27 Feb 2003 17:32:49 GMT Received: from gwngate.homelinux.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ool-43547318.dyn.optonline.net [67.84.115.24]) id QQodwo15086 for ; Thu, 27 Feb 2003 17:32:49 GMT Received: from bigguy ([192.168.0.7] helo=ieee.org) by gwngate.homelinux.org with esmtp (Exim 3.35 #1 (Debian)) id 18oRtU-0001c2-00; Thu, 27 Feb 2003 12:32:28 -0500 Message-ID: <3E5E4BA9.8080301@ieee.org> Date: Thu, 27 Feb 2003 12:32:25 -0500 From: George Newsome User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Malcolm Betts , Stephen Trowbridge CC: "'Loa Andersson'" , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <710197BD5AF9D4119E4400508BCFA13604381507@zcard04u.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Malcolm Betts wrote: > Loa, the from the outside looking in the liaison process and the change > process are closely coupled. The liaison process is described in ITU-T > Recommendation A.4 and A.5 and in RFC 3356. > ......... It seems to me that Malcolm and Monica's remarks, and Steve's suggestions to improve the usefulness of the document are all heading in the right direction. I would have thought that the IETF understands very well how to make changes to its documents, so a new document discussing that aspect seems to have little use. On the other hand, Loa suggested earlier that the liaison process is not well understood, so a document describing how the interaction between SDO's can work seems very relevant. It is difficult or impossible to separate out the fact that other SDO's are not individuals, and that formal communications (liaison's) are how other SDO's communicate with each other. Steve's suggested changes address both of these facts, and are thus helpful. George From owner-mpls@UU.NET Thu Feb 27 17:54:37 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26870 for ; Thu, 27 Feb 2003 17:54:36 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxj12809 for ; Thu, 27 Feb 2003 22:58:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxj12501; Thu, 27 Feb 2003 22:58:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxj24189 for mpls-outgoing; Thu, 27 Feb 2003 22:58:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodxj24173 for ; Thu, 27 Feb 2003 22:57:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodxj26835 for ; Thu, 27 Feb 2003 22:57:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxj13618 for ; Thu, 27 Feb 2003 22:57:48 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQodxj13613 for ; Thu, 27 Feb 2003 22:57:47 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1RMvkJ23555; Thu, 27 Feb 2003 17:57:46 -0500 (EST) Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA16911; Thu, 27 Feb 2003 16:57:44 -0600 (CST) Message-ID: <3E5E97E8.FCBD80C0@lucent.com> Date: Thu, 27 Feb 2003 15:57:44 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: Loa Andersson , "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <2FEC2C81634CDB4C9F191943ACCDC62406845A2D@OCCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Deborah, > I don't think you are requesting IETF to simply endorse another > sdo's work without review (unless the interpretation of assist=review), > and I am not so sure about the promotion either. This is not quite what I am trying to say - Presumably the other SDO starts communication at the problem statement phase (e.g., the Oct 2001 liaisons SG15 to ccamp). IETF is free to decide if it makes sense for IETF to be involved in development of the solution. If they decide not to be involved and the other SDO goes ahead with developing their own solution, they don't need to bless the extension, or even like it, but they do need to accept it. At this point we may as well document it in an info RFC (not standards track for IETF) and make sure the codepoint assignments are done in a way that avoids conflict or overlap with other extensions. There is another subtlety that perhaps I failed to capture in enough detail. If the IETF does decide to be involved, their involvement is in applying their protocol expertise in determining HOW to solve the problem that the other SDO has raised. I am uncomfortable with a process that leaves the IETF as the sole arbiter of WHETHER the problem will be solved or whether the requirements developed by the other SDO are valid. The application domain being addressed by the other SDO may very well be different than the one being addressed by IETF, and the validity of what the other SDO sees as their requirements for their application domain is not for IETF to decide. I am also a concerned with the following: > One option suggested by Kireeti "this is where the SDO can decide, > as you point out, that it can do it on its own, but > changes the name of the protocol so that innocent bystanders can tell > the difference." This seems like a road to chaos. You end up with a proliferation of (G)MPLS-like protocols which are all slightly different whenever there is a requirement of another SDO that IETF doesn't accept or understand. I think if we can come up with something more of the "clearinghouse" flavor, we can at least keep a common umbrella over the family of IETF and non-IETF developed extensions (based on whether IETF had the interest or expertise to be involved in any particular extension), to understand (as Stephen Shew pointed out) which extensions can co-exist, to avoid conflicts, etc. Regards, Steve From owner-mpls@UU.NET Thu Feb 27 18:01:18 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27038 for ; Thu, 27 Feb 2003 18:01:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxk20386 for ; Thu, 27 Feb 2003 23:05:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxk19734; Thu, 27 Feb 2003 23:04:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxk12303 for mpls-outgoing; Thu, 27 Feb 2003 23:04:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodxk12137 for ; Thu, 27 Feb 2003 23:04:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodxk12033 for ; Thu, 27 Feb 2003 23:04:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxk23488 for ; Thu, 27 Feb 2003 23:04:08 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQodxk23484 for ; Thu, 27 Feb 2003 23:04:07 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1RN43S82017; Thu, 27 Feb 2003 15:04:07 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h1RN43F32217; Thu, 27 Feb 2003 15:04:03 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 27 Feb 2003 15:04:03 -0800 (PST) From: Kireeti Kompella To: Stephen Trowbridge cc: ccamp@ops.ietf.org, "" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-Reply-To: <3E5E97E8.FCBD80C0@lucent.com> Message-ID: <20030227150131.N32160@kummer.juniper.net> References: <2FEC2C81634CDB4C9F191943ACCDC62406845A2D@OCCLUST02EVS1.ugd.att.com> <3E5E97E8.FCBD80C0@lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Steve, On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > If they decide not to be involved and the other SDO goes ahead with > developing their own solution, they don't need to bless the extension, > or even like it, but they do need to accept it. Going back to the examples that Deborah brought up: what if other SDOs produced variants of SDH -- would you say that the ITU "do need to accept it"? Kireeti. From owner-mpls@UU.NET Thu Feb 27 18:16:28 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27331 for ; Thu, 27 Feb 2003 18:16:28 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxl07094 for ; Thu, 27 Feb 2003 23:20:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxl06269; Thu, 27 Feb 2003 23:19:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxl14606 for mpls-outgoing; Thu, 27 Feb 2003 23:19:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodxl14597 for ; Thu, 27 Feb 2003 23:19:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodxl27333 for ; Thu, 27 Feb 2003 23:18:58 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxl05556 for ; Thu, 27 Feb 2003 23:18:57 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQodxl05550 for ; Thu, 27 Feb 2003 23:18:57 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1RNIuJ02642; Thu, 27 Feb 2003 18:18:56 -0500 (EST) Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA24081; Thu, 27 Feb 2003 17:18:54 -0600 (CST) Message-ID: <3E5E9CDE.A86FB1BF@lucent.com> Date: Thu, 27 Feb 2003 16:18:54 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <2FEC2C81634CDB4C9F191943ACCDC62406845A2D@OCCLUST02EVS1.ugd.att.com> <3E5E97E8.FCBD80C0@lucent.com> <20030227150131.N32160@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, I'm not sure that this is the same. IETF develops control plane technology that can control SONET/SDH equipment used to carry physical layer connections supporting an IP network. Presumably SONET/SDH doesn't need to change for this application as long as virtual concatenation, etc. support the necessary pipe sizes. If SONET/SDH did not have what was required for this application, I assume that IETF should first come to T1X1/ITU-T for the needed extensions (much as ITU-T first came to IETF for the needed extensions- remember?). If ITU-T then was not interested to help and if standardized SONET/SDH did not meet the requirements, I suppose that IETF would have the right to do what it needed for its application and inform ITU-T what it had done. ITU-T wants to apply the control plane technology to a general purpose (not necessarily IP) transport network. In contrast to the IP network, you have demarcation points User/Network and between network operators for billing purposes, etc. This leads to some new requirements (e.g., call & connection separation) not met by the base protocol. Is it reasonable that we want to use the (G)MPLS protocols as a base and (inside or outside of IETF) define the minimum set of extensions to meet the requirements, or should we just have stuck with PNNI? Regards, Steve Kireeti Kompella wrote: > > Hi Steve, > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > If they decide not to be involved and the other SDO goes ahead with > > developing their own solution, they don't need to bless the extension, > > or even like it, but they do need to accept it. > > Going back to the examples that Deborah brought up: what if other SDOs > produced variants of SDH -- would you say that the ITU "do need to > accept it"? > > Kireeti. From owner-mpls@UU.NET Thu Feb 27 18:20:04 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27446 for ; Thu, 27 Feb 2003 18:20:04 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxl14273 for ; Thu, 27 Feb 2003 23:23:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxl13441; Thu, 27 Feb 2003 23:23:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxl14864 for mpls-outgoing; Thu, 27 Feb 2003 23:23:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodxl14815 for ; Thu, 27 Feb 2003 23:22:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodxl28163 for ; Thu, 27 Feb 2003 23:22:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxl12021 for ; Thu, 27 Feb 2003 23:22:21 GMT Received: from lightwave.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQodxl12010 for ; Thu, 27 Feb 2003 23:22:21 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZGGTZ>; Thu, 27 Feb 2003 15:22:17 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972272@nimbus> From: John Drake To: "'Kireeti Kompella'" , Stephen Trowbridge Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 15:22:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, There's always been a few things that I didn't like about G.709, so maybe we can just go ahead and deprecate them in CCAMP. Then we can figure this liason stuff and tell the ITU about it. Thanks, John > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, February 27, 2003 3:04 PM > To: Stephen Trowbridge > Cc: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi Steve, > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > If they decide not to be involved and the other SDO goes ahead with > > developing their own solution, they don't need to bless the > extension, > > or even like it, but they do need to accept it. > > Going back to the examples that Deborah brought up: what if other SDOs > produced variants of SDH -- would you say that the ITU "do need to > accept it"? > > Kireeti. > From owner-mpls@UU.NET Thu Feb 27 18:58:08 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28225 for ; Thu, 27 Feb 2003 18:58:07 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxo13752 for ; Fri, 28 Feb 2003 00:02:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxo12801; Fri, 28 Feb 2003 00:01:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxo24028 for mpls-outgoing; Fri, 28 Feb 2003 00:01:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodxo21914 for ; Fri, 28 Feb 2003 00:00:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodxo23257 for ; Fri, 28 Feb 2003 00:00:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxo18973 for ; Fri, 28 Feb 2003 00:00:05 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodxo18953 for ; Fri, 28 Feb 2003 00:00:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1S002Nh004332 for ; Thu, 27 Feb 2003 19:00:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA23177 for ; Thu, 27 Feb 2003 19:00:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1S002318693 for mpls@uu.net; Thu, 27 Feb 2003 19:00:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodxn17504 for ; Thu, 27 Feb 2003 23:59:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodxn23654 for ; Thu, 27 Feb 2003 23:57:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxn17262 for ; Thu, 27 Feb 2003 23:57:54 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodxn17244 for ; Thu, 27 Feb 2003 23:57:53 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA38712; Thu, 27 Feb 2003 18:56:41 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302272356.SAA38712@workhorse.fictitious.org> To: Kireeti Kompella cc: Stephen Trowbridge , ccamp@ops.ietf.org, "" Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Thu, 27 Feb 2003 15:04:03 PST." <20030227150131.N32160@kummer.juniper.net> Date: Thu, 27 Feb 2003 18:56:41 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20030227150131.N32160@kummer.juniper.net>, Kireeti Kompella writes: > Hi Steve, > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > If they decide not to be involved and the other SDO goes ahead with > > developing their own solution, they don't need to bless the extension, > > or even like it, but they do need to accept it. > > Going back to the examples that Deborah brought up: what if other SDOs > produced variants of SDH -- would you say that the ITU "do need to > accept it"? > > Kireeti. It really becomes a practical matter. For example, SONET scrambling was changed because the original was too short and too easy to send an IP packet containing the entire reverse scramble sequence leading to all same bit after scrambling, causing a SONET framing error. The ease of doing this was demostrated by a BBN engineer in network operations. Although the push came from the IETF to change this and there was resistance it was changed when it was obvious that customers were going to insist on the change in products, whether or not any SDO blessed the change. The opposite is true in the case of ITU requirements for QoS published in the mid 1990s. IETF didn't like it. No one implemented. No customers asked for it. End of story. An example where the SDO didn't accept changes and the SDO became irrelevant wrt those specs is ISIS, where nearly 100% of implemented and deployed ISIS is according to the IETF defined extensions to ISIS which began with rfc1195. ISO has never quite recognized the IETF extensions, but no one really cares much what ISO thinks about this. A few things have been jammed through the IETF that never went any where. For example, guarenteed services in RSVP, NHRP (and everything the ROLC and ION WGs did, and most of what IPATM did), QoS routing extensions for OSPF. The requirements documet first is a means of insuring better quality control over what emerges from the IETF. (Not in terms of "to the letter perfect" documents, but useful protocols). The emphasis on running code and rough consensus rather than study groups and voting has worked quite well. There is not reason to change it or to consider a liason comment or contribution and different from any other contribution. Curtis From owner-mpls@UU.NET Thu Feb 27 19:52:39 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29132 for ; Thu, 27 Feb 2003 19:52:39 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxr15634 for ; Fri, 28 Feb 2003 00:56:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxr14256; Fri, 28 Feb 2003 00:55:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxr10504 for mpls-outgoing; Fri, 28 Feb 2003 00:55:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodxr10495 for ; Fri, 28 Feb 2003 00:55:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodxr18992 for ; Fri, 28 Feb 2003 00:55:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxr13434 for ; Fri, 28 Feb 2003 00:55:05 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodxr13426 for ; Fri, 28 Feb 2003 00:55:04 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1S0t2JR010938 for ; Thu, 27 Feb 2003 19:55:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA26088 for ; Thu, 27 Feb 2003 19:55:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1S0t1Y23554 for mpls@uu.net; Thu, 27 Feb 2003 19:55:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodxr10444 for ; Fri, 28 Feb 2003 00:53:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodxr16416 for ; Fri, 28 Feb 2003 00:53:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxr12776 for ; Fri, 28 Feb 2003 00:53:49 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQodxr12758 for ; Fri, 28 Feb 2003 00:53:48 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA38978; Thu, 27 Feb 2003 19:52:40 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302280052.TAA38978@workhorse.fictitious.org> To: Stephen Trowbridge cc: Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Thu, 27 Feb 2003 16:18:54 MST." <3E5E9CDE.A86FB1BF@lucent.com> Date: Thu, 27 Feb 2003 19:52:40 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E5E9CDE.A86FB1BF@lucent.com>, Stephen Trowbridge writes: > Kireeti, > I'm not sure that this is the same. > IETF develops control plane technology that can control SONET/SDH > equipment used to carry physical layer connections supporting an > IP network. Presumably SONET/SDH doesn't need to change for this > application as long as virtual concatenation, etc. support the > necessary pipe sizes. > > If SONET/SDH did not have what was required for this application, > I assume that IETF should first come to T1X1/ITU-T for the needed > extensions (much as ITU-T first came to IETF for the needed extensions- > remember?). If ITU-T then was not interested to help and if standardized > SONET/SDH did not meet the requirements, I suppose > that IETF would have the right to do what it needed for its > application and inform ITU-T what it had done. > > ITU-T wants to apply the control plane technology to a general > purpose (not necessarily IP) transport network. In contrast to > the IP network, you have demarcation points User/Network and > between network operators for billing purposes, etc. This > leads to some new requirements (e.g., call & connection separation) > not met by the base protocol. Is it reasonable that we want to > use the (G)MPLS protocols as a base and (inside or outside of > IETF) define the minimum set of extensions to meet the requirements, > or should we just have stuck with PNNI? > Regards, > Steve Steve, Go right a head and use PNNI. Don't forget to run it over CLNP on a cell based infrastructure. :-) Curtis > Kireeti Kompella wrote: > > > > Hi Steve, > > > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > > > If they decide not to be involved and the other SDO goes ahead with > > > developing their own solution, they don't need to bless the extension, > > > or even like it, but they do need to accept it. > > > > Going back to the examples that Deborah brought up: what if other SDOs > > produced variants of SDH -- would you say that the ITU "do need to > > accept it"? > > > > Kireeti. > From owner-mpls@UU.NET Thu Feb 27 20:34:09 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29858 for ; Thu, 27 Feb 2003 20:34:09 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxk25328; Thu, 27 Feb 2003 23:07:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxk12732 for mpls-outgoing; Thu, 27 Feb 2003 23:06:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodxk12709 for ; Thu, 27 Feb 2003 23:06:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodxk21353 for ; Thu, 27 Feb 2003 23:05:56 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxk09007 for ; Thu, 27 Feb 2003 23:05:55 GMT Received: from relay2.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQodxk08936 for ; Thu, 27 Feb 2003 23:05:50 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h1RN5M722982; Fri, 28 Feb 2003 00:05:22 +0100 (MET) Received: from alcatel.be ([138.203.137.4]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003022800051927:117 ; Fri, 28 Feb 2003 00:05:19 +0100 Message-ID: <3E5E996D.E98F6BA5@alcatel.be> Date: Fri, 28 Feb 2003 00:04:13 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Drake Cc: "'George Newsome'" , "'Kireeti Kompella'" , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <9D42C6E086250248810DCADA39CE7EFC97226B@nimbus> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/28/2003 00:05:19, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/28/2003 00:05:21, Serialize complete at 02/28/2003 00:05:21 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit john, here it is ... ... and if i well remember.. trying to summarize here the issue: 1) in order to initiate an action a clear under standing of the problem must be achieved by the ccamp wg community in order to make this happen 2) expect that ietf community would understand the terminology used in g.8080 (and subsequently the issue) by sending a liaison was probably a bit too optimistic -> thus the idea was to initiate a sort of "decoder ring" (just to be sure that when we say a "table" we are all in common agreement on what a table is) 3) instead of request changes to gmpls it would have been much more constructive to know really what are the architectural aspects covered by itu that are the key in enabling signalling for optical networks -> from that *clear* perspective the ccamp wg was expecting a "functional spec" i-d ... since the idea here was to understand the functional requirement outside of any specific signalling protocol (thus make abstraction of what was included in g.7713.x in a first phase) 4) once terminology + functional aspects would have been understood by the ccamp wg deliver the right answer using the ccamp community tools and protocols in brief, the idea developed in yokohama was "please put the g.8080 architecture on the table, and let's have a signalling functional i-d to clearly understand the issue and then the ccamp wg community will deliver the adequate gmpls profile" instead of that the two editors of the document decided to go the "info track" ... i never understood the real argumentation behind this ... clearly as we say in french "la sauce n'a pas prise" but i consider this as a turning- point in the ccamp/sg15 collaboration then, as already pointed out, we couldn't avoid "that the SDO can decide to do it on its own, but then changes the name of the protocol so that innocent bystanders can tell the difference." and this is what happened for signalling. note: kireeti please correct me if you think there is something missing or wrong here hope this clarifies, - dimitri. John Drake wrote: > > George, > > I didn't attend. > > Thanks, > > John > > > -----Original Message----- > > From: George Newsome [mailto:gnewsome@ieee.org] > > Sent: Thursday, February 27, 2003 10:17 AM > > To: John Drake > > Cc: 'Kireeti Kompella'; Stephen Trowbridge; ccamp@ops.ietf.org; > > mpls@UU.NET > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > > John Drake wrote: > > > > > > > Snipped... > > > > > > Stephen Trowbridge asked what further information the IETF > > requires. > > > > > > Dimitri and Kireeti answered the question in detail." > > > > > > > > > And the answer was ???? > > > > A pity that the detailed answer is apparently not minuted. > > > > George > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Thu Feb 27 20:48:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00174 for ; Thu, 27 Feb 2003 20:48:08 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxv20356 for ; Fri, 28 Feb 2003 01:52:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxv19856; Fri, 28 Feb 2003 01:51:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxv03397 for mpls-outgoing; Fri, 28 Feb 2003 01:51:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodxv03387 for ; Fri, 28 Feb 2003 01:51:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodxv16853 for ; Fri, 28 Feb 2003 01:50:34 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxv24930 for ; Fri, 28 Feb 2003 01:50:33 GMT Received: from lightwave.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQodxv24920 for ; Fri, 28 Feb 2003 01:50:33 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZGG6H>; Thu, 27 Feb 2003 17:50:28 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972273@nimbus> From: John Drake To: "'Stephen Trowbridge'" , Kireeti Kompella Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 17:50:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Snipped... > If SONET/SDH did not have what was required for this application, > I assume that IETF should first come to T1X1/ITU-T for the needed > extensions (much as ITU-T first came to IETF for the needed > extensions-remember?) JD: I'm assuming that in your worldview that the Yokohama CCAMP meeting never happened? > In contrast to the IP network, you have demarcation points User/Network and > between network operators for billing purposes, etc. This > leads to some new requirements (e.g., call & connection separation) > not met by the base protocol. Is it reasonable that we want to > use the (G)MPLS protocols as a base and (inside or outside of > IETF) define the minimum set of extensions to meet the requirements, > or should we just have stuck with PNNI? JD: Is that a threat or a promise? BTW, call & connection separation doesn't exist in PNNI either, at least up to the point that I stopped attending the ATM Forum. From owner-mpls@UU.NET Thu Feb 27 21:45:22 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01332 for ; Thu, 27 Feb 2003 21:45:21 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxz23308 for ; Fri, 28 Feb 2003 02:49:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodxz22676; Fri, 28 Feb 2003 02:48:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQodxz26457 for mpls-outgoing; Fri, 28 Feb 2003 02:48:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodxz26344 for ; Fri, 28 Feb 2003 02:48:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodxz23849 for ; Fri, 28 Feb 2003 02:47:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodxz11019 for ; Fri, 28 Feb 2003 02:47:36 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQodxz11010 for ; Fri, 28 Feb 2003 02:47:36 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h1S2lZS94101; Thu, 27 Feb 2003 18:47:35 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h1S2lZG32934; Thu, 27 Feb 2003 18:47:35 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 27 Feb 2003 18:47:35 -0800 (PST) From: Kireeti Kompella To: Curtis Villamizar cc: ccamp@ops.ietf.org, "" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-Reply-To: <200302272356.SAA38712@workhorse.fictitious.org> Message-ID: <20030227182933.M32865@kummer.juniper.net> References: <200302272356.SAA38712@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, On Thu, 27 Feb 2003, Curtis Villamizar wrote: > The emphasis on running code and rough consensus rather than study > groups and voting has worked quite well. There is not reason to > change it or to consider a liason comment or contribution and > different from any other contribution. I'm glad to hear this! It is important, especially as this argument goes downhill fast (starting with veiled threats and "I'm calling your bluff" responses), to keep the big picture in mind: a) There is a half-written, half-implicit and half-in-the-hallways process *for the IETF* to change IETF protocols. It would be good to have more of the process written down, at least in the context of (G)MPLS. The primary goal of the (G)MPLS change document is that this process is made known to all SDOs (including the IETF!). b) There are often requirements from other SDOs for changes in IETF protocols. *If* they choose to bring these to the IETF and have the IETF do the changes, it is good for them to know the process. If, as Steve points out, the SDO chooses to make the changes on its own, for whatever reason, that is beyond the scope of the (G)MPLS change document. c) A liaison statement may declare the intent to follow up with the requirements or requests for changes in IETF protocols, but should not (IMO) be used to effect those changes. A process for replying to (and generating) liaisons statements is needed. d) The fundamental IETF mechanisms (though some may view them as broken) such as rough consensus and running code are *not* in question here. Those may be brought up on the general IETF list, or with the IESG or IAB. Kireeti. From owner-mpls@UU.NET Fri Feb 28 03:37:07 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17366 for ; Fri, 28 Feb 2003 03:37:07 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodyw05451 for ; Fri, 28 Feb 2003 08:41:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodyw04393; Fri, 28 Feb 2003 08:40:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQodyw11788 for mpls-outgoing; Fri, 28 Feb 2003 08:40:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodyw11772 for ; Fri, 28 Feb 2003 08:39:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodyw07524 for ; Fri, 28 Feb 2003 08:39:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodyw02602 for ; Fri, 28 Feb 2003 08:39:26 GMT Received: from mta0 by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.2]) id QQodyw02538 for ; Fri, 28 Feb 2003 08:39:22 GMT Received: from l10814 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HB0004MXFYNHO@mta0.huawei.com> for MPLS@UU.NET; Fri, 28 Feb 2003 16:37:44 +0800 (CST) Date: Fri, 28 Feb 2003 16:38:00 +0800 From: Enhui Liu Subject: Another requirement for MPLS Header Compression To: "Ash, Gerald R (Jerry), ALABS" , Loa Andersson , "GOODE, B (Bur), ALABS" Cc: "Ash, Gerald R (Jerry), ALABS" , Jim Hand , raymond zhang , "MPLS@UU.net" , George Swallow Reply-to: Enhui Liu Message-id: <015201c2df04$b4530c80$21426e0a@HUAWEI.COM> Organization: HUAWEI TECHNOLOGIES CO. LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <28F05913385EAC43AF019413F674A01704CB8756@OCCLUST04EVS1.ugd.att.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Hi, There is another requirement for MPLS header compression: MTU problem in MPLS L2 VPN. In MPLS layer2 VPN model, customer premises' data link layer frames are transported transparently on virtual circuits. CE1<-------------->PE1<------------->P<--------->PE2<------>CE2 | | |----------------------a MPLS Virtual Circuit----------------------| The frame format forwarded between PE1 and PE2 is the following. +---------------------+-------------+----------------------+---------+------------+ |data link layerA head | mpls head | data link layerB head | IP head | IP payload | +---------------------+-------------+----------------------+---------+------------+ |-------14 bytes------+---8 bytes---+---------------1518 bytes ------------------| If two data link layers are ethernet, ethernet MTU(1518 bytes) + mpls head(8 bytes) + ethernet head(14 byte) is greater than ethernet MTU(1518 bytes). This equation is always valid if data link layer has MTU limit. So it's a problem that PEs or CEs must deal with. There are three solutions to this MTU problem. 1.To request that all customers' IP packets are smaller than 1482 bytes, though the default is 1500bytes. 2.To split and recombine IP packets greater than MTU in PE. 3.To compress and decompress head information of MPLS payload in PE, including data link layerB head, IP head, UDP/TCP head and RTP/RTCP head etc. I think MPLS head compression is a good solution. compression algorithms can be acknowledged through RSVP or LDP signaling. Regards, Enhui Liu From owner-mpls@UU.NET Fri Feb 28 06:15:28 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20370 for ; Fri, 28 Feb 2003 06:15:28 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzh22677 for ; Fri, 28 Feb 2003 11:19:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzh20869; Fri, 28 Feb 2003 11:18:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzh18589 for mpls-outgoing; Fri, 28 Feb 2003 11:18:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodzh18584 for ; Fri, 28 Feb 2003 11:18:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodzh19055 for ; Fri, 28 Feb 2003 11:17:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzh06097 for ; Fri, 28 Feb 2003 11:17:53 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQodzh06074 for ; Fri, 28 Feb 2003 11:17:52 GMT Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA19773; Fri, 28 Feb 2003 12:17:41 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA28241; Fri, 28 Feb 2003 12:17:42 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id <1Z1MRY48>; Fri, 28 Feb 2003 12:16:51 +0100 Message-ID: From: Heiles Juergen To: "'velev@panasonic.de'" , mpls@UU.NET, ccamp@ops.ietf.org Cc: vlan-mpls@panasonic.de Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt Date: Fri, 28 Feb 2003 12:16:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA20370 Genadi, the draft proposes to use the MPLS control plane protocols for a different transport plane (Ethernet VLAN). This is excatly what GMPLS is about. So I think it would be better to have the ID and dicussion in ccamp under the GMPLS work. Regards Juergen > -----Ursprüngliche Nachricht----- > Von: Genadi Velev [mailto:velev@panasonic.de] > Gesendet: Donnerstag, 27. Februar 2003 17:53 > An: mpls@UU.NET > Cc: vlan-mpls@panasonic.de > Betreff: draft-kawakami-mpls-lsp-vlan-00.txt > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > Hi all, > > A new draft was published today (please see below). > > Any feedback and comments are welcome, especially from those > of you who are > dealing with packet transport over wide area Ethernet networks. > > thanks, > Genadi > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Thursday, February 27, 2003 1:44 PM > > To: IETF-Announce: > > Cc: mpls@UU.NET > > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Method to Setup LSP using VLAN Tag Switching > > Author(s) : T. Kawakami et al. > > Filename : draft-kawakami-mpls-lsp-vlan-00.txt > > Pages : 15 > > Date : 2003-2-26 > > > > This document describes a method to setup a Layer 2 tunnel over > > networks based on Ethernet technology. For this purpose, > the ports of > > an Ethernet switch are configured to forward VLAN > tag-labeled packets > > incoming from a certain port to another unambiguous port by using > > VLAN tag information. The Ethernet switches themselves are a part of > > the Label Switching Routers (LSRs), which distribute the VLAN tags > > using Label Distribution Protocol (LDP). To enable LDP to > fulfil this > > function, an LDP extension is proposed. The introduced method > > simplifies the transport of Ethernet frames over wide area Ethernet > > networks. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-kawakami-mpls-lsp-vlan-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mpls@UU.NET Fri Feb 28 07:32:13 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23307 for ; Fri, 28 Feb 2003 07:32:13 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzm04018 for ; Fri, 28 Feb 2003 12:36:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzm29248; Fri, 28 Feb 2003 12:32:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzm11959 for mpls-outgoing; Fri, 28 Feb 2003 12:32:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodzm11954 for ; Fri, 28 Feb 2003 12:32:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodzm18761 for ; Fri, 28 Feb 2003 12:31:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzm27628 for ; Fri, 28 Feb 2003 12:31:05 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodzm27610 for ; Fri, 28 Feb 2003 12:31:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SCV2JR006104 for ; Fri, 28 Feb 2003 07:31:02 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA25480 for ; Fri, 28 Feb 2003 07:31:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SCV2Q29072 for mpls@uu.net; Fri, 28 Feb 2003 07:31:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodzm11768 for ; Fri, 28 Feb 2003 12:30:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodzl29900 for ; Fri, 28 Feb 2003 12:28:28 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzl22028 for ; Fri, 28 Feb 2003 12:28:27 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQodzl22006 for ; Fri, 28 Feb 2003 12:28:27 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22449; Fri, 28 Feb 2003 07:24:29 -0500 (EST) Message-Id: <200302281224.HAA22449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-thomas-mpls-ldp-dod-restart-00.txt Date: Fri, 28 Feb 2003 07:24:29 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDP DoD Graceful Restart Author(s) : B. Thomas, A. Raj Filename : draft-thomas-mpls-ldp-dod-restart-00.txt Pages : 21 Date : 2003-2-27 LDP graceful restart is a mechanism that helps reduce the negative effects on MPLS traffic caused by the restart of a Label Switching Router's (LSR's) control plane, specifically by the restart of its Label Distribution Protocol (LDP) component [RFC3036], on LSRs that are capable of preserving MPLS forwarding state across the restart. [RFC3478] defines procedures for LDP graceful restart for downstream unsolicited label distribution but leaves procedures for downstream on demand label distribution a subject for future study. This document defines graceful restart procedures for downstream on demand label distribution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thomas-mpls-ldp-dod-restart-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-thomas-mpls-ldp-dod-restart-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thomas-mpls-ldp-dod-restart-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thomas-mpls-ldp-dod-restart-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-thomas-mpls-ldp-dod-restart-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132701.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Feb 28 08:24:09 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26832 for ; Fri, 28 Feb 2003 08:24:09 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzp02907 for ; Fri, 28 Feb 2003 13:27:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzp01123; Fri, 28 Feb 2003 13:27:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzp04724 for mpls-outgoing; Fri, 28 Feb 2003 13:26:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodzp04717 for ; Fri, 28 Feb 2003 13:26:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodzp09970 for ; Fri, 28 Feb 2003 13:26:18 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzp19027 for ; Fri, 28 Feb 2003 13:26:17 GMT Received: from mail.pel.panasonic.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.pel.panasonic.de [194.162.191.12]) id QQodzp19016 for ; Fri, 28 Feb 2003 13:26:17 GMT Received: from mcomvelg (vw1.pel.panasonic.de [10.78.238.55]) by mail.pel.panasonic.de (__________PEL__Mail-Server__________) with SMTP id <0HB000FVKT9RHP@panasonic.de> for mpls@UU.NET; Fri, 28 Feb 2003 14:25:04 +0100 (MET) Date: Fri, 28 Feb 2003 14:25:04 +0100 From: Genadi Velev Subject: RE: draft-kawakami-mpls-lsp-vlan-00.txt In-reply-to: To: Heiles Juergen Cc: mpls@UU.NET, ccamp@ops.ietf.org Reply-to: velev@panasonic.de Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8BIT Hi Juergen, thanks for the feedback! This was (and seems to be still) a hot topic. The decision where to present the draft has been already a subject of discussions with the chairmen of MPLS, PWE3 and PPVPN WGs. The reason to let this draft for submission in the MPLS WG was that the basic intention is to propose a new LDP extension ("VLAN label TLV") and MPLS WG is in charge of the LDP protocol. It's true that the transport plane in our proposal is based on VLAN-aware Ethernet switches. Compared to the GMPLS classification of interfaces (RFC3471), VLAN tag switching belongs (I'd say so) to the Packet-Switch Capable (PSC) interfaces, and thus, extensions regarding these interfaces should be a subject of the MPLS WG. This is my personal opinion. However, since I'm not a long-experienced person in the IETF's MPLS related work, I'd like to hear also another opinions on this issue. regards, Genadi > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Heiles > Juergen > Sent: Friday, February 28, 2003 12:17 PM > To: 'velev@panasonic.de'; mpls@UU.NET; ccamp@ops.ietf.org > Cc: vlan-mpls@panasonic.de > Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt > > > Genadi, > > the draft proposes to use the MPLS control plane protocols for a > different transport plane (Ethernet VLAN). > This is excatly what GMPLS is about. So I think it would be > better to have the ID and dicussion in ccamp under the GMPLS work. > > Regards > > Juergen > > > > -----Ursprüngliche Nachricht----- > > Von: Genadi Velev [mailto:velev@panasonic.de] > > Gesendet: Donnerstag, 27. Februar 2003 17:53 > > An: mpls@UU.NET > > Cc: vlan-mpls@panasonic.de > > Betreff: draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > > Hi all, > > > > A new draft was published today (please see below). > > > > Any feedback and comments are welcome, especially from those > > of you who are > > dealing with packet transport over wide area Ethernet networks. > > > > thanks, > > Genadi > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > > Internet-Drafts@ietf.org > > > Sent: Thursday, February 27, 2003 1:44 PM > > > To: IETF-Announce: > > > Cc: mpls@UU.NET > > > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > > > > Title : Method to Setup LSP using VLAN Tag Switching > > > Author(s) : T. Kawakami et al. > > > Filename : draft-kawakami-mpls-lsp-vlan-00.txt > > > Pages : 15 > > > Date : 2003-2-26 > > > > > > This document describes a method to setup a Layer 2 tunnel over > > > networks based on Ethernet technology. For this purpose, > > the ports of > > > an Ethernet switch are configured to forward VLAN > > tag-labeled packets > > > incoming from a certain port to another unambiguous port by using > > > VLAN tag information. The Ethernet switches themselves are a part of > > > the Label Switching Routers (LSRs), which distribute the VLAN tags > > > using Label Distribution Protocol (LDP). To enable LDP to > > fulfil this > > > function, an LDP extension is proposed. The introduced method > > > simplifies the transport of Ethernet frames over wide area Ethernet > > > networks. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of > > the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with > > the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-kawakami-mpls-lsp-vlan-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > From owner-mpls@UU.NET Fri Feb 28 08:37:37 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27439 for ; Fri, 28 Feb 2003 08:37:37 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzq00362 for ; Fri, 28 Feb 2003 13:41:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzq00140; Fri, 28 Feb 2003 13:41:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzq05466 for mpls-outgoing; Fri, 28 Feb 2003 13:41:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodzq05402 for ; Fri, 28 Feb 2003 13:40:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodzq28583 for ; Fri, 28 Feb 2003 13:40:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzq29614 for ; Fri, 28 Feb 2003 13:40:43 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQodzq29606 for ; Fri, 28 Feb 2003 13:40:43 GMT Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SDeeX23424; Fri, 28 Feb 2003 08:40:41 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.58.32]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA15093; Fri, 28 Feb 2003 08:40:40 -0500 (EST) Message-ID: <3E5F66D7.D8FB0C2A@lucent.com> Date: Fri, 28 Feb 2003 08:40:39 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: curtis@fictitious.org CC: Stephen Trowbridge , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <200302280052.TAA38978@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, > > Go right a head and use PNNI. Don't forget to run it over CLNP on a > cell based infrastructure. :-) > Just a minor correction, it's PNNI over SSCOPMCE over anything (include IP). Yet, I am not saying that I like it :-) Yangguang From owner-mpls@UU.NET Fri Feb 28 09:19:41 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29450 for ; Fri, 28 Feb 2003 09:19:41 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzt08190 for ; Fri, 28 Feb 2003 14:23:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzt07409; Fri, 28 Feb 2003 14:23:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzt27162 for mpls-outgoing; Fri, 28 Feb 2003 14:22:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodzt27157 for ; Fri, 28 Feb 2003 14:22:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodzt16306 for ; Fri, 28 Feb 2003 14:21:41 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzt08904 for ; Fri, 28 Feb 2003 14:21:41 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQodzt08896 for ; Fri, 28 Feb 2003 14:21:40 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SELdF03310; Fri, 28 Feb 2003 09:21:39 -0500 (EST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [192.11.157.153]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA11858; Fri, 28 Feb 2003 08:21:33 -0600 (CST) Message-ID: <3E5F706D.C7879FA3@lucent.com> Date: Fri, 28 Feb 2003 07:21:33 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: John Drake CC: Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <9D42C6E086250248810DCADA39CE7EFC972273@nimbus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John, > JD: Is that a threat or a promise? BTW, call & connection separation > doesn't exist in PNNI either, at least up to the point that I stopped > attending the ATM Forum. Interesting that you should mention this. We sent liaisons to the ATM forum, just as we did to IETF ccamp. The reaction we got from the ATM forum was a great deal of help to extend the PNNI protocols to meet our requirements. They provided us numerous, helpful comments all through the process of development of G.7713.1. What we got from IETF ccamp was ignored (until we finally did the work somewhere else and tried to get code points assigned). We seem to have different understandings of what the problem is that needs to be solved. My belief is that the problem is that we don't have a good process for dealing with liaisons in IETF, and this inhibits the kinds of productive relationships between IETF and other SDOs that exist between many other (non-IETF) SDOs. Some others on this thread seem to think that the problem is those other pesky SDOs: after all, how could there possibly be a valid problem statement or requirement that wasn't conceived of and developed entirely within IETF? Every possible measure should be taken to prevent that any work is done to address such requirements. What is your perception of the problem? Steve From owner-mpls@UU.NET Fri Feb 28 09:38:39 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29839 for ; Fri, 28 Feb 2003 09:38:39 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzu21854 for ; Fri, 28 Feb 2003 14:42:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzu21155; Fri, 28 Feb 2003 14:42:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzu28394 for mpls-outgoing; Fri, 28 Feb 2003 14:42:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodzu28389 for ; Fri, 28 Feb 2003 14:41:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodzu01426 for ; Fri, 28 Feb 2003 14:41:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzu19239 for ; Fri, 28 Feb 2003 14:41:05 GMT Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQodzu19226 for ; Fri, 28 Feb 2003 14:41:04 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZGHQ1>; Fri, 28 Feb 2003 06:41:00 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972275@nimbus> From: John Drake To: "'Gert Grammel'" Cc: "'Kireeti Kompella'" , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 06:40:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Gert, I'm sorry, I was teasing. I was saying that if the IETF didn't like certain features of the G.709 transport plane, following Stephen's argument, it shouldn't feel constrained about changing them. I wasn't talking about your draft, which I think is a very good piece of work. Thanks, John > -----Original Message----- > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de] > Sent: Friday, February 28, 2003 4:10 AM > To: John Drake > Cc: 'Kireeti Kompella'; Stephen Trowbridge; ccamp@ops.ietf.org; > mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi John, > > I am not sure if I've got your point here about G.709 and the > way it is linked > to the liason stuff. ITU-T defined G.709 as another circuit > technology to > transport bits from A to B. It is similar to SDH/SONET and > falls into the ASON > scope. Applying GMPLS on G.709 is straight forward and I am > not aware of any > specific open issues here. > In SDH/SONET some of the involved guys were trying to include > non-standard > SDH/SONET features in the ietf-draft, meaning those not > explicitly mentioned in > G.707. This caused of course a lot of friction. In contrast > to that, the G.709 > authors team is committed to remove everything from > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g70 > 9-03.txt which is > not covered by G.709. In this sense it has the potential to > become a boiler > plate for tight collaboration. > So why do you think this work should be depreciated in CCAMP? > > Regards > > Gert > > > > > > > John Drake wrote: > > > Kireeti, > > > > There's always been a few things that I didn't like about > G.709, so maybe we > > can just go ahead and deprecate them in CCAMP. Then we can > figure this > > liason stuff and tell the ITU about it. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > Sent: Thursday, February 27, 2003 3:04 PM > > > To: Stephen Trowbridge > > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > > > > > Hi Steve, > > > > > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > > > > > If they decide not to be involved and the other SDO > goes ahead with > > > > developing their own solution, they don't need to bless the > > > extension, > > > > or even like it, but they do need to accept it. > > > > > > Going back to the examples that Deborah brought up: what > if other SDOs > > > produced variants of SDH -- would you say that the ITU "do need to > > > accept it"? > > > > > > Kireeti. > > > > > -- > Alcatel Optical Network Division Gert Grammel > Network Strategy phone: +49 711 821 47368 > Lorenzstrasse 10 fax: +49 711 821 43169 > D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de > > From owner-mpls@UU.NET Fri Feb 28 09:44:36 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00142 for ; Fri, 28 Feb 2003 09:44:35 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzv05296 for ; Fri, 28 Feb 2003 14:48:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzv03080; Fri, 28 Feb 2003 14:47:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzv29223 for mpls-outgoing; Fri, 28 Feb 2003 14:47:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodzv29197 for ; Fri, 28 Feb 2003 14:46:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodzv05035 for ; Fri, 28 Feb 2003 14:46:32 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzv05316 for ; Fri, 28 Feb 2003 14:46:30 GMT Received: from bt0g2p.god.bel.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc136.alcatel.be [195.207.101.136]) id QQodzv05293 for ; Fri, 28 Feb 2003 14:46:29 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h1SEkIt21586; Fri, 28 Feb 2003 15:46:18 +0100 Received: from alcatel.be ([138.203.64.155]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003022815461609:3104 ; Fri, 28 Feb 2003 15:46:16 +0100 Message-ID: <3E5F75FC.C87FE659@alcatel.be> Date: Fri, 28 Feb 2003 15:45:16 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Trowbridge Cc: John Drake , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <9D42C6E086250248810DCADA39CE7EFC972273@nimbus> <3E5F706D.C7879FA3@lucent.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/28/2003 15:46:16, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/28/2003 15:46:17, Serialize complete at 02/28/2003 15:46:17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit stephen i am resending you the e-mail sent to john because i am not sure you have red it "> What we got from IETF ccamp was ignored (until we finally did the work somewhere else and tried to get code points assigned)." --- 1) in order to initiate an action a clear under standing of the problem must be achieved by the ccamp wg community in order to make this happen 2) expect that ietf community would understand the terminology used in g.8080 (and subsequently the issue) by sending a liaison was probably a bit too optimistic -> thus the idea was to initiate a sort of "decoder ring" (just to be sure that when we say a "table" we are all in common agreement on what a table is) 3) instead of request changes to gmpls it would have been much more constructive to know really what are the architectural aspects covered by itu that are the key in enabling signalling for optical networks -> from that *clear* perspective the ccamp wg was expecting a "functional spec" i-d ... since the idea here was to understand the functional requirement outside of any specific signalling protocol (thus make abstraction of what was included in g.7713.x in a first phase) 4) once terminology + functional aspects would have been understood by the ccamp wg deliver the right answer using the ccamp community tools and protocols --- last it is not the ccamp wg consensus that has pushed itu editors to go to the info track ... thanks, - dimiti. Stephen Trowbridge wrote: > > John, > > > JD: Is that a threat or a promise? BTW, call & connection separation > > doesn't exist in PNNI either, at least up to the point that I stopped > > attending the ATM Forum. > Interesting that you should mention this. > > We sent liaisons to the ATM forum, just as we did to IETF ccamp. > The reaction we got from the ATM forum was a great deal of help to > extend the PNNI protocols to meet our requirements. They provided > us numerous, helpful comments all through the process of development > of G.7713.1. > > What we got from IETF ccamp was ignored (until we finally did the > work somewhere else and tried to get code points assigned). > > We seem to have different understandings of what the problem is that > needs to be solved. My belief is that the problem is that we don't > have a good process for dealing with liaisons in IETF, and this > inhibits the kinds of productive relationships between IETF and other > SDOs that exist between many other (non-IETF) SDOs. > > Some others on this thread seem to think that the problem is those > other pesky SDOs: after all, how could there possibly be a valid > problem statement or requirement that wasn't conceived of and developed > entirely within IETF? Every possible measure should be taken to > prevent that any work is done to address such requirements. > > What is your perception of the problem? > Steve -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Fri Feb 28 09:49:28 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00454 for ; Fri, 28 Feb 2003 09:49:28 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzv20981 for ; Fri, 28 Feb 2003 14:53:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzv19501; Fri, 28 Feb 2003 14:52:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzv29635 for mpls-outgoing; Fri, 28 Feb 2003 14:52:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodzv29629 for ; Fri, 28 Feb 2003 14:52:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodzv08338 for ; Fri, 28 Feb 2003 14:52:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzv12977 for ; Fri, 28 Feb 2003 14:52:11 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodzv12933 for ; Fri, 28 Feb 2003 14:52:10 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SEq4Nh004056 for ; Fri, 28 Feb 2003 09:52:08 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA03428 for ; Fri, 28 Feb 2003 09:52:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SEq3b08440 for mpls@uu.net; Fri, 28 Feb 2003 09:52:03 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodye00400 for ; Fri, 28 Feb 2003 04:01:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQodye22183 for ; Fri, 28 Feb 2003 04:01:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodye26527 for ; Fri, 28 Feb 2003 04:01:20 GMT Received: from alpha2.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQodye26519 for ; Fri, 28 Feb 2003 04:01:20 GMT Received: from mail3.tellium.com (unverified) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 23:00:09 -0500 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 22:57:57 -0500 Message-ID: <05707214338CD5119BFF0040A5B170D3028897C1@mail3.tellium.com> From: Bala Rajagopalan To: Loa Andersson Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 22:57:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Just ran into this ID. The flow chart, as usual, was too complicated for me to comprehend, to I ran it through the decoder software that IESG provides to unscramble its policy statements (see http://www.ietf.org/iesg/policy_faq/demystify.exe). The flow chart was then rendered human-readable as follows: MPLS and GMPLS Change Process ----------------------------- +-------------------------+ | Receive New ID | +-------------------------+ | | V +-------------------------------------+ | Briefly wonder about the resilience | | of the MPLS/GMPLS bandwagon. | | Start review. | +-------------------------------------+ | | V +-----------------------------------+ | Does the draft contain the term | Yes | "ASON"? |-------> TRASH +-----------------------------------+ | | No V +----------------------------------+ | Does the draft contain the term | Yes | "UNI"? |--------> Incinerate +----------------------------------+ | | No V +-------------------------------+ Yes, I-NNI | How about "NNI?" |-----+----> TRASH +-------------------------------+ | | | E-NNI | No +-----> Shred V +-------------------------------+ | Does the draft mention Call | Yes | vs Connection control? |-------> Send a sample +-------------------------------+ of draft to CDC, | incinerate rest | No V +-------------------------------+ | Does the draft have the term | Yes | "G.xyz." in the title? |---------> TRASH +-------------------------------+ | | No V +-------------------------------+ | Draft has progressed too far. | | Send to Curtis for review. | +-------------------------------+ | | V | | | TRASH | +------------+ Seems a bit draconian and no wonder, people are anxious about the process and expect the worst. Still, I believe this will help in limiting the generation of useless drafts and protocol extensions to WGs within the IETF and prevent outside groups from doing the same. Regards, Bala Rajagopalan Tellium, Inc. 2 Crescent Pl. Ocean Port, NJ 07757 USA Ph: +1-732-923-4237 Email: braja@tellium.com From owner-mpls@UU.NET Fri Feb 28 09:50:08 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00475 for ; Fri, 28 Feb 2003 09:50:08 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzv15491 for ; Fri, 28 Feb 2003 14:54:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzv13986; Fri, 28 Feb 2003 14:53:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzv29644 for mpls-outgoing; Fri, 28 Feb 2003 14:52:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodzv29639 for ; Fri, 28 Feb 2003 14:52:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodzv23422 for ; Fri, 28 Feb 2003 14:52:28 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzv19277 for ; Fri, 28 Feb 2003 14:52:27 GMT Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQodzv19262 for ; Fri, 28 Feb 2003 14:52:26 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SEqNJR012509 for ; Fri, 28 Feb 2003 09:52:23 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA03444 for ; Fri, 28 Feb 2003 09:52:22 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SEqMn08444 for mpls@uu.net; Fri, 28 Feb 2003 09:52:22 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodzk10639 for ; Fri, 28 Feb 2003 12:12:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodzk27581 for ; Fri, 28 Feb 2003 12:10:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzk25894 for ; Fri, 28 Feb 2003 12:10:32 GMT Received: from mailrelay2.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75]) id QQodzk25873 for ; Fri, 28 Feb 2003 12:10:31 GMT Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id NAA20735; Fri, 28 Feb 2003 13:09:21 +0100 (MET) Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18ojLH-0002Oq-00; Fri, 28 Feb 2003 13:10:19 +0100 Received: from sls3on.stgl.sel.alcatel.de ([149.204.30.251] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18ojLH-0001NB-00; Fri, 28 Feb 2003 13:10:19 +0100 Message-ID: <3E5F519F.68510CBC@alcatel.de> Date: Fri, 28 Feb 2003 13:10:08 +0100 From: Gert Grammel Organization: Alcatel TND Product Strategy X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: John Drake CC: "'Kireeti Kompella'" , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <9D42C6E086250248810DCADA39CE7EFC972272@nimbus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, I am not sure if I've got your point here about G.709 and the way it is linked to the liason stuff. ITU-T defined G.709 as another circuit technology to transport bits from A to B. It is similar to SDH/SONET and falls into the ASON scope. Applying GMPLS on G.709 is straight forward and I am not aware of any specific open issues here. In SDH/SONET some of the involved guys were trying to include non-standard SDH/SONET features in the ietf-draft, meaning those not explicitly mentioned in G.707. This caused of course a lot of friction. In contrast to that, the G.709 authors team is committed to remove everything from http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-03.txt which is not covered by G.709. In this sense it has the potential to become a boiler plate for tight collaboration. So why do you think this work should be depreciated in CCAMP? Regards Gert John Drake wrote: > Kireeti, > > There's always been a few things that I didn't like about G.709, so maybe we > can just go ahead and deprecate them in CCAMP. Then we can figure this > liason stuff and tell the ITU about it. > > Thanks, > > John > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Thursday, February 27, 2003 3:04 PM > > To: Stephen Trowbridge > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > > Hi Steve, > > > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > > > If they decide not to be involved and the other SDO goes ahead with > > > developing their own solution, they don't need to bless the > > extension, > > > or even like it, but they do need to accept it. > > > > Going back to the examples that Deborah brought up: what if other SDOs > > produced variants of SDH -- would you say that the ITU "do need to > > accept it"? > > > > Kireeti. > > -- Alcatel Optical Network Division Gert Grammel Network Strategy phone: +49 711 821 47368 Lorenzstrasse 10 fax: +49 711 821 43169 D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de From owner-mpls@UU.NET Fri Feb 28 09:52:01 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00541 for ; Fri, 28 Feb 2003 09:52:00 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzv19419 for ; Fri, 28 Feb 2003 14:55:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzv17480; Fri, 28 Feb 2003 14:55:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzv29658 for mpls-outgoing; Fri, 28 Feb 2003 14:53:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodzv29649 for ; Fri, 28 Feb 2003 14:53:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodzv22787 for ; Fri, 28 Feb 2003 14:52:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzv13906 for ; Fri, 28 Feb 2003 14:52:51 GMT Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQodzv13885 for ; Fri, 28 Feb 2003 14:52:51 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZGHRJ>; Fri, 28 Feb 2003 06:52:50 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972276@nimbus> From: John Drake To: "'Stephen Trowbridge'" Cc: Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 06:52:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Stephen, This is the note I sent yesterday, which I thought was fairly clear. Thanks, John ============================================================================ ==================================== Kireeti, Extremely well reasoned and thoughtful. As I understand it, this document is intended to prevent the situation that just occured, in which the IETF published an RFC which detailed some changes to RSVP-TE (which had technical issues) without any review by the CCAMP or MPLS working groups, thereby explicitly appearing to endorse these changes. The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that the CCAMP working group wanted to work on the ASON extensions, so I am still puzzled as to why the authors of the ASON draft decided, after the Yokohama meeting, to progress the draft as an informational RFC rather than as a normal working group draft. Thanks, John > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Friday, February 28, 2003 6:22 AM > To: John Drake > Cc: Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > John, > > > JD: Is that a threat or a promise? BTW, call & connection > separation > > doesn't exist in PNNI either, at least up to the point that > I stopped > > attending the ATM Forum. > Interesting that you should mention this. > > We sent liaisons to the ATM forum, just as we did to IETF ccamp. > The reaction we got from the ATM forum was a great deal of help to > extend the PNNI protocols to meet our requirements. They provided > us numerous, helpful comments all through the process of development > of G.7713.1. > > What we got from IETF ccamp was ignored (until we finally did the > work somewhere else and tried to get code points assigned). > > We seem to have different understandings of what the problem is that > needs to be solved. My belief is that the problem is that we don't > have a good process for dealing with liaisons in IETF, and this > inhibits the kinds of productive relationships between IETF and other > SDOs that exist between many other (non-IETF) SDOs. > > Some others on this thread seem to think that the problem is those > other pesky SDOs: after all, how could there possibly be a valid > problem statement or requirement that wasn't conceived of and > developed > entirely within IETF? Every possible measure should be taken to > prevent that any work is done to address such requirements. > > What is your perception of the problem? > Steve > From owner-mpls@UU.NET Fri Feb 28 09:59:38 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00702 for ; Fri, 28 Feb 2003 09:59:38 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzw12520 for ; Fri, 28 Feb 2003 15:02:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzw10940; Fri, 28 Feb 2003 15:02:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzw10338 for mpls-outgoing; Fri, 28 Feb 2003 15:01:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQodzw10199 for ; Fri, 28 Feb 2003 15:01:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodzw06777 for ; Fri, 28 Feb 2003 15:00:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzw07435 for ; Fri, 28 Feb 2003 15:00:44 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQodzw07377 for ; Fri, 28 Feb 2003 15:00:43 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SF0e402743 for ; Fri, 28 Feb 2003 10:00:40 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <1HW0CR6R>; Fri, 28 Feb 2003 10:00:39 -0500 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA837E@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Brungard, Deborah A, ALABS'" , Loa Andersson Cc: "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 10:00:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk One of the reasons I believe it to be critical to address the liaison aspects up front is that the issue actually goes well beyond specification of an administrative process. I.e., as can be seen from the email threads, it brings up the whole discussion of how requirements for non-IP applications originating from other SDOs are addressed. One train of thought expressed on the email list appears to take the view that such requirements should have no extra weight than an individual than that of an individual; there is no concept of a peer SDO. Eve -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Thursday, February 27, 2003 5:20 PM To: Loa Andersson Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt agree... I suggest the liaison process should be a separate document. And update this if it needs updating. For people outside of IETF or new to IETF, it is useful to have these process descriptions. And they are two different subjects (with common links). For Steve, Eve, etc, I think there are two (at least) discussions on-going (1) the liaison process (which will have the "hooks" to this document and vice versa), and (2) the "what if scenario" (for non-USA, this is our new shuttle terminology): how this document relates to if an sdo (or individual) works outside this process (info rfcs). It would be good (considering the discussion level) to add some clarification text to the chng proc draft. One option suggested by Kireeti "this is where the SDO can decide, as you point out, that it can do it on its own, but changes the name of the protocol so that innocent bystanders can tell the difference." The SDO protocol is not IETF (as this chng proc draft states) and not (G)MPLS. And as Kireeti suggested the assignments by IANA should distinguish. Another option, suggested by Steve, is that IETF should be a clearinghouse. And discussion is on-going on the interpretation of clearinghouse. Steve, your email may be mis-interpreted, e.g.: "A better approach would be for the IETF to PROMOTE the use of its protocols for new applications, and, when another Standards Development Organization wishes to apply (G)MPLS protocols to an application domain outside of the scope of IETF, that IETF will (1) assist with the development of any necessary extensions; and (2) to facilitate documentation of such new applications and extensions in a central place (e.g., by informational RFC, even for extensions that are developed outside of IETF) and to insure that code points are assigned in a coherent manner through IANA to avoid collisions where different extensions may use the same code points to indicate different things." I don't think you are requesting IETF to simply endorse another sdo's work without review (unless the interpretation of assist=review), and I am not so sure about the promotion either. In T1X1/ITU, just at this last meeting, many have voiced concern with new applications (suggested within the group) for GFP: PON, switched layer. The concern is on extending GFP beyond what it was designed. What if another forum decided to do switched GFP? And they liaisoned to ITU to incorporate the necessary extensions? Remember the difficulties we have with IEEE 10G WAN. It calls itself SDH, but it is not SDH (as we know SDH is more than just G.707). And it is already causing confusion among the innocent. And remember "SONET Lite". Here, in IETF, they have the same concern if the name GMPLS is used. GMPLS is more than just extensions. Some possibilities: at minimum, if IANA assignment is requested by a sdo, the name should at least distinguish it as non-IETF. And in the scope clarify it is outside of the IETF process. Or change the rfc name "informational" as it can be mis-interpreted. In ITU rec'ds, we have appendices which are informational, but they are part of the "ITU process" i.e. reviewed/agreed. Deborah -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, February 27, 2003 11:59 AM To: Brungard, Deborah A, ALABS Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Deborah, I suggested earlier that we describe (short) in the draft how we will handle liasions comeing into the IETF with request for changes or requirments related to the (g)mpls protocols. It needs to be understood that the internal IETF process is specified for IDs, and in some way we need bridge that gap. IETF and its working groups modifies IDs, and I don't think it is good idea to start modifying liasions from other SDOs. That we define the liasion process so it becoes crips and clear, and if when we are doing find that it has an impact on the change process, we updte or re-organize the the documents at that time. Would that work? I guess that the answer is - yes, but only as much (little) as needed. /Loa Brungard, Deborah A, ALABS wrote: >Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify. > >One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond: >1. simple thank you for the information >2. here's the answer/clarification based on current work >3. for a quick answer, at the meeting, have a breakout group to address a proposal >4. for new work, send a response saying we invite contributions to our future meetings to progress > - if no contributions, not anything is done (yes we have done this too) > - at the next meeting, send several proposals to the other group for their review > >I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process. > >Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)? > >Deborah > > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Thursday, February 27, 2003 10:47 AM >To: Kireeti Kompella; Wijnen, Bert (Bert) >Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > >Inline > > > >>-----Original Message----- >>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>Sent: donderdag 27 februari 2003 10:09 >>To: Wijnen, Bert (Bert) >>Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt >> >> >>Hi Bert, >> >>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: >> >> >> >>>No of course NOT. Many Liasons will want an answer. >>>So we need a process to follow up and to track if a timely >>>response has been (or will be) send. >>> >>> >>Is the IETF process for replying to liaison statements (and of >>generating them) written down, say in some RFC? If so, could you >>send me a pointer? >> >> >> >Unfortunately, I don't think the process for that has been defined. >That is why I said that "we need a process..." >We do not have it yet (I think... at least I do not know it either). >I think we were all just hoping people would take responsibility and >do the right things... but as we know that is how things fall through >the cracks. > > > >>>But the Liasons communication between ITU and CCAMP/MPLS has not >>>been going smoothly so far (even though we had good intentions). >>>Responses have not gone out in time (or in some cases at all). >>> >>> >>I'll take full responsibility for that. >> >> >> >W.r.t. CCAMP I will share some of the responsibility too. I should >also have kept a better eye on it. > >Bert > > >>Thanks, >>Kireeti. >> >> >> > > > > > > From owner-mpls@UU.NET Fri Feb 28 10:02:21 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00853 for ; Fri, 28 Feb 2003 10:02:21 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzw09630 for ; Fri, 28 Feb 2003 15:06:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzw07724; Fri, 28 Feb 2003 15:05:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzw18228 for mpls-outgoing; Fri, 28 Feb 2003 15:04:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQodzw18188 for ; Fri, 28 Feb 2003 15:04:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodzw17832 for ; Fri, 28 Feb 2003 15:04:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzw06289 for ; Fri, 28 Feb 2003 15:04:20 GMT Received: from relay2.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQodzw06276 for ; Fri, 28 Feb 2003 15:04:19 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h1SF48722746; Fri, 28 Feb 2003 16:04:08 +0100 (MET) Received: from alcatel.be ([138.203.64.155]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003022816040690:3197 ; Fri, 28 Feb 2003 16:04:06 +0100 Message-ID: <3E5F7A2B.1EA172F8@alcatel.be> Date: Fri, 28 Feb 2003 16:03:07 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Drake Cc: "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <9D42C6E086250248810DCADA39CE7EFC972273@nimbus> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/28/2003 16:04:07, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/28/2003 16:04:08, Serialize complete at 02/28/2003 16:04:08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit john, i worry about the fundamental reasons behind "I'm assuming that in your worldview that the Yokohama CCAMP meeting never happened?" which is for me a very sensible and relevant point because it means imho that independently of the real quality and level of details of the (future) liaison process, clearly there are some "centrifuge" forces that tends to discourage a good collaboration (meaning is there somewhere reasons and interest in not making this happening - why ?), consensus made during this yokohama meeting was unformal and had been overridden thus why the formal one would work better and preclude such situations to happen once again ? since at the end of the day people behind the process make the decision (and since we speak about the same group of people...) in a sense the yokohama meeting is not just about it went to an info track ... it is to know *which* were the technical and non-technical reasons for the i-d editors in deciding to go the info track and not working in the scope of the working group ? as long as this question is not solved i really worry about the real intent behind the current thread. thanks, - dimitri. John Drake wrote: > > Snipped... > > > If SONET/SDH did not have what was required for this application, > > I assume that IETF should first come to T1X1/ITU-T for the needed > > extensions (much as ITU-T first came to IETF for the needed > > extensions-remember?) > > JD: I'm assuming that in your worldview that the Yokohama CCAMP meeting > never happened? > > > In contrast to the IP network, you have demarcation points User/Network > and > > between network operators for billing purposes, etc. This > > leads to some new requirements (e.g., call & connection separation) > > not met by the base protocol. Is it reasonable that we want to > > use the (G)MPLS protocols as a base and (inside or outside of > > IETF) define the minimum set of extensions to meet the requirements, > > or should we just have stuck with PNNI? > > JD: Is that a threat or a promise? BTW, call & connection separation > doesn't exist in PNNI either, at least up to the point that I stopped > attending the ATM Forum. > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Fri Feb 28 10:15:56 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01141 for ; Fri, 28 Feb 2003 10:15:56 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzx24684 for ; Fri, 28 Feb 2003 15:19:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzx23549; Fri, 28 Feb 2003 15:19:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzx21070 for mpls-outgoing; Fri, 28 Feb 2003 15:19:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodzx21064 for ; Fri, 28 Feb 2003 15:18:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQodzx22376 for ; Fri, 28 Feb 2003 15:17:54 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzx08364 for ; Fri, 28 Feb 2003 15:17:53 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQodzx08351 for ; Fri, 28 Feb 2003 15:17:53 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SFHpF28657; Fri, 28 Feb 2003 10:17:51 -0500 (EST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [192.11.157.124]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA00793; Fri, 28 Feb 2003 09:17:45 -0600 (CST) Message-ID: <3E5F7D95.8120462D@lucent.com> Date: Fri, 28 Feb 2003 08:17:41 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: John Drake , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <9D42C6E086250248810DCADA39CE7EFC972273@nimbus> <3E5F706D.C7879FA3@lucent.com> <3E5F75FC.C87FE659@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dimitri, I have to respond in the same flavor that I responded to John. Why is it that when we send the same type of request to ATM forum, the result is that they spend effort to try to understand the problem we are trying to solve and provide a great deal of helpful input directed at solving the problem we have raised? They have been genuinely interested in trying to figure out how their protocol can be applied and extended to solve our problem. You mention needing a "decoder ring" to decipher G.8080 terminology, yet this terminology is certainly as foreign to ATM forum as it would be to ccamp (perhaps even moreso, since I think there is far more overlap in attendance between ITU-T SG15 and ccamp than there is between ITU-T SG15 and ATM forum). Yet ATM forum had no difficulty to understand what we were trying to do and to help us to develop the solution. I do not think that this is because people in the ATM forum are so much more intelligent than those in ccamp: in fact, many people I have met in ccamp are absolutely brilliant. So if it is not the ability of the people that prevents this kind of productive work, I have to believe it is a shortcoming of the process. IETF stands nearly alone in the community of International standards development organizations in not taking incoming liaisons as a very serious input. It is only recently that we even had a place to post incoming liaisons for IETF (http://www.ietf.org/IESG/liaison.html). Now it is important to develop a process to make sure that those liaisons are considered. In addition, IETF needs to be able to generate liaison statements in order to effectively influence the work of other SDOs. IETF has historically taken the view that they don't need to send anybody anything because any information related to IETF can be found on their web site or seen on the mailing list. But as a practical matter, for most SDOs, input documents include contributions from members, documents (like agendas and reports) prepared by those with official positions, and LIAISON STATEMENTS. Surely you don't expect that most SDOs will consider as serious input something that somebody found on a web site or saw on a mailing list. To make IETF output be an input to another SDO, in most cases IETF will need to formally send it to the other SDO in the form of a liaison statement. To date, IETF has been unsuccessful in doing this. Regards, Steve Dimitri.Papadimitriou@alcatel.be wrote: > > stephen > > i am resending you the e-mail sent to john because > i am not sure you have red it "> What we got from > IETF ccamp was ignored (until we finally did the > work somewhere else and tried to get code points > assigned)." > > --- > 1) in order to initiate an action a clear under > standing of the problem must be achieved by the > ccamp wg community in order to make this happen > > 2) expect that ietf community would understand > the terminology used in g.8080 (and subsequently > the issue) by sending a liaison was probably > a bit too optimistic -> thus the idea was to > initiate a sort of "decoder ring" (just to be sure > that when we say a "table" we are all in common > agreement on what a table is) > > 3) instead of request changes to gmpls it would > have been much more constructive to know really > what are the architectural aspects covered by > itu that are the key in enabling signalling for > optical networks -> from that *clear* perspective > the ccamp wg was expecting a "functional spec" > i-d ... since the idea here was to understand > the functional requirement outside of any specific > signalling protocol (thus make abstraction of > what was included in g.7713.x in a first phase) > > 4) once terminology + functional aspects would > have been understood by the ccamp wg deliver the > right answer using the ccamp community tools and > protocols > --- > > last it is not the ccamp wg consensus that has > pushed itu editors to go to the info track ... > > thanks, > - dimiti. > > Stephen Trowbridge wrote: > > > > John, > > > > > JD: Is that a threat or a promise? BTW, call & connection separation > > > doesn't exist in PNNI either, at least up to the point that I stopped > > > attending the ATM Forum. > > Interesting that you should mention this. > > > > We sent liaisons to the ATM forum, just as we did to IETF ccamp. > > The reaction we got from the ATM forum was a great deal of help to > > extend the PNNI protocols to meet our requirements. They provided > > us numerous, helpful comments all through the process of development > > of G.7713.1. > > > > What we got from IETF ccamp was ignored (until we finally did the > > work somewhere else and tried to get code points assigned). > > > > We seem to have different understandings of what the problem is that > > needs to be solved. My belief is that the problem is that we don't > > have a good process for dealing with liaisons in IETF, and this > > inhibits the kinds of productive relationships between IETF and other > > SDOs that exist between many other (non-IETF) SDOs. > > > > Some others on this thread seem to think that the problem is those > > other pesky SDOs: after all, how could there possibly be a valid > > problem statement or requirement that wasn't conceived of and developed > > entirely within IETF? Every possible measure should be taken to > > prevent that any work is done to address such requirements. > > > > What is your perception of the problem? > > Steve > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 From owner-mpls@UU.NET Fri Feb 28 10:51:29 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02434 for ; Fri, 28 Feb 2003 10:51:29 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzz06096 for ; Fri, 28 Feb 2003 15:55:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQodzz05105; Fri, 28 Feb 2003 15:54:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQodzz22935 for mpls-outgoing; Fri, 28 Feb 2003 15:54:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQodzz22930 for ; Fri, 28 Feb 2003 15:54:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodzz06822 for ; Fri, 28 Feb 2003 15:54:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzz14998 for ; Fri, 28 Feb 2003 15:54:07 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQodzz14984 for ; Fri, 28 Feb 2003 15:54:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SFs3Nh007887 for ; Fri, 28 Feb 2003 10:54:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA09953 for ; Fri, 28 Feb 2003 10:54:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SFs3517107 for mpls@uu.net; Fri, 28 Feb 2003 10:54:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQodzz22910 for ; Fri, 28 Feb 2003 15:53:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQodzz22243 for ; Fri, 28 Feb 2003 15:52:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQodzz13759 for ; Fri, 28 Feb 2003 15:52:46 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQodzz13754 for ; Fri, 28 Feb 2003 15:52:45 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SFqh402774 for ; Fri, 28 Feb 2003 10:52:44 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 16:52:42 +0100 Message-ID: From: "Mak, L (Leen)" To: "'Stephen Trowbridge'" , Dimitri.Papadimitriou@alcatel.be Cc: John Drake , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 16:52:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Wouldn't it be good to bring this whole discussion to the ietf-problem-statement mailing list? It appears to be of a wider scope than ccamp and mpls. Leen. > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: vrijdag 28 februari 2003 16:18 > To: Dimitri.Papadimitriou@alcatel.be > Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Dimitri, > I have to respond in the same flavor that I responded to John. > > Why is it that when we send the same type of request to ATM > forum, the result is that they spend effort to try to understand > the problem we are trying to solve and provide a great deal > of helpful input directed at solving the problem we have raised? > They have been genuinely interested in trying to figure out how > their protocol can be applied and extended to solve our problem. > > You mention needing a "decoder ring" to decipher G.8080 terminology, > yet this terminology is certainly as foreign to ATM forum as it > would be to ccamp (perhaps even moreso, since I think there is > far more overlap in attendance between ITU-T SG15 and ccamp than > there is between ITU-T SG15 and ATM forum). Yet ATM forum had no > difficulty to understand what we were trying to do and to help us > to develop the solution. > > I do not think that this is because people in the ATM forum are > so much more intelligent than those in ccamp: in fact, many people > I have met in ccamp are absolutely brilliant. So if it is not the > ability of the people that prevents this kind of productive work, > I have to believe it is a shortcoming of the process. > > IETF stands nearly alone in the community of International standards > development organizations in not taking incoming liaisons as a > very serious input. It is only recently that we even had a place > to post incoming liaisons for IETF > (http://www.ietf.org/IESG/liaison.html). > Now it is important to develop a process to make sure that > those liaisons > are considered. > > In addition, IETF needs to be able to generate liaison statements > in order to effectively influence the work of other SDOs. IETF has > historically taken the view that they don't need to send anybody > anything because any information related to IETF can be found > on their web site or seen on the mailing list. But as a practical > matter, for most SDOs, input documents include contributions from > members, documents (like agendas and reports) prepared by those with > official positions, and LIAISON STATEMENTS. Surely you don't expect > that most SDOs will consider as serious input something that somebody > found on a web site or saw on a mailing list. To make IETF output > be an input to another SDO, in most cases IETF will need to formally > send it to the other SDO in the form of a liaison statement. > To date, IETF has been unsuccessful in doing this. > Regards, > Steve > > Dimitri.Papadimitriou@alcatel.be wrote: > > > > stephen > > > > i am resending you the e-mail sent to john because > > i am not sure you have red it "> What we got from > > IETF ccamp was ignored (until we finally did the > > work somewhere else and tried to get code points > > assigned)." > > > > --- > > 1) in order to initiate an action a clear under > > standing of the problem must be achieved by the > > ccamp wg community in order to make this happen > > > > 2) expect that ietf community would understand > > the terminology used in g.8080 (and subsequently > > the issue) by sending a liaison was probably > > a bit too optimistic -> thus the idea was to > > initiate a sort of "decoder ring" (just to be sure > > that when we say a "table" we are all in common > > agreement on what a table is) > > > > 3) instead of request changes to gmpls it would > > have been much more constructive to know really > > what are the architectural aspects covered by > > itu that are the key in enabling signalling for > > optical networks -> from that *clear* perspective > > the ccamp wg was expecting a "functional spec" > > i-d ... since the idea here was to understand > > the functional requirement outside of any specific > > signalling protocol (thus make abstraction of > > what was included in g.7713.x in a first phase) > > > > 4) once terminology + functional aspects would > > have been understood by the ccamp wg deliver the > > right answer using the ccamp community tools and > > protocols > > --- > > > > last it is not the ccamp wg consensus that has > > pushed itu editors to go to the info track ... > > > > thanks, > > - dimiti. > > > > Stephen Trowbridge wrote: > > > > > > John, > > > > > > > JD: Is that a threat or a promise? BTW, call & > connection separation > > > > doesn't exist in PNNI either, at least up to the point > that I stopped > > > > attending the ATM Forum. > > > Interesting that you should mention this. > > > > > > We sent liaisons to the ATM forum, just as we did to IETF ccamp. > > > The reaction we got from the ATM forum was a great deal of help to > > > extend the PNNI protocols to meet our requirements. They provided > > > us numerous, helpful comments all through the process of > development > > > of G.7713.1. > > > > > > What we got from IETF ccamp was ignored (until we finally did the > > > work somewhere else and tried to get code points assigned). > > > > > > We seem to have different understandings of what the > problem is that > > > needs to be solved. My belief is that the problem is that we don't > > > have a good process for dealing with liaisons in IETF, and this > > > inhibits the kinds of productive relationships between > IETF and other > > > SDOs that exist between many other (non-IETF) SDOs. > > > > > > Some others on this thread seem to think that the problem is those > > > other pesky SDOs: after all, how could there possibly be a valid > > > problem statement or requirement that wasn't conceived of > and developed > > > entirely within IETF? Every possible measure should be taken to > > > prevent that any work is done to address such requirements. > > > > > > What is your perception of the problem? > > > Steve > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > From owner-mpls@UU.NET Fri Feb 28 11:08:07 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02875 for ; Fri, 28 Feb 2003 11:08:07 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaa08977 for ; Fri, 28 Feb 2003 16:11:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeaa07501; Fri, 28 Feb 2003 16:11:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeaa12766 for mpls-outgoing; Fri, 28 Feb 2003 16:10:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoeaa12710 for ; Fri, 28 Feb 2003 16:10:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeaa06471 for ; Fri, 28 Feb 2003 16:10:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaa09971 for ; Fri, 28 Feb 2003 16:10:06 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoeaa09945 for ; Fri, 28 Feb 2003 16:10:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SGA3Nh008797 for ; Fri, 28 Feb 2003 11:10:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12247 for ; Fri, 28 Feb 2003 11:10:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SGA2a20576 for mpls@uu.net; Fri, 28 Feb 2003 11:10:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeaa12456 for ; Fri, 28 Feb 2003 16:08:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeaa17145 for ; Fri, 28 Feb 2003 16:08:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaa25280 for ; Fri, 28 Feb 2003 16:08:12 GMT Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.54]) id QQoeaa25268 for ; Fri, 28 Feb 2003 16:08:12 GMT Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1SG8A6N002127; Fri, 28 Feb 2003 08:08:11 -0800 (PST) Received: from cisco.com (sjc-vpn3-502.cisco.com [10.21.65.246]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AEL00863; Fri, 28 Feb 2003 07:51:12 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Fri, 28 Feb 2003 11:08:03 -0500 Date: Fri, 28 Feb 2003 11:08:03 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030228160802.GI2224@sbrim-w2k> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk On Fri, Feb 28, 2003 04:52:40PM +0100, Mak, L (Leen) allegedly wrote: > Wouldn't it be good to bring this whole discussion to the > ietf-problem-statement mailing list? It appears to be of > a wider scope than ccamp and mpls. > > Leen. Yes, but wrong problem. They're working on truly fundamental processes right now, and won't have room for issues of external relations until they finish with the internals. From owner-mpls@UU.NET Fri Feb 28 11:12:22 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03165 for ; Fri, 28 Feb 2003 11:12:21 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeab18935 for ; Fri, 28 Feb 2003 16:16:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeab18019; Fri, 28 Feb 2003 16:15:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeab13773 for mpls-outgoing; Fri, 28 Feb 2003 16:15:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoeab13731 for ; Fri, 28 Feb 2003 16:15:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeaa09798 for ; Fri, 28 Feb 2003 16:14:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaa15913 for ; Fri, 28 Feb 2003 16:14:16 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoeaa15880 for ; Fri, 28 Feb 2003 16:14:15 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SGEDNh009042 for ; Fri, 28 Feb 2003 11:14:13 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12576 for ; Fri, 28 Feb 2003 11:14:12 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SGECb21031 for mpls@uu.net; Fri, 28 Feb 2003 11:14:12 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeaa13282 for ; Fri, 28 Feb 2003 16:12:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeaa26066 for ; Fri, 28 Feb 2003 16:11:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaa11371 for ; Fri, 28 Feb 2003 16:11:10 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoeaa11335 for ; Fri, 28 Feb 2003 16:11:08 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA42946; Fri, 28 Feb 2003 11:07:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302281607.LAA42946@workhorse.fictitious.org> To: Bala Rajagopalan cc: Loa Andersson , ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Thu, 27 Feb 2003 22:57:56 EST." <05707214338CD5119BFF0040A5B170D3028897C1@mail3.tellium.com> Date: Fri, 28 Feb 2003 11:07:29 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <05707214338CD5119BFF0040A5B170D3028897C1@mail3.tellium.com>, Bala R ajagopalan writes: > Just ran into this ID. The flow chart, as usual, > was too complicated for me to comprehend, to I > ran it through the decoder software that IESG > provides to unscramble its policy statements > (see http://www.ietf.org/iesg/policy_faq/demystify.exe). > The flow chart was then rendered human-readable > as follows: AFAIK - When IESG members run the compiler they don't produce exe files. :-) > MPLS and GMPLS Change Process > ----------------------------- > > +-------------------------+ > | Receive New ID | > +-------------------------+ > | > | > V > +-------------------------------------+ > | Briefly wonder about the resilience | > | of the MPLS/GMPLS bandwagon. | > | Start review. | > +-------------------------------------+ > | > | > V > +-----------------------------------+ > | Does the draft contain the term | Yes > | "ASON"? |-------> TRASH > +-----------------------------------+ > | > | No > V > +----------------------------------+ > | Does the draft contain the term | Yes > | "UNI"? |--------> Incinerate > +----------------------------------+ > | > | No > V > +-------------------------------+ Yes, I-NNI > | How about "NNI?" |-----+----> TRASH > +-------------------------------+ | > | | E-NNI > | No +-----> Shred > V Not bad. I think you're OK up to here. > +-------------------------------+ > | Does the draft mention Call | Yes > | vs Connection control? |-------> Send a sample > +-------------------------------+ of draft to CDC, > | incinerate rest > | No > V I think that either "call control" or "connection control" warents a trip to the dumpster. > +-------------------------------+ > | Does the draft have the term | Yes > | "G.xyz." in the title? |---------> TRASH > +-------------------------------+ > | > | No > V Not true. Examples: 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. October 1998. (Format: TXT=43166 bytes) (Status: PROPOSED STANDARD) 3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi. January 2001. (Format: TXT=16292 bytes) (Status: PROPOSED STANDARD) 3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: TXT=368746 bytes) (Status: PROPOSED STANDARD) 3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. June 2002. (Format: TXT=110652 bytes) (Status: PROPOSED STANDARD) 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN). R. Zopf. September 2002. (Format: TXT=17018 bytes) (Status: PROPOSED STANDARD) These have plenty of G. and H. numbers in them and none of them are informational. All of them make sense (for example: no severe scaling issues). > +-------------------------------+ > | Draft has progressed too far. | > | Send to Curtis for review. | > +-------------------------------+ > | > | > V > | | > | TRASH | > +------------+ I didn't realize I played such an important role in this process. All this time I thought I was just making technical comments. Sounds like you're still upset that I didn't like the OIF-UNI and/or you don't like technical comments regarding the feasibility of proposed encapsulation of G.709. A primary point regarding OIF-UNI is that ATM-UNI service (ie: SVCs) never took off therefore the last thing we needed was a UNI for optical. In other words, there is no credible requirement. We'll have to see how the market acceptance of OIF-UNI goes. So far it looks about as alive as CR-LDP did for a few years. The market certainly put an end to LANE, NHRP, MPOA, and the whole idea of modeling ATM as a LIS. Check the IPATM and ION archives if you'd like to read my comments on those standards which were strongly supported by SDOs outside the IETF. I'm sorry that you don't like technical comments made about the G.709 compressions. Apparently some people think the IETF should just rubber stamp everything because it came from the ITU even if there are scalability issues which make deployment infeasible. > Seems a bit draconian and no wonder, people are anxious > about the process and expect the worst. Still, I believe > this will help in limiting the generation of useless drafts > and protocol extensions to > WGs within the IETF and prevent outside groups from doing the same. > > Regards, > > Bala Rajagopalan The IETF can't stop other SDOs from creating useless protocols and protocol extensions and some have become quite good at it. :-) Curtis From owner-mpls@UU.NET Fri Feb 28 11:13:53 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03303 for ; Fri, 28 Feb 2003 11:13:53 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeab07457 for ; Fri, 28 Feb 2003 16:17:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeab06663; Fri, 28 Feb 2003 16:17:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeab14092 for mpls-outgoing; Fri, 28 Feb 2003 16:16:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoeab14070 for ; Fri, 28 Feb 2003 16:16:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoeab08183 for ; Fri, 28 Feb 2003 16:16:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeab16494 for ; Fri, 28 Feb 2003 16:15:45 GMT Received: from maild.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maild.telia.com [194.22.190.101]) id QQoeab16449 for ; Fri, 28 Feb 2003 16:15:44 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maild.telia.com (8.12.5/8.12.5) with ESMTP id h1SGFhQT010813 for ; Fri, 28 Feb 2003 17:15:43 +0100 (CET) X-Original-Recipient: Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1SGFg213368 for ; Fri, 28 Feb 2003 17:15:42 +0100 (CET) Message-ID: <3E5F8A25.8030201@pi.se> Date: Fri, 28 Feb 2003 17:11:17 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <9D42C6E086250248810DCADA39CE7EFC972275@nimbus> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All, I might be stupid, but I actually see some commonality forming on this thread, though there is much smoke I think we agree on the following: 1. and most important - we want a productive, trustful and comprehensive co-operatiom between IETF and other SDOs 2. the process that describes how this co-operation is handled needs to be described 3. we need to have a known, reliable and open (g)mpls technology area process for how extend and change the (g)mpls protocols 4. this process also needs to be descirbed 5. that the (g)mpls working groups in the IETF (or maybe the IETF in general) [sometimes, often, regulary, a few times] have mismanaged incoming liasions from other SDOs Note 1: I know that some voices has been raised saying that "the general process for c-operation between IETF and other SDOs" are not a subject matter for for the mpls-list. I tend to agree, however one of our ADs made it appropriate as long as we discuss the coupling between the to processes above. We disagree on: a. whether the two processes needs to go into the same document or not b. whether documents generated in one process could go seemlessly into the other process I hope we agree on this: 6. that the relationship between IETF and other SDOs are by nature a relationship between equal parties 7. that each organization are entitled to define it own processes, methodology and document types Some personal reflections - Kireeti and Bert has recognized that here has been less than satifactory performanse by the IETF in handling liasions in the past, we will not be any wiser if that aregument is repeated - I don't think it is agood idea to describe the two process in the same document. the chnage-process is for our internal use, the liasion process is for our commuinication with other SDOs (I understand that from the other side this might look pretty much the same, but if the only problem is that of how some type of info sent from one organisation is received by another, let us solve that problem) It must be fairly easy for the sending organization say to the IETF "Please, handle the content of this liasion as an Internet Draft!" Based on that we can publish is as an ID, and include it in our work. But if there is written in stone that a liasion is a liasion is a liasion, then we will require that other SDOs send us IDs. - in our internal processes we need documents ofer which we have change control and therefore it is unsatifactory to use non-IETF documents Would be good if we could agree on points 1-6 and on a and b, would be far easier to continue the disucssion. /Loa From owner-mpls@UU.NET Fri Feb 28 11:47:59 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04353 for ; Fri, 28 Feb 2003 11:47:59 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoead14755 for ; Fri, 28 Feb 2003 16:51:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoead13853; Fri, 28 Feb 2003 16:51:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQoead16636 for mpls-outgoing; Fri, 28 Feb 2003 16:51:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoead16585 for ; Fri, 28 Feb 2003 16:51:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoead08010 for ; Fri, 28 Feb 2003 16:50:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoead03538 for ; Fri, 28 Feb 2003 16:50:31 GMT Received: from alpha2.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.125.55.125]) id QQoead03532 for ; Fri, 28 Feb 2003 16:50:31 GMT Received: from mail3.tellium.com (unverified) by alpha2.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Feb 2003 11:48:47 -0500 Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 11:46:34 -0500 Message-ID: <05707214338CD5119BFF0040A5B170D3028897C7@mail3.tellium.com> From: Bala Rajagopalan To: "'curtis@fictitious.org'" Cc: Loa Andersson , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 11:46:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Curtis: First, thanks for your patient response. Needless to say, a bit of exaggeration is necessary for humor (I hope there was some humor in this). I wasn't really following the thread on G.709, so this was not the issue. There are a number of G.xxxx documents related to ASON that use IETF protocols and this is what I was referring to. Now, I don't think that all solutions developed outside of IETF (using IETF protocols) are clean. However, I do think that so far, there has not been an adequate effort in IETF to understand the problem formulations coming from outside. This is the crux of my message. In this regard, yes, I do believe that you have been prominent in rejecting the entire notion of the UNI. I personally don't have an addiction to UNI (or any of the G.xxxx stuff), except that some number of service providers (the potential customers of the technology) wanted this and an effort was made to deliver the features they wanted. Is there a better way of providing the same UNI functionality using GMPLS protocols? This is what one would like to hear from IETF, rather than a dismissal of the whole concept. Correct me if I'm wrong, but the present Andersson draft, IMO, doesn't address this problem. Clearly, I won't place any bets on the success of UNI in the market place (what market?). Neither will I place any bets on GMPLS at this point in time. Thank you. Bala Bala Rajagopalan Tellium, Inc. 2 Crescent Pl. Ocean Port, NJ 07757 USA Ph: +1-732-923-4237 Email: braja@tellium.com > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Friday, February 28, 2003 11:07 AM > To: Bala Rajagopalan > Cc: Loa Andersson; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > In message > <05707214338CD5119BFF0040A5B170D3028897C1@mail3.tellium.com>, Bala R > ajagopalan writes: > > Just ran into this ID. The flow chart, as usual, > > was too complicated for me to comprehend, to I > > ran it through the decoder software that IESG > > provides to unscramble its policy statements > > (see http://www.ietf.org/iesg/policy_faq/demystify.exe). > > The flow chart was then rendered human-readable > > as follows: > > > AFAIK - When IESG members run the compiler they don't produce exe > files. :-) > > > > MPLS and GMPLS Change Process > > ----------------------------- > > > > +-------------------------+ > > | Receive New ID | > > +-------------------------+ > > | > > | > > V > > +-------------------------------------+ > > | Briefly wonder about the resilience | > > | of the MPLS/GMPLS bandwagon. | > > > | Start review. | > > +-------------------------------------+ > > | > > | > > V > > +-----------------------------------+ > > | Does the draft contain the term | Yes > > | "ASON"? |-------> TRASH > > +-----------------------------------+ > > | > > | No > > V > > +----------------------------------+ > > | Does the draft contain the term | Yes > > | "UNI"? |--------> Incinerate > > +----------------------------------+ > > | > > | No > > V > > +-------------------------------+ Yes, I-NNI > > | How about "NNI?" |-----+----> TRASH > > +-------------------------------+ | > > | | E-NNI > > | No +-----> Shred > > V > > > Not bad. I think you're OK up to here. > > > > +-------------------------------+ > > | Does the draft mention Call | Yes > > | vs Connection control? |-------> Send a sample > > +-------------------------------+ of draft to CDC, > > | incinerate rest > > | No > > V > > > I think that either "call control" or "connection control" warents a > trip to the dumpster. > > > > +-------------------------------+ > > | Does the draft have the term | Yes > > | "G.xyz." in the title? |---------> TRASH > > +-------------------------------+ > > | > > | No > > V > > > Not true. Examples: > > 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. > H.263 Video > (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, > C. Maciocco, > D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. > October 1998. > (Format: TXT=43166 bytes) (Status: PROPOSED STANDARD) > > 3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi. > January 2001. (Format: TXT=16292 bytes) (Status: > PROPOSED STANDARD) > > 3095 RObust Header Compression (ROHC): Framework and four profiles: > RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. > Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. > Hakenberg, T. > Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. > Svanbro, T. > Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: > TXT=368746 bytes) > (Status: PROPOSED STANDARD) > > 3267 Real-Time Transport Protocol (RTP) Payload Format and File > Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive > Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, > M. Westerlund, > A. Lakaniemi, Q. Xie. June 2002. (Format: TXT=110652 > bytes) (Status: > PROPOSED STANDARD) > > 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise > (CN). R. Zopf. September 2002. (Format: TXT=17018 > bytes) (Status: > PROPOSED STANDARD) > > These have plenty of G. and H. numbers in them and none of them are > informational. All of them make sense (for example: no severe scaling > issues). > > > +-------------------------------+ > > | Draft has progressed too far. | > > | Send to Curtis for review. | > > +-------------------------------+ > > | > > | > > V > > | | > > | TRASH | > > +------------+ > > > I didn't realize I played such an important role in this process. All > this time I thought I was just making technical comments. > > Sounds like you're still upset that I didn't like the OIF-UNI and/or > you don't like technical comments regarding the feasibility of > proposed encapsulation of G.709. A primary point regarding OIF-UNI is > that ATM-UNI service (ie: SVCs) never took off therefore the last > thing we needed was a UNI for optical. In other words, there is no > credible requirement. > > We'll have to see how the market acceptance of OIF-UNI goes. So far > it looks about as alive as CR-LDP did for a few years. The market > certainly put an end to LANE, NHRP, MPOA, and the whole idea of > modeling ATM as a LIS. Check the IPATM and ION archives if you'd like > to read my comments on those standards which were strongly supported > by SDOs outside the IETF. > > I'm sorry that you don't like technical comments made about the G.709 > compressions. Apparently some people think the IETF should just > rubber stamp everything because it came from the ITU even if there are > scalability issues which make deployment infeasible. > > > > Seems a bit draconian and no wonder, people are anxious > > about the process and expect the worst. Still, I believe > > this will help in limiting the generation of useless drafts > > and protocol extensions to > > WGs within the IETF and prevent outside groups from doing the same. > > > > Regards, > > > > Bala Rajagopalan > > > The IETF can't stop other SDOs from creating useless protocols and > protocol extensions and some have become quite good at it. :-) > > Curtis > From owner-mpls@UU.NET Fri Feb 28 11:51:49 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04504 for ; Fri, 28 Feb 2003 11:51:49 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoead22706 for ; Fri, 28 Feb 2003 16:55:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoead21421; Fri, 28 Feb 2003 16:55:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQoead16775 for mpls-outgoing; Fri, 28 Feb 2003 16:54:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoead16763 for ; Fri, 28 Feb 2003 16:54:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoead13618 for ; Fri, 28 Feb 2003 16:54:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoead07191 for ; Fri, 28 Feb 2003 16:54:06 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoead07182 for ; Fri, 28 Feb 2003 16:54:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SGs3Nh011334 for ; Fri, 28 Feb 2003 11:54:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA15893 for ; Fri, 28 Feb 2003 11:54:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SGs3028472 for mpls@uu.net; Fri, 28 Feb 2003 11:54:03 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoead16678 for ; Fri, 28 Feb 2003 16:51:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoead04509 for ; Fri, 28 Feb 2003 16:51:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoead23274 for ; Fri, 28 Feb 2003 16:51:22 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoead23259 for ; Fri, 28 Feb 2003 16:51:21 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA43484; Fri, 28 Feb 2003 11:50:10 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302281650.LAA43484@workhorse.fictitious.org> To: Loa Andersson cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Fri, 28 Feb 2003 17:11:17 +0100." <3E5F8A25.8030201@pi.se> Date: Fri, 28 Feb 2003 11:50:10 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E5F8A25.8030201@pi.se>, Loa Andersson writes: > > - I don't think it is agood idea to describe the two process in the same > document. the chnage-process is for our internal use, the liasion process > is for our commuinication with other SDOs If we can agree on this, then we can move forward with your document. Curtis From owner-mpls@UU.NET Fri Feb 28 12:06:32 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04972 for ; Fri, 28 Feb 2003 12:06:31 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeae02935 for ; Fri, 28 Feb 2003 17:10:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeae19454; Fri, 28 Feb 2003 17:04:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeae28000 for mpls-outgoing; Fri, 28 Feb 2003 17:03:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeae27646 for ; Fri, 28 Feb 2003 17:03:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoeae13315 for ; Fri, 28 Feb 2003 17:03:29 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeae05454 for ; Fri, 28 Feb 2003 17:03:29 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQoeae05438 for ; Fri, 28 Feb 2003 17:03:28 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SH3RF17835 for ; Fri, 28 Feb 2003 12:03:27 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <1HW0C6DK>; Fri, 28 Feb 2003 12:03:27 -0500 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA838A@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Loa Andersson'" , mpls@UU.NET, "'ccamp@ops.ietf.org'" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 12:03:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Very helpful email. I concur with points 1-6. Re points (a) and (b), perhaps the best approach would be to first generate the material itself. Discussion of its subsequent subdivision would be far easier, if there were actual content to work with. Eve -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Friday, February 28, 2003 11:11 AM To: mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt All, I might be stupid, but I actually see some commonality forming on this thread, though there is much smoke I think we agree on the following: 1. and most important - we want a productive, trustful and comprehensive co-operatiom between IETF and other SDOs 2. the process that describes how this co-operation is handled needs to be described 3. we need to have a known, reliable and open (g)mpls technology area process for how extend and change the (g)mpls protocols 4. this process also needs to be descirbed 5. that the (g)mpls working groups in the IETF (or maybe the IETF in general) [sometimes, often, regulary, a few times] have mismanaged incoming liasions from other SDOs Note 1: I know that some voices has been raised saying that "the general process for c-operation between IETF and other SDOs" are not a subject matter for for the mpls-list. I tend to agree, however one of our ADs made it appropriate as long as we discuss the coupling between the to processes above. We disagree on: a. whether the two processes needs to go into the same document or not b. whether documents generated in one process could go seemlessly into the other process I hope we agree on this: 6. that the relationship between IETF and other SDOs are by nature a relationship between equal parties 7. that each organization are entitled to define it own processes, methodology and document types Some personal reflections - Kireeti and Bert has recognized that here has been less than satifactory performanse by the IETF in handling liasions in the past, we will not be any wiser if that aregument is repeated - I don't think it is agood idea to describe the two process in the same document. the chnage-process is for our internal use, the liasion process is for our commuinication with other SDOs (I understand that from the other side this might look pretty much the same, but if the only problem is that of how some type of info sent from one organisation is received by another, let us solve that problem) It must be fairly easy for the sending organization say to the IETF "Please, handle the content of this liasion as an Internet Draft!" Based on that we can publish is as an ID, and include it in our work. But if there is written in stone that a liasion is a liasion is a liasion, then we will require that other SDOs send us IDs. - in our internal processes we need documents ofer which we have change control and therefore it is unsatifactory to use non-IETF documents Would be good if we could agree on points 1-6 and on a and b, would be far easier to continue the disucssion. /Loa From owner-mpls@UU.NET Fri Feb 28 12:13:44 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05142 for ; Fri, 28 Feb 2003 12:13:44 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaf19979 for ; Fri, 28 Feb 2003 17:17:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeaf17456; Fri, 28 Feb 2003 17:16:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeaf07215 for mpls-outgoing; Fri, 28 Feb 2003 17:16:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoeaf07209 for ; Fri, 28 Feb 2003 17:16:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoeaf13697 for ; Fri, 28 Feb 2003 17:15:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaf16460 for ; Fri, 28 Feb 2003 17:15:48 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQoeaf16449 for ; Fri, 28 Feb 2003 17:15:48 GMT Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SHFke23282; Fri, 28 Feb 2003 12:15:46 -0500 (EST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [192.11.157.124]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA20581; Fri, 28 Feb 2003 11:15:40 -0600 (CST) Message-ID: <3E5F993C.27CFAB0D@lucent.com> Date: Fri, 28 Feb 2003 10:15:40 -0700 From: Stephen Trowbridge Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: curtis@fictitious.org CC: Loa Andersson , mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <200302281650.LAA43484@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, I have no problem to seperate the liaison process from the internal process. In fact, a good liaison process is needed that would have much broader applicability than (G)MPLS protocols. However, I do disagree that we can go forward on one with out the other. As Bala's flowchart shows, the effect of applying this draft to internally and externally initated work alike is to give the externally initiated work a fast track to the trash. Without the liaison process, this draft seems to make what is already a bad problem with how we deal with input from other SDOs even worse. Regards, Steve Curtis Villamizar wrote: > > In message <3E5F8A25.8030201@pi.se>, Loa Andersson writes: > > > > - I don't think it is agood idea to describe the two process in the same > > document. the chnage-process is for our internal use, the liasion process > > is for our commuinication with other SDOs > > If we can agree on this, then we can move forward with your document. > > Curtis From owner-mpls@UU.NET Fri Feb 28 12:21:47 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05433 for ; Fri, 28 Feb 2003 12:21:47 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaf02523 for ; Fri, 28 Feb 2003 17:25:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeaf00857; Fri, 28 Feb 2003 17:24:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeaf07670 for mpls-outgoing; Fri, 28 Feb 2003 17:24:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoeaf07665 for ; Fri, 28 Feb 2003 17:24:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeaf18000 for ; Fri, 28 Feb 2003 17:24:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaf17177 for ; Fri, 28 Feb 2003 17:24:13 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoeaf17154 for ; Fri, 28 Feb 2003 17:24:13 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SHOAJR022383 for ; Fri, 28 Feb 2003 12:24:10 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA18198 for ; Fri, 28 Feb 2003 12:24:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SHOA403334 for mpls@uu.net; Fri, 28 Feb 2003 12:24:10 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeaf07618 for ; Fri, 28 Feb 2003 17:22:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeaf11043 for ; Fri, 28 Feb 2003 17:21:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaf20087 for ; Fri, 28 Feb 2003 17:21:49 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoeaf20077 for ; Fri, 28 Feb 2003 17:21:47 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA43686; Fri, 28 Feb 2003 12:17:12 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302281717.MAA43686@workhorse.fictitious.org> To: Bala Rajagopalan cc: "'curtis@fictitious.org'" , Loa Andersson , ccamp@ops.ietf.org, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Fri, 28 Feb 2003 11:46:25 EST." <05707214338CD5119BFF0040A5B170D3028897C7@mail3.tellium.com> Date: Fri, 28 Feb 2003 12:17:12 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <05707214338CD5119BFF0040A5B170D3028897C7@mail3.tellium.com>, Bala R ajagopalan writes: > > Curtis: > > First, thanks for your patient response. > Needless to say, a bit of exaggeration is > necessary for humor (I hope there was some > humor in this). Yes. I can parse humor. [seems like an oxymoron as stated. :) ] > I wasn't really following the thread on G.709, > so this was not the issue. There are a number > of G.xxxx documents related to ASON that use > IETF protocols and this is what I was referring > to. > > Now, I don't think that all solutions developed > outside of IETF (using IETF protocols) are clean. > However, I do think that so far, there has not > been an adequate effort in IETF to understand > the problem formulations coming from outside. > This is the crux of my message. There are also individuals, some of whom played a key role in ASON, who could not make a convincing argument at times in the IETF, and have gone outside the IETF where questionable requirements will receive less carefull scrutiny, then come back to the IETF and expect a rubber stamp. Some of the same people that dominated IPLDN, IPATM, ROLC and ION within the IETF went outside IETF and gave us ASON. To be perfectly honest with you, I personally put no more credibility in ASON that I did in the ITU IP-QoS documents of the mid-90s. The ITU has stepped out of bounds (again). They deserve to be ignored. > In this regard, yes, I do believe that you have > been prominent in rejecting the entire notion > of the UNI. I personally don't have an addiction > to UNI (or any of the G.xxxx stuff), except that > some number of service providers > (the potential customers of the technology) wanted > this and an effort was made to deliver the features > they wanted. Is there a better way of providing > the same UNI functionality using GMPLS protocols? This > is what one would like to hear from IETF, rather than > a dismissal of the whole concept. Correct me if > I'm wrong, but the present Andersson draft, IMO, > doesn't address this problem. The ISPs certainly did not drive this. The SPs, wannabe ISPs, maybe. I do think the vendors pushed this and a few people at SPs, mostly in legacy transport, were willing to stand behind it. > Clearly, I won't place any bets on > the success of UNI in the market place (what > market?). Neither will I place any bets on GMPLS > at this point in time. OK. I tend to agree, however GMPLS may become successful. The future of GMPLS is not certain, however if GMPLS dies it will be very likely to due to core optical switching turning out to be even less useful than currently anticipated. > Thank you. > > Bala Curtis ps - for a related dose of humor see keeping in mind that at the time of publication (April 1, 2000) it was herassy to suggest that optical switching was going to be anything less than enormously successful or suggest that all optical switching would not be the dominant technology of IP backbones or suggest that exponential growth of the Internet would not be sustained indefinitely. From owner-mpls@UU.NET Fri Feb 28 12:32:55 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06563 for ; Fri, 28 Feb 2003 12:32:55 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeag07235 for ; Fri, 28 Feb 2003 17:36:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeag06553; Fri, 28 Feb 2003 17:36:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeag08728 for mpls-outgoing; Fri, 28 Feb 2003 17:36:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeag08630 for ; Fri, 28 Feb 2003 17:35:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeag24715 for ; Fri, 28 Feb 2003 17:35:28 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeag05440 for ; Fri, 28 Feb 2003 17:35:28 GMT Received: from kcmso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQoeag05436 for ; Fri, 28 Feb 2003 17:35:27 GMT Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1SHVnWn000084 for ; Fri, 28 Feb 2003 11:35:27 -0600 (CST) Received: from OCCLUST02EVS1.ugd.att.com (135.71.164.8) by attrh1i.attrh.att.com (6.5.019) id 3E5CD82C00072363; Fri, 28 Feb 2003 12:35:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 12:35:25 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA61B@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLfTdwup82ty5vxR8i+lN2NZtwLmgAAc7Zg From: "Brungard, Deborah A, ALABS" To: "Stephen Trowbridge" , Cc: "Loa Andersson" , , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA06563 Was the concern by saying "external standards bodies", it was interpreted as liaisons (as this is the only formal way for T1/ITU to communicate), which implies submission of an "individual draft", review, etc.? So as not to confuse "standards bodies" with liaison communication, how about in the draft changing this to "participants of external standards bodies"? Or perhaps best is to just remove. And let the liaison process address, with links to this document. Deborah -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Friday, February 28, 2003 12:16 PM To: curtis@fictitious.org Cc: Loa Andersson; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Curtis, I have no problem to seperate the liaison process from the internal process. In fact, a good liaison process is needed that would have much broader applicability than (G)MPLS protocols. However, I do disagree that we can go forward on one with out the other. As Bala's flowchart shows, the effect of applying this draft to internally and externally initated work alike is to give the externally initiated work a fast track to the trash. Without the liaison process, this draft seems to make what is already a bad problem with how we deal with input from other SDOs even worse. Regards, Steve Curtis Villamizar wrote: > > In message <3E5F8A25.8030201@pi.se>, Loa Andersson writes: > > > > - I don't think it is agood idea to describe the two process in the same > > document. the chnage-process is for our internal use, the liasion process > > is for our commuinication with other SDOs > > If we can agree on this, then we can move forward with your document. > > Curtis From owner-mpls@UU.NET Fri Feb 28 12:44:24 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06893 for ; Fri, 28 Feb 2003 12:44:23 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeah18105 for ; Fri, 28 Feb 2003 17:48:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeah16133; Fri, 28 Feb 2003 17:47:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeah09692 for mpls-outgoing; Fri, 28 Feb 2003 17:46:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoeah09687 for ; Fri, 28 Feb 2003 17:46:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeah08893 for ; Fri, 28 Feb 2003 17:46:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeah20558 for ; Fri, 28 Feb 2003 17:46:06 GMT Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoeah20538 for ; Fri, 28 Feb 2003 17:46:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SHk3Nh013933 for ; Fri, 28 Feb 2003 12:46:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA20076 for ; Fri, 28 Feb 2003 12:46:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SHk2E07113 for mpls@uu.net; Fri, 28 Feb 2003 12:46:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeag09247 for ; Fri, 28 Feb 2003 17:43:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoeag21089 for ; Fri, 28 Feb 2003 17:43:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeag25193 for ; Fri, 28 Feb 2003 17:43:40 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoeag25155 for ; Fri, 28 Feb 2003 17:43:39 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA43999; Fri, 28 Feb 2003 12:42:24 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302281742.MAA43999@workhorse.fictitious.org> To: Stephen Trowbridge cc: curtis@fictitious.org, Loa Andersson , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Fri, 28 Feb 2003 10:15:40 MST." <3E5F993C.27CFAB0D@lucent.com> Date: Fri, 28 Feb 2003 12:42:24 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E5F993C.27CFAB0D@lucent.com>, Stephen Trowbridge writes: > Curtis, > I have no problem to seperate the liaison process from the internal process. > In fact, a good liaison process is needed that would have much broader > applicability than (G)MPLS protocols. > > However, I do disagree that we can go forward on one with out the other. > As Bala's flowchart shows, the effect of applying this draft to internally > and externally initated work alike is to give the externally initiated > work a fast track to the trash. Without the liaison process, this draft > seems to make what is already a bad problem with how we deal with input > from other SDOs even worse. > Regards, > Steve > > Curtis Villamizar wrote: > > > > In message <3E5F8A25.8030201@pi.se>, Loa Andersson writes: > > > > > > - I don't think it is agood idea to describe the two process in the same > > > document. the chnage-process is for our internal use, the liasion proce > ss > > > is for our commuinication with other SDOs > > > > If we can agree on this, then we can move forward with your document. > > > > Curtis Steve, Loa's draft documents IETF process that has pretty much been put into place under the guidance of the IESG to keep the level of junk down to a minimum and insure that extensions both address real needs and their deployment is feasible. The sooner participants in outside SDOs recognize this, the better for them. Earlier you stated, that if an outside SDO specified an extension and you expect the IETF to simply accept that. It may turn out that the IETF has documented their process in rfc2026 and clarified it here and you simply have to accept that. :-) Curtis From owner-mpls@UU.NET Fri Feb 28 14:29:11 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09755 for ; Fri, 28 Feb 2003 14:29:11 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeao03719 for ; Fri, 28 Feb 2003 19:33:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeao02738; Fri, 28 Feb 2003 19:32:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeao24941 for mpls-outgoing; Fri, 28 Feb 2003 19:32:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeao24921 for ; Fri, 28 Feb 2003 19:32:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoeao04171 for ; Fri, 28 Feb 2003 19:31:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeao01803 for ; Fri, 28 Feb 2003 19:31:45 GMT Received: from gwngate.homelinux.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ool-43547318.dyn.optonline.net [67.84.115.24]) id QQoeao01788 for ; Fri, 28 Feb 2003 19:31:45 GMT Received: from bigguy ([192.168.0.7] helo=ieee.org) by gwngate.homelinux.org with esmtp (Exim 3.35 #1 (Debian)) id 18oqE4-0002Dt-00; Fri, 28 Feb 2003 14:31:20 -0500 Message-ID: <3E5FB905.1000001@ieee.org> Date: Fri, 28 Feb 2003 14:31:17 -0500 From: George Newsome User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: curtis@fictitious.org CC: Stephen Trowbridge , Loa Andersson , mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <200302281742.MAA43999@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > Steve, > > Loa's draft documents IETF process that has pretty much been put into > place under the guidance of the IESG to keep the level of junk down to > a minimum and insure that extensions both address real needs and their > deployment is feasible. The sooner participants in outside SDOs > recognize this, the better for them. > So in the spirit of reducing the amount of junk to IESG, it seems that the IETF already understand their process, so this ID can be dropped. > Earlier you stated, that if an outside SDO specified an extension and > you expect the IETF to simply accept that. It may turn out that the > IETF has documented their process in rfc2026 and clarified it here and > you simply have to accept that. :-) > The IETF doesn't collaborate with other SDO's, so there is no need for any further discussion on mechanisms for collaboration, and one less ID is needed. George From owner-mpls@UU.NET Fri Feb 28 14:58:31 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10872 for ; Fri, 28 Feb 2003 14:58:30 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaq15152 for ; Fri, 28 Feb 2003 20:02:24 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeaq13674; Fri, 28 Feb 2003 20:01:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeaq11864 for mpls-outgoing; Fri, 28 Feb 2003 20:01:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoeaq11655 for ; Fri, 28 Feb 2003 20:01:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeaq10702 for ; Fri, 28 Feb 2003 20:01:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaq25188 for ; Fri, 28 Feb 2003 20:01:06 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoeaq25178 for ; Fri, 28 Feb 2003 20:01:06 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SK13JR002257 for ; Fri, 28 Feb 2003 15:01:04 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA02018 for ; Fri, 28 Feb 2003 15:01:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SK12Y18222 for mpls@uu.net; Fri, 28 Feb 2003 15:01:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoeaq08652 for ; Fri, 28 Feb 2003 20:00:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeap08151 for ; Fri, 28 Feb 2003 19:59:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeap23465 for ; Fri, 28 Feb 2003 19:59:39 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoeap23460 for ; Fri, 28 Feb 2003 19:59:39 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA45159; Fri, 28 Feb 2003 14:58:14 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302281958.OAA45159@workhorse.fictitious.org> To: George Newsome cc: curtis@fictitious.org, Stephen Trowbridge , Loa Andersson , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Fri, 28 Feb 2003 14:31:17 EST." <3E5FB905.1000001@ieee.org> Date: Fri, 28 Feb 2003 14:58:14 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3E5FB905.1000001@ieee.org>, George Newsome writes: > Curtis Villamizar wrote: > > > Steve, > > > > Loa's draft documents IETF process that has pretty much been put into > > place under the guidance of the IESG to keep the level of junk down to > > a minimum and insure that extensions both address real needs and their > > deployment is feasible. The sooner participants in outside SDOs > > recognize this, the better for them. > > So in the spirit of reducing the amount of junk to IESG, it seems that > the IETF already understand their process, so this ID can be dropped. Can we stick to constructive comments. Determining that there are legitimate requirements is a good thing and so Loa's draft should go forward. As Deborah pointed out the mention of liason should be removed to decouple the two issues. > > Earlier you stated, that if an outside SDO specified an extension and > > you expect the IETF to simply accept that. It may turn out that the > > IETF has documented their process in rfc2026 and clarified it here and > > you simply have to accept that. :-) > > The IETF doesn't collaborate with other SDO's, so there is no need for > any further discussion on mechanisms for collaboration, and one less ID > is needed. This draft wasn't intended to address liason. It doesn't but it serves a useful purpose. Its clear we don't have full consensus on SDO liason relationships to the IETF. Those who wish to have liasons be given special consideration in the IETF have brought up the orthogonal topic of liasons. This document is about having agreed upon requirements before considering protocol extensions. > George Curtis From owner-mpls@UU.NET Fri Feb 28 15:13:40 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12098 for ; Fri, 28 Feb 2003 15:13:40 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoear21965 for ; Fri, 28 Feb 2003 20:16:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoear20582; Fri, 28 Feb 2003 20:16:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQoear02305 for mpls-outgoing; Fri, 28 Feb 2003 20:15:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoear02232 for ; Fri, 28 Feb 2003 20:15:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoear15562 for ; Fri, 28 Feb 2003 20:15:21 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoear10899 for ; Fri, 28 Feb 2003 20:15:21 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQoear10893 for ; Fri, 28 Feb 2003 20:15:21 GMT Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SKFJb05905 for ; Fri, 28 Feb 2003 15:15:19 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 15:15:19 -0500 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA8390@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'curtis@fictitious.org'" , George Newsome Cc: Stephen Trowbridge , Loa Andersson , mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 15:15:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Your comment re "legitimate requirements" has everything to do with the relationship with other SDOs, which is currently implicitly coupled into the liaison discussions. My concern, as is also expressed in Steve Trowbridge's earlier comments, is related to the Gatekeeper role that you are appearing to advocate. For individual contributor drafts coming in, it's quite appropriate to evaluate requirements and determine if they are legitimate. It's a different case when another SDO, responsible for a non-IP applications domain, has established a set of requirements related to that domain. Eve -----Original Message----- From: Curtis Villamizar [mailto:curtis@fictitious.org] Sent: Friday, February 28, 2003 2:58 PM To: George Newsome Cc: curtis@fictitious.org; Stephen Trowbridge; Loa Andersson; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In message <3E5FB905.1000001@ieee.org>, George Newsome writes: > Curtis Villamizar wrote: > > > Steve, > > > > Loa's draft documents IETF process that has pretty much been put into > > place under the guidance of the IESG to keep the level of junk down to > > a minimum and insure that extensions both address real needs and their > > deployment is feasible. The sooner participants in outside SDOs > > recognize this, the better for them. > > So in the spirit of reducing the amount of junk to IESG, it seems that > the IETF already understand their process, so this ID can be dropped. Can we stick to constructive comments. Determining that there are legitimate requirements is a good thing and so Loa's draft should go forward. As Deborah pointed out the mention of liason should be removed to decouple the two issues. > > Earlier you stated, that if an outside SDO specified an extension and > > you expect the IETF to simply accept that. It may turn out that the > > IETF has documented their process in rfc2026 and clarified it here and > > you simply have to accept that. :-) > > The IETF doesn't collaborate with other SDO's, so there is no need for > any further discussion on mechanisms for collaboration, and one less ID > is needed. This draft wasn't intended to address liason. It doesn't but it serves a useful purpose. Its clear we don't have full consensus on SDO liason relationships to the IETF. Those who wish to have liasons be given special consideration in the IETF have brought up the orthogonal topic of liasons. This document is about having agreed upon requirements before considering protocol extensions. > George Curtis From owner-mpls@UU.NET Fri Feb 28 15:52:48 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12950 for ; Fri, 28 Feb 2003 15:52:48 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeat11624 for ; Fri, 28 Feb 2003 20:54:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeat10535; Fri, 28 Feb 2003 20:54:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeat17804 for mpls-outgoing; Fri, 28 Feb 2003 20:53:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoeat17760 for ; Fri, 28 Feb 2003 20:53:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeat02474 for ; Fri, 28 Feb 2003 20:52:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeat22479 for ; Fri, 28 Feb 2003 20:52:05 GMT Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoeat22466 for ; Fri, 28 Feb 2003 20:52:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SKq2JR005591 for ; Fri, 28 Feb 2003 15:52:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA06323 for ; Fri, 28 Feb 2003 15:52:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SKq2424214 for mpls@uu.net; Fri, 28 Feb 2003 15:52:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoeat16784 for ; Fri, 28 Feb 2003 20:50:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeat17136 for ; Fri, 28 Feb 2003 20:49:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeat13217 for ; Fri, 28 Feb 2003 20:49:57 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoeat13202 for ; Fri, 28 Feb 2003 20:49:56 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA45896; Fri, 28 Feb 2003 15:48:31 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302282048.PAA45896@workhorse.fictitious.org> To: "Varma, Eve L (Eve)" cc: "'curtis@fictitious.org'" , George Newsome , Stephen Trowbridge , Loa Andersson , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Fri, 28 Feb 2003 15:15:18 EST." <61B49BC6DA0DDE40957FB499E1835E3705FA8390@nj7460exch010u.ho.lucent.com> Date: Fri, 28 Feb 2003 15:48:31 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk > Your comment re "legitimate requirements" has everything to do with > the relatio nship with other SDOs, which is currently implicitly > coupled into the liaison discussions. My concern , as is also > expressed in Steve Trowbridge's earlier comments, is related to the > Gatekeeper role that you are appearing to advocate. > > For individual contributor drafts coming in, it's quite appropriate to > evaluate requirements and determine if they are legitimate. It's a > different case when another SDO, responsible for a non-IP applications > domain, has established a set of requirements related to that domain. > > Eve If we remove all mention of liason, then the document applies to all individual submissions. You are not arguing that this is a bad thing for individual submissions. A second orthogonal issue which this draft does not address is whether liason internet-drafts would be given special consideration or would continue to be handled as individual submissions. If the mention of liasons is removed and there are no further issues, we can move forward with this draft. [Then discuss the liason issue later and preferably on some other list.] Curtis From owner-mpls@UU.NET Fri Feb 28 15:58:21 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13166 for ; Fri, 28 Feb 2003 15:58:21 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeat26978 for ; Fri, 28 Feb 2003 20:59:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeat23171; Fri, 28 Feb 2003 20:58:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeat19674 for mpls-outgoing; Fri, 28 Feb 2003 20:57:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoeat19628 for ; Fri, 28 Feb 2003 20:57:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeat28234 for ; Fri, 28 Feb 2003 20:56:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeat20336 for ; Fri, 28 Feb 2003 20:56:11 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQoeat20313 for ; Fri, 28 Feb 2003 20:56:10 GMT Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SKu9r08569 for ; Fri, 28 Feb 2003 15:56:09 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <1HW0DJN5>; Fri, 28 Feb 2003 15:56:08 -0500 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA8395@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'curtis@fictitious.org'" , "Varma, Eve L (Eve)" Cc: George Newsome , Stephen Trowbridge , Loa Andersson , mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 15:56:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, I concur the second issue is the key one. However, I don't view it as orthogonal as there are some interpretations (including yours ;-)) that liaison internet drafts from another SDO should also be handled as individual submissions. Eve -----Original Message----- From: Curtis Villamizar [mailto:curtis@fictitious.org] Sent: Friday, February 28, 2003 3:49 PM To: Varma, Eve L (Eve) Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa Andersson; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > Your comment re "legitimate requirements" has everything to do with > the relatio nship with other SDOs, which is currently implicitly > coupled into the liaison discussions. My concern , as is also > expressed in Steve Trowbridge's earlier comments, is related to the > Gatekeeper role that you are appearing to advocate. > > For individual contributor drafts coming in, it's quite appropriate to > evaluate requirements and determine if they are legitimate. It's a > different case when another SDO, responsible for a non-IP applications > domain, has established a set of requirements related to that domain. > > Eve If we remove all mention of liason, then the document applies to all individual submissions. You are not arguing that this is a bad thing for individual submissions. A second orthogonal issue which this draft does not address is whether liason internet-drafts would be given special consideration or would continue to be handled as individual submissions. If the mention of liasons is removed and there are no further issues, we can move forward with this draft. [Then discuss the liason issue later and preferably on some other list.] Curtis From owner-mpls@UU.NET Fri Feb 28 16:15:51 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13566 for ; Fri, 28 Feb 2003 16:15:50 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeav26995 for ; Fri, 28 Feb 2003 21:17:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeav26085; Fri, 28 Feb 2003 21:17:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeav16003 for mpls-outgoing; Fri, 28 Feb 2003 21:16:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoeav15984 for ; Fri, 28 Feb 2003 21:16:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeau10605 for ; Fri, 28 Feb 2003 21:14:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeau22846 for ; Fri, 28 Feb 2003 21:14:53 GMT Received: from lightwave.chromisys.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lightwave.chromisys.com [63.102.55.206]) id QQoeau22837 for ; Fri, 28 Feb 2003 21:14:53 GMT Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <4GJZG2M1>; Fri, 28 Feb 2003 13:14:32 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972283@nimbus> From: John Drake To: "'erosen@cisco.com'" , "Varma, Eve L (Eve)" Cc: "'curtis@fictitious.org'" , George Newsome , Stephen Trowbridge , Loa Andersson , mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 13:14:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I agree with Eric. As an example, we have call/connection separation, which has been kicking around since the early days of ISDN. In discussions as to why it is needed, the first reason is always "because". Once past that, I have consistently heard four or five examples cited. What is interesting is that all of them can be handled with the existing Make Before Break component of RSVP-TE. Thanks, John > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, February 28, 2003 12:54 PM > To: Varma, Eve L (Eve) > Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa > Andersson; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > Eve> For individual contributor drafts coming in, it's quite > appropriate to > Eve> evaluate requirements and determine if they are > legitimate. It's a > Eve> different case when another SDO, responsible for a > non-IP applications > Eve> domain, has established a set of requirements related to > that domain. > > I'd certainly disagree with that. Many of the > "requirements" I see from > other organizations are not requirements at all, but > just dogmatic > statements of connection-oriented religion. If the IETF > were to accept > requirements from other organizations, it would quickly be > inundated with > "requirements" to make IP behave exactly like ATM. In > fact, anyone who > works in the PWE3 group can testify that such "requirements" > come in all the > time. > > > From owner-mpls@UU.NET Fri Feb 28 16:58:11 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14580 for ; Fri, 28 Feb 2003 16:58:11 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeay19712 for ; Fri, 28 Feb 2003 22:00:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeax18294; Fri, 28 Feb 2003 21:59:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeax19156 for mpls-outgoing; Fri, 28 Feb 2003 21:59:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeax19149 for ; Fri, 28 Feb 2003 21:58:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeax22095 for ; Fri, 28 Feb 2003 21:57:32 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoeae23655 for ; Fri, 28 Feb 2003 17:06:05 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SH63JR021441 for ; Fri, 28 Feb 2003 12:06:03 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA16774 for ; Fri, 28 Feb 2003 12:06:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SH62601204 for mpls@uu.net; Fri, 28 Feb 2003 12:06:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeae27642 for ; Fri, 28 Feb 2003 17:03:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeae13008 for ; Fri, 28 Feb 2003 17:03:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeae18451 for ; Fri, 28 Feb 2003 17:03:24 GMT Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12]) id QQoeae18443 for ; Fri, 28 Feb 2003 17:03:23 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1SH33JR021277; Fri, 28 Feb 2003 12:03:03 -0500 (EST) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA16553; Fri, 28 Feb 2003 12:03:02 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA00661; Fri, 28 Feb 2003 12:03:02 -0500 (EST) Message-Id: <200302281703.MAA00661@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: curtis@fictitious.org cc: Loa Andersson , mpls@UU.NET, swallow@cisco.com Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Fri, 28 Feb 2003 11:50:10 EST." <200302281650.LAA43484@workhorse.fictitious.org> Date: Fri, 28 Feb 2003 12:03:02 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > In message <3E5F8A25.8030201@pi.se>, Loa Andersson writes: > > > > - I don't think it is agood idea to describe the two process in the same > > document. the chnage-process is for our internal use, the liasion process > > is for our commuinication with other SDOs > > If we can agree on this, then we can move forward with your document. I think they need to be separate because the liaison draft should apply across the board to IETF / ITU interactions and this document applies only to (G)MPLS. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Feb 28 16:58:32 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14596 for ; Fri, 28 Feb 2003 16:58:32 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeay14797 for ; Fri, 28 Feb 2003 22:00:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeay14113; Fri, 28 Feb 2003 22:00:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeax19171 for mpls-outgoing; Fri, 28 Feb 2003 21:59:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoeax19166 for ; Fri, 28 Feb 2003 21:59:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeax09961 for ; Fri, 28 Feb 2003 21:58:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeax12541 for ; Fri, 28 Feb 2003 21:58:57 GMT Received: from maila.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maila.telia.com [194.22.194.231]) id QQoeax12531 for ; Fri, 28 Feb 2003 21:58:56 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maila.telia.com (8.12.5/8.12.5) with ESMTP id h1SLwred000906; Fri, 28 Feb 2003 22:58:53 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1SLwr209296; Fri, 28 Feb 2003 22:58:53 +0100 (CET) Message-ID: <3E5FDA92.7060504@pi.se> Date: Fri, 28 Feb 2003 22:54:26 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <2FEC2C81634CDB4C9F191943ACCDC624079AA61B@OCCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Deborah, I'm trying to understand the statement on "as this is the only formal way for T1/ITU to communicate" if the key word is "formal" then it might be an obstacle, but at least in one case the "formal" part has not been imposible to overcome. Looking at the recent history e.g. the OAM label. This was brought in to IETF, as an liasion and as a ID by Hiroshi Ohta it was reviewed and discussed in the mpls group and progressed to an RFC, to cover the need of one of the ITU study groups. I'm not saying that it went smoth adn that everyone are happy with the decision, and possibly we weren't as attentative as we should have been, but given a bumpy road - it went through. Why can't this be the model for other similar "request for changes"? The change process are there for trying to take the worst bumps out of the road. /Loa Brungard, Deborah A, ALABS wrote: >Was the concern by saying "external standards bodies", it was interpreted as liaisons (as this is the only formal way for T1/ITU to communicate), which implies submission of an "individual draft", review, etc.? So as not to confuse "standards bodies" with liaison communication, how about in the draft changing this to "participants of external standards bodies"? Or perhaps best is to just remove. And let the liaison process address, with links to this document. > >Deborah > > > From owner-mpls@UU.NET Fri Feb 28 17:20:35 2003 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15191 for ; Fri, 28 Feb 2003 17:20:35 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaz20338 for ; Fri, 28 Feb 2003 22:22:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeaz19513; Fri, 28 Feb 2003 22:22:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeaz09694 for mpls-outgoing; Fri, 28 Feb 2003 22:21:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeaz09684 for ; Fri, 28 Feb 2003 22:21:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoeaz07728 for ; Fri, 28 Feb 2003 22:20:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeaz24410 for ; Fri, 28 Feb 2003 22:20:55 GMT Received: from mailg.telia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailg.telia.com [194.22.194.26]) id QQoeaz24395 for ; Fri, 28 Feb 2003 22:20:54 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by mailg.telia.com (8.12.5/8.12.5) with ESMTP id h1SMKoPw000867; Fri, 28 Feb 2003 23:20:50 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1SMKo216638; Fri, 28 Feb 2003 23:20:50 +0100 (CET) Message-ID: <3E5FDFB7.2070305@pi.se> Date: Fri, 28 Feb 2003 23:16:23 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Trowbridge CC: mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <200302281650.LAA43484@workhorse.fictitious.org> <3E5F993C.27CFAB0D@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Steve, Bala said it was a joke! And it wasn't hard to parse with a bit of humor. Actuall quite funny :). I guess I could make a very similar flow chart, in trying to discuss with some people around mpls. But seriously claiming (you are not joking, are you?) that Balas flow chart demonstrates that we intend to give work "externally generated" a fast track to the trash I find below the level of this discussion. The intention of the change process is to create a way for the (g)mpls technology area to recieve and handle new requirements and new ideas, the exact opposite of you are claiming. In fact every time I send a new ID (draft-andersson-xxxx-foo-00.txt) seen from the IETF and the working groups it is in some sense "external". What is that makes something that originates from "the other SDOs" so special from a technical point of view. The change process are focused on guaranteeing that new (g)mpls technology ideas are evaluated based on their technical merits. /Loa Stephen Trowbridge wrote: >Curtis, >I have no problem to seperate the liaison process from the internal process. >In fact, a good liaison process is needed that would have much broader >applicability than (G)MPLS protocols. > >However, I do disagree that we can go forward on one with out the other. >As Bala's flowchart shows, the effect of applying this draft to internally >and externally initated work alike is to give the externally initiated >work a fast track to the trash. Without the liaison process, this draft >seems to make what is already a bad problem with how we deal with input >from other SDOs even worse. >Regards, >Steve > >Curtis Villamizar wrote: > > >>In message <3E5F8A25.8030201@pi.se>, Loa Andersson writes: >> >> >>>- I don't think it is agood idea to describe the two process in the same >>> document. the chnage-process is for our internal use, the liasion process >>> is for our commuinication with other SDOs >>> >>> >>If we can agree on this, then we can move forward with your document. >> >>Curtis >> >> > > > > From owner-mpls@UU.NET Fri Feb 28 17:32:19 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15397 for ; Fri, 28 Feb 2003 17:32:19 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeba05755 for ; Fri, 28 Feb 2003 22:34:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeba04378; Fri, 28 Feb 2003 22:33:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeba10621 for mpls-outgoing; Fri, 28 Feb 2003 22:33:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoeba10613 for ; Fri, 28 Feb 2003 22:32:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeba25719 for ; Fri, 28 Feb 2003 22:32:46 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeba19882 for ; Fri, 28 Feb 2003 22:32:46 GMT Received: from maila.telia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maila.telia.com [194.22.194.231]) id QQoeba19868 for ; Fri, 28 Feb 2003 22:32:45 GMT Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241]) by maila.telia.com (8.12.5/8.12.5) with ESMTP id h1SMWEed007957; Fri, 28 Feb 2003 23:32:14 +0100 (CET) X-Original-Recipient: mpls@UU.NET Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45]) by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h1SMWE220150; Fri, 28 Feb 2003 23:32:14 +0100 (CET) Message-ID: <3E5FE263.9050809@pi.se> Date: Fri, 28 Feb 2003 23:27:47 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@fictitious.org CC: "Varma, Eve L (Eve)" , George Newsome , Stephen Trowbridge , mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt References: <200302282107.QAA46282@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Cutis and Eve, I think we have come a full circle, now Curtis is suggesting that I remove something that is not in the draft ;). I don't discus liasions, simply because it was and is my opinion that they are not in the picture then it comes to handling changes to the (g)mpls protocols. Even though they are good for other things ;) /Loa Curtis Villamizar wrote: >In message <61B49BC6DA0DDE40957FB499E1835E3705FA8395@nj7460exch010u.ho.lucent.c >om>, "Varma, Eve L (Eve)" writes: > > >>Hi Curtis, >> >>I concur the second issue is the key one. However, I don't view it as orthog >>onal >>as there are some interpretations (including yours ;-)) that liaison internet >> drafts >>from another SDO should also be handled as individual submissions. >> >>Eve >> >> > > >Eve, > >Correction. There are not "some interpretations". Liaison internet >drafts from another SDO may be either submitted as informational or >they are treated as individual submissions. > >That issue is not relevant to the draft under discussion if Loa >removes any mention of liasons. > >Curtis > > > > >>-----Original Message----- >>From: Curtis Villamizar [mailto:curtis@fictitious.org] >>Sent: Friday, February 28, 2003 3:49 PM >>To: Varma, Eve L (Eve) >>Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa >>Andersson; mpls@UU.NET >>Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt >> >> >> >> >> >>>Your comment re "legitimate requirements" has everything to do with >>>the relatio nship with other SDOs, which is currently implicitly >>>coupled into the liaison discussions. My concern , as is also >>>expressed in Steve Trowbridge's earlier comments, is related to the >>>Gatekeeper role that you are appearing to advocate. >>> >>>For individual contributor drafts coming in, it's quite appropriate to >>>evaluate requirements and determine if they are legitimate. It's a >>>different case when another SDO, responsible for a non-IP applications >>>domain, has established a set of requirements related to that domain. >>> >>>Eve >>> >>> >>If we remove all mention of liason, then the document applies to all >>individual submissions. You are not arguing that this is a bad thing >>for individual submissions. >> >>A second orthogonal issue which this draft does not address is whether >>liason internet-drafts would be given special consideration or would >>continue to be handled as individual submissions. >> >>If the mention of liasons is removed and there are no further issues, >>we can move forward with this draft. [Then discuss the liason issue >>later and preferably on some other list.] >> >>Curtis >> >> >> > > > > From owner-mpls@UU.NET Fri Feb 28 17:49:01 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15702 for ; Fri, 28 Feb 2003 17:49:01 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeat29296; Fri, 28 Feb 2003 20:58:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeat19796 for mpls-outgoing; Fri, 28 Feb 2003 20:57:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeat19683 for ; Fri, 28 Feb 2003 20:57:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeat07325 for ; Fri, 28 Feb 2003 20:57:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeat27315 for ; Fri, 28 Feb 2003 20:57:06 GMT Received: from newdev.harvard.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQoeat27307 for ; Fri, 28 Feb 2003 20:57:06 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.12.6/8.12.2) id h1SKuxaf029460; Fri, 28 Feb 2003 15:56:59 -0500 (EST) Date: Fri, 28 Feb 2003 15:56:59 -0500 (EST) From: Scott Bradner Message-Id: <200302282056.h1SKuxaf029460@newdev.harvard.edu> To: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Sender: owner-mpls@UU.NET Precedence: bulk yipe - go off-line for a long plane flight and kablooe the world explodes You may rest assured that the intention of the ID (and the one that came out today about change control for RSVP) is positive. The basic concept is the same as RFC 3427 does for SIP - be sure that the IETF is "in the loop" on extensions to IETF protocols. Note that these two IDs are 1st drafts and are meant to be discussed (that part seems to have worked :-) ) We have had recent experience with the OIF UNI and ITU ASON documents that it is easy to get into sort of a mess (and we are not accusing anyone specific here). There were many reasons. Including neglected liaison statements from ITU and documents from ITU folk. Clearly the IETF needs to figure out a better way to deal with such messages (This was a topic at the ITU-T TSAG (their sort of IESG) meeting this past week in geneva.) So in order to try to regularize the change process with RSVP and (G)MPLS the SUB-IP ADs with a few WG chairs prepared this document. The idea is that we define the process so that it is clear how and when various steps need to be taken and by whom. The doc is far from complete we suspect and so comments (certainly ones with recommended wording) will be very welcome. As noted above, these are first drafts and we expect that there will be quite a few changes before these get adopted. We also need to evaluate the issues w.r.t. to liaison statements. We think we have seen quite a set of opinions on the usefulness and function of liaison statements. These opinions need to be evaluated and revised text needs to be put in these documents to deal with them, but maybe this should be done as a comprehensive IETF review of how we deal with liaison statements. It would be good to tone down the "discussion" a bit. We do not think that making accusations etc helps the discussion. The idea was to try and prevent that from happening in the future. So now that you all have been able to blow of some steam, can you please start to post constructive text proposals as how to do things in these documents and relative to how the IETF deals with working with other SDOs that want to use and extend IETF protocols. (BTW - it is not a bad thing that multiple SDOs want to make use of the same protocols, it seems that it should be considered a good thing and we should work out ways that using existing protocols or working together on ways to extend current protocols is encouraged rather than making it more likely that competing protocols doing the same function get developed.) Thanks, Bert and Scott From owner-mpls@UU.NET Fri Feb 28 18:06:47 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16329 for ; Fri, 28 Feb 2003 18:06:47 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeat15897; Fri, 28 Feb 2003 20:56:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeat18739 for mpls-outgoing; Fri, 28 Feb 2003 20:55:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoeat18564 for ; Fri, 28 Feb 2003 20:55:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeat06407 for ; Fri, 28 Feb 2003 20:54:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeat18361 for ; Fri, 28 Feb 2003 20:54:29 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQoeat18353 for ; Fri, 28 Feb 2003 20:54:28 GMT Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1SKsD56012929; Fri, 28 Feb 2003 12:54:14 -0800 (PST) Message-Id: <200302282054.h1SKsD56012929@sj-msg-core-1.cisco.com> To: "Varma, Eve L (Eve)" cc: "'curtis@fictitious.org'" , George Newsome , Stephen Trowbridge , Loa Andersson , mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of Fri, 28 Feb 2003 15:15:18 -0500. <61B49BC6DA0DDE40957FB499E1835E3705FA8390@nj7460exch010u.ho.lucent.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 28 Feb 2003 15:54:13 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Eve> For individual contributor drafts coming in, it's quite appropriate to Eve> evaluate requirements and determine if they are legitimate. It's a Eve> different case when another SDO, responsible for a non-IP applications Eve> domain, has established a set of requirements related to that domain. I'd certainly disagree with that. Many of the "requirements" I see from other organizations are not requirements at all, but just dogmatic statements of connection-oriented religion. If the IETF were to accept requirements from other organizations, it would quickly be inundated with "requirements" to make IP behave exactly like ATM. In fact, anyone who works in the PWE3 group can testify that such "requirements" come in all the time. From owner-mpls@UU.NET Fri Feb 28 18:50:47 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17437 for ; Fri, 28 Feb 2003 18:50:47 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoeau08037; Fri, 28 Feb 2003 21:11:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQoeau13763 for mpls-outgoing; Fri, 28 Feb 2003 21:11:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQoeau13629 for ; Fri, 28 Feb 2003 21:11:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoeau02727 for ; Fri, 28 Feb 2003 21:10:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeau14160 for ; Fri, 28 Feb 2003 21:10:09 GMT Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13]) id QQoeau14150 for ; Fri, 28 Feb 2003 21:10:09 GMT Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SLA3Nh025054 for ; Fri, 28 Feb 2003 16:10:07 -0500 (EST) Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA07841 for ; Fri, 28 Feb 2003 16:10:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h1SLA2W28067 for mpls@uu.net; Fri, 28 Feb 2003 16:10:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoeau12477 for ; Fri, 28 Feb 2003 21:09:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQoeau14817 for ; Fri, 28 Feb 2003 21:08:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoeau16094 for ; Fri, 28 Feb 2003 21:08:47 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQoeau16083 for ; Fri, 28 Feb 2003 21:08:46 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA46282; Fri, 28 Feb 2003 16:07:28 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200302282107.QAA46282@workhorse.fictitious.org> To: "Varma, Eve L (Eve)" cc: "'curtis@fictitious.org'" , George Newsome , Stephen Trowbridge , Loa Andersson , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt In-reply-to: Your message of "Fri, 28 Feb 2003 15:56:08 EST." <61B49BC6DA0DDE40957FB499E1835E3705FA8395@nj7460exch010u.ho.lucent.com> Date: Fri, 28 Feb 2003 16:07:28 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <61B49BC6DA0DDE40957FB499E1835E3705FA8395@nj7460exch010u.ho.lucent.c om>, "Varma, Eve L (Eve)" writes: > Hi Curtis, > > I concur the second issue is the key one. However, I don't view it as orthog > onal > as there are some interpretations (including yours ;-)) that liaison internet > drafts > from another SDO should also be handled as individual submissions. > > Eve Eve, Correction. There are not "some interpretations". Liaison internet drafts from another SDO may be either submitted as informational or they are treated as individual submissions. That issue is not relevant to the draft under discussion if Loa removes any mention of liasons. Curtis > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Friday, February 28, 2003 3:49 PM > To: Varma, Eve L (Eve) > Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa > Andersson; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > Your comment re "legitimate requirements" has everything to do with > > the relatio nship with other SDOs, which is currently implicitly > > coupled into the liaison discussions. My concern , as is also > > expressed in Steve Trowbridge's earlier comments, is related to the > > Gatekeeper role that you are appearing to advocate. > > > > For individual contributor drafts coming in, it's quite appropriate to > > evaluate requirements and determine if they are legitimate. It's a > > different case when another SDO, responsible for a non-IP applications > > domain, has established a set of requirements related to that domain. > > > > Eve > > > If we remove all mention of liason, then the document applies to all > individual submissions. You are not arguing that this is a bad thing > for individual submissions. > > A second orthogonal issue which this draft does not address is whether > liason internet-drafts would be given special consideration or would > continue to be handled as individual submissions. > > If the mention of liasons is removed and there are no further issues, > we can move forward with this draft. [Then discuss the liason issue > later and preferably on some other list.] > > Curtis > From owner-mpls@UU.NET Fri Feb 28 19:09:03 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17721 for ; Fri, 28 Feb 2003 19:09:03 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoebg20254 for ; Sat, 1 Mar 2003 00:11:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoebg19809; Sat, 1 Mar 2003 00:10:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQoebg24500 for mpls-outgoing; Sat, 1 Mar 2003 00:10:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQoebg24479 for ; Sat, 1 Mar 2003 00:10:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoebg09502 for ; Sat, 1 Mar 2003 00:10:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoebg19210 for ; Sat, 1 Mar 2003 00:10:11 GMT Received: from w2ksjexg01.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [12.7.169.25]) id QQoebg19199 for ; Sat, 1 Mar 2003 00:10:10 GMT Received: from wntcsdexg01.csd.ciena.com ([10.34.31.31]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FN36508V; Fri, 28 Feb 2003 16:09:52 -0800 Received: by webdev-llnt.oni.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 16:10:08 -0800 Message-ID: <2135200C183FD5119588009027DE572302836D71@webdev-owa.oni.com> From: "Ong, Lyndon" To: "'curtis@fictitious.org'" , George Newsome Cc: Stephen Trowbridge , Loa Andersson , mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 16:10:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Folks, I support the request to stick to constructive comments. Of course that means avoiding statements like "The ITU has stepped out of bounds (again). They deserve to be ignored." (Last I heard, SDH/OTN networks were within bounds of ITU ;o) Or "dogmatic statements of connection-oriented religion" (these are, for gmpls, connection-oriented networks we're talking about ;0) Seriously, though, I do have some comments on the draft: -- the figure shows the only path outside of the IETF process to be a dustbin. Hopefully that's not intentional, although a lot of folks on the list probably believe this ;o) -- there's some text mixed up in 2.2.1 regarding which mailing list should be used. -- we should incorporate Deborah's suggestion for 2.2.2 about having the decision posted to the mailing list within a specified period (the posting of a decision could apply to liaisons, and might have helped avoid the confusion with the ITU liaison) -- in 2.2.4, the paragraph after item (2) seems a little premature - the recommendation by the rewg presumably must be approved by IESG/IAB before a decision is made. -- there is a bit of a loophole in that the problem could be accepted and farmed off to a WG but there's no check to see if anything is ever done, and items could easily fall through a crack given the large numbers of work items usually in CCAMP and MPLS. There could be a procedure to revisit the decision in case no progress is being made within some specified timeframe. -- in general, I hope people keep in mind that the scope of interest and the resources available in IETF are limited, and should not become a bottleneck - if work can be or is already being done in other bodies and there is a process for IETF to review this work and identify potential problems or simpler/more general ways to do the desired function, this should be viewed as a generally positive thing. Cheers, Lyndon From owner-mpls@UU.NET Fri Feb 28 19:26:40 2003 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18109 for ; Fri, 28 Feb 2003 19:26:40 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoear01121; Fri, 28 Feb 2003 20:20:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQoear04355 for mpls-outgoing; Fri, 28 Feb 2003 20:20:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQoear04281 for ; Fri, 28 Feb 2003 20:20:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQoear01982 for ; Fri, 28 Feb 2003 20:19:38 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoear28086 for ; Fri, 28 Feb 2003 20:19:32 GMT Received: from relay2.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQoear28060 for ; Fri, 28 Feb 2003 20:19:31 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h1SKJTv20945; Fri, 28 Feb 2003 21:19:29 +0100 (MET) Received: from alcatel.be ([138.203.64.155]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003022821192683:4130 ; Fri, 28 Feb 2003 21:19:26 +0100 Message-ID: <3E5FC411.FAF850FF@alcatel.be> Date: Fri, 28 Feb 2003 21:18:25 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: velev@panasonic.de Cc: Heiles Juergen , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: draft-kawakami-mpls-lsp-vlan-00.txt References: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/28/2003 21:19:26, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/28/2003 21:19:28 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA18109 hi, per gmpls, Layer-2 Switch Capable (L2SC) interfaces are defined: Interfaces that recognize frame/cell boundaries and can forward data based on the content of the frame/cell header. Examples include interfaces on Ethernet bridges that forward data based on the content of the MAC header and interfaces on ATM-LSRs that forward data based on the ATM VPI/VCI. i agree with juergen, this i-d should be discussed at the ccamp working group thanks, - dimitri. Genadi Velev wrote: > > Hi Juergen, > > thanks for the feedback! This was (and seems to be still) a hot topic. The > decision where to present the draft has been already a subject of > discussions with the chairmen of MPLS, PWE3 and PPVPN WGs. The reason to let > this draft for submission in the MPLS WG was that the basic intention is to > propose a new LDP extension ("VLAN label TLV") and MPLS WG is in charge of > the LDP protocol. > > It's true that the transport plane in our proposal is based on VLAN-aware > Ethernet switches. Compared to the GMPLS classification of interfaces > (RFC3471), VLAN tag switching belongs (I'd say so) to the Packet-Switch > Capable (PSC) interfaces, and thus, extensions regarding these interfaces > should be a subject of the MPLS WG. > > This is my personal opinion. However, since I'm not a long-experienced > person in the IETF's MPLS related work, I'd like to hear also another > opinions on this issue. > > regards, > Genadi > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Heiles > > Juergen > > Sent: Friday, February 28, 2003 12:17 PM > > To: 'velev@panasonic.de'; mpls@UU.NET; ccamp@ops.ietf.org > > Cc: vlan-mpls@panasonic.de > > Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > Genadi, > > > > the draft proposes to use the MPLS control plane protocols for a > > different transport plane (Ethernet VLAN). > > This is excatly what GMPLS is about. So I think it would be > > better to have the ID and dicussion in ccamp under the GMPLS work. > > > > Regards > > > > Juergen > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Genadi Velev [mailto:velev@panasonic.de] > > > Gesendet: Donnerstag, 27. Februar 2003 17:53 > > > An: mpls@UU.NET > > > Cc: vlan-mpls@panasonic.de > > > Betreff: draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > > > > Hi all, > > > > > > A new draft was published today (please see below). > > > > > > Any feedback and comments are welcome, especially from those > > > of you who are > > > dealing with packet transport over wide area Ethernet networks. > > > > > > thanks, > > > Genadi > > > > > > > -----Original Message----- > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > > > Internet-Drafts@ietf.org > > > > Sent: Thursday, February 27, 2003 1:44 PM > > > > To: IETF-Announce: > > > > Cc: mpls@UU.NET > > > > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts directories. > > > > > > > > > > > > Title : Method to Setup LSP using VLAN Tag Switching > > > > Author(s) : T. Kawakami et al. > > > > Filename : draft-kawakami-mpls-lsp-vlan-00.txt > > > > Pages : 15 > > > > Date : 2003-2-26 > > > > > > > > This document describes a method to setup a Layer 2 tunnel over > > > > networks based on Ethernet technology. For this purpose, > > > the ports of > > > > an Ethernet switch are configured to forward VLAN > > > tag-labeled packets > > > > incoming from a certain port to another unambiguous port by using > > > > VLAN tag information. The Ethernet switches themselves are a part of > > > > the Label Switching Routers (LSRs), which distribute the VLAN tags > > > > using Label Distribution Protocol (LDP). To enable LDP to > > > fulfil this > > > > function, an LDP extension is proposed. The introduced method > > > > simplifies the transport of Ethernet frames over wide area Ethernet > > > > networks. > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a message to > > > ietf-announce-request with the word unsubscribe in the body of > > > the message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with > > > the username > > > "anonymous" and a password of your e-mail address. After logging in, > > > type "cd internet-drafts" and then > > > "get draft-kawakami-mpls-lsp-vlan-00.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From owner-mpls@UU.NET Fri Feb 28 23:07:48 2003 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21773 for ; Fri, 28 Feb 2003 23:07:48 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoebw20019 for ; Sat, 1 Mar 2003 04:09:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQoebw19531; Sat, 1 Mar 2003 04:09:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQoebw25843 for mpls-outgoing; Sat, 1 Mar 2003 04:09:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQoebw25833 for ; Sat, 1 Mar 2003 04:09:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQoebw17193 for ; Sat, 1 Mar 2003 04:08:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQoebw17110 for ; Sat, 1 Mar 2003 04:08:05 GMT Received: from web21206.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21206.mail.yahoo.com [216.136.175.8]) id QQoebw17080 for ; Sat, 1 Mar 2003 04:08:03 GMT Message-ID: <20030301040803.89152.qmail@web21206.mail.yahoo.com> Received: from [138.25.8.1] by web21206.mail.yahoo.com via HTTP; Sat, 01 Mar 2003 15:08:03 EST Date: Sat, 1 Mar 2003 15:08:03 +1100 (EST) From: =?iso-8859-1?q?Tep=20riu?= Subject: Quesions of CR-LDP To: mpls@UU.NET MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1030961798-1046491683=:88543" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk --0-1030961798-1046491683=:88543 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I am a student who has just started to learn about CR-LDP. I have a basic questions as following: CR-LDP implicitly refers to Edge rules and admission controls at nodes, where can I find more information about this? Is this somewhere in DiffServ rfc(s)? Thanks --------------------------------- Yahoo! Mobile - Exchange IMs with Messenger friends on your Telstra or Vodafone mobile phone. --0-1030961798-1046491683=:88543 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi, I am a student who has just started to learn about CR-LDP. I
have a basic questions as following:  CR-LDP implicitly refers to Edge
rules and admission controls at nodes, where can I find more information
about this? Is this somewhere in DiffServ rfc(s)?

Thanks


Yahoo! Mobile
- Exchange IMs with Messenger friends on your Telstra or Vodafone mobile phone. --0-1030961798-1046491683=:88543--