Re: [Isis-wg] draft-previdi-filsfils-isis-segment-routing

Robert Raszuk <robert@raszuk.net> Tue, 02 April 2013 17:09 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16CA21F89FB for <isis-wg@ietfa.amsl.com>; Tue, 2 Apr 2013 10:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.527
X-Spam-Level:
X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oybAYFqjTlr1 for <isis-wg@ietfa.amsl.com>; Tue, 2 Apr 2013 10:09:11 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 363DF21F89D3 for <isis-wg@ietf.org>; Tue, 2 Apr 2013 10:09:11 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id qd14so691381ieb.28 for <isis-wg@ietf.org>; Tue, 02 Apr 2013 10:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UllVx+m605CE+QpEa7cNmoDqHNCRTG1B0c/1zjcil5o=; b=JTj3cgiFW3y7iS4z/L7KBdqOUtbxb+zJFGtTAj9M/8ZEUh9phZ6MrQ3qgtGiShDAzm 6DIQiHT9AWBG3BwuVHk0ETVB9SEmKWz+IkAKXgh1q9CidcaFJJWV35N5ML6vV3ahQS/V +A0ABOCMqnYSuIj2z+oWTbFYSp1tQxVXNMMi59eVo1PXO7IKlEC8Btq96wYwO9sjncJK gtee/QyX5M6xgvQWQCoWcF23NUsjlbZX0Jc1veUdKazmsPCCQqcShdVXXxwE/icmDg3H 4Ai3C8ALW0SrTwmtYfemIdgVmdiPqPGvuaMrm/w6eBGpYR7mVINz8fwvo0XDDw9KGHTt ZajQ==
MIME-Version: 1.0
X-Received: by 10.50.47.200 with SMTP id f8mr5391511ign.98.1364922550774; Tue, 02 Apr 2013 10:09:10 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.100.207 with HTTP; Tue, 2 Apr 2013 10:09:10 -0700 (PDT)
In-Reply-To: <CA+b+ERmVPFdeCg7c8dLyJ+qtoWggZv4jT9gNtHdmKxtDetDKKg@mail.gmail.com>
References: <D7D7AB44C06A2440B716F1F1F5E70AE53F9FE2A3@SV-EXDB-PROD1.infinera.com> <8301C743-21EB-4497-9759-41CCAE0097C3@cisco.com> <D7D7AB44C06A2440B716F1F1F5E70AE53F9FE405@SV-EXDB-PROD1.infinera.com> <AE254066-0500-4B5C-A233-AFC29F73EB68@cisco.com> <CA+b+ERmVPFdeCg7c8dLyJ+qtoWggZv4jT9gNtHdmKxtDetDKKg@mail.gmail.com>
Date: Tue, 02 Apr 2013 19:09:10 +0200
X-Google-Sender-Auth: 8znq2uyQoqkA0xgN43YZ29vmtxg
Message-ID: <CA+b+ERkGYP0uxA6CXY695Ftnm+RRzCVX8cyFnguTResh6CWHJg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: stefano previdi <sprevidi@cisco.com>
Content-Type: multipart/alternative; boundary="14dae9340cc3c8f4b504d963cb54"
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] draft-previdi-filsfils-isis-segment-routing
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 17:09:11 -0000

One additional point .. As just hinted offline by Sam when I said MTU I
assumed it is equal to MRU. If not we should discuss both values and it's
consequences on the packet size in this sort of source based segment chain
selection.

Cheers,
R.


On Tue, Apr 2, 2013 at 6:35 PM, Robert Raszuk <robert@raszuk.net> wrote:

> Hi Stefano,
>
> As we have discussed in the past I like the proposal a lot. Control plane
> encoding seems fine as well.
>
> My slight concern is however related to data plane. As you recall even
> with label stack of 2 we have had number of issues when deploying L3VPNs
> with MTU. The draft is very silent on the issue of potential MTU problems -
> I would suggest new section to at least recommend some MTU handling (pMTU
> for example) before applying this technique.
>
> Likewise one could easily extend your signalling to add MTU on the links
> to make sure that while going via all segments data plane packets will
> "fit". Such extensions would in fact have more use cases, but I will let
> you discover them :)
>
> Also the empty section of IPv6 header encoding is a bit surprising yet
> quite an interesting in the light of potential multiple v6 headers and MTU
> issues.
>
> Cheers,
> R.
>
>
>