notify 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 d
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 th
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
;.
Thanks!
Jim, Joel & 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<
ames 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 i
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, t
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] https://mailarchive.ietf.org/arch/msg/spring/zo
rsons 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:
oun...@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 li
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 r
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.
Conside
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 in
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 si
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 telemet
immediately 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
Xi
[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 multipoin
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 ap
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 whic
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 sour
[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 Networks Us
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 speci
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 comm
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:
rk 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-compre
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 -
draft-srcompdt-spring-compression-requi
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 a
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; J
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 ; spring@ietf.org;
[mailto:risha...@gmail.com]
Sent: Friday, July 17, 2020 12:42 AM
To: Xiejingrong (Jingrong)
Cc: spring@ietf.org; p...@ietf.org
Subject: Re: [spring] Understanding the replication draft
Jingrong,
Your understanding is essentially correct. Think of a Replication function at a
node represented by the function
=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: [spring
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: [spri
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: spring-cha
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 ? say
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 layer
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 verba
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 from
Joel 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 i
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 gue
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.
Ev
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
any packet with Next Header value other than 4/41/47/etc.
It may send such packet with any routing header to its slow-path for the
compliance but lose the necessary performance.
Thanks
Jingrong
From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Monday, March 2, 2020 4:20 AM
To: Xiejingrong
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
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 to
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 +,
"Xiejingrong (Jingrong)"
mailto:xiejingr...@huawei..com>> wrote:
>
e SRH
S14.3. Decrease the IPv6 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 2
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
d of engineering 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 ;
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 eve
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 d
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" regis
significant 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
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 d
Thanks Bob for sharing your opinion.
I fully agree with that, and I either don’t have any problem if an intermediate
node decides to parse extension headers and modified one based on the
definition of the specific EH.
Regards,
Jingrong
-Original Message-
From: ipv6 [mailto:ipv6-boun...@
+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. Inste
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 Behalf
Hi
I support adoption of the two drafts.
Path Segment is a simple and useful identifier of a Path in SR-MPLS technology,
and the use of BGP-SRPolicy and BGP-LS for the management of Path Segment is
proper to me.
1) Should this SR Policy technology be included in BGP for SR-MPLS
Yes.
2)
ntics previously
established between the source and destination."
Thanks
Jingrong
-Original Message-
From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
Sent: Tuesday, September 17, 2019 3:44 AM
To: Xiejingrong ; Joel M. Halpern
; SPRING WG
Cc: 6...@ietf.org
Subject: Re: [spr
I agree with Joel, and strongly opposed to the proposal text !
"The value TBD in the Next Header field of an IPv6 header or any extension
header indicates that the payload content is identified via the segment
identifier in the IPv6 Destination Address."
It is a hole digging to exclude other po
Hi Brian and Robert,
So it really makes much more sense to encode everything in the same EH rather
than scatter them around.
[xjr1] I agree with Robert 100%.
so header formats should be rigid enough that conditional or linked-list
processing can be largely avoided.
[xjr2] Sorry Brian,
+1
I think the need to ‘walk through the EH chain’ in fast-path is difficult, for
the last 2 decades, and will for the near future I guess.
The SRv6 is very careful not to ‘walk through the EH chain’.
Instead it just ‘handle the least leading header(s)’, with a preceding ‘FIB
lookup’ indication,
the CHG bit is meaningful of hop-by-hop options, but is totally meaningless for
Destination options.
CHG is meaningful for both.
Also I think the use of unique last-5bits of option is just a week
recommendation. There is still enough space of 8bit if needed. It's not
necessary to change interp
+1.
I didn't see the possibility of handling packets with EH in fast path without
the indication of SRv6 SID in the preceding FIB lookup. This is uniquely
introduced in SRH and SRv6 networking programming draft.
The only 'problem' rising on the list, the V6 TI LFA, has been uniquely
considered
I am happy to see the converging, and I agree with both Robert and Gernando.
The problem that an EH-insertion want to solve can also be solved by using an
extra encap/decap, which is obviously compliant.
The more bytes used by extra encap/decap may be the tax we have to pay for
using IPv6!
The
Completely agree with Bruno.
I have raised similar comments on the list 3 weeks ago.
(1) To let an SR Replication policy be a variant of an SR policy, SR-policy
framework should be inherited as much as possible.
(2) Building of a tree is really outside the scope of the group.
(3) I
Hi,
Please see my comments inline below:
From: Zafar Ali (zali) [z...@cisco.com]
Sent: Wednesday, July 17, 2019 8:48
To: Xiejingrong; 6...@ietf.org
Cc: Zafar Ali (zali); spring@ietf.org
Subject: Re: Comments on
Hi Xiejingrong,
Many thanks for your comments
Hi,
I remember there had been lots of discussions on the list about two points,
One is the definition of ENH, the other is the use of Next Header 59.
Seems like this rev doesn't accept any of them, but make them clear in text..
They work for me.
But one point I am even more confused:
The SRv6
Hi,
I have a few comments on draft-voyer-spring-sr-p2mp-policy-03:
A Point-to-Multipoint service delivery could be via Ingress
Replication (aka Spray in some SR context), i.e., the root unicasts
individual copies of traffic to each leaf. The corresponding P2MP
segment consists of repl
Hi Tom,
Number 97 is a choice but it has 2 bytes wasting.
Jingrong
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Monday, May 06, 2019 9:11 AM
To: Ron Bonica
Cc: SPRING WG ; 6man
Subject: Re: SRv6 Network Programming: ENH = 59
On Sun, May 5, 2019, 5:47 PM Ron Bonica
Hello authors,
Section 4.3.1.2. Upper-layer Header or No Next Header of
doesn't include the No Next Header
case ?
The SRv6-Network-programming relies heavily on the No-next-header in SRv6-L2VPN
cases.
Thanks
Jingrong
___
spring mailing list
spring
I Support the adoption but I also have a comment.
The Next Header value 59 used in SRv6-L2VPN scenario should be a new value
applied from IANA officially.
Please find in the WG mail list my comment yesterday.
Thanks
Jingrong
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra.
Dear authors of :
Thanks for introducing this great concept about how to develop the 128-bit IPv6
address.
One comment/question:
Next header value 59 is used when an Ethernet-packet is as the IPv6 payload in
SRv6-L2VPN scenario.
It is confusing, because 59 is generally used to indicate that the
Hi Bob,
Will SPRING consider multicast/BIER being included ? These are some reasons I
am thinking about:
(1) multicast/multipoint-transfer is always a requirement for internet service,
and is always requiring some unicast technology as a precursor.
(2) there is already a similar WG BIER to consi
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Saturday, April 28, 2018 4:21 PM
To: Xiejingrong ; Xiayang (Yolanda)
; Mike McBride ; Yangang
Subject: New Version Notification for draft-xie-bier-6man-encapsulation-00.txt
A new version of I-D
88 matches
Mail list logo
