Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)

Benjamin Kaduk <> Wed, 26 September 2018 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91166128CB7; Wed, 26 Sep 2018 15:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jQn6dzDiKSMT; Wed, 26 Sep 2018 15:47:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF8A1126F72; Wed, 26 Sep 2018 15:47:10 -0700 (PDT)
X-AuditID: 12074422-81fff700000028e5-bc-5bac0c6bae19
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 93.17.10469.C6C0CAB5; Wed, 26 Sep 2018 18:47:08 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w8QMl2iK017931; Wed, 26 Sep 2018 18:47:03 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w8QMkvAN014182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 18:47:00 -0400
Date: Wed, 26 Sep 2018 17:46:57 -0500
From: Benjamin Kaduk <>
To: Alvaro Retana <>
Cc: The IESG <>,,,, Christian Hopps <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sb0gTYRzHe+62223eyW0qezaT7DIKY5ZQtBcivfDFDCx7E9KIutzphtvU u01UIhZZlJY6S9FbhOUwUZdmpTOzdL5xRgTawCVOECPwRdCrEoZ1t+Gfd19+n+f7eXh4fjiq 8cn1uM3pYjknY6cxlUyjKMwx2Ilh86nfP/KNy6FRxNj1ZhY1xgMFxu64FzWORMIy4/zGgPwc Zoqt9iGmSWFVYfL7t5BS9IqqwMLabXUsd7Lwusp6W+gHNV1E/dTsCOIBEWUzUOKQOg2jLUOo lDVUHwLbvhYk82sA//hTm4FKzBEEvvg1gUhARh2FPXd75VLGqBzoaVlKlNOpXLgyOamQCijl A/Df1igmgTSqAo6veRMFUrytv38NS1o7AewIf8eSQA3DPRsyKaPUMRh/tihacTFnwpfbeHJ8 CN5550tcpqQuwadTHUDKGdQRON0aUrQDtbDPJOwzCXsmYZ+pF8gGQZbF0WhwMDY7z5Yb+HLG 6WQ5w5k8h82Vx1rcYyDxB0V0EHi3z4cAhQOaIMtGhswaOVPHNzhCQIcjdAaZPS2OUm9UWxqs DG+9xrntLB8CEEfpdPLVhMhIC9PQyHLVOygTl9Fa0tvUZ9ZQlYyLrWLZGpbboQdxnIbkxZRh s0bNsZVsfYXN7trDCK6U5IQoz5bOkHwN4+BtlUm+AA7rtWS3SgSUBKxu525X2ilY9enmJtCK T0kjS6U6IW7cbntTFCOiuP3hgCR2MXtI7wEV47qFGaDMWv8L3XNtxZ7wLQEvzp+rJdbHglMd XYMZSx8XY8Tz7KD+8uyXYS7c7As0zZcFsJ9bpY+jRYzuqvVbXiwlXBIe1Uz4TwQW10yftUOr 0ZQHZGHnzIHxFf8j99sL9PHW2nvRktiT+vv2ZZf6Pbp+Np47l6nDgx9oGW9l8nNRjmf+Awll eFYuAwAA
Archived-At: <>
Subject: Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Sep 2018 22:47:14 -0000

On Wed, Sep 26, 2018 at 03:41:23PM -0700, Alvaro Retana wrote:
> On September 26, 2018 at 5:46:18 PM, Benjamin Kaduk ( wrote:
> Benjamin:
> Hi!
> I don’t see your updated ballot in my archive…hmmm..??
> But I wanted to reply to the additional point.  You wrote:
> ===
> I'm not sure I followed correctly some discussion around the rtgdir
> review, specifically the meaning of the indicated MSD value for SR-enabled
> vs. non-SR-enabled networks.  In particular, I still don't really understand
> why it's okay to use the same codepoint (value 1 as assigned here) for
> the max SID depth in SR-enabled networks and for the max label depth
> in non-SR MPLS networks.  Why couldn't they just be separate MSD Type
> codepoints?
> ===
> The answer is relatively simple: SR doesn’t change the MPLS architecture,
> it just looks at the label stack in a different way by calling the labels a
> segment [rfc8402].  IOW, the SID depth is the same as the max label depth
> because a segment is the same as a label (for the purposes of forwarding
> and considering the max segment/label depth).

That helps, thanks.  I was probably getting confused with some other system
that interspersed the "new type of label" (whatever it was) and other
existing labels.  Maybe entropy labels; I think we read that recently...

I may try to suggest some new text that would help clarify this
relationship, but probably not until after the telechat, and there's no
need to wait for it, regardless.