Re: [Idr] Some comments about the flags in draft-ietf-idr-te-lsp-distribution-11

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 04 July 2019 12:07 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D97C120294; Thu, 4 Jul 2019 05:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LjJvPiuL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lJhFROK2
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 9Anei0QDKHpN; Thu, 4 Jul 2019 05:07:04 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89F51204AD; Thu, 4 Jul 2019 05:07:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35528; q=dns/txt; s=iport; t=1562242023; x=1563451623; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4c6x0/1O2eaQJGfv/b747Crtg5PnLGzGApkqq5NbINQ=; b=LjJvPiuLStGg9/+Na0RVdIKWkSc6WQ4Y8td4nbIa4vGjIu7sTgjq3I4E t5M6PM53t3iNA2JRG+ZJpT5naQYUrmotBWyG7nPsHOMloABaJzm64PEhz g2zpCqN7Wd3iApuT4YTNAf8CXUUbmyLF9aDW4DC0ZFwKnXfMvGI7LfN+w c=;
IronPort-PHdr: 9a23:KKe0TBNrFbVojK2aHH0l6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBj4IeLjaTASF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AIAABJ6x1d/4QNJK1mGgEBAQEBAgEBAQEHAgEBAQGBUwUBAQEBCwGBFC9QA2pVIAQLKAqEEoNHA4RSiXeCW5dGgS4UgRADVAkBAQEMAQEtAgEBhEACF4IUIzQJDgEDAQEEAQECAQVtijcMhUoBAQEBAxIRChMBASUSAQ8CAQgRBAEBIQcDAgICMBQJCAEBBAENBQgagwGBHU0DHAEBm3UCgTiIYHGBMoJ5AQEFhRUYghIJgTQBi14XgUA/gRFGgh4uPoQMOhUfglQygiaMD4JbhH2CKZQ5CQKCF5QegiyHHoxegVCNMIEwlgsCBAIEBQIOAQEFgVA4gVhwFTuCbIJBDBeDTopTcoEpixsrgQQBgSABAQ
X-IronPort-AV: E=Sophos;i="5.63,451,1557187200"; d="scan'208,217";a="587888374"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jul 2019 12:07:02 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x64C72K8001948 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jul 2019 12:07:02 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 07:07:01 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 07:07:01 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 4 Jul 2019 08:07:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4c6x0/1O2eaQJGfv/b747Crtg5PnLGzGApkqq5NbINQ=; b=lJhFROK243N4AxNuBYxQwlVHJ9ipIkwnMz7tSRZNXFiDGl/z6KtFiVrNHhoDkeao6Ds30p/Sf5oQASRvzAwQyyCskArvBkfoebkQC+BaAGrpTvSzJ+SOXvad3KCG1RM5a3zZUfVD9oP9KC7uiSfqVSmtypzjNSHIkNJrnB3Dnw8=
Received: from DM5PR11MB2027.namprd11.prod.outlook.com (10.168.103.22) by DM5PR11MB1273.namprd11.prod.outlook.com (10.168.105.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.17; Thu, 4 Jul 2019 11:52:58 +0000
Received: from DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::3cb3:24e6:1ba8:bba5]) by DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::3cb3:24e6:1ba8:bba5%6]) with mapi id 15.20.2032.019; Thu, 4 Jul 2019 11:52:58 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "draft-ietf-idr-te-lsp-distribution@ietf.org" <draft-ietf-idr-te-lsp-distribution@ietf.org>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Some comments about the flags in draft-ietf-idr-te-lsp-distribution-11
Thread-Index: AdUZtXNNpFwWiZR2SGe57tDeoqrMCwX8hpJAACRcxaAACQDOkA==
Date: Thu, 04 Jul 2019 11:52:58 +0000
Message-ID: <DM5PR11MB2027D140E2F15D8A380F6AB4C1FA0@DM5PR11MB2027.namprd11.prod.outlook.com>
References: <76CD132C3ADEF848BD84D028D243C927CCE11BEC@NKGEML515-MBX.china.huawei.com> <DM5PR11MB2027C8332D6B5B3DFE5B3A20C1FB0@DM5PR11MB2027.namprd11.prod.outlook.com> <76CD132C3ADEF848BD84D028D243C927CCEE1590@NKGEML515-MBS.china.huawei.com>
In-Reply-To: <76CD132C3ADEF848BD84D028D243C927CCEE1590@NKGEML515-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com;
x-originating-ip: [49.36.30.1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d86a4ce1-1394-4b78-daf8-08d7007628b1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR11MB1273;
x-ms-traffictypediagnostic: DM5PR11MB1273:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <DM5PR11MB1273A341ED78BBBE3E306168C1FA0@DM5PR11MB1273.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0088C92887
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(136003)(346002)(39860400002)(366004)(199004)(189003)(11346002)(71190400001)(66066001)(33656002)(446003)(71200400001)(486006)(476003)(2501003)(478600001)(14454004)(99286004)(81156014)(2906002)(26005)(53936002)(6506007)(7736002)(76176011)(81166006)(53546011)(6246003)(102836004)(74316002)(7696005)(3846002)(9326002)(790700001)(6116002)(8936002)(8676002)(316002)(186003)(110136005)(68736007)(6436002)(52536014)(66556008)(64756008)(66446008)(66946007)(55016002)(76116006)(5660300002)(73956011)(229853002)(14444005)(86362001)(4326008)(6306002)(54896002)(25786009)(256004)(66476007)(9686003)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1273; H:DM5PR11MB2027.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: t1c3LmMFSicJUDJUcYLKohOD5E29ZnpdIjOws/huNNUYVALGJxFSDq8MqLPOxKwVBfxtcbGGmcGALo6FYzdLRUj2tKJV3HhFXU4k6FGShlEOyuNprqV6XmStGs2usVrflIiZIAcuEvdn7eSC7wyYRq2HSXhDJ8bgtecoSso5x/zskfaJRIi4m7dGi4ruQX2i6RNx5/I3yq8rdrzq4wRVlkDyCzydm6ereDV/x7d5auTdc5LMwy/sVW7ieCVvfHZmGru8WY9uLaXE6irR64/jzNvLXtnsbDSzRv/vjqcsn6ERsg1ZLOMUhJN7l1sq1bFDDg3t1RlbR9y+YaGzESl9dAH2JpLDI0ZEt+1SSbC5YB1qPkVdQ4/zyBx1I2IZN8WD8+hON/8OytyBeqPUtU46RBr9fnZqtG6o+hds84PO1sM=
Content-Type: multipart/alternative; boundary="_000_DM5PR11MB2027D140E2F15D8A380F6AB4C1FA0DM5PR11MB2027namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d86a4ce1-1394-4b78-daf8-08d7007628b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2019 11:52:58.4399 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ketant@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1273
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ESnbIYfovAgb0S_1biBEkYcIgxc>
Subject: Re: [Idr] Some comments about the flags in draft-ietf-idr-te-lsp-distribution-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 12:07:07 -0000

Hi Jie,

Please check inline below for [KT].

From: Dongjie (Jimmy) <jie.dong@huawei.com>
Sent: 04 July 2019 16:58
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; draft-ietf-idr-te-lsp-distribution@ietf.org
Cc: idr@ietf.org
Subject: RE: Some comments about the flags in draft-ietf-idr-te-lsp-distribution-11

Hi Ketan,

Thanks for your reply, please see further inline with [Jie]:

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Wednesday, July 03, 2019 10:13 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; draft-ietf-idr-te-lsp-distribution@ietf.org<mailto:draft-ietf-idr-te-lsp-distribution@ietf.org>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: Some comments about the flags in draft-ietf-idr-te-lsp-distribution-11

+ IDR list

Hi Jie,

Please check inline below for responses.

From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Sent: 03 June 2019 08:26
To: draft-ietf-idr-te-lsp-distribution@ietf.org<mailto:draft-ietf-idr-te-lsp-distribution@ietf.org>
Subject: Some comments about the flags in draft-ietf-idr-te-lsp-distribution-11

Dear coauthors,

After reviewing the latest version of this draft, here are some comments about the description of the flags:


1)      6.1. SR Binding SID
*  S-Flag : Indicates the BSID value in use is specified or provisioned value when set and dynamically allocated value when clear.

o  Provisioned BSID: Optional field used to report the explicitly provisioned BSID value as indicated by the S-Flag being clear.
When the provisioned BSID is unavailable, there can be two cases, in the first case a dynamically allocated BSID is used, in another case a statically configured BSID is used.
[KT] Provisioned BSID indicates a statically configured (when using a mgmt. interface like CLI or Yang) or signaled (when using a protocol like PCEP or BGP-SRTE) value. The Provisioned BSID field never carries a dynamically allocated value. So we only have the second case you mention.

[Jie] Let me rephrase to clarify my comment: In section 6.1, the format of SR Binding SID TLV contains a BSID field and an optional provisioned BSID field. If my understanding is correct, the optional Provisioned BSID field is to carry the provisioned BSID when it is unavailable (and not in use) on the ingress node,
[KT] How about the following text for the Provisioned BSID field : “Optional field used to report the explicitly provisioned BSID value regardless of whether it is successfully allocated or not.”

in this case the BSID field would contain the BSID in use, which can be either dynamically allocated, or statically configured.
[KT] This is correct. The BSID field contains the “operational or allocated” BSID value. When BSID is provisioned, this may be same as the value in Provisioned BSID field provided that SID was successfully allocated on the headend.

If the BSID in use is dynamically allocated, the S-Flag should be clear, while if the BSID in use is statically configured on the device, the S-Flag should be set. This shows that the provisioned BSID can be unavailable and reported when the S-Flag is either set or clear.  Thus my suggestion is to remove “as indicated by the S-Flag being clear.”
[KT] Ack and I hope the propose text clarifies.

In both cases the Provisioned BSID needs to be reported using BGP-LS, which means the provisioned BSID needs to be reported regardless of the value of the S-flag. Thus it is suggested to remove “as indicated by the S-Flag being clear.”
[KT] The S-flag indicates whether the CP had a provisioned BSID value or not. I think it would be clearer if the text was “Optional field used to report the explicitly provisioned BSID value when the S-Flag is set.” We can fix this in the next version if you agree.



2)      6.2. SR Candidate Path State
      *  V-Flag : Indicates the CP has at least one valid SID-List when set.

In some cases a candidate path may not be verified, should the V-flag also be set?  The similar cases are described in the V-flag definition in 6.5 “SR Segment List” and 6.6 “SR Segment”, where the V-flag is set when the verification was not required.
[KT] You are right that a CP may not be verified. We have an E flag that indicates whether it has been verified or not in the first place. So the V flag comes into picture only if E is set. Otherwise, validation has not been done and hence V flag is not set.

Thus it is suggested to use the similar statement in the definition of V-flag of SR Candidate Path State: “Indicates the CP has at least one valid SID-List or its verification was not required when set and failed verification when clear.”
[KT] Does it help to indicate explicitly that the V flag should be clear when the CP has not been verified (i.e. when E flag is clear)?

These are minor changes to the description of Flags, while they can help to clarify the setting of the flags in different cases.
[KT] Agree. Please let know your views and we can accordingly update the text in the next update.

[Jie] Agree that V-flag makes sense only when E flag is set. It would be good to make this explicit in the next update. Thanks.
[KT] Ack – will add the following text to the V-Flag to indicate this “When the E-Flag is clear (i.e. the CP has not been evaluated), then this flag MUST be set to 0 by the originator and ignored by the receiver.”

Thanks,
Ketan

Best regards,
Jie

Thanks,
Ketan

Thoughts?

Best regards,
Jie