Mike,
We have published revision 09 addressing some comments we got during WGLC.
-Rishabh
On Mon, May 6, 2024 at 1:36 PM Michael McBride <
michael.mcbr...@futurewei.com> wrote:
> Thank you for the responses. We have consensus to progress this draft.
> Once authors update the draft I’ll shepherd
Andrew,
I will fix the nits in the next revision.
-> should "path" and "paths" be capitalized when in context of "Candidate
> path" ?. Related, some text has "candidate path" and others has "Candidate
> path".
>
>
>
I will make all occurrence consistent as "Candidate Path(s)"
>
> Section
I support this document as a co-author. It builds on top of RFC 9524 to
deploy P2MP trees in SR domain.
Looking for comments from PIM and SPRING WG members
Rishabh
On Sun, Apr 21, 2024 at 7:37 PM Michael McBride <
michael.mcbr...@futurewei.com> wrote:
> Hello good people,
>
>
>
> Today begins
Greg,
Some OAM considerations were added to the parent Replication Segment
document, now RFC 9524, in section 2.2.2 and Appendix A.2.1 during the WGLC
in SPRING.
-Rishabh
On Mon, Apr 22, 2024 at 12:25 AM Greg Mirsky wrote:
> Dear Authors,
> thank you for a well-written document that is a
Lars,
We have published revision 18 to address your request.
Please review,
-Rishabh
On Thu, Aug 24, 2023 at 7:45 AM Rishabh Parekh wrote:
> Yes. I can add some text clarifying this.
>
> On Thu, Aug 24, 2023 at 12:23 AM Lars Eggert wrote:
>
>> Hi,
>>
>> On A
Yes. I can add some text clarifying this.
On Thu, Aug 24, 2023 at 12:23 AM Lars Eggert wrote:
> Hi,
>
> On Aug 23, 2023, at 20:42, Rishabh Parekh wrote:
> > My point is this draft specifies behavior of a single replication
> segment which can be deployed for ingress replic
en update this one, allowing this option
and describing the details.
This is precisely why sharing of replication segment is out of scope of
this document.
Thanks,
-Rishabh
On Wed, Aug 23, 2023 at 2:59 AM Lars Eggert wrote:
> Hi,
>
> On Aug 11, 2023, at 21:40, Rishabh Parekh wrote:
Andrew,
We have added text addressing your DISCUSS concern in revision 17 of the
document.
Please take a look,
-Rishabh
On Tue, Aug 8, 2023 at 3:19 PM Rishabh Parekh wrote:
> Andrew,
>
> On Fri, Aug 4, 2023 at 4:25 AM Andrew Alston via Datatracker <
> nore...@ietf.org>
Lars,
Revision 17 addresses your concerns about loop prevention and other
comments.
Please take a look,
-Rishabh
On Fri, Aug 11, 2023 at 11:40 AM Rishabh Parekh wrote:
> Lars,
> Inline @ [RP2]
>
> Thanks,
> -Rishabh
>
> On Thu, Aug 10, 2023 at 12:54 AM Lars Eggert wrote:
R Replication segment for Multi-point Service
> Delivery
>Authors : Daniel Voyer (editor)
> Clarence Filsfils
> Rishabh Parekh
> Hooman Bidgoli
> Zhaohui Zhang
>Filename: draft
Lars,
Inline @ [RP2]
Thanks,
-Rishabh
On Thu, Aug 10, 2023 at 12:54 AM Lars Eggert wrote:
> Hi,
>
> On Aug 10, 2023, at 00:24, Rishabh Parekh wrote:
> > This document introduces packet replication functionality into SR
> > networks. This significantly increases and c
Erik,
Thanks for catching the typo. I will fix both in the next revision.
-Rishabh
On Thu, Aug 10, 2023 at 9:55 PM Erik Kline wrote:
> Rishabh,
>
> Thanks for the update. Some thoughts on draft-16:
>
> ### S2.2.1
>
> S01. If (Upper-Layer header type == 4(IPv4) OR
>
Lars,
Responses inline @ [RP]
On Fri, Aug 4, 2023 at 1:26 AM Lars Eggert via Datatracker
wrote:
> Lars Eggert has entered the following ballot position for
> draft-ietf-spring-sr-replication-segment-16: Discuss
>
>
> --
>
Andrew,
On Fri, Aug 4, 2023 at 4:25 AM Andrew Alston via Datatracker <
nore...@ietf.org> wrote:
> Andrew Alston has entered the following ballot position for
> draft-ietf-spring-sr-replication-segment-16: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email
V>
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *Rishabh Parekh
> *Date: *Monday, 31 July 2023 at 22:05
> *To: *Eric Vyncke
> *Cc: *The IESG , "
> draft-ietf-spring-sr-replication-segm...@ietf.org" <
> draft-ietf-spring-sr-replication-s
Andrew,
While I cannot solve all your concerns about SRv6 security in general, we
have added some text to about potential security implications (like DoS
attacks) for replication in the new revision of the draft.
I hope you can review the new text,
-Rishabh
On Wed, Jul 5, 2023 at 11:31 AM Andrew
Warren,
Though I cannot address SR in general, we have added some text about
possible DoS attacks in the Security section of the new revision of the
draft. I hope you can review it.
Thanks,
-Rishabh
On Wed, Jul 5, 2023 at 11:19 AM Warren Kumari via Datatracker <
nore...@ietf.org> wrote:
>
Roman,
We have expanded text in the Security section of the latest revision of the
draft. I hope that addresses your DISCUSS concerns.
Please review the latest revision,
-Rishabh
On Mon, Jul 10, 2023 at 11:35 AM Rishabh Parekh wrote:
> Roman,
> For your DISCUSS comment, can you
Erik,
I had responded earlier to your DISCUSS comments. I hope you have had a
chance to look at it.
The latest revision of draft addresses your other COMMENTS.
Please review,
-Rishabh
On Mon, Jul 10, 2023 at 11:30 AM Rishabh Parekh wrote:
> Erik,
> Thanks for the review. Comments inline
Robert,
Both of your comments have been addressed in latest revision of the draft,
-Rishabh
On Mon, Jul 10, 2023 at 10:08 AM Rishabh Parekh wrote:
> Rob,
> I will add a reference to the examples in Appendix in the Introduction and
> see if we can improve readability of text in Se
Eric,
I have addressed your comments and nits in latest revision of draft.
Thanks,
-Rishabh
On Fri, Jun 30, 2023 at 9:45 AM Rishabh Parekh wrote:
> Eric,
>
> Please find my responses below.
>
> Thanks,
> -Rishabh
>
> On Wed, Jun 28, 2023 at 2:17 AM Éric Vyncke
Clarence Filsfils
> Rishabh Parekh
> Hooman Bidgoli
> Zhaohui Zhang
>Filename: draft-ietf-spring-sr-replication-segment-16.txt
>Pages : 25
>Date: 2023-
Roman,
For your DISCUSS comment, can you please elaborate on what DoS risks are
you concerned about that we should add to the Security section document?
I will address your two COMMENT items in the next revision.
Thanks for your review,
-Rishabh
On Wed, Jul 5, 2023 at 7:28 PM Roman Danyliw via
Erik,
Thanks for the review. Comments inline @ [RP].
On Wed, Jul 5, 2023 at 6:24 PM Erik Kline via Datatracker
wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-spring-sr-replication-segment-15: Discuss
>
>
>
>
Mohit,
Thanks for your review. Comments inline @ [RP].
On Wed, Jul 5, 2023 at 10:58 AM Mohit Sethi via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Mohit Sethi
> Review result: Ready
>
> ..
>
> The security considerations section seems reasonable and I did not find any
> other issues
Rob,
I will add a reference to the examples in Appendix in the Introduction and
see if we can improve readability of text in Section 2.1.
Thanks,
Rishabh
On Wed, Jul 5, 2023 at 10:48 AM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:
> Robert Wilton has entered the following ballot
Eric,
Please find my responses below.
Thanks,
-Rishabh
On Wed, Jun 28, 2023 at 2:17 AM Éric Vyncke via Datatracker <
nore...@ietf.org> wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-spring-sr-replication-segment-15: No Objection
>
>
>
Sarah,
Thanks for the review.
Security sections of RFC 8402 and 8986 describe the trust model for SR
domain and filtering of packets at domain boundaries to prevent unwanted or
malicious injection of packets into a SR domain. The same apply to this new
SR behavior. I will add some text to the
Wesley,
Thanks for the review.
The Replication function is performed by nodes within an SR domain. The
trust model of SR with traffic filtering at SR domain boundaries applies to
this document and is covered by the first sentence referring to security
considerations of RFCs 8402, 8986 and 8754.
Thomas,
Thanks for the review. We will address your editorial comments in next
revision.
-Rishabh
On Fri, Jun 9, 2023 at 9:03 AM Thomas Fossati via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Thomas Fossati
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The
Jim,
Thanks for the comments. I will address the editorial comments below.
On Mon, May 22, 2023 at 6:54 AM James Guichard <
james.n.guich...@futurewei.com> wrote:
> Jim> Replication-ID is now defined twice; in the terminology section and
> in this section. If you want to keep the definition in
as mandated by Section 2
of RFC 8754
Thanks,
-Rishabh
On Tue, Feb 28, 2023 at 1:51 PM Rishabh Parekh wrote:
> Jim,
> Fine. Will add SRH TLV processing to pseudo-code in next revision.
>
> -Rishabh
>
> On Tue, Feb 28, 2023 at 1:49 PM James Guichard <
> james.n.guich...@futur
ally configured) I think is a worthwhile update.
>
>
>
> Jim
>
>
>
> *From:* Rishabh Parekh
> *Sent:* Tuesday, February 28, 2023 4:48 PM
> *To:* James Guichard
> *Cc:* SPRING WG List ; spring-cha...@ietf.org
> *Subject:* Re: WGLC for draft-ietf-spring-sr-replica
segment list in SRH under some circumstances
> - *[Jim] It would be helpful to provide an example of such a
> circumstance here.*
> - Section 2.2.2
> - the Leaf/Bud bud node which responds with an ICMPv6 Echo
> - *[Jim] remove “bud” ty
t;
>
>
> 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments may contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address i
elieve it would be helpful to add a sentence to clarity the
>> scope and offer the following text "Coordination regarding the absence or
>> presence and value of context information for replication leaves is outside
>> the scope of this document.".
>>
>>
>
regarding the absence or
> presence and value of context information for replication leaves is outside
> the scope of this document.".
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
>
>
> *From:* Rishabh Parekh
> *Sent:* Thursday, Febru
>
>
>
> [Jim] Section 4.3.1 of RFC 8754 would appear to agree with you but I
> welcome the WGs comments on this if there is disagreement.
>
>
>
> Jim
>
>
>
>
>
> *From:* James Guichard
> *Sent:* Thursday, February 16, 2023 9:08 AM
> *To:* Risha
James,
On Wed, Feb 15, 2023 at 8:05 AM James Guichard <
james.n.guich...@futurewei.com> wrote:
> Hi Jingrong & document authors,
>
>
>
> I would like for now to leave aside the issue of whether or not
> application/VPN specifics should be outside the scope of this SPRING
> document (I will
James,
Replies inline @ [RP]
On Wed, Feb 15, 2023 at 6:58 AM James Guichard <
james.n.guich...@futurewei.com> wrote:
> Hi Rishabh, Authors, & WG:
>
>
>
> Having reviewed the latest version of
> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
>
Thanks for the review Bruno. Responses inline @ [RP]
-Rishabh
On Fri, Feb 10, 2023 at 1:27 AM 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
Jingrong,
Your point [1] (Context SID in SRH), has already been discussed
back-and-forth a few times in this thread. Our solution is not wrong
technically. In SRv6 architecture, it is the function associated with a
local SID that determines how a packet, including any additional headers
like SRH,
Dhruv,
All of your suggestions make sense. I will incorporate them in the next
revision.
Thanks,
-Rishabh
On Tue, Jan 10, 2023 at 8:34 PM Dhruv Dhody wrote:
> Hi Rishabh,
>
> Thanks for your response, snipping...
>
> On Tue, Jan 10, 2023 at 11:14 PM Rishabh Parekh
>
Dhruv,
Thanks for the review. Comments inline @ [RP]
On Mon, Jan 2, 2023 at 10:00 PM Dhruv Dhody wrote:
>
> ## Major
> * For a standard track document, IMHO you need to clearly specify the size
> of Replication-ID.
>
>In simplest case, Replication-ID can be a 32-bit number, but it can
Xingrong,
Replies inline @ [RP2]
On Sat, Dec 17, 2022 at 1:34 AM Xiejingrong (Jingrong) wrote:
>
>
> Why SRv6 is broken in current proposal IMO:
>
> 1. PE1 allocate VPN SID 1/2/3 from its Locator for each MVPN (say MVPN
> 1/2/3) that want to share a single replication tree.
>
> 2. PE1
d above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
&
prompt and very encouraging response.
>
> Please see more inline below marked *[[Sasha]].*
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* Rishabh Parekh
> *Sent:* Sunday, December 11, 2022 9:04 PM
> *To:* Alexander Vainshtein
> *Cc:* draft-ietf-spring-sr-repli
Sasha,
Inline @ [RP]
On Sun, Dec 11, 2022 at 3:43 AM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:
> Hi all,
>
> More questions regarding the definition of the Replication State of a
> Replication Segment:
>
>
>
> The draft states that:
>
>
>
> If a Downstream Node is an egress
Huaimo,
The Replication Segment as defined in this draft, with Replication Node at
ingress of SR domain and downstream nodes at the egress of SR domain does
not need any state in core nodes.
-Rishabh
On Fri, Dec 9, 2022 at 1:53 PM Huaimo Chen
wrote:
> Hi Everyone,
>
> It seems that the
22 at 9:50 AM Shraddha Hegde wrote:
> Rishabh,
>
>
>
> Pls see inline..
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Rishabh Parekh
> *Sent:* Friday, December 9, 2022 10:50 PM
> *To:* Shraddha Hegde
> *Cc:* Xiejingrong (Jingrong) ;
>
Shraddha,
As I clarified to Jingron in an earlier email in this thread, this
restriction applies to Replication nodes, not to intermediate nodes on the
paths between upstream and downstream replication nodes. Even if two
replication nodes in an Anycast set or PeerSet have the same Replication
Jingrong,
For the second one regarding the SID after the replication SID, I still
> have some further question when considering it a “VPN SID”:
>
>
>
> In MPLS data plane, Is the SID an Upstream-assigned Label ? Or an SRGB
> label (though may be a more strictly unique number than SRGB that is a
>
Ines,
Please find my replies inline below @ [RP]
> 1- Requirements Language section should add RFC 8174, i.e. ""NOT
> RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted
> as
> described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear
> in all
>
Jingrong,
In section 2.1 and 2.2, it says “An Anycast SID or BGP PeerSID MUST NOT
appear in segment list preceding a Replication SID.”
I don’t know BGP PeerSID very well, but for anycast SID, I think it may be
useful and suitable to appear in seg list preceding a Replication SID.
Can you please
As a co-author, I am not aware of any undisclosed IPR for this draft.
On Mon, Nov 28, 2022 at 7:11 AM James Guichard <
james.n.guich...@futurewei.com> wrote:
> Dear WG:
>
>
>
> This email starts a 2-week Working Group Last Call for
>
Chairs,
We have published revision 10 of the draft with Implementation status
section as per WG policy,
-Rishabh
On Wed, Oct 19, 2022 at 8:18 AM James Guichard <
james.n.guich...@futurewei.com> wrote:
> Dear WG:
>
>
>
> Unfortunately the chairs timing on this WGLC overlooked the policy that we
ring/wiki.
>
> Yours,
>
> Joel
> On 7/27/2022 4:10 PM, Rishabh Parekh wrote:
>
> Joel,
> Maybe you missed my earlier email to the WG and chairs, but I did not see
> this draft on the WGLC queue during WG status update in today's session.
>
> -Rishabh
>
>
Joel,
Maybe you missed my earlier email to the WG and chairs, but I did not see
this draft on the WGLC queue during WG status update in today's session.
-Rishabh
On Thu, Jul 14, 2022 at 12:38 PM Rishabh Parekh wrote:
> We recently published rev 08 of
> https://datatracker.ietf.org/doc
We recently published rev 08 of
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/.
The authors believe the work is finished on this document and it should be
put on the WGLC queue.
Thanks,
-Rishabh
___
spring mailing list
defined many behaviors with the applicable flavors. That does not mean
RFC8986 defines multiple data planes!
I strongly support the WG adoption call.
Thanks,
Rishabh Parekh
On Fri, Oct 1, 2021 at 7:05 AM James Guichard <
james.n.guich...@futurewei.com> wrote:
> Dear WG:
>
>
>
>
; Cheers,
>
> Fan
>
>
>
> *发件人:* spring [mailto:spring-boun...@ietf.org] *代表 *Jeffrey (Zhaohui)
> Zhang
> *发送时间:* 2021年3月30日 5:06
> *收件人:* Yangfan (IP Standard) ; Gengxuesong
> (Geng Xuesong) ; 'Rishabh Parekh (riparekh)' <
> ripar...@cisco.com>; 'Arvind Venkat
ly
>
> *From:* Srcomp *On Behalf Of *Weiqiang Cheng
> *Sent:* Tuesday, March 2, 2021 12:28 AM
> *To:* 'Rishabh Parekh'
> *Cc:* src...@ietf.org; 'SPRING WG List'
> *Subject:* Re: [Srcomp] [spring] New drafts from SRCOMP design team
>
>
>
> *[External Email. Be ca
Weiqiang,
Text quoted below from the SPRING charter indirectly covers
Point-to-Multipoint requirement which is addressed by SR Replication
Segment draft
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
New types of segments mapping to forwarding behaviour (e.g., local
Weiqiang,
Text quoted below from the SPRING charter indirectly covers
Point-to-Multipoint requirement which is addressed by SR Replication
Segment draft
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ .
New types of segments mapping to forwarding behaviour (e.g., local
pkt24)R4(pkt47)R7
>
>
>
> And this is my assumption:
>
> Pkt12: (SA=R1, DA=R2_RepSID) (C-multicast pkt)
>
> Pkt23/Pkt36: (SA=R1, DA=R6_RepSID) (C-multicast pkt)
>
> Pkt24/Pkt47: (SA=R1, DA=R7_RepSID) (C-multicast pkt)
>
>
>
> Is that correc
Bruno,
Replies inline @ [RP]
> [Bruno] Agreed, in this specific case, you don't need the SID on the
> _packet_.
> - Still the PCE/configuration CLI/YANG need a way to identify this
> interface and it could be via a SID (e.g. both local adjacency SID and
> global nodes SID (assuming PHP) seems
Jingrong,
Replies inline.
1) About the distinction of Replication-ID and Replication-SID, and
> their usage.
>
> If there is an SID block specially reserved for the P2MP Transport on each
> of the Replication Node, and such SID block (on each Replication Node) is
> advertised through
tion SID respectively.
>
>
>
> The Replication Node R3 receives the packet { Replication SID, (VPN
> Label, IPv4/IPv6 C-multicast packet) }.
>
>
>
> The Replication Node R4 receives the packet { Replication SID, (VPN
> Label, IPv4/IPv6 C-multicast packet) }.
>
&g
e new draft-ietf-pim-sr-p2mp-policy until
> they give us the green light."
> >
> > Does this answer your question?
> >
> > --Bruno
> >
> > > Thanks!
> > > Dhruv
> > >
> > > [1]
> > > https://clicktime.symantec.com/36sx
Bruno,
Replies inline
> ---
>
> "A SR Replication segment allows a packet to be replicated from a replication
> node to downstream nodes."
>
> May be adding "Each downstream node is reached by using a unicast segment or
> SR policy."
>
> (otherwise, the building of a multicast tree seem
!
> > Dhruv
> >
> > [1] https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
> > [2]
> > https://mailarchive.ietf.org/arch/msg/pim/YyF7I02aaRtpZngf7uTno69IB90/
> >
> >
> >
> > On Thu, Jul 2, 2020 at 12:05 PM Rishabh Parekh
> > w
ith the new, post
> replication/branching path that is imposed on top of existing label stack, so
> service label ( + optionally more transport labels) are preserved.
>
> Cheers,
> Jeff
> On Jul 1, 2020, 12:40 PM -0700, Rishabh Parekh , wrote:
>
> Robert,
>
> A) Fir
iminate the possibility of building MDTs with more than one level using
>> Replication Segments.
>>
>> Which is probably not the intent of the draft.
>>
>> My 2c.
>>
>> Get Outlook for Android
>>
>> ____
>> From
Robert,
>A) Firmly state that replication SID MUST be the last one on the stack
>B) Instead of real SID after the replication SID provide a binding SID which
>locally will be mapped to a different SID list imposed to each replicated flow.
We would be fine with A), but we don't want to exclude
domain have the same SRGB base?
>
> And, BTW, how is R-SID-1 encoded in the SRH in the case of SRv6?
>
> My 2c,
> Sasha
>
>
>
>
>
> Get Outlook for Android
>
>
> From: spring on behalf of Joel Halpern Direct
>
>
ication segments is not, in my personal view, enough clarity or
> value to be adopted as a working group document.
>
> Yours,
> Joel
>
> On 7/1/2020 12:06 PM, Rishabh Parekh wrote:
> > Joel,
> > Your request was not "lost", but it fell between the crack
Huaimo,
Responses inline below.
On Tue, Jun 30, 2020 at 7:46 AM Huaimo Chen wrote:
>
> Hi Authors,
>
> I have a few of questions.
>
> Should a replication-segment be generalized to be a special SID (say a
> multicast SID allocated from a multicast SID block)?
,
[RP] This is a good
Joel,
Your request was not "lost", but it fell between the cracks :)
Anyway, responses inline.
On Mon, Jun 29, 2020 at 3:17 PM Joel M. Halpern wrote:
>
> I asked the authors a version of this question, but apparently my
> request got lost.
>
> For now, this is speaking as an individual. And I
Support as co-author.
-Rishabh
On Mon, Jun 22, 2020 at 7:46 AM wrote:
>
> Hi SPRING WG,
>
> Authors of draft-voyer-spring-sr-replication-segment [1] have asked for WG
> adoption.
>
> Please indicate your support, comments, or objection, for adopting this draft
> as a working group item by
del.
>
> I am guessing BIER maybe an option?
>
> Any other options for operators?
>
> Kind regards
>
> Gyan
>
> On Sat, Mar 21, 2020 at 1:49 PM Rishabh Parekh wrote:
>>
>> Gyan,
>> These questions are implementation specific and should be addressed
>
Chairs,
IPR Poll finished about 3 months ago. When can we expect WG adoption
poll for this draft?
Thanks,
-Rishabh
On Mon, Dec 23, 2019 at 5:40 PM Pengshuping (Peng Shuping)
wrote:
>
> Dear Chairs, all,
>
>
>
> We have received IPR confirmations from all authors and contributors of this
>
Gyan,
These questions are implementation specific and should be addressed
off the mailing list. Please contact me at ripar...@cisco.com.
-Rishabh
On Fri, Mar 20, 2020 at 6:41 PM Gyan Mishra wrote:
>
>
> Daniel & Authors
>
> I had a question related to the draft related to lab POC testing.
>
>
Shuping,
Jeffrey Zhang has also replied on 13th Nov.
https://mailarchive.ietf.org/arch/msg/spring/bxoZuvyAY7X_roxnOULvqc1Dd-Q
-Rishabh
On Thu, Dec 19, 2019 at 7:52 PM Pengshuping (Peng Shuping)
wrote:
>
> Hi all,
>
>
>
> A reminder for this IPR Poll.
>
>
>
> The missing authors: R. Parekh, Z.
Shuping,
I had replied on 13th Nov.
https://mailarchive.ietf.org/arch/msg/spring/1Bi0X0AQgvdRFcFyoubQla7Vjto
-Rishabh Parekh
On Thu, Dec 19, 2019 at 7:52 PM Pengshuping (Peng Shuping)
wrote:
>
> Hi all,
>
>
>
> A reminder for this IPR Poll.
>
>
>
> The missin
Jingrong,
You must have read a completely different document.
>You confirmed “Also the SPRING WG is not really chartered nor have the
>expertise to define a specification creating a multicast tree”
>But the updated document seems to create a multicast tree. As above, “stitch
>multiple
I, as an author, am not aware of any IPR related to this draft.
Thanks,
Rishabh
From: bruno.decra...@orange.com
Sent: Tuesday, November 12, 2019 9:04 AM
To: draft-voyer-spring-sr-replication-segm...@ietf.org
Cc: spring
Subject: IPR Poll: draft-voyer-spring-sr-replication-segment
Hi Authors,
We would like to present the following draft. It replaces
draft-voyer-spring-sr-p2mp-policy-03
- draft-voyer-spring-sr-replication-segment-00
(https://datatracker.ietf.org/doc/draft-voyer-spring-sr-replication-segment)
- Speaker: Zafar Ali
- Time: 10 mins
Thanks,
-Rishabh
On Wed, Oct
the
CONTINUE/NEXT semantic at the same time. A node could be a “bud node” – a leaf
and a replication node at the same time. This is unique to multicast.
Jeffrey
From: Alexander Vainshtein
mailto:alexander.vainsht...@ecitele.com>>
Sent: Thursday, October 24, 2019 5:40 AM
To: Rishabh Parekh (ri
2.1 of the P2MP policy draft.
-Rishabh
From: Alexander Vainshtein
Sent: Tuesday, October 22, 2019 7:30 AM
To: Rishabh Parekh (riparekh)
Cc: spring@ietf.org; Clarence Filsfils (cfilsfil) ;
hooman.bidg...@nokia.com; zzh...@juniper.net; daniel.vo...@bell.ca
Subject: RE: Some questions regarding
shtein
Sent: Wednesday, October 16, 2019 10:26 PM
To: Rishabh Parekh (riparekh)
Cc: spring@ietf.org; Clarence Filsfils (cfilsfil) ;
hooman.bidg...@nokia.com; zzh...@juniper.net; daniel.vo...@bell.ca
Subject: RE: Some questions regarding Replication SID
Re-sending with corrected To and CC li
ce Replication SID is local to a Node, the Replication SID of the
Replication segment at Root (or Headend) node can be used as a (constant)
Binding SID to steer traffic into the segment.
-Rishabh
From: Alexander Vainshtein
Sent: Tuesday, October 15, 2019 6:31 AM
To: daniel.vo...@bell.ca; Clarence Fils
91 matches
Mail list logo
