Re: [spring] A question regarding Section 3.2 of RFC 8402

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 09 January 2020 14:00 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D29120089 for <spring@ietfa.amsl.com>; Thu, 9 Jan 2020 06:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.991
X-Spam-Level:
X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecitele.com header.b=Fp3fGnF2; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=P/BMMFvS
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 hKp6r20-za5n for <spring@ietfa.amsl.com>; Thu, 9 Jan 2020 06:00:18 -0800 (PST)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.114]) (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 74734120026 for <spring@ietf.org>; Thu, 9 Jan 2020 06:00:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1578578415; i=@ecitele.com; bh=c4qL+DbzAydvTPEB6m52H97QyGWH/dO3SzI7KGYuniA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Fp3fGnF2uM7AENTo7cN+K31h7kJ2EfSkbIwudrQYmR7BrHRLQd00s4/y+7b5JOTsV gyvx09SRhbt8hk4cW30ZlhaQsS517zFlqLrWnD7iVODdKYYc4do9vocD+FBBlNnDHd fs5vQeX1Q6k4eopVFJ40rnKLuiXnxskY7/2lNjWU=
Received: from [85.158.142.203] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.eu-central-1.aws.symcld.net id 58/24-12313-FE1371E5; Thu, 09 Jan 2020 14:00:15 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1VTf0wbZRjmu7u2B1I9yo++NkBCBxaJ7Uo2tW5 BjVWz4eZYjDFTi7Zw0sZSWK+MQox2c2aTjrAxZIO1xQGNC0zJKiTougSIAQZmIpqAW6EQMAhC tWhWKm56vdvm/OfN8z7P++P5Lu+RuCQilJG03UZbLXqzXJhASNZO+JShfGmxem0mR9N/+ZhQM zKxiZ7FdjVtXhLs6uyMYkXY6wKTxVBhf1tgDAfnBJXfnsbs0aluzIH+bMDqUAKJKC8OkeGvcD 4ZJmAg9BvBJ18iGB1pFMUSgvochyPXeoWxRELVYzDtXML5ZBZBMBhhe+JJIVUAvu4ZYQynUNn gmTrBzcIpFwaLfb1cUTL1HPhWmzG+SAtngpfu4B2wOOUXxDDBNs/fuMANElM6WJu/ifHbGhDM rCxxDfHstuXPergiRKVBZOwix+OUFK4vtnEYKAo6/d/hPE6F5YXbAr7eAMGfzyOez4Kzsy4Rj zNgss3J8iSLt0DvLzqe3gsT/qiAp/PAM/AAD7Ph9lANX2GG+R/4zwCUAo6GPQIep8N426Yg5h 6ocQKc1z3cJglVAqOuP4iTaGvrfaZ5bIG6xkG8lXt9ElxtWSRa2XU49Sj0fH2nPAuanPMiHuf CRy636H7+UyTqQhqD1VRmtJXrTWZlvlqtzM/fptyu3KZW6WuVBhVdpSyhLTarnhVV+mpGxdSU l5hLVRba5kPsfZUeJDL7UePNNdUQepjE5KnikV/TiiUPGipKa4x6xviWtcpMM0MonSTlII5jD 1GSZKXLaPs7JjN7pXdlIBPlKeImNSuLmUp9OWMq46UxtJ88uexux8lQtIONV7s62RjmYoSL37 i9bGxfuuzFJYSlwkLLpGJbbBAVG2Ssstxbc/d/mEQZsmQxiouLkyRW0tZyk+3/+gqSkkieLM6 MuU00WWz33KywRjHWaCCQGjNq0/8nyRxYmp9+I+rLwQ+lJRHUK2MH5jY3m/96gvF4+xiTrij+ jNWhQxst6aeTtjNffP8kMRs+tfFTwZWFFwLwnnb1w+M5zxvnJhaWchndB7WJEbf3UEHR46TYi HJ9KWh9Wqu4da5hr+IaVj95o/rVA+svmv9+6VZNYXRnWv1rijKFu/h4Yd9u17HDhaHpfZr+IV lKX93qm5qgM6Gl5KHdWwNGf96g/4ixvSnQ/HT4fVvGxoh5T/jg5O87M63axsyOo489suOprGV tx/7aLQN5059U9Gx4uwPWwSsZz1QHHdnVw50j47KPHcn7Rv/BDntkZ90R/4/n6UBX6OX1d6UX LgYYuT0ZlxOMUZ+fh1sZ/b+csJxCigQAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-24.tower-248.messagelabs.com!1578578411!1988481!1
X-Originating-IP: [18.237.140.178]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.44.22; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 18548 invoked from network); 9 Jan 2020 14:00:13 -0000
Received: from p01c.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.178) by server-24.tower-248.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Jan 2020 14:00:13 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KYRrswo1Lyl8IWE5zb+K47CtgVW+5X+/jD4/yX7PQBut8wSNdkjY4SVv2gNMCdmuKWczFWNY9pQiwsK8AWUvYO3wBMoPEm2TU6ooAvuAxroJ02PQnSTq66oGG2jL4Biwk5bbHCZsfQX4uWh/JjSU35x2T4yO3K8Fp688LlD1fRp000eAqo8L65IUmKNdqtcj1E6B1JMJ0sAV6Hx1K+FEFRzRVGCF50rispDSl2QCHK/defLTachyEod6Jtax4VfnmGM0TV1/vPCRpedJCRjJow0fKR1X7oKlRAhyYy/ymiP6JxZnha/fjprKpiIfwugrQg4JdLqP1g4JjcjpByqhRw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M0CaXrO90yRx+tuO6ohyXdPZTgZOMd1sKaNkmT3Mz7I=; b=b/s+w1Pw6hhuxLu8lrVcneTNVMLPBqhndHEQhVdnrduR5JO0vlHxXQjw9ttjNVbt8faZPIJ6ZmFucdlIYWVfvLrEfhYDfBPguT19LoiM9SS5gw74DqlsAgCok5tbKF2zqw/MH9kDseLulA7aaRkIkhZcGHfN/4PG6EGjUUyStAHipfJUt63AbZseqhpA1RIyj4DEumklVsD/id/qUANVReXxrbT0Cl0UIGxMQXBMhv8e0Va9EAedWTG80H+kYNp+SsQX2Q2iQgmj/TkUOwG0mrZhZEhYimCUA8xdwTwvDy1z+h5howCKb9EqBJ3NPp5+knUP5ZNY0seo0rVGdIFylA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ecitele.com; dmarc=pass action=none header.from=ecitele.com; dkim=pass header.d=ecitele.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector2-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M0CaXrO90yRx+tuO6ohyXdPZTgZOMd1sKaNkmT3Mz7I=; b=P/BMMFvSCVQfFY6hzcxXAHfrnCPzAJh1XGVnvM09kTWodLm5D+sUBZLubnaQAuH7ufwoOr/Oo/1RrjSVg88ukPb5Pgw47Lf4yrbAKZM57gef+CvhUgtga1hEBmAn6jOVrNxNgxoMM/pR5LxXFKzAffwJONabANFD6yb+ijIu/g0=
Received: from DB8PR03MB5865.eurprd03.prod.outlook.com (10.255.16.31) by DB8PR03MB6059.eurprd03.prod.outlook.com (10.255.18.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Thu, 9 Jan 2020 14:00:09 +0000
Received: from DB8PR03MB5865.eurprd03.prod.outlook.com ([fe80::4db4:42fa:5ee2:8de3]) by DB8PR03MB5865.eurprd03.prod.outlook.com ([fe80::4db4:42fa:5ee2:8de3%7]) with mapi id 15.20.2623.010; Thu, 9 Jan 2020 14:00:09 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Peter Psenak <ppsenak@cisco.com>
CC: Madhav Purohit <Madhav.Purohit@ecitele.com>, Dmitry Valdman <Dmitry.Valdman@ecitele.com>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Abhijit Gokaraju <Abhijit.Gokaraju@ecitele.com>, Sheetal Jangeed <Sheetal.Jangeed@ecitele.com>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] A question regarding Section 3.2 of RFC 8402
Thread-Index: AdWvR90JFVFlVi/cQa2YeNQhog9JBQXpr3UAAABCKoA=
Date: Thu, 09 Jan 2020 14:00:09 +0000
Message-ID: <DB8PR03MB5865BCFA47BBFFE50A63AD829D390@DB8PR03MB5865.eurprd03.prod.outlook.com>
References: <AM0PR03MB3828E82BA287730AD51947659D5B0@AM0PR03MB3828.eurprd03.prod.outlook.com> <4f5ca51f-8229-7f82-8d35-e289d5da8f94@cisco.com>
In-Reply-To: <4f5ca51f-8229-7f82-8d35-e289d5da8f94@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: dd164798-1fdd-4319-acde-08d7950c3d5a
x-ms-traffictypediagnostic: DB8PR03MB6059:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB8PR03MB60593971265D1DC2A1B632779D390@DB8PR03MB6059.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02778BF158
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(136003)(376002)(39860400002)(396003)(199004)(189003)(13464003)(51874003)(51444003)(53754006)(26005)(53546011)(64756008)(66946007)(6506007)(54906003)(52536014)(2906002)(6916009)(186003)(66476007)(66556008)(81156014)(81166006)(66446008)(8936002)(8676002)(55016002)(9686003)(21615005)(86362001)(76116006)(5660300002)(66574012)(71200400001)(7696005)(316002)(4326008)(478600001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB8PR03MB6059; H:DB8PR03MB5865.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xFTc5UNJuX5rn9JGjNk2BFLb6ZQaD2LIT3fWXMXWmJjkZdPbTGKHDj7mjoFdJGmu8Kgiapt/Giq1prpMICPIuXZfiGj6jUm3THoiBVv8xIEbivoGTvxcO+t9f1kZR7I9bIu7ZG3SCGoEv0Wk5QwxzdSclCDKBAqnns/MZbFR8WCQoI0O7nKj3xIwgWqtVZtiveVns2cLdJ9VBHPdYFgT9SGs6JXxQr87uEvxfibk8TE6lj0h8PsL4s34LtlegLUrGAhj92IYQTma0Pfw4OJ94V73JutJfkgRffknF0V/nJIqmWicvdy7Pbb+UxATCj+nCgde6qRahEexaXHNQszt5TYViyuqW0Qmf/zu7RmHr+lBQ3vdTJulCw3oW4dzPRBxMWiwVf6mfNXD3+OLBDKea83zeKt+v6AT1dAJkdIp/KAfG4yWq0XDlROTEcuXnMefisteSofoSBK3pyKj7/bXsRZQ3S0E0I7BakC/5ZGn+We1ZAxYJKOg1zC1AwQOcrUnQlA8G3i5xWhCMH/onIhHOH4sSsMxXB7x+eBT++6sgopaNPj6wGjvH4+bieKZckniCDWzgcdyVF7kqxI76DhuSTkrEQnVit4iWLHVWYXxfqFfSy2y9P2GuTK6UgTRITItjmku8xPJx8z5To+e8nDheQ==
Content-Type: multipart/alternative; boundary="_000_DB8PR03MB5865BCFA47BBFFE50A63AD829D390DB8PR03MB5865eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd164798-1fdd-4319-acde-08d7950c3d5a
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 14:00:09.5824 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: L8pNB/Clxesd+BtNM264g7BQP2PIj3yrsQ/QLGwXW+0wwkoFLfpoKIJPOfwsjntMnKvevtYPQbKkxdrKnWQFLg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB6059
X-CFilter-Loop: Reflected
X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/8Q0IEPc4JMOQvXZbzJFOHKoCCPQ>
Subject: Re: [spring] A question regarding Section 3.2 of RFC 8402
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 14:00:22 -0000

Peter,

Lots of thanks for your response.



I fully agree with you when you say that "there are way too many ways how one can misconfigure things".

However, I think that in many cases IETF tries to standardize handling of these misconfigurations, and, specifically for RFC 8660<https://tools.ietf.org/html/rfc8660> deals with some of these misconfigurations in Section 2.5 and in Appendix A (BTW, the SPRING conflict resolution draft that you mention has been, with some modifications, subsumed into these sections of  RFC 8660).



However, the conflicts that I have described are not covered by RFC 8660 since it only speaks about incoming label conflicts when the same incoming label is mapped to multiple segments. Our case is different, since we have just one Prefix Segment (same prefix, same topology and same algorithm).



Regarding your references to IPv6: I think that there is a subtle difference between SR-MPLS and SRv6 when it comes to Node SIDs:

-          In SRv6,  you can explicitly mark the prefix as either Anycast or Node SID with the preference given to Anycast (if both N-flag and A-flag are set, N-flag is ignored, if one of the routers that own a prefix advertises with A-flag set, the prefix becomes an Anycast one)

-          In SR-MPLS you have to explicitly indicate that a given prefix (/32 for IPv4 and /128 for IPv6) is a Node Segment. Without this indication the Prefix SID is (implicitly) an Anycast one (see RFC 8667<https://www.rfc-editor.org/rfc/rfc8667.html>).



Based on this I still think that the problem my colleagues and I have raised is relevant and should be addressed.









Regards,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com



-----Original Message-----
From: Peter Psenak <ppsenak@cisco.com>
Sent: Thursday, January 9, 2020 3:14 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; spring@ietf.org
Cc: Madhav Purohit <Madhav.Purohit@ecitele.com>; Dmitry Valdman <Dmitry.Valdman@ecitele.com>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>; Abhijit Gokaraju <Abhijit.Gokaraju@ecitele.com>; Sheetal Jangeed <Sheetal.Jangeed@ecitele.com>
Subject: Re: [spring] A question regarding Section 3.2 of RFC 8402



Hi Alexander,



On 10/12/2019 12:13, Alexander Vainshtein wrote:

> Hi all,

>

> My colleagues and I have a question pertaining to Section 3.2 of RFC

> 8402

> <https://eci365.sharepoint.com/sites/technicaldocsite/genericdev/System/System%20Documents/Forms/AllItems.aspx?FolderCTID=0x012000858C3D81A4889F449868AC62A2AABDCD&id=%2Fsites%2Ftechnicaldocsite%2Fgenericdev%2FSystem%2FSystem%20Documents%2FIP%2DMPLS%2FNE%20Management%2FCLI>.

> This section says:

>

>     An IGP Node-SID MUST NOT be associated with a prefix that is owned

> by

>

>     more than one router within the same routing domain.

>

> The requirement itself is well understood. However, neither RFC 8402

> nor any other SPRING document I have seen defines the expected

> behavior of SR-capable nodes if, due to misconfiguration, a certain

> prefix that is owned by multiple nodes in the SR domain is associated

> with the Node-SID in at least one of them.

>

> There are several sub-scenarios of the misconfiguration problem above, e.g.:



there are way too many ways how one can misconfigure things and I don't believe we have to always standardize the way these errors are handled.



>

> ·The prefix is owned by multiple nodes. One of these nodes advertises

> it as associated with the Node-SID, while the other owners do not

> associate it with any SID at all

>

> ·The prefix is owned by multiple nodes. One of these nodes advertises

> it as associated with the Node-SID, while one (or more) of the other

> nodes advertise it as associated with an IGP-Prefix SID but not as a

> Node-SID



Above two are similar in a nature. Prefix is anycast, but at least one node advertise a Node-SID with such anycast prefix.



There are ways to detect the anycast prefix property - one is defined in the section 6 of draft-ietf-lsr-isis-srv6-extensions - e.g. A-flag. That section says:



"If at least one of them sets the A-Flag in its advertisement, the

  prefix/SRv6 Locator SHOULD be considered as anycast."



If the prefix is considered anycast, one should not use the SID advertised with the prefix as Node-SID, even when the N-flag is set for it.



Other way to detect the prefix is anycast one is simply looking at the number of sources that advertise it.





>

> ·The prefix is owned by multiple nodes, and  two (or more) of these

> nodes advertise it as associated with the Node-SID but with different

> indices in the SRGB



this is SID conflict, where you have multiple sources of the same prefix

advertising a different SID value.



There used to be a draft that went into details of all possible SID

conflicts (draft-ietf-spring-conflict-resolution), but it became way too

complex and people lost interest.





>

> ·The prefix is owned by multiple nodes, and  two (or more) of these

> nodes advertise it as associated with the Node-SID with the same index

> in the SRGB.



problem is the same as the first two. Prefix is anycast, but at least

one node advertise a Node-SID wit the anycast prefix.



thanks,

Peter



>

> Our experiments (admittedly incomplete) with SR-capable equipment from

> different vendors have shown that:

>

> ·None of the tested devices have reported this situation as an error

> when they encounter some of the problematic scenarios

>

> ·Different devices have demonstrated different forwarding behavior when

> they encounter some of the problematic scenarios. In some of these

> scenarios the offending prefix would be associated with some SID and the

> resulting forwarding behavior installed.

>

> We think that it would be nice if the WG could define a minimal set of

> requirements for handling this kind of misconfiguration. These

> requirements should include at least the following:

>

> ·A device that encounters this kind of misconfiguration SHOULD report

> the problem to the network management layer

>

> ·The prefix for which this kind of misconfiguration has been detected

> SHOULD NOT be associated with any IGP Prefix-SID at all.

>

> There may be other possibilities, but we feel that RFC 8402 is

> underspecified in this regard,

>

> We would highly appreciate your feedback.

>

> Regards, and lots of thanks in advance,

>

> Sasha (on behalf of the team).

>

> Office: +972-39266302

>

> Cell:      +972-549266302

>

> Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

>

>

> ___________________________________________________________________________

>

> This e-mail message is intended for the recipient only and contains

> information which is

> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have

> received this

> transmission in error, please inform us by e-mail, phone or fax, and

> then delete the original

> and all copies thereof.

> ___________________________________________________________________________



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________