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

stefano previdi <sprevidi@cisco.com> Mon, 29 April 2013 14:00 UTC

Return-Path: <sprevidi@cisco.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 F1BB821F9DD0 for <isis-wg@ietfa.amsl.com>; Mon, 29 Apr 2013 07:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 L666yBAc-xcp for <isis-wg@ietfa.amsl.com>; Mon, 29 Apr 2013 07:00:45 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2524C21F9A01 for <isis-wg@ietf.org>; Mon, 29 Apr 2013 07:00:44 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3TE0cgw002523; Mon, 29 Apr 2013 16:00:38 +0200 (CEST)
Received: from [10.61.213.33] ([10.61.213.33]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3TE0GOs011960; Mon, 29 Apr 2013 16:00:27 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: stefano previdi <sprevidi@cisco.com>
In-Reply-To: <CAP1rCZOnCFx0wSuSohFnyj6xSfW9aTTGMg-bt9FfgrmL8XZs4g@mail.gmail.com>
Date: Mon, 29 Apr 2013 16:00:16 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <4AB5A31E-CCC0-4DD1-B30E-EF80414B9258@cisco.com>
References: <CAP1rCZOnCFx0wSuSohFnyj6xSfW9aTTGMg-bt9FfgrmL8XZs4g@mail.gmail.com>
To: Patryk Konczyk <pkonczyk@gmail.com>
X-Mailer: Apple Mail (2.1283)
Cc: 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: Mon, 29 Apr 2013 14:00:46 -0000

Hi Patryk,

On Apr 25, 2013, at 5:31 PM, Patryk Konczyk wrote:
> Hello Stefano I've seen Clarence presentation about Segment Routing
> at MWC in Paris. I like the concept of using IGP for signalling and to
> simply use existing tools like remote LFA for traffic protection.
> Traffic Engineering looks simple as well. My initial concern was
> around large label stack  especially in cases where there is
> significant amount of Traffic Engineering going on. Clarence pointed
> out that this can be resolved with loose hops using just two labels in
> majority of the cases.


indeed. In current SP topologies, and with current HW capabilities, 
the label stack size is a non issue. Having said that, we shouldn't 
neglect mechanisms for stack compression anyway.


> I was also chatting to Stewart Bryant and he suggested compressing
> the label stack I belive you touched on that on page 6 in the ECMP
> context. I was wondering if this could be extended for strict and
> loose path signalled with single label only, so that we have the same
> label stack as in LDP/RSVP based solution. This probably would require
> additional signalling.


the question is whether (and how much more) do you need to compress 
the stack and what benefits it brings you (assuming my statement 
above).


> IPv6 variant is looking interesting as well. I'm hoping that more
> details will appear in the draft shortly and we will have more
> discussion on the mailing list.


yes, we're in the process of updating the draft and more details 
are to come soon.


> In Section 2.2 comparative study has been mentioned could your share
> more details ?
> 
> Also are there any plans to discuss segment routing in Berlin ?


Hopefully yes!

Thanks.
s.


> 
> Thanks Patryk Konczyk
>