Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Ketan Talaulikar <[e-mail]>]

Hi Bruno/All,

This is a short note to update that the v01 with the changes
discussed/agreed in this thread has been posted.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-srv6-args-01

Thanks,
Ketan (on behalf of co-authors)



On Wed, Oct 25, 2023 at 5:25 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Bruno,
>
> Thanks for confirming. These changes will be included in the v01 of the
> draft.
>
> Thanks,
> Ketan
>
>
> On Tue, Oct 24, 2023 at 6:13 PM <[e-mail]> wrote:
>
>> Hi Ketan,
>>
>>
>>
>> Thanks for your reply.
>>
>>
>>
>> Your proposed changes look good to me.
>>
>>
>>
>> Thanks for this.
>>
>>
>>
>> --Bruno
>>
>>
>>
>> *From:* Ketan Talaulikar <[e-mail]>
>> *Sent:* Monday, October 23, 2023 1:06 PM
>> *To:* DECRAENE Bruno INNOV/NET <[e-mail]>
>> *Cc:* Matthew Bocci (Nokia) <[e-mail]>;
>> [e-mail]; [e-mail]
>> *Subject:* Re: WG adoption and IPR poll for
>> draft-trr-bess-bgp-srv6-args-02
>>
>>
>>
>> Hi Bruno,
>>
>>
>>
>> Thanks for your support and comments. Please check inline below for
>> response.
>>
>>
>>
>> On Wed, Oct 11, 2023 at 7:51 PM <[e-mail]> wrote:
>>
>> I support adoption : clarifying spec and improving interop is important.
>>
>>
>>
>> Thank you for section 4 regarding Backward Compatibility.
>>
>> May be 1 comment although I didn’t take time to read everything in
>> details and I’m not familiar with EVPN.
>>
>>
>>
>> It’s not completely clear to me whether backward compatibility MAY be
>> preserved or MUST be preserved.
>>
>> Unless there is a good technical reason, my preference would be for “MUST
>> be preserved”.
>>
>> e.g.
>>
>> §4
>>
>> OLD: Backward compatibility with implementations doing the bitwise
>>
>>    logical-OR operation can be preserved by the advertisement of SIDs
>>
>>
>>
>> NEW: Backward compatibility with implementations doing the bitwise
>>
>>    logical-OR operation is preserved thanks to the advertisement of SIDs
>>
>>
>>
>>
>>
>> KT> Ack. We will incorporate this change in the next version.
>>
>>
>>
>> §3.1
>>
>> OLD:
>>
>> it is
>>
>>    REQUIRED that proper LBL, LNL, and FL values be set corresponding to
>>
>>    the supported SID Structure for the End.DT2M SRv6 Service SIDs.
>>
>>
>>
>> KT> In this context, the "proper" values are the same values as signaled
>> via the SID Structure for the End.DT2M SID. Would the following work?
>>
>>
>>
>> NEW:
>>
>> it is
>>
>> REQUIRED that the LBL, LNL, and FL values be set as indicated via
>>
>> the SID Structure for the End.DT2M SRv6 Service SIDs.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Given that this is already the second spec to clarify this, may be
>> “proper [..] value” could be expanded so as to specify the precise behavior
>> which is REQUIRED.
>>
>>
>>
>> Probably similar comment for §3.2 (“The LBL, LNL, and FL MUST be set to appropriate values”).
>>
>>
>>
>> KT> Perhaps the word "appropriate" is redundant here ... would removing
>> it help?
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Regards,
>>
>> --Bruno
>>
>>
>>
>>
>>
>> Orange Restricted
>>
>>
>>
>> Orange Restricted
>>
>> *From:* BESS <[e-mail]> *On Behalf Of *Matthew Bocci (Nokia)
>> *Sent:* Thursday, September 28, 2023 4:49 PM
>> *To:* [e-mail]
>> *Cc:* [e-mail]
>> *Subject:* [bess] WG adoption and IPR poll for
>> draft-trr-bess-bgp-srv6-args-02
>>
>>
>>
>> This email begins a two-week WG adoption and IPR poll for
>> draft-trr-bess-bgp-srv6-args-02 [1].
>>
>>
>>
>> Please review the draft and post any comments to the BESS working group
>> list.
>>
>>
>>
>> We are also polling for knowledge of any undisclosed IPR that applies to
>> this document, to ensure that IPR has been disclosed in compliance with
>> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>>
>> If you are listed as an author or a contributor of this document, please
>> respond to this email and indicate whether or not you are aware of any
>> relevant undisclosed IPR, copying the BESS mailing list. The document will
>> not progress without answers from all the authors and contributors.
>>
>> Currently, there is currently no IPR disclosure against this document.
>>
>>
>>
>> If you are not listed as an author or a contributor, then please
>> explicitly respond to the IPR poll only if you are aware of any IPR that
>> has not yet been disclosed in conformance with IETF rules.
>>
>>
>>
>> This poll for adoption closes on Thursday 12th October 2023.
>>
>>
>>
>> [1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP
>> Services (ietf.org)
>> <https://datatracker.ietf.org/doc/draft-trr-bess-bgp-srv6-args/>
>>
>> ____________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>>
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>
>> they should not be distributed, used or copied without authorisation.
>>
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>
>> Thank you.
>>
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>>