Hi PK, Sorry for the delay. We'll soon publish an update to fix the BSID Flags order and clarify the Segment V-Flag. Thanks for pointing.
The BSID Flags would be as follows: Bit 0 : S-Flag Bit 1 : I-Flag thanks≪shyam From: Przemyslaw Krol <[email protected]> Sent: Monday, November 12, 2018 1:04 PM To: Ketan Talaulikar (ketant) <[email protected]> Cc: [email protected]; [email protected]; Shyam Sethuram (shsethur) <[email protected]>; Swadesh Agrawal (swaagraw) <[email protected]>; [email protected] Subject: Re: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency Hi Ketan, Did you manage to confirm bit ordering for the flag? thanks, pk On Thu, Oct 25, 2018 at 7:50 AM Przemyslaw Krol <[email protected]<mailto:[email protected]>> wrote: Hi Ketan, Thanks for the reply. [KT] Thanks for catching that it looks like perhaps the IANA section needs to be updated to reflect the ordering in the main section text. [PK] Great, thanks for that. Is it safe to assume the ordering in 2.4.2 (instead of 8.5) to be final then? Normally, only the path resolution is needed to be performed and that too for the first SID. The “V” flag may be used to indicate to the headend to perform the verification. When the SID is of type 1 or 2 then it is only about checking the path resolution (reachability) for it. When the SID is of type 3-through-11 then it would be about first resolving to get the SID value and then doing its path resolution. Perhaps this text in the SR Policy Architecture draft could clarify this further (if needed) and we use “SID verification” term in the BGP draft for alignment of terminologies. [PK] I reckon even pointing to draft-ietf-idr-segment-routing-te-policy in the context of SID verification would make the meaning of V-flag much more obvious. Anyhow, this is just a suggestion as it's been signaled to me that it's not easy to make that association. thanks, On Wed, Oct 24, 2018 at 8:26 PM Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>> wrote: Hi PK, Thanks for your review and including the BGP draft authors to keep them posted. Please check inline below. From: spring <[email protected]<mailto:[email protected]>> On Behalf Of Przemyslaw Krol Sent: 24 October 2018 23:35 To: [email protected]<mailto:[email protected]> Subject: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency Authors, There seems to be a discrepancy in BSID flag ordering: https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04#section-2.4.2 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|I| | +-+-+-+-+-+-+-+-+ https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04#section-8.5 Bit Description Reference --------------------------------------------------------------------------------- 0 Drop Upon Invalid Flag (I-Flag) This document 1 Specified-BSID-Only Flag (S-Flag) This document Would it be possible to clarify this please? [KT] Thanks for catching that it looks like perhaps the IANA section needs to be updated to reflect the ordering in the main section text. Also, draft mentions "V-flag: Segment Verification Flag": V-Flag: This flag encodes the "Segment Verification" behavior. It is used by SRPM as described in section 5 in [I-D.ietf-spring-segment-routing-policy]. Yet its meaning doesn't look to be clearly described in either drafts. [KT] I believe this is referring to the following text in Sec 5.1 of the draft-ietf-spring-segment-routing-policy. o It is empty. o Its weight is 0. o The headend is unable to perform path resolution for the first SID into one or more outgoing interface(s) and next-hop(s). o The headend is unable to perform SID resolution for any non-first SID of type 3-through-11 into an MPLS label or an SRv6 SID. o The headend verification fails for any SID for which verification has been explicitly requested. "Unable to perform path resolution" means that the headend has no path to the SID in its SR database. SID verification is performed when the headend is explicitly requested to verify SID(s) by the controller via the signaling protocol used. Normally, only the path resolution is needed to be performed and that too for the first SID. The “V” flag may be used to indicate to the headend to perform the verification. When the SID is of type 1 or 2 then it is only about checking the path resolution (reachability) for it. When the SID is of type 3-through-11 then it would be about first resolving to get the SID value and then doing its path resolution. Perhaps this text in the SR Policy Architecture draft could clarify this further (if needed) and we use “SID verification” term in the BGP draft for alignment of terminologies. Thanks, Ketan thanks, pk -- Przemyslaw "PK" Krol | Strategic Network Engineer ing | [email protected]<mailto:[email protected]> -- Przemyslaw "PK" Krol | Strategic Network Engineer ing | [email protected]<mailto:[email protected]> -- Przemyslaw "PK" Krol | Strategic Network Engineer ing | [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
