Re: [spring] draft-previdi-idr-segment-routing-te-policy

Howdy,

Thank you for sorting this out.

pk

On Wed, Nov 21, 2018 at 9:44 AM Shyam Sethuram <shyam.ioml@gmail.com> wrote:

> 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=
> 40google.com@dmarc.ietf.org> wrote:
>
>> Thanks for clarification.
>>
>> pk
>>
>> On Mon, Nov 12, 2018 at 1:20 PM Shyam Sethuram (shsethur) <
>> shsethur@cisco.com> 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 <pkrol@google.com>
>>> *Sent:* Monday, November 12, 2018 1:04 PM
>>> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
>>> *Cc:* spring@ietf...org <spring@ietf.org>;
>>> draft-ietf-idr-segment-routing-te-policy@ietf.org; Shyam Sethuram
>>> (shsethur) <shsethur@cisco.com>; Swadesh Agrawal (swaagraw) <
>>> swaagraw@cisco.com>; draft-ietf-spring-segment-routing-policy@ietf.org
>>> *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 <pkrol@google.com>
>>> 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) <
>>> ketant@cisco.com> wrote:
>>>
>>> Hi PK,
>>>
>>>
>>>
>>> Thanks for your review and including the BGP draft authors to keep them
>>> posted.
>>>
>>>
>>>
>>> Please check inline below.
>>>
>>>
>>>
>>> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Przemyslaw Krol
>>> *Sent:* 24 October 2018 23:35
>>> *To:* spring@ietf...org <spring@ietf.org>
>>> *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 | pkrol@google.com
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Przemyslaw "PK" Krol |
>>>
>>>  Strategic Network Engineer
>>>
>>> ing | pkrol@google.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Przemyslaw "PK" Krol |
>>>
>>>  Strategic Network Engineer
>>>
>>> ing | pkrol@google.com
>>>
>>>
>>>
>>
>>
>> --
>> Przemyslaw "PK" Krol |  Strategic Network Engineer ing | pkrol@google.com
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>

-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | pkrol@google.com

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