IETF Logo Mail Archive

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

Benjamin Kaduk <kaduk@mit.edu> Wed, 26 September 2018 22:47 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91166128CB7; Wed, 26 Sep 2018 15:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQn6dzDiKSMT; Wed, 26 Sep 2018 15:47:11 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8A1126F72; Wed, 26 Sep 2018 15:47:10 -0700 (PDT)
X-AuditID: 12074422-81fff700000028e5-bc-5bac0c6bae19
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 93.17.10469.C6C0CAB5; Wed, 26 Sep 2018 18:47:08 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w8QMl2iK017931; Wed, 26 Sep 2018 18:47:03 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (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 <kaduk@mit.edu>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-isis-segment-routing-msd@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Christian Hopps <chopps@chopps.org>
Message-ID: <20180926224657.GV24695@kduck.kaduk.org>
References: <153799837555.21625.17869101343542542632.idtracker@ietfa.amsl.com> <CAMMESswJCPHAAv+_Go0Oi6i3Lxszqgkz4YXL_+-K59f+1gitig@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMMESswJCPHAAv+_Go0Oi6i3Lxszqgkz4YXL_+-K59f+1gitig@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/lsr/Wl8oF_gxPeIzgLIv2GJVwG4OMYI>
Subject: Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=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 (kaduk@mit.edu) 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.

-Benjamin

v2.23.0 | Report a Bug | By Email