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]
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
