Re: [mpls] Comments on draft-nainar-mpls-spring-lsp-ping-sr-generic-sid

Tarek Saad <tsaad.net@gmail.com> Mon, 18 November 2019 02:19 UTC

Return-Path: <tsaad.net@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 40D2D120048; Sun, 17 Nov 2019 18:19:49 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-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 IVYqQFBiV_Ym; Sun, 17 Nov 2019 18:19:47 -0800 (PST)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 6A1CE120106; Sun, 17 Nov 2019 18:19:44 -0800 (PST)
Received: by mail-yb1-xb2d.google.com with SMTP id v15so6551555ybp.13; Sun, 17 Nov 2019 18:19:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=iGyvo1qP7zRa0N2DfCfeLOb0ymrqXxSEG3t8eLhCsU8=; b=nn4MXdLwDfUr74oyZ5M721vU31FSX12WerC9daN2U3POHzQi/tnBgJFwTg5uhz/cgV o7nqFjsAL3pazxitJoN9ujQ3+0aSHVCfWPamCpC8gi9qBQInLjYsuIhpM9cxwof3EmDh 0IYFbUktBbdIJxkERwWhRUONCsJOGeoAwHwJwwJiz3sm4HzGqIU2gCY4BbxxG+QaQN6u U2WknF2zACsHQd5M8IXzGw3l3aVVLhozlfWo2n+ehcv/6GvVSDr2vlw8Rkrjh0FkYj2+ NSphiUJ6QBnbcJGCHTCtsu8Ncy4E0q63GeXCkvUjuoRfkvDXFsOY2PhvnT1+JAsVrss3 sEWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=iGyvo1qP7zRa0N2DfCfeLOb0ymrqXxSEG3t8eLhCsU8=; b=eTDv9pRap3xjzWvOP/zcglVzkJZ6uMs+yXyVhTLsy6lNIwRYAstrhQ9o3l5v8Jw1FP CpPnLWzwrjAgNlzDVtYcetUgQHM8+Xliv/K1ZfmBweW35IfNs/yioIb2XohN1DkaXc+n WeasuFnYjPKnO+b91Vk5n1TBqvVS+kaQ8vFQ1TGK7fEyWmW+x13ndHDIbu/eDFTKCpY3 I8p4Mr3biPWIhtoHSvsIfRdrpMRWBROT/0m3RhUuM+sV20JHr0vBR4e9e7YHGh108fbt 2mHbLoDfmnu6aObYSUcNaZVMSmxogNP2S8IMJGCysdZViyxuJZfhScZxsI2q3NqKUc+V sxWg==
X-Gm-Message-State: APjAAAUH+8WqTefT0xfyIfym4RZ5fPFdj/7Y2hCKaVBW789n0uQl5Eb5 xgGEX62TVoqeDOFNCh4M28s=
X-Google-Smtp-Source: APXvYqzjwqxxCEyUnYqI12CaFl38sOtQJDjIwYC4T9W5xycceG8u0rhZQz/bEqkvxeq6MgiR1JADHw==
X-Received: by 2002:a25:a0c8:: with SMTP id i8mr21647933ybm.242.1574043583495; Sun, 17 Nov 2019 18:19:43 -0800 (PST)
Received: from DM6PR19MB3689.namprd19.prod.outlook.com ([2603:1036:301:21db::5]) by smtp.gmail.com with ESMTPSA id e71sm7204615ywh.109.2019.11.17.18.19.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 18:19:42 -0800 (PST)
From: Tarek Saad <tsaad.net@gmail.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, "naikumar@cisco.com" <naikumar@cisco.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, "draft-nainar-mpls-spring-lsp-ping-sr-generic-sid@ietf.org" <draft-nainar-mpls-spring-lsp-ping-sr-generic-sid@ietf.org>
Thread-Topic: Comments on draft-nainar-mpls-spring-lsp-ping-sr-generic-sid
Thread-Index: ATA5NTQz+jTvY3cRB06SRCoE4f9cpsrJAts1
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 18 Nov 2019 02:19:41 +0000
Message-ID: <DM6PR19MB3689BD06580B4D0AB484C016FC4D0@DM6PR19MB3689.namprd19.prod.outlook.com>
References: <BYAPR19MB341508F4CAE48E5D530B998BFCC40@BYAPR19MB3415.namprd19.prod.outlook.com>
In-Reply-To: <BYAPR19MB341508F4CAE48E5D530B998BFCC40@BYAPR19MB3415.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM6PR19MB3689BD06580B4D0AB484C016FC4D0DM6PR19MB3689namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/UnaYHZPWcSaSLVw6Hgjl6ebfCGQ>
Subject: Re: [mpls] Comments on draft-nainar-mpls-spring-lsp-ping-sr-generic-sid
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Nov 2019 02:19:49 -0000

Hi authors,

Resending some comments from last time and adding one more:
Can you comment on what validation checks are possible with this approach in case there’s an incoming label collision for multiple SR FECs (as described in in draft-ietf-spring-segment-routing-mpls section 2.5)?

Regards,
Tarek

From: Tarek Saad <tsaad.net@gmail.com>
Date: Monday, July 22, 2019 at 9:17 PM
To: "draft-nainar-mpls-spring-lsp-ping-sr-generic-sid@ietf.org" <draft-nainar-mpls-spring-lsp-ping-sr-generic-sid@ietf.org>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Comments on draft-nainar-mpls-spring-lsp-ping-sr-generic-sid

Hi authors,

I read through this draft and need some clarification.
      *  Else:

         +  Set the Best-return-code to 10 when the index derived from
            the label at Label-stack-depth is not advertised by LSP End
            Point.

The procedure above seems to hint that a transit node (e.g. for a traced node SID) will have to derive the SR index from the SRGL SID (as absolute label) so it can do further local validation? If my understanding is correct,

1.      How does the node know deterministically that the SRGL SID is for a remote prefix SID -- so it can do this derivation?

2.      I presume there is an assumption that R8’s SRGB is known to all transit SR nodes along the path so index can be derived? I’m not sure the condition will always be true -- e.g. what about inter-area case? Also, what about BGP prefix SIDs?

3.      What happens if R8 is non SR capable (e.g. runs LDP) and SRMS is advertising the prefix SID on its behalf – i.e R8 never advertises an SRGB?

As comparison, RFC8287 suggests to carry the (i.e. node/prefix of R8) in the prefix SID Target FEC Stack and any transit node can easily do local validation in the respective protocol DB (e.g. IGP or BGP).

Regards,
Tarek