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

From: Przemyslaw Krol <[email-masked]>
Date: Mon, 12 Nov 2018 13:04:02 -0800

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-masked]> 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-masked]> wrote:
>
>> 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,
>>
>>
>>
>> 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-masked]
>>
>>
>>
>
>
> --
> Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [email-masked]
>

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

---

From: "Shyam Sethuram (shsethur)" <[email-masked]>
Date: Mon, 12 Nov 2018 21:20:18 +0000

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-masked]>
Sent: Monday, November 12, 2018 1:04 PM
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; [email-masked]; Shyam Sethuram (shsethur) <[email-masked]>; Swadesh Agrawal (swaagraw) <[email-masked]>; [email-masked]
Subject: Re: [spring] draft-previdi-idr-segment-routing-te-policy - BSID flag inconsistency

Hi Ketan,

thanks,
pk

On Thu, Oct 25, 2018 at 7:50 AM Przemyslaw Krol <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:
Hi PK,

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

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Przemyslaw Krol
Sent: 24 October 2018 23:35
To: [email-masked]<mailto:[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.

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

--
Przemyslaw "PK" Krol |

ing | [email-masked]<mailto:[email-masked]>

--
Przemyslaw "PK" Krol |

ing | [email-masked]<mailto:[email-masked]>

---

From: Przemyslaw Krol <[email-masked]>
Date: Mon, 12 Nov 2018 13:23:26 -0800

Thanks for clarification.

pk

On Mon, Nov 12, 2018 at 1:20 PM Shyam Sethuram (shsethur) <
[email-masked]> wrote:

> *From:* Przemyslaw Krol <[email-masked]>
> *Sent:* Monday, November 12, 2018 1:04 PM
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> Shyam Sethuram (shsethur) <[email-masked]>; Swadesh Agrawal
> (swaagraw) <[email-masked]>;
> [email-masked]
> *Subject:* Re: [spring] draft-previdi-idr-segment-routing-te-policy -
> BSID flag inconsistency
>
>
>
> Hi Ketan,
>
>
>

---

From: Shyam Sethuram <[email-masked]>
Date: Wed, 21 Nov 2018 09:44:11 -0800

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

>> *Cc:* spring@ietf..org <[email-masked]>;
>> [email-masked]; Shyam Sethuram
>> (shsethur) <[email-masked]>; Swadesh Agrawal (swaagraw) <
>> [email-masked]>; [email-masked]
>> [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,
>>
>>
>>
>> *To:* spring@ietf..org <[email-masked]>
>> 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>
>>
>>
>> *   protocol used*..
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Przemyslaw Krol <[email-masked]>
Date: Wed, 21 Nov 2018 09:53:34 -0800

Howdy,

Thank you for sorting this out.

pk

On Wed, Nov 21, 2018 at 9:44 AM Shyam Sethuram <[email-masked]> wrote:

>>> *Cc:* spring@ietf...org <[email-masked]>;
>>> *To:* spring@ietf...org <[email-masked]>
>>> https://tools...ietf.org/html/draft-ietf-idr-segment-routing-te-policy-04#section-8.5
>>>
>>> *[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.
>>>
>>> *   protocol used*...