[mpls] Comments on draft-nainar-mpls-spring-lsp-ping-sr-generic-sid
Tarek Saad <tsaad.net@gmail.com> Mon, 22 July 2019 13:17 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 07F2412027E; Mon, 22 Jul 2019 06:17:32 -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_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 Jlv5Q18yLvn6; Mon, 22 Jul 2019 06:17:30 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 DF6A6120248; Mon, 22 Jul 2019 06:17:26 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id w17so38404446qto.10; Mon, 22 Jul 2019 06:17:26 -0700 (PDT)
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 :accept-language:content-language:mime-version; bh=uF0JWEszdjGmGtvWFUxkiBkyhpJb5wcOr+Fl5pN3sbw=; b=KDPoBUcaBccoRPxc+FhK3ry4IEj9SJkkdYfNA9LY+Xi9dqEfie8y+g808Tzp+nb2td ydJyZKtgJvEg4Hxnjghb+8utOTN8n61rfMot0pXCKKJy/lmRc0LZ6g1uTB+Ci3qMh7CF rn5UdGUXTcYmIR6LYx4qAV7x/flFx/XjZE4CGtfrackq8ygmja9ROyvcklPSB6puHghp DR4Vc5RjRw2kaL995OZhlbqRTzymRLowyBmc8WIgpw4sqozDGzRurMVpto/o8vh1i2k5 PNU73rF2J2EZXSalN45XT6ekU4TMdhQaujBklnuadbvZAqP6BU3PmtQCLB5Sh+9bK8t4 H5uw==
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:accept-language:content-language:mime-version; bh=uF0JWEszdjGmGtvWFUxkiBkyhpJb5wcOr+Fl5pN3sbw=; b=QQ6+/97qCWcHjMazlh9GHCg8BJ0YsNZtBPX/16dYPzIQs4bG6P0oSiKMC4gl/Rb4NP 6Fnm6j+1jsw/FYjGRAeqVpT+QjXEdjUKInLPybM32GeYApkUkbCwUWN7PZPh7+cUyV5Y Mk72qksyw4xopAcVGKICkWeZpHEOGCs5z7IlKQ/ZKlHo/mXZ/gCSBVXXWvC1vFUbA1ia esxgFDWwKwfbHQQ2RJk36FtGpTMtCnr1n4CPq++B67++ChXWn2DbHtGFXIozzL/7xBaW 2nX6iLcxY+E7OzWbQLesaTM4qfRFOzmkbfOcNqWys+bkjhuyw2xitVS8lZZkxmM+8/VJ 93rw==
X-Gm-Message-State: APjAAAUM8Qe7dwjQLM1wWLBYX2pyu53OCFDmxqHE6iTwHIlSSz7DUdoh h2vAcb6NE6qD7GFm7fSjP9YAodzC
X-Google-Smtp-Source: APXvYqyfaWHG/c+Awm+5UvdBp4W49k3DK1/GK/+NaFBU5U541P0RPUFWZQPvJYZQhTjOPdNi6iYm2g==
X-Received: by 2002:a0c:d7c7:: with SMTP id g7mr50861537qvj.171.1563801444837; Mon, 22 Jul 2019 06:17:24 -0700 (PDT)
Received: from BYAPR19MB3415.namprd19.prod.outlook.com ([2603:1036:307:293b::5]) by smtp.gmail.com with ESMTPSA id z1sm18702246qke.122.2019.07.22.06.17.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 06:17:24 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
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>
Thread-Topic: Comments on draft-nainar-mpls-spring-lsp-ping-sr-generic-sid
Thread-Index: AQHVQI/L/0pbkzMWaEihSBQ9Ee6i2g==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 22 Jul 2019 13:17:21 +0000
Message-ID: <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_BYAPR19MB341508F4CAE48E5D530B998BFCC40BYAPR19MB3415namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/XWVennqmSAbZP7TQIZMXyGQz4lA>
Subject: [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, 22 Jul 2019 13:17:32 -0000
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