IETF Logo Mail Archive

Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensions / draft-ietf-isis-segment-routing-extensions)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 10 April 2019 22:05 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 0E9DB1202EE; Wed, 10 Apr 2019 15:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, 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 31IqAaoK_A4p; Wed, 10 Apr 2019 15:05:52 -0700 (PDT)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 6F31F1201BC; Wed, 10 Apr 2019 15:05:52 -0700 (PDT)
Received: by mail-oi1-x234.google.com with SMTP id y84so3147552oia.12; Wed, 10 Apr 2019 15:05:52 -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=PXQuesc0DXVqgM34w1cckNk7TA0GfNs6ZgQJBdXf8LU=; b=uuWa0qpsNAVNGjZoDwMyxcOZs7KmGzjZfKyy+jwc8hPWMWge/s+Ila7RrENy6//36c HdSyEpbOKR8tJxGhuT5NOMVPWiM3iMjEMw5rNGBAtWKbCmibZGa0njOR3sYlhCIQSnuZ s1qTTEEf8U+65zBnfwyvsjOW5cHoiO3TAhr4xQJaaMNQVTis2qQetsPx+QTbQgMiHAR5 hE4dXjMaN9i13ARo3Oy8DYTHJMOMcBr7HTQEj1AlqjOILn4j3ZTx6aSGMsBgW7lOpkeg JTIH5iC1KiVIqcffs/Ujwt0J/PUbjFVAIk8YL/Ab90/yUnF8zM7fFi2BoVqG/m6TOOPH XgbA==
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=PXQuesc0DXVqgM34w1cckNk7TA0GfNs6ZgQJBdXf8LU=; b=kyDszq8sTxJWioonYu05iKWzPUjp0aoKqYPY/M4smr4IhWZVeFvlSg6H2Q0Fn8D6f2 NCnmw0Egr+ymON4ZUk3mxt3ueo2Jl/oA5MAOnGO4tvE0naQuLcwzCL2nuTvIuEazoipD PpklngsuDqUYCvzTc56VwvYGLqzycdhoE1QEYAl/jwXRWdnMNjn9iu7xHnobX4dLOE91 C4TY91edRv8icwG6S45T7TVcVsIhWgovGqlWFLCZ1WuCAOr+9yMegR/1zsqxhEFxPUQy InvG34mEMpY0oNW8N0R2E7/3k/KTbjTKOlvsLGCOmb3sRcXHBsA75DpnJxSXRx/yrmvC BN3Q==
X-Gm-Message-State: APjAAAUXrKxv+sldd1Oa6OFXtCptDgtY80llENPAXmkzofThQ3H8gvr+ yW32v9iWY13RWMpFsgAaa8UKa2cgklEn3u3n7u0YVA==
X-Google-Smtp-Source: APXvYqwTNQfxF3kWonRvFnxavI4z9tWd3WxkoEdTLHvwBqC9m/GixkVJfMSSmx6IgkkXBH77wZ9/HoINm8pitCcPKkI=
X-Received: by 2002:aca:b288:: with SMTP id b130mr3885601oif.154.1554933951570; Wed, 10 Apr 2019 15:05:51 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Apr 2019 15:05:51 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <DB7PR07MB4999B1D9BE0BF5B459051F598C2E0@DB7PR07MB4999.eurprd07.prod.outlook.com>
References: <CAMMESsxRGWhgUOniQBiELTc4FaaG5gDaA08FQ_KfcEDdB_HfHg@mail.gmail.com> <DB7PR07MB4999B1D9BE0BF5B459051F598C2E0@DB7PR07MB4999.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Date: Wed, 10 Apr 2019 15:05:50 -0700
Message-ID: <CAMMESsyusiWBp67SucC4NLWV-9E4Ygt9npSa+=QZsGNkqTGZxA@mail.gmail.com>
To: "draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org" <draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org>, "draft-ietf-spring-segment-routing-mpls.all@ietf.org" <draft-ietf-spring-segment-routing-mpls.all@ietf.org>, "draft-ietf-isis-segment-routing-extensions.all@ietf.org" <draft-ietf-isis-segment-routing-extensions.all@ietf.org>, "draft-ietf-ospf-segment-routing-extensions.all@ietf.org" <draft-ietf-ospf-segment-routing-extensions.all@ietf.org>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, SPRING WG <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d5280c05863445a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/M0GbG4zLBpbXxW-fXGIHK-okIOI>
Subject: Re: [Lsr] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-mpls-19: (with DISCUSS and COMMENT) (draft-ietf-ospf-segment-routing-extensions / draft-ietf-ospf-ospfv3-segment-routing-extensions / draft-ietf-isis-segment-routing-extensions)
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, 10 Apr 2019 22:05:54 -0000

On April 10, 2019 at 5:46:56 PM, Vigoureux, Martin (Nokia -
FR/Paris-Saclay) (martin.vigoureux@nokia.com) wrote:

Martin:

Hi!

It looks to me that you don’t disagree with what is written in the draft
but rather with the fact that the draft may suggest that IGPs should do
things which are in fact not specified in the IGPs drafts. I think this
point covers 1.1 to 1.4

Assuming that I’m correct, I believe that in order to clear the
misunderstanding authors could simply remove the sentence: “IGPs with SR
extensions...are examples of MCCs.”.

…and probably clean up some other text, for example, §2.10.1
references I-D.ietf-isis-segment-routing-extensions specifically.

Bottom line, I think you’re right.

On 1.5. I don’t think there is a conflict. It does not contradict 8402. It
is not saying “An IGP Node-SID SHOULD NOT be associated with a prefix …”

The way I see it is that this is a belt and suspenders approach. The base
req says MUST NOT and this req says “check if this req is respected”.

I read this document as saying “check, but you may have reasons not to”…
 IMHO, there’s no reason to specify the behavior here again, if it’s
already specified in rfc8402.

Of course this is only my view. I expect authors to have their own.

I’m sure they will. ;-)

Thanks!

Alvaro.

v2.23.0 | Report a Bug | By Email