Thanks for the review Bruno. Responses inline @ [RP]
-Rishabh
On Fri, Feb 10, 2023 at 1:27 AM <bruno.decra...@orange.com> wrote:
> Hi Rishabh, authors
>
>
>
> Speaking as an individual contributor.
>
> Following a request, I've done a review of the latest version of the draft.
>
> Please find below some proposed comments.
>
>
>
> --
>
> As a general comment, may be this draft could be better restricted to the
> SR-replication segment itself, leaving any application/VPN specifics
> outside the scope of this SPRING document. This may help with the
> resolution of some WGLC comments.
>
[RP] The VPN text was introduced when we were asked to add some
description of which SIDs are allowed before and after the Replication SID.
Let me see if we can re-word the text so VPN details are kept out of scope.
>
>
> --
>
> Ideally, SR Replication and SRv6 compression would be orthogonal hence
> SRv6 compression would not need to be referenced, not to mention
> recommended ("SHOULD use a Compressed SID (C-SID) container with Downstream
> Replication SID as the Last uSID"). If you chose to keep recommending or
> even proposing uSID, you would need a normative reference to the SRv6
> compression document, which may delay the RFC publication of this document.
> Also, depending on your choices, a uSID End.Replicate Endpoint behavior may
> be needed to be allocated by the IANA.
>
[RP] On further thought I agree, the Replication SID would work
identically with or without compression. I shall remove the compression
text.
>
>
> --
>
> In general, there are two replication SIDs/nodes: the one instantiating
> the replication SID and the downstream one.
>
> In order to help the reader, making this explicit in some sentences could
> be useful. e.g.
>
>
>
> §2.1 SR-MPLS
>
>
>
> OLD: There MAY be SIDs preceding the SR-MPLS Replication SID
>
> NEW: SIDs MAY be added before the downstream SR-MPLS Replication SID
>
[RP] Will do.
>
>
> --
>
> For the SRv6 dataplane, as the IPv6 destination address is modified en
> route, there seem to be some impact for the ICMP ping checksum.
>
> cf
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-03#section-10.2
>
> Probably, it would be useful to cover this in the document.
>
[RP] Will take a look and see what we can cover.
>
>
> Hope this helps.
>
> Regards,
>
> --Bruno
>
>
>
>
>
> Orange Restricted
>
> *From:* spring <spring-boun...@ietf.org> *On Behalf Of *James Guichard
> *Sent:* Tuesday, January 10, 2023 5:04 PM
> *To:* SPRING WG <spring@ietf.org>
> *Cc:* spring-cha...@ietf.org
> *Subject:* Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
>
>
>
> Hi WG:
>
>
>
> Just a quick update on the status of this WGLC. The authors are working on
> the various comments received so far on the list and will also most likely
> publish a new version of the document once all comments have been
> addressed. For this reason the chairs will keep this WGLC open until those
> actions have taken place and commenters have confirmed that their comments
> have been addressed.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> *From:* James Guichard
> *Sent:* Monday, November 28, 2022 10:10 AM
> *To:* SPRING WG <spring@ietf.org>
> *Cc:* spring-cha...@ietf.org
> *Subject:* WGLC for draft-ietf-spring-sr-replication-segment
>
>
>
> Dear WG:
>
>
>
> This email starts a 2-week Working Group Last Call for
> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
>
>
>
> Please read the updated document if you haven’t already and send your
> comments to the SPRING WG list no later than December 12th 2022.
>
>
>
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
>
>
>
> Lastly, if you are an author or contributor please respond to indicate
> whether you know of any undisclosed IPR related to this document.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
