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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 04 July 2019 11:28 UTC

Return-Path: <jie.dong@huawei.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 06A16120048; Thu, 4 Jul 2019 04:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jwAbX_ffx_BI; Thu, 4 Jul 2019 04:28:13 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B013012003F; Thu, 4 Jul 2019 04:28:12 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1C5514A2EADE02EFB192; Thu, 4 Jul 2019 12:28:11 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Jul 2019 12:28:10 +0100
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Thu, 4 Jul 2019 19:28:04 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.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: AdUZtXNNpFwWiZR2SGe57tDeoqrMCwX8hpJAACRcxaA=
Date: Thu, 4 Jul 2019 11:28:04 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927CCEE1590@NKGEML515-MBS.china.huawei.com>
References: <76CD132C3ADEF848BD84D028D243C927CCE11BEC@NKGEML515-MBX.china.huawei.com> <DM5PR11MB2027C8332D6B5B3DFE5B3A20C1FB0@DM5PR11MB2027.namprd11.prod.outlook.com>
In-Reply-To: <DM5PR11MB2027C8332D6B5B3DFE5B3A20C1FB0@DM5PR11MB2027.namprd11.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.151.75]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927CCEE1590NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qPf0cUjgxu0E3ilW-M7kL-JRiyg>
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 11:28:15 -0000

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>om>; 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

+ 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, in this case the BSID field would contain the BSID in use, which can be either dynamically allocated, or statically configured. 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.”

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.

Best regards,
Jie

Thanks,
Ketan

Thoughts?

Best regards,
Jie