the sender by phone or email immediately and
delete it!
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, March 9, 2023 10:47 AM
To: Xiejingrong (Jingrong) ; Gengxuesong (Geng Xuesong)
Subject: New Version Notification for draft-xie-s
Hi Guozhen and authors,
Thanks for introducing your I-D.
I have read this I-D roughly, and noticed the following description in section
3:
When a new IPv6 packet arrives at PE2, PE2 parses its Locator part.
If it matches the IPv6 mapping prefix instantiated by itself, it
decapsulates
immediately and
delete it!
From: Rishabh Parekh [mailto:risha...@gmail.com]
Sent: Wednesday, March 1, 2023 5:38 AM
To: Xiejingrong (Jingrong)
Cc: SPRING WG List ; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
Jingrong,
Your suggestion, especially
mp; Bruno
From: Rishabh Parekh mailto:risha...@gmail.com>>
Sent: Thursday, February 16, 2023 12:37 AM
To: James Guichard
mailto:james.n.guich...@futurewei.com>>
Cc: Xiejingrong (Jingrong)
mailto:40huawei@dmarc.ietf.org>>;
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com
Guichard [mailto:james.n.guich...@futurewei.com]
Sent: Monday, February 20, 2023 11:30 PM
To: Xiejingrong (Jingrong) ; Joel Halpern
; bruno.decra...@orange.com
Cc: SPRING WG ; spring-cha...@ietf.org
Subject: RE: [spring] WGLC for draft-ietf-spring-sr-replication-segment
Hi Jingrong,
Please see inline
Hi Joel, and the WG chairs,
As I commented in previous mail [B], the authors are trying the best to find
some scattered pieces of sentences, sometimes from RFC8754, and sometimes from
RFC8986 or RFC9256, to argue that the “VPN SID after Replication SID” is a
valid solution.
As an example,
Hi Jim, and WG chairs:
For Jim’s comment: ”[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.”
I think the sentence “Future documents may define additional SRv6 SIDs. In such
a case, the entire content of this section
Hi Authors,
Do you have a timeline in mind to address my questions in the following [1] [3]
[4] [8b] that are still pending before you write a new Pseudo-code ?
[1] https://mailarchive.ietf.org/arch/msg/spring/659RqpS2eOabwBpist6iH6nGgrw/
[2]
other than the intended recipient(s) is prohibited. If you receive this
e-mail in error, please notify the sender by phone or email immediately and
delete it!
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Xiejingrong
(Jingrong)
Sent: Thursday, February 16, 2023 3:47 PM
To: James
.@ietf.org] On Behalf Of James Guichard
Sent: Thursday, February 16, 2023 12:05 AM
To: Xiejingrong (Jingrong) ;
bruno.decra...@orange.com; Rishabh Parekh
Cc: SPRING WG
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
Hi Jingrong & document authors,
I would like fo
Hi WG,
I don’t agree with Bruno’s point that “this draft could be better restricted to
the SR-replication segment itself, leaving any application/VPN specifics
outside the scope of this SPRING document”.
As I commented in [8] to the same point, the backing solution of this document
is tightly
the sender by phone or email immediately and
delete it!
From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Tuesday, January 24, 2023 2:06 PM
To: Xiejingrong (Jingrong)
Cc: James Guichard ; Rishabh Parekh
; SPRING WG ; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-sr
Hi WG,
I am still waiting for the issue about “SRv6 VPN SID in Multicast” in WGLC
draft [*] draft-ietf-spring-sr-replication-segment to be resolved.
To be collaborative, I had already mentioned repeatedly to use “Source Address”
for considering as an possible option to solve the issue.
and
delete it!
From: Rishabh Parekh [mailto:risha...@gmail.com]
Sent: Wednesday, January 18, 2023 11:15 AM
To: Xiejingrong (Jingrong)
Cc: James Guichard ; SPRING WG
; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
Jingrong,
Your point [1] (Context SID
Hi WG:
Thank you Jim, Joel & Bruno for updating the status of the WGLC and committing
that every comments will be addressed and confirmed by the committers.
However, my comments, for example the “issue #1 VPN SID in Multicast” we have
heavily argued [1], are not confirmed but seem to hide by
Hi Gyan,
Thank you firstly for introducing this document to spring and to me (not
subscribed IPPM yet ^-^).
After read this draft and the discussions under this thread, I have recalled my
understanding on passport, postcard (PBT-Mark, DEX).
I think PBT-M is a useful approach for postcard
mmediately and
delete it!
From: Rishabh Parekh [mailto:risha...@gmail.com]
Sent: Thursday, December 22, 2022 2:00 AM
To: Xiejingrong (Jingrong)
Cc: SPRING WG ; spring-cha...@ietf.org
Subject: Re: [spring] Issue #1: VPN SID in Multicast //RE: WGLC for
draft-ietf-spring-sr-replication-segment
Xingron
[mailto:risha...@gmail.com]
Sent: Saturday, December 17, 2022 6:21 AM
To: Xiejingrong (Jingrong)
Cc: SPRING WG ; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
Jingrong,
Replies @ [RP]
Thanks,
-Rishabh.
On Sat, Dec 10, 2022 at 5:22 PM Xiejingrong
? fe08:x:x:x:x:x:x:x? ::127.x.x.x ?
4. What does the “insert” in the draft exactly mean for SRv6 ?
Thanks,
Jingrong
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Xiejingrong
(Jingrong)
Sent: Sunday, December 11, 2022 9:22 AM
To: SPRING WG
Cc: spring-cha...@ietf.org
Subject: Re: [spring
]
Sent: Thursday, December 8, 2022 6:52 AM
To: Xiejingrong (Jingrong)
Cc: James Guichard ; SPRING WG
; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
Jingrong,
For the second one regarding the SID after the replication SID, I still have
some
it!
From: Rishabh Parekh [mailto:risha...@gmail.com]
Sent: Thursday, December 8, 2022 6:52 AM
To: Xiejingrong (Jingrong)
Cc: James Guichard ; SPRING WG
; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
Jingrong,
For the second one regarding the SID
Parekh [mailto:risha...@gmail.com]
Sent: Wednesday, December 7, 2022 6:32 AM
To: Xiejingrong (Jingrong)
Cc: James Guichard ; SPRING WG
; spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
Jingrong,
In section 2.1 and 2.2, it says “An Anycast SID or BGP
Hi PIM & MSR6 :
I feel the last-calling document in SPRING may be useful to understand MSR6 and
related work.
This Spring document[1] defines an SRv6 SID End.Replicate to perform a
multipoint transport behavior statefully.
The MSR6 document[2] defines an SRv6 SID End.RGB to perform a
Hi WG and authors,
I have read this document and have some questions.
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
Hi,
Thank you Toerless for your summary on the "core BIER/MSR6 differentiation".
I feel no words other than the two you have summarized below, "Operational and
Architectural."
Operational: MSR6 is for IPv6 network, and BIER for MPLS network (yes I know
BIER has a Non-MPLS BIER encapsulation
Hi Suresh,
Sorry for the late reply due to a long holiday. Please see inline below
marked with [XJR].
Thanks,
Jingrong.
-Original Message-
From: Suresh Krishnan [mailto:suresh.krish...@gmail.com]
Sent: Friday, September 30, 2022 4:46 AM
To: Xiejingrong (Jingrong)
Cc: Jen Linkova
Hi working group:
I have a few comments/questions on the draft (Marked with ==> in the beginning
of a line).
Section 1 "SR source nodes initiate packets with a segment identifier in the
Destination Address of the IPv6 header".
==>SR source node may be a host originating a packet ...
==>SR
[mailto:etm...@gmail.com]
Sent: Tuesday, March 15, 2022 9:02 PM
To: Andrew Alston - IETF
Cc: Xiejingrong (Jingrong) ; Gyan Mishra
; Andrew Alston - IETF ;
spring@ietf.org; Tom Hill
Subject: Re: [spring] Network Programming Interface for Provisioning of
Underlay Services to Overlay Network
nt the NPI.
Regards,
Jingrong
From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Sunday, March 13, 2022 8:26 AM
To: Andrew Alston - IETF
Cc: Tom Hill ; Xiejingrong (Jingrong)
; spring@ietf.org
Subject: Re: [spring] Network Programming Interface for Provisioning of
Underlay Services to Overlay
rch 9, 2022 10:43 PM
To: spring@ietf.org
Subject: Re: [spring] Network Programming Interface for Provisioning of
Underlay Services to Overlay Networks Using SRv6
(draft-xie-spring-srv6-npi-for-overlay)
Hi Jinrong,
On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote:
> I just posted a draft that
Hi,
I just posted a draft that specifies a framework and some more detail of the
idea for provisioning of underlay services (Slice/SR-policy/Mcast/etc) to
overlay networks(SD-WAN/CDN/etc), using SRv6.
https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-overlay
Please
Hi WG,
I have read the polling draft.
I think it provides a valid solution for SRv6 SID list compression in a simple
way Compatible with SRH 8754 and SRv6 PGM 8986, and thus I support the adoption.
Thanks
Jingrong
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent:
of the authors and the working group.
Thanks
Jingrong
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Xiejingrong
(Jingrong)
Sent: Friday, September 10, 2021 3:42 PM
To: bruno.decra...@orange.com; spring@ietf.org
Subject: Re: [spring] WG Adoption call -
draft-srcompdt-spring-compression
Hi WG,
I support the WG adoption of the two documents !
Thanks
Jingrong
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Tuesday, September 7, 2021 9:13 PM
To: spring@ietf.org
Subject: [spring] WG Adoption call -
Hi working-group:
I support the adoption, and I have the following questions:
1. Section 4.1.4.2 and 4.2.2.2 depict the packet format with word "as needed"
for inner IP Header. Can authors please clarify in which case(s) it is needed
and in which it is not.
2. Section 4.3.1 "Destination ipv6
Hi,
I have some comments inline below marked with [XJR].
Thanks
Jingrong
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pablo Camarillo
(pcamaril)
Sent: Saturday, September 26, 2020 2:30 AM
To: Erik Kline ; The IESG
Cc: Bruno Decraene ; spring@ietf.org;
Hi,
I have some comments inline below marked with [XJR].
Thanks
Jingrong
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pablo Camarillo
(pcamaril)
Sent: Saturday, September 26, 2020 2:32 AM
To: Benjamin Kaduk ; The IESG
Cc: Bruno Decraene ;
=R7_RepSID) (C-multicast pkt)
Is that correct ?
Thanks
Jingrong
From: Rishabh Parekh [mailto:risha...@gmail.com]
Sent: Thursday, July 16, 2020 4:46 AM
To: Xiejingrong (Jingrong)
Cc: Jeff Tantsura ; Dhruv Dhody
; bruno.decra...@orange.com; spring@ietf.org; Alexander
Vainshtein
Subject: Re
Basic building block of SR technology for inter-op between routers and NMS.
I do support the adoption.
Thanks
Jingrong Xie
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Monday, July 13, 2020 11:38 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject:
Basic building block of SRv6 technology for inter-op between routers and NMS.
I do support the adoption.
Thanks
Jingrong Xie
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Tuesday, July 14, 2020 5:52 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject:
Very useful use case for Segment routing technology, and very well written
document.
I do support the WG adoption of this draft.
Thanks
Jingrong Xie
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: spring@ietf.org
Cc:
will cover SRv6 as well, but if it does, then I
would like to see the same level of consideration as SR-MPLS.
Thanks,
Jingrong
From: Rishabh Parekh [mailto:risha...@gmail.com]
Sent: Wednesday, July 15, 2020 4:25 AM
To: Xiejingrong (Jingrong)
Cc: Jeff Tantsura ; Dhruv Dhody
; bruno.decra...@orange.com
Hi
The rev-04 says “The Replication SID MUST be the last SID (at the bottom of
stack for SR-MPLS) in a packet that is steered out from a Replication node of a
Replication Segment.”.
I feel a little hard to understand ……
My question is: Can an “MPLS packet” be carried over the P2MP policy ?
Bonica [mailto:rbon...@juniper.net]
Sent: Monday, June 15, 2020 9:54 PM
To: Xiejingrong (Jingrong) ; Aijun Wang
; i...@ietf.org; spring@ietf.org
Subject: RE: About the upper layer header processing in RFC8754(SRH)
Aijun, Jingrong,
Could the upper-layer header also be ICMP, as in a ICMP Echo
layer
header.
}
End of the proposed text
Your thoughts?
Thanks
Jingrong
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Xiejingrong (Jingrong)
Sent: Monday, June 15, 2020 10:29 AM
To: Aijun Wang ; i...@ietf.org; spring@ietf.org
Subject: RE: About the upper lay
Hi Aijun,
Very good catch!
I think the 4.3.1.2 need to be updated !
I would like to propose some text (maybe later today) for RFC8754 4.3.1.2, as
well as some other text in SRv6-PGM section 4.1 (and some related sections) I
have observed about the Upper-layer processing for further discussion.
Hi Robert,
"What … would happen … if there is no Routing Header at all and I still modify
DA at each segment endpoint"
Good question. I saw no less than 2 existing drafts and no less than 2
potential proposals with this behavior, and IMO they are all reasonable.
Or reading the RFC8200
Hi !
Let me jump to this topic, and tell a fact first: Most design examples of DOH
in RFCs so far do NOT follow the “recommended order” of RFC1883/2460/8200.
EXAMPLE1: RFC3775/3776/4584/6275 requires DOH carrying a specific option is
located after RH and before Fragmentation/AH/ESP (copied
Halpern Direct [mailto:jmh.dir...@joelhalpern.com]
Sent: Wednesday, March 4, 2020 9:39 PM
To: Xiejingrong (Jingrong) ; spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Jingrong, the only "processing" of the SRH required in the ultimate node is
Hi Joel, Ketan,
Let me share my points about the statement "The SRH removal does not remove the
expensive part of the work, namely the need to decapsulate and process the
inner header."
For the ultimate segment endpoint that is well capable of processing SRH, the
statement is true I think. I
Hi WG,
What I can see is that the version 11 diffs are just borrowed from the initial
text I proposed on the mailing list days before.
https://mailarchive.ietf.org/arch/msg/spring/nZwDUSpsVxTN_3UO0VLE9_2Eo5s/
These changes were editorial in nature and did not change anything of the
behavior.
of the SID processing, copies the last SID from the SRH into the IPv6
Destination Address and decrements Segments Left value from one to
zero.
Thanks
Jingrong
From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Tuesday, March 3, 2020 12:52 PM
To: Xiejingrong (Jingrong)
Cc: 6...@ietf.org; Bob
ell for SR paths - the idea that the final
destination PE would lack hardware capability for SRH processing does not make
sense as the source and final destination node are one and the same.
Am I missing something?
Kind Regards
Gyan
On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong)
mailt
Cheers!
Jingrong
From: Wang, Weibin (NSB - CN/Shanghai) [mailto:weibin.w...@nokia-sbell.com]
Sent: Sunday, March 1, 2020 4:53 PM
To: Xiejingrong (Jingrong)
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft
the SRH is deleted:
(SA=VM, DA=subscriber) (payload).
Thanks
Jingrong
From: Wang, Weibin (NSB - CN/Shanghai) [mailto:weibin.w...@nokia-sbell.com]
Sent: Sunday, March 1, 2020 4:01 PM
To: Xiejingrong (Jingrong)
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request
H from the IPv6 extension header chain
S14.5. }
Many thx,
R.
On Sat, Feb 29, 2020 at 2:28 AM 神明達哉
mailto:jin...@wide.ad.jp>> wrote:
At Fri, 28 Feb 2020 07:54:28 +,
"Xiejingrong (Jingrong)"
mailto:xiejingr...@huawei..com>> wrote:
> The design of PSP for the bene
v6 header Payload Length by the Hdr Ext Len
value of the SRH
S14.4. Remove the SRH from the IPv6 extension header chain
S14.5. }
Many thx,
R.
On Sat, Feb 29, 2020 at 2:28 AM 神明達哉
mailto:jin...@wide.ad.jp>> wrote:
At Fri, 28 Feb 2020 07:54:28 +,
"Xiejin
Got it.
Thanks for your clarification of your point.
Jingrong
-Original Message-
From: 神明達哉 [mailto:jin...@wide.ad.jp]
Sent: Saturday, February 29, 2020 9:28 AM
To: Xiejingrong (Jingrong)
Cc: Ted Lemon ; Pablo Camarillo (pcamaril)
; Brian E Carpenter ; Bob
Hinden ; Joel M. Halpern
g problems
for deployment, and that's why I think once that is not necessary it should not
be recommended.
Thanks
Jingrong
-Original Message-
From: Bob Hinden [mailto:bob.hin...@gmail.com]
Sent: Saturday, February 29, 2020 6:52 AM
To: Brian Carpenter
Cc: Bob Hinden ; Xiejingrong (Jingrong)
;
Hi
Thanks Ted for the constructive suggestions, which remind me to try to
understand the questions. Here are the questions I think give the clear
suggestions for LC.
Brian: So could the draft make this explicit, because I guarantee you it is not
in the least obvious to the non-expert reader?
However, the PSP behavour doesn't even fit in that fictional interpretation of
RFC8200.
What PSP does is that, given:
B - C
routers, when B realizes, after processing the SRH and setting the Dest Addr to
the last segment, SegmentsLeft==0, it removes the SRH.
This case is not
Hi Mark,
I think both AH and PSP are optional.
If AH is desired to deploy, then the operator can choose not to use PSP.
If AH is not deployed, and the operator has its requirements of
incremental-deployment, then the operator can choose to use PSP.
If the already deployed PSP is removed from the
Support.
thanks,
Jingrong
From:bruno.decraene
To:SPRING WG
Date:2019-12-20 00:54:44
Subject:[spring] draft-ietf-spring-srv6-network-programming - 2 week Early
Allocation Call
Hi SPRING WG,
This begins a 2 week Early Allocation call for a “Ethernet” value from the
"Protocol Numbers"
ificant increase
in complexity on the device performing PSP? The question I am trying to
get at is about the tradeoff, which needs one to evaluate both sides.
Yours,
Joel
On 12/10/2019 11:13 PM, Xiejingrong (Jingrong) wrote:
> I think it's a good idea.
> Nothing new, but benefits that pe
I think it's a good idea.
Nothing new, but benefits that people have already said seems notable to me.
(1) reduce the load of final destination. This benefit can be notable for the
following sub reasons.
(1.1) final destination tends to have heavy load. It need to handle all the EHs
and do the
+1
Kindly remind that, there are ‘final destination’ wording 5 times in RFC8200.
The 8200 is aware of difference of ‘destination’ and ‘final destination’.
Line 375: note 3: for options to be processed only by the final
destination
Line 443:packet's final destination.
Hi Bruno,
I read the updated draft, draft-voyer-spring-sr-replication-segment-00, and
feel it is not your suggested direction, but the opposite one.
You suggested "Re-use the existing SR-policy framework as much as possible"
But the updated document does not re-use the existing SR-policy.
I support the adoption of this document.
It is well-written, and I think it is very timely and useful, as the SR being
widely developed and the requirements for enhanced VPN services being strong.
Thanks
Jingrong
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On
68 matches
Mail list logo
