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

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Jie,

I think that perhaps in the quest of encoding efficiency we may be making things more complex with all the flag and field combinations. Can you please let know your views on the attached proposal? Basically going back to what you suggested originally – removing the S flag and not making the Provisional BSID field optional.

Thanks,
Ketan

From: Dongjie (Jimmy) <[e-mail]>
Sent: 05 July 2019 14:51
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: Some comments about the flags in draft-ietf-idr-te-lsp-distribution-11

Hi Ketan,

It is good that we are converging on most of the comments.

Just one minor suggestion inline with [Jie].

From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
Sent: Thursday, July 04, 2019 7:53 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Some comments about the flags in draft-ietf-idr-te-lsp-distribution-11

Hi Jie,

Please check inline below for [KT].

From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: 04 July 2019 16:58
To: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Wednesday, July 03, 2019 10:13 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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) <[e-mail]<mailto:[e-mail]>>
Sent: 03 June 2019 08:26
To: [e-mail]<mailto:[e-mail]>
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.”

[Jie] This looks much better, and please see my below suggestion for potential encoding optimization when the provisioned BSID value is allocated successfully.

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.

[Jie] When the provisioned BSID value is successfully allocated and used by the headend, the TLV encoding could be more efficient by carrying this BSID value only in the BSID field, in this case the U flag could be clear to indicate that the provisioned BSID value is available and the optional Provisioned BSID is not present in the TLV.

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.”

[Jie] This text looks good to me.

Best regards,
Jie

Thanks,
Ketan

Best regards,
Jie

Thanks,
Ketan

Thoughts?

Best regards,
Jie