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>om>; <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
>