Thanks for clarification. pk
On Mon, Nov 12, 2018 at 1:20 PM Shyam Sethuram (shsethur) < [email protected]> wrote: > 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]> 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]> 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]> *On Behalf Of *Przemyslaw Krol > *Sent:* 24 October 2018 23:35 > *To:* [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] > > > > > > > -- > > Przemyslaw "PK" Krol | > > Strategic Network Engineer > > ing | [email protected] > > > > > -- > > Przemyslaw "PK" Krol | > > Strategic Network Engineer > > ing | [email protected] > > > -- Przemyslaw "PK" Krol | Strategic Network Engineer ing | [email protected]
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
