Subject: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency

From: Przemyslaw Krol <[email-masked]>
Date: Wed, 24 Oct 2018 11:05:20 -0700

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?

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.

thanks,
pk

-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [email-masked]

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 25 Oct 2018 03:26:08 +0000

Hi PK,

Thanks for your review and including the BGP draft authors to keep them posted.

Please check inline below.

From: spring <[email-masked]> On Behalf Of Przemyslaw Krol
Sent: 24 October 2018 23:35
To: [email-masked]
Subject: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency

Authors,

   0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |S|I|           |
   +-+-+-+-+-+-+-+-+

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.

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-masked]<mailto:[email-masked]>

---

From: Przemyslaw Krol <[email-masked]>
Date: Thu, 25 Oct 2018 07:50:14 -0700

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-masked]>
wrote:

> *From:* spring <[email-masked]> *On Behalf Of *Przemyslaw Krol
> *Sent:* 24 October 2018 23:35
> *To:* [email-masked]
> *Subject:* [spring] draft-previdi-idr-segment-routing-te-policy - BSID
> flag inconsistency
>
>
>
> Authors,
>
>
>
> *[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.*
>
>
>
> *[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 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.*
>
>
>
>    *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 |
>
> ing | [email-masked]