IETF Logo Mail Archive

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

Alvaro Retana <aretana.ietf@gmail.com> Wed, 26 September 2018 22:41 UTC

Return-Path: <aretana.ietf@gmail.com>
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 E398B130DCA; Wed, 26 Sep 2018 15:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 iZmW08DUbSvg; Wed, 26 Sep 2018 15:41:25 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 C0EB4128CB7; Wed, 26 Sep 2018 15:41:25 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id c18-v6so655881otm.3; Wed, 26 Sep 2018 15:41:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=lhQ8tKd9pfe0nI0TCNhtdOd8g/CtQN84P3qE0ME0iMM=; b=h+/XFmQyfK/UuO3VUl+6rdhX8po+N0tGJfMOHldFSjroHxEmLaQCetIDbPJ50+C7Dt l0I0Ksji0owH44xq8mEa5RGhbE+wEWyDEXtxVvLfEyuCeAOTnCkZhfPyXq1lgqohtvAx /+1hP6g6mISgzd8I9DxmyMLnJjHObSNYNsUVxEhH8efQW7KunbpWxTnf6xZs0k7C9twR J0fPUeMRMhqKhdcgKBRceKBiNPt9QkQqQccCr+DCNqQYcr64UnUahh1wRpaJbmZut0aV 5PmzavPZyt469ZlS+Xck0jPvMjBJNqvmIAa8HmtDMl2X50rPF6UwPC6drwYtudU/qYJp ZGNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=lhQ8tKd9pfe0nI0TCNhtdOd8g/CtQN84P3qE0ME0iMM=; b=gYWvG9PjSpKlZHiF9NGnF/8lEk1iqvxEuO24U6IuTjnzTY2sntn1KfnEJKA9GJcBjX gb44DvrE0N6b0YEF7sZgClklwK5BYx0S3mftfJfCqpFBvyxclcXk1AzGJWp6uDnWd08f 21EzER9zHSW1EvmXEaVn8GPzWHyuRRfJ94OtypaJE82pc0BmZj1esAivw4IXt4xPkcoh q0/TlbGe2zxppWieyCMghS16jCu/4p/LHb25Cu3KfniCHW+I7QayK6hV62CaZia62eHq allfpH69Qu3p0J1kwOx27rFeEraETNQkDa6gauDtEhM1apy0OEde9JB3L3v0nDADpPDs /JXQ==
X-Gm-Message-State: ABuFfoiV9tIzk8eLZ0CxH+KqfdGi8rDw0IWGILN3Q8dottSHEhryKGYl UtQqIa7gYfpT7pxlyyJPX8wu1BdFsEyYXVdKVWo=
X-Google-Smtp-Source: ACcGV60atdIkhTupNF5IIYN8Paeh1M1MomDkvri3G2h6Ji3o4j3LMo44GAEcDSmNwoFGEod9gQ1MhZJXLNvP6r8C0CA=
X-Received: by 2002:a9d:5f82:: with SMTP id g2-v6mr5346643oti.126.1538001685174; Wed, 26 Sep 2018 15:41:25 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 26 Sep 2018 15:41:24 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <153799837555.21625.17869101343542542632.idtracker@ietfa.amsl.com>
References: <153799837555.21625.17869101343542542632.idtracker@ietfa.amsl.com>
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Wed, 26 Sep 2018 15:41:23 -0700
Message-ID: <CAMMESswJCPHAAv+_Go0Oi6i3Lxszqgkz4YXL_+-K59f+1gitig@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: draft-ietf-isis-segment-routing-msd@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Christian Hopps <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="0000000000001bdebd0576cdec22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/yfZBIu-HZvq9_v6rgSRJp1AX5wU>
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:41:28 -0000

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).

Alvaro.

v2.23.0 | Report a Bug | By Email