Re: [mpls] draft-ietf-mpls-forwarding
t.petch <ietfc@btconnect.com> Fri, 21 February 2014 15:17 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37771A0282 for <mpls@ietfa.amsl.com>; Fri, 21 Feb 2014 07:17:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vf7YMeTH2GJ for <mpls@ietfa.amsl.com>; Fri, 21 Feb 2014 07:17:19 -0800 (PST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id CD1021A01AB for <mpls@ietf.org>; Fri, 21 Feb 2014 07:17:18 -0800 (PST)
Received: from DB3PRD0411HT004.eurprd04.prod.outlook.com (157.56.253.53) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.0.883.10; Fri, 21 Feb 2014 15:17:13 +0000
Message-ID: <003a01cf2f17$4eede300$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: curtis@ipv6.occnc.com
References: <201401302106.s0UL6tln065171@maildrop2.v6ds.occnc.com>
Date: Fri, 21 Feb 2014 15:05:59 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.253.53]
X-ClientProxiedBy: AM3PR07CA009.eurprd07.prod.outlook.com (10.242.16.49) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20)
X-Forefront-PRVS: 01294F875B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(52604005)(377454003)(199002)(189002)(13464003)(85306002)(81542001)(61296002)(14496001)(84392001)(50466002)(94946001)(88136002)(93136001)(46102001)(49866001)(47736001)(19580405001)(83322001)(59766001)(87266001)(87976001)(90146001)(80976001)(83072002)(56816005)(44736004)(92566001)(74876001)(4396001)(50226001)(87286001)(74706001)(47976001)(31966008)(51856001)(89996001)(47446002)(74502001)(77982001)(85852003)(19580395003)(33646001)(50986001)(74662001)(23756003)(81342001)(44716002)(76796001)(76482001)(47776003)(76786001)(42186004)(53806001)(62236002)(93516002)(54316002)(92726001)(63696002)(66066001)(80022001)(69226001)(65816001)(95666003)(62966002)(95416001)(77156001)(93916002)(94316002)(77096001)(86362001)(74366001)(56776001)(79102001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB062; H:DB3PRD0411HT004.eurprd04.prod.outlook.com; CLIP:157.56.253.53; FPR:FC5BC215.ACC687FD.7BD91D77.88E7F56D.2043D; PTR:InfoNoRecords; A:0; MX:1; LANG:en;
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/krtogejkCh0MOaTZ0UiR8ePwKFo
Cc: mpls@ietf.org
Subject: Re: [mpls] draft-ietf-mpls-forwarding
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 15:17:22 -0000
Curtis I just finished reading this - and see that the IESG have approved it. Ah well, perhaps the RFC Editor will be interested. s.1 /advise/advice/ CC-CV Connectivity Check and Connectivity Verification we have used Continuity Check elsewhere (e.g. mpls-tp-oam-framework) s2.3 "For example, an on-chip buffer capable of handling 4K packets of 64 bytes in length, or 256KB, corresponds to 2 msec on a 10 Mb/s" My maths is hopeless. 4K packets of 64byte is 256Kbyte which is 2048Kbit on a 10Mbit/s link is 2048K divided by 10M/s which is '2mS' - why do I keep getting 200mS or 2dS? s2.4.5.1 5) /closest to the bottom of stack/closer to the bottom of stack/ s2.6.4 we have used Continuity Check elsewhere (e.g. mpls-tp-oam-framework) s3 This is quite cryptic where no references are given, e.g. Q40 for Pseudowire OAM, MPLS-TP OAM, Layer-2 OAM Interworking Tom Petch ----- Original Message ----- From: "Curtis Villamizar" <curtis@ipv6.occnc.com> To: "t.petch" <ietfc@btconnect.com> Cc: <curtis@ipv6.occnc.com>; <mpls@ietf.org> Sent: Thursday, January 30, 2014 9:06 PM > > In message <00ce01cf1de4$45fb9ba0$4001a8c0@gateway.2wire.net> > "t.petch" writes: > > > Curtis > > > > MP2MP Multipoint to Point ? > > Multipoint to multipoint. Ie: capable of supporting <*,G> though > possibly for a policy constrained value of "*". Some chips can do it > but I'm not sure what routers can do (whether software supports it) > and if so if anyone deploys MP2MP. At least some P2MP for > distribution of stuff like video, maybe a lot but I don't know. > Plenty of MP2P since LDP is inherently MP2P. > > > I would like the first sentence of the Abstract to start the > > Introduction - otherwise there is no intended audience (and I tend to > > skip Abstracts when I know I am going to be interested in a document). > > The intended audience is in the intro later on in Section 1.4 ("Target > Audience"). > > > And is that second clause for Operators eg > > a basis for operators to evaluate forwarding implementations. > > It is meant for both operators and system designers. System designers > (ie: people working for router vendors that buy off the shelf silicon) > need to pick a forwarding chip long before operators are evaluating. > See Section 1.4. > > In the case of forwarding the "implementor" is designing a chip. The > "system designer" is using it in a product. The operator is (we hope) > trying to find out what if any bad decisions were made in an > evaluation to determine what effect any shortcomings would have before > deploying and finding out the hard way. > > > (more to follow - the I-D is big and my reading is slow:-( > > No problem. Thanks for taking a look. > > > Tom Petch > > Curtis >
- Re: [mpls] draft-ietf-mpls-forwarding t.petch
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Curtis Villamizar
- [mpls] AD review of draft-ietf-mpls-forwarding Adrian Farrel
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Curtis Villamizar
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Carlos Pignataro (cpignata)
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Curtis Villamizar
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Carlos Pignataro (cpignata)
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Adrian Farrel
- Re: [mpls] AD review of draft-ietf-mpls-forwarding l.wood
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Curtis Villamizar
- Re: [mpls] AD review of draft-ietf-mpls-forwarding l.wood
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Curtis Villamizar
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Curtis Villamizar
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Curtis Villamizar
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Adrian Farrel
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Adrian Farrel
- Re: [mpls] AD review of draft-ietf-mpls-forwarding Curtis Villamizar
- Re: [mpls] draft-ietf-mpls-forwarding t.petch
- Re: [mpls] draft-ietf-mpls-forwarding Curtis Villamizar
- Re: [mpls] draft-ietf-mpls-forwarding Curtis Villamizar