As per the mail below, a new version has been posted: https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05
On Mon, Nov 12, 2018 at 1:24 PM Przemyslaw Krol <pkrol= [email protected]> wrote: > 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]>; >> [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] <[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 >> >> <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 >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
