Re: [mpls] [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

Stewart Bryant <stewart.bryant@gmail.com> Mon, 30 January 2017 11:51 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AD4129458; Mon, 30 Jan 2017 03:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RX6dEMYaOMp3; Mon, 30 Jan 2017 03:51:07 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC3F129456; Mon, 30 Jan 2017 03:51:06 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id v77so43941159wmv.0; Mon, 30 Jan 2017 03:51:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=lVqrwG6PKIrWHoD02h+mn7+3AiiFXNeIaD3oM0tnIvs=; b=HEUO3gFYCt+OZcyDkpd6T9LH7G4++COOITTMITnlA04vPZ2Jt/mbQ0KHnht08VREKT t69vcZlae1lwTub1LoVVnrFmRvV9CkGrLq3lR3J/QXNLCE0B41GdsUqHDWjSN2sxqtne uotV5tJHSjGngYBJDpMne5IGLHK4F4sXR87I5N8jJzIE61CZml5UnP6OoquuJtPrO81m JfE/hhn+izespomm+0Fu/bLlNTrDTPI+BzmCK7Wsd1PNK8XNY/YDeE9+7+pPu5/y55Zb 0vW4CGxC89N5HyxFMFWF+BhglFkGDrEaFXJvCt+MerywuwL2x7/mHA22AknpfaTa5yTf TNRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lVqrwG6PKIrWHoD02h+mn7+3AiiFXNeIaD3oM0tnIvs=; b=WXEx9lHuuAl0gEHG4A4otd2XeBO43k1m3SLWf2/45FZYtFsokfL5UFBb9IbTp90wXU kLpHiAkq1T75QnhYY0RFVMMAnBdTcYnwPWVHGXm03ombkV7qhziNcZsPm1IVohrUFhYJ gG7nNNdQlEGT7HgOPxusslxdjGFgXdwRkfJP/ZMrRZjuCjpSUgtrbL/GaVZGR3wwaFMy 3JeEfd1ULAdsC6gXRgDZ+yCAjdN+7GWNXe/UbLRS4b77zFN1WT7wZg07DNAFo7TOR04C gGQbMtlYvBtgA9gSjqoUM7NTvHNhYZU+Nn/n1zfA3C9pb7i6pRMf+XMogiuL05hDCrzG znRA==
X-Gm-Message-State: AIkVDXKNLrjoVz0BMwT5T/u+VHFf/sfglznSt05M4dvzeK5pSQJ/1wnVsFrKvYc6sF44aw==
X-Received: by 10.28.152.137 with SMTP id a131mr14569680wme.139.1485777065381; Mon, 30 Jan 2017 03:51:05 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id q4sm22409331wrc.35.2017.01.30.03.51.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 03:51:04 -0800 (PST)
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, Martin Horneffer <maho@nic.dtag.de>
References: <e9839b0c-6ce4-48f0-c44d-9524c78b6c74@nokia.com> <25B4902B1192E84696414485F57268540187F20F@SJCEML703-CHM.china.huawei.com> <72705bfb-1c80-37ab-423f-27aec7378462@nic.dtag.de> <D8B1301A-330E-40D6-A2AF-A8B90B73163A@cisco.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <d44ab2a7-bdc7-497d-473e-b2fd43e6fbdd@gmail.com>
Date: Mon, 30 Jan 2017 11:51:02 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <D8B1301A-330E-40D6-A2AF-A8B90B73163A@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/5TU1KM2eA2l8ZSQSGvqF1GdFPhQ>
Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" <draft-ietf-spring-segment-routing-mpls@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 30 Jan 2017 11:51:09 -0000

Stefano,

This is the document that someone interested in SR from and an MPLS 
perspective may well start with. A discussion on the issue of label 
stack depth and the practical constrains is thus very much in scope. The 
fact that you had a debate in the past immediately points to the need 
for a summary of the key issues and conclusions in this document.

Stewart


On 30/01/2017 11:27, Stefano Previdi (sprevidi) wrote:
> I agree with Martin,
>
> I think we have discussed this at length and I wouldn't re-spin the debate (and come to the same conclusion again and again). The manageability section of the architecture draft mention that a node may want to signal its stack capabilities and we have igp extensions for that.
>
> s.
>
>
>> On Jan 30, 2017, at 10:13 AM, Martin Horneffer <maho@nic.dtag.de> wrote:
>>
>> Hello Uma,
>>
>> what kind of label depth discussion are you thinking of?
>>
>> It seems to me this could easily become an endless discussion again. People seem to have very different views on it. Thus I'm not sure whether it would be suitable for this document.
>>
>> BTW:
>>
>> For my needs, bandwidth optimization is one of the major use cases for all traffic engineering technologies such as SR or RSVP.
>>
>> We are currently supporting scientific university research about this, and first results give strong confirmation that for bandwidth optimization in real world networks you rarely need more than 1 additional segment. Or rather, the additional efficiency gained by using mor than 1 additional segment is very small. We compare a global real backbone network with current routing, theoretical MCF optimization and realistic optimization with 1 (or 2 or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 4-SR).
>> Thus, from my point of view, an SR optimized network would typically have the same label stack depth as a similarily RSVP optimized network in some places, and a smaller label stack for the overall average .
>>
>> All other use-cases I found of serious interest so far all work with 1 additional segment (i.e. label) at most.
>>
>> Best regards, Martin
>>
>>
>> Am 27.01.17 um 20:59 schrieb Uma Chunduri:
>>> Support.
>>>
>>> One quick comment:
>>>
>>> While section 3 correctly documents MPLS instantiation of SR -  given the constructs SR has (ADJ SID for example) it's good to document SID/Label depth implications in the deployments.
>>>
>>> --
>>> Uma C.
>>>
>>> -----Original Message-----
>>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Vigoureux
>>> Sent: Friday, January 27, 2017 3:05 AM
>>> To: spring@ietf.org
>>> Cc: draft-ietf-spring-segment-routing-mpls@ietf.org
>>> Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06
>>>
>>> Hello Working Group,
>>>
>>> This email starts a 2-week Working Group Last Call on
>>> draft-ietf-spring-segment-routing-mpls-06 [1].
>>>
>>> ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *12th of February*.
>>> Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as a Proposed Standard RFC.
>>>
>>> ¤ We have already polled for IPR knowledge on this document and all Authors have replied.
>>> IPR exists against this document and has been disclosed [2].
>>>
>>> Thank you
>>>
>>> M&B
>>>
>>> ---
>>> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>>> [2]
>>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls
>>>
>>> _______________________________________________
>>> spring mailing list
>>> spring@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>> _______________________________________________
>>> spring mailing list
>>> spring@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring