Re: [spring] New Version Notification for draft-xie-spring-srv6-multicast-00.txt

[Xiejingrong (Jingrong)]

Hi Working group,

As previously mentioned in the mail list 
https://mailarchive.ietf.org/arch/msg/spring/5iLxCBmOrSNqOafiCRYy3BZGvkg/, 
we've finished the work "to write a draft [DRAFT] to explain in detail about 
the impacts of SRv6-multicast approaches to SRv6 architecture in general for 
the WG to evaluate".
We had also submitted the ietf116 presentation request by filling the google 
form according to Shuping's guidance in 
https://mailarchive.ietf.org/arch/msg/spring/NRl7B0bxoUZsiidvGSfVjbfQVFI/.
Hopefully there is a chance to present it in the ietf116.
It is also welcomed to receive comments in the list.

Thanks,
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 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-spring-srv6-multicast-00.txt


A new version of I-D, draft-xie-spring-srv6-multicast-00.txt
has been successfully submitted by Jingrong Xie and posted to the IETF 
repository.

Name:   draft-xie-spring-srv6-multicast
Revision:   00
Title:  SRv6 Multicast: Approaches and Impacts to SRv6 Architecture
Document date:  2023-03-09
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/archive/id/draft-xie-spring-srv6-multicast-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-xie-spring-srv6-multicast/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-multicast


Abstract:
   Multicast was not originally supported with SR, as indicated in
   [RFC8402]: Segment Routing is defined for unicast.

   However, with the wide development and deployment of SR and SRv6
   technology, there have been proposals to develop SR-based multicast
   solutions, showing the interests to develop multicast solutions that
   facilitate incremental deployment based on SR and SRv6.

   This document examines two typical SRv6 multicast approaches and
   considers a number of different aspects to provide a framework for
   understanding.  The purpose is to help the working group and IETF
   community to understand and thus evaluate these possible impacts.



  


The IETF Secretariat



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Re：New Version Notification for draft-dong-spring-sr-4map6-segment-00.txt

[Xiejingrong (Jingrong)]

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 the packet according to the instructions in Function, ……

So my understanding is that, only Map-E is considered in current revision.
Do you consider Map-T also in this document in the future ?

Regards,
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Dong Guozhen
Sent: Sunday, March 12, 2023 8:06 PM
To: spring ; spring-chairs 
Cc: Chongfeng Xie ; xing ; 
Pengshuping (Peng Shuping) 
Subject: [spring] Re：New Version Notification for 
draft-dong-spring-sr-4map6-segment-00.txt

Hello everyone,

We have just submitted a new draft, which is about 4map6 Segment for IPv4 
Service delivery over IPv6-only underlay networks. Since this is the first 
submission, there must be many defects in it, we look forward to receiving more 
comments, suggestions and even criticism.


   ——

   Best Regards

  Guozhen
E-mail：don...@chinatelecom.cn
——

在 2023年3月12日 
11:56，internet-draftsmailto:internet-dra...@ietf.org>>
 写道：


A new version of I-D, draft-dong-spring-sr-4map6-segment-00.txt

has been successfully submitted by Guozhen Dong and posted to the

IETF repository.



Name: draft-dong-spring-sr-4map6-segment

Revision: 00

Title:   4map6 Segment for IPv4 Service delivery over IPv6-only 
underlay networks

Document date:   2023-03-12

Group:   Individual Submission

Pages:   7

URL:
https://www.ietf.org/archive/id/draft-dong-spring-sr-4map6-segment-00.txt

Status: 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-4map6-segment/

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-dong-spring-sr-4map6-segment





Abstract:

   This document defines a new type of segment for Segment Routing,

   i.e., 4map6 segment, which is a mapping rule-based IPv4/IPv6

   conversion function running in PE nodes.  This segment can be used

   for IPv4 service delivery over IPv6-only undelay networks.









The IETF Secretariat






___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Hi Rishabh:

For your statement “disallow any SIDs after Replication SID in SRH and break 
the MVPN use case”, I understand it that, the “SIDs after Replication SID in 
SRH” is intended for “MVPN use case”.
Therefore I think that is exactly in Bruno’s comment “leaving any 
application/VPN specifics outside the scope of this SPRING document”.

You said previously that aggregation of multiple MVPN is optional for this 
document, therefore I assume “to disallow any SIDs after Replication SID in 
SRH” may not be a big problem for your solution as it is optional.
Further, to “disallow any SIDs after Replication SID in SRH”, there are still 
many possible ways to solve the “MVPN use case” outside the SPRING wg, do you 
agree with that ?
So why need to insist on keeping “SIDs after Replication SID in SRH” in the 
SPRING document but is really a solution  IMO for “MVPN use case” ?

I don’t think the use of ambiguous terms like “context” instead of MVPN or 
VPN-SID does really “leave the application/VPN specifics outside the scope of 
this SPRING document”.
Please remember my previous questions about VPN-SID like SRv6 Upstream-assigned 
SID or SRv6 DCB SID that are still pending, and that have been understood by 
Gyan.
But I think they can be all solved if it is to “disallow any SIDs after 
Replication SID in SRH”.

And further, I assume “to disallow any SIDs after Replication SID in SRH” is 
the original and correct design in rev-05 and previous versions. For example In 
Rev-05 the text below shows a very clear design with careful consideration IMO:
   An End.Replicate SID MUST only appear as the ultimate SID in a SID-
   list.  An implementation that receives a packet destined to a locally
   instantiated End.Replicate SID that is not the ultimate segment
   SHOULD reply with ICMP Parameter Problem error (Erroneous header
   field encountered) and discard the packet.

   There MUST not be any topological SID after a Replication SID in a
   packet.  Otherwise, the behavior at Downstream nodes of a Replication
   segment is undefined and outside the scope of this document.


Thanks,
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email 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 the proposed SRv6 pseudo-code changes, would 
completely disallow any SIDs after Replication SID in SRH and break the MVPN 
use case! When Bruno mentioned " leaving any application/VPN specifics outside 
the scope of this SPRING document", I think he meant to keep the details of the 
"context" (VPN-SID) out of the SPRING draft, not discard it altogether. With 
the clarifications and caveats in text and pseudo-code  of the latest version 
about SRH processing on Replication nodes,  use of a SID in SRH to provide 
context for packet processing packets on Leaf/Bud node is clear and valid 
according to chairs and WG.

Thanks,
-Rishabh



On Tue, Feb 28, 2023 at 1:50 AM Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>> wrote:
Hi, WG chairs, authors, and all:

Thanks the authors firstly for positively work on this document and update the 
draft.
To be clear, I am not blocking the WGLC. Instead, I am willing to see the 
technical concerns could be solved, and I would like to give my suggestions 
based on your latest rev-12.

I noticed that:
Jim had required the document to provide SRv6 pseudo-code for the accurate 
behavior defining.
Joel had commented/questioned  that “the replication behavior does under soem 
circumstances result in a packet with a partially processed segment list in an 
SRH and a destination address that does not appear explicitly or by mechanical 
manipulation in the SRH”.
Bruno had suggested that “leaving any application/VPN specifics outside the 
scope of this SPRING document. This may help with the resolution of some WGLC 
comments”.

To better understand all these comments about application/VPN/MVPN, I have 
carefully checked all the diffs from rev-00 to rev-12.
I feel that, the question may had been brought to the document unintentionally 
in rev-06, because there was no “application/VPN/MVPN for SRv6 data plane” 
problem in rev-05 and the definition of SRv6 Replication SID to be the ultimate 
SID in rev-05 is c

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

ely and 
delete it!

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rishabh Parekh
Sent: Tuesday, February 28, 2023 3:57 AM
To: SPRING WG List 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

We have published revision 12 of the draft. Main changes include:
- Pseudo-code for SRv6 End.Replicate
- Description and example of ping to a Replication SID
- Changes to text to address comments from Bruno, Jim and Joel

Please review.

Thanks,
-Rishabh

On Fri, Feb 24, 2023 at 4:06 PM Rishabh Parekh 
mailto:risha...@gmail.com>> wrote:
Jim,
The text you refer to in Section 2.1 and .2.2 has changed after addressing 
comments since the last revision, but we will try to incorporate the suggested 
change.

Thanks,
-Rishabh

On Mon, Feb 20, 2023 at 8:06 AM James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:
Hi Rishabh & authors,

To close out this discussion, in sections 2.1 and 2.2 we have:
There MAY be SIDs after the Replication SID in the segment list of a packet. 
These SIDs are used to provide additional context for processing a packet 
locally at the node where the Replication SID is the Active Segment. The 
processing of SIDs following the Replication SID MUST NOT forward the SR-MPLS 
packet to another node.

The chairs believe 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.".

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<mailto:bruno.decra...@orange.com>; SPRING WG 
mailto:spring@ietf.org>>
Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment

James,

On Wed, Feb 15, 2023 at 8:05 AM James Guichard 
mailto: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 however 
be revisiting this point in subsequent emails) and focus on bringing closure to 
the technical comments detailed in 
https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cdb56daac0d014f3482a208db0fdfde76%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121226437340003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=xMx%2BHL31Nq%2FdqZZOXZf9ZEkPD5dptGq7Tsdp7mwieiU%3D=0>.

As I read through your comments Jingrong I think I can summarize your objection 
to be that you believe the proposal breaks the SRv6 architecture as the 
forwarding relies upon local state rather than state carried within the SRH. Do 
I have that right? If this is the case then you need to be specific in terms of 
which text/sentences in the document are in conflict with which text/sentences 
of existing RFCs. As written I think Rishabh’s forwarding example is accurate 
as he describes a lookup on the Replication SID and the action is to either 
update the outer IPv6 address with the downstream nodes address, or 
re-encapsulate the packet with a new IPv6 header and SRH. I might draw your 
attention to  
https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8754.html%23name-fib-entry-is-a-locally-inst=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cdb56daac0d014f3482a208db0fdfde76%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121226437340003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=q56RV5lZ8B6B%2F43YzGfa1LyhHu3l1JZbK9M%2Byx3hDvk%3D=0>
 which talks about the definition of future SIDs and their behaviors.

Further your comments appear to me to suggest that the VPN identification 
encapsulated at PE1 acts like a normal VPN SID in the sense that forwarding is 
based upon that IPv6 address. I don’t think that is the intent here; I think 
the SID is used as an identifier for the VPN itself so that the downstream 
nodes are given the correct VPN forwarding context i.e. they are not supposed 
to use that SID to forward the packets back to PE1. Perhaps the authors could 
clarify this point further?

Hi Rishabh, it would be helpful if you could review the comments in 
https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.o

[spring] Violation of the SRv6 architecture concern //RE: WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Hi Jim, Joel & Bruno,

For the “Violation of the SRv6 architecture” concern, I have checked *all* the 
behaviors of SRv6 SID that is following with another SID:


l  End,

l  End.X,

l  End.T,

l  End.B6.Encaps,

l  End.B6.Encaps.Red,

l  End.BM

l  The SID defined in RFC 8754


I find that *all* of them are aligned with the meaning & semantics of 
SRv6/SRH/SID-list/Segment-Left:  process the next SID by updating the DA before 
submitting the packet to the IPv6 module. See below:


Example Pseudo-code of End SID (and also End.X, End.T):
S01. When an SRH is processed {
S12.   Decrement IPv6 Hop Limit by 1
S13.   Decrement Segments Left by 1
S14.   Update IPv6 DA with Segment List[Segments Left]
S15.   Submit the packet to the egress IPv6 FIB lookup for transmission to the 
new destination
S16. }


Example Pseudo-code of End.B6.Encaps (and also End.B6.Encaps.Red, End.BM):
S01. When an SRH is processed {
S12.   Decrement IPv6 Hop Limit by 1
S13.   Decrement Segments Left by 1
S14.   Update IPv6 DA with Segment List[Segments Left]
S15.   Push a new IPv6 header with its own SRH containing B
S16.   Set the outer IPv6 SA to A
S17.   Set the outer IPv6 DA to the first SID of B
S18.   Set the outer Payload Length, Traffic Class, Flow Label,
  Hop Limit, and Next Header fields
S19.   Submit the packet to the egress IPv6 FIB lookup for
  transmission to the new destination
S20. }


Example Pseudo-code of “The SID defined in RFC8754” (which is a general example 
of processing by the meaning of SRv6/SRH/SID-List/Segment-Left) :
S01. When an SRH is processed {
S14. Else {
S15.   Decrement Segments Left by 1.
S16.   Copy Segment List[Segments Left] from the SRH to the destination 
address of the IPv6 header.
S17.   If the IPv6 Hop Limit is less than or equal to 1 {
S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in
 Transit message to the Source Address and discard
 the packet.
S19.   }
S20.   Else {
S21. Decrement the Hop Limit by 1
S22. Resubmit the packet to the IPv6 module for transmission
 to the new destination.
S23.   }
S24. }
S25.   }
S26. }


Please allow me to list the main meaning & semantics of 
SRv6/SRH/SID-list/Segment-Left (below):
SRv6(8986): The Segment Routing over IPv6 (SRv6) Network Programming framework 
enables a network operator or an application to specify a packet processing 
program by encoding a sequence of instructions in the IPv6 packet header.
SRH(8754): Segment Routing can be applied to the IPv6 data plane using a new 
type of Routing Extension Header called the Segment Routing Header (SRH).
RH(8200): The Routing header is used by an IPv6 source to list one or more 
intermediate nodes to be "visited" on the way to a packet's destination.
Segment Left(8200): 8-bit unsigned integer.  Number of route segments 
remaining, i.e., number of explicitly listed intermediate nodes still to be 
visited before reaching the final destination.


For Replication-SID with an SRv6 VPN SID after it, there is still  an SRv6 SID 
“to be visited” as the (Segment-Left==1) indicates, the behavior is not 
“processing” it but is overriding by the state of the Replication-SID.

SRv6 architecture, in my understanding, is built on the meaning & semantics of 
the above SRv6/SRH/RH/SID-list/Segment-Left, and has proven by *all* the SRv6 
SID that is in RFC8754 & 8986.

That’s an additional argument for my concern about “Violation of the SRv6 
architecture”.

Thanks,
Jingrong


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: James 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.

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Monday, February 20, 2023 3:02 AM
To: James Guichard 
mailto:james.n.guich...@futurewei.com>>; Joel 
Halpern mailto:j...@joelhalpern.com>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Cc: SPRING WG mailto:spring@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: RE: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi Jim, and WG chairs:

For Jim

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

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, the piece of sentence “This document and section define a single 
SRv6 SID. Future documents may define additional SRv6 SIDs.” in 
https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst 
was sometimes used as the above argument.  But as I have answered in [B] to 
this, the piece of sentence does not support the Replication SID solution at 
all.





Another example, as Joel may care more about, is the piece of sentence 
“End.B6.Encaps and End.B6.Encaps.Red (and End.BM)” in the following claim made 
by Rishabh.

This claim is also documented in the WGLC document “At a Replication node, the 
Replication SID is the equivalent of Binding SID [RFC9256] of a Segment Routing 
Policy.”.
I would guess it is used as the “key” piece for arguing that the “VPN SID after 
Replication SID” is a valid solution (because of the behavior of a Binding 
SID), and the following is my reason to guess so and please correct me if my 
guess is wrong.


Use End.B6.Encaps defined in  
https://www.rfc-editor.org/rfc/rfc8986.html#name-endb6encaps-endpoint-bound-  
as an example (in below), the step S15 *always* requires a push of new IPv6 
header, not optionally.

S01. When an SRH is processed {

S02~S11 omitted……

S12.   Decrement IPv6 Hop Limit by 1

S13.   Decrement Segments Left by 1

S14.   Update IPv6 DA with Segment List[Segments Left]

S15.   Push a new IPv6 header with its own SRH containing B

S16.   Set the outer IPv6 SA to A

S17.   Set the outer IPv6 DA to the first SID of B

S18.   Set the outer Payload Length, Traffic Class, Flow Label,

  Hop Limit, and Next Header fields

S19.   Submit the packet to the egress IPv6 FIB lookup for

  transmission to the new destination

S20. }


Is the Replication SID really “equivalent” to this ?  that is to say, it 
*always* push a new IPv6 header when a packet is traversing the path toward the 
Leaf nodes ?
Example 1, a Ingress PE (PE1) and 2 Egress PEs (PE2 & PE3) are the only 
Replication nodes of a network, and 2 SR-Policies are required to the 2 Egress 
PEs separately, what would the two packets (sent from PE1 to PE2 & PE3) 
supposed to be like ? { {IPv6 + SRH} { IPv6 + SRH} (IPv4 or IPv6 Customer 
Multicast Packet) } ?
Example N, TO-BE-thought about…


Then let’s go back to the “meaning” and “semantics” of the “Binding SID 
[RFC9256] of a Segment Routing Policy” :
[RFC9256]: The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. 
It provides scaling, network opacity, and service independence.
[RFC8402]: The BSID is bound to an SR Policy, instantiation of which may 
involve a list of SIDs.

The Replication SID, as defined in the WGLC document, says “Replication State 
is a list of replication branches to the Downstream Nodes.  In this document, 
each branch is abstracted to a  
tuple.”.
I guess, the authors are arguing that, the Replication SID is bound to an 
Replication State that may have relation to  0,1 or N Downstream Nodes, and to 
each of the Downstream Nodes there *MAY* be an SR-Policy, so “the Replication 
SID is the equivalent of Binding SID”.

However, Binding SID *always* bound to *an* SR-Policy, not allowing 0 or N 
SR-Policy(s),  as defined in RFC8402,9256 and verified by the pseudo-code of 
RFC8986.

Why are these two concepts claimed as “equivalent” by the WGLC document ?

What does the claim of “equivalent of Binding SID” intends to argue  to 
argue the basic behavior of Replication-SID is reasonable, or to argue the 
behavior of Replication-SID following with an SRv6 VPN SID (Upstream-assigned 
or DCB) is reasonable ?


I would suggest that we do not use such “scattered pieces of 
sentences/approximation” for argumentation, but focus on the comparison between 
the behavior of “normal SRv6”, the behavior of “alternative solutions (like 
DOH/Src.DT4/SRH TLV)”, and the behavior of “Replication SID with an SRv6 VPN 
SID in SRH”.
Because the meaning of SRv6/SRH/SID-List/Segment-Left from 
RFC8402/8754/8986/8200 are more related to an overall architecture of SRv6  
than the scattered pieces of sentences IMO.


Thanks
Jingrong


References:
[B] https://mailarchive.ietf.org/arch/msg/spring/ufUkSOy2_Tdkjr2AuVIr7gpnXzU/


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

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 will be defined in that document.” 
in 4.3.1 of RFC8754 does agree with that a Replication-SID can be defined in a 
document, but that does not mean that a Replication-SID defined in a document 
is technically correct.


Just in the same section, the following sentence is technical guideline of 
correctly using the SRH: “If the FIB entry represents a locally instantiated 
SRv6 SID, process the next header chain of the IPv6 header as defined in 
Section 4 of 
[RFC8200]. Section 
4.3.1.1 describes how to 
process an SRH; Section 
4.3.1.2 describes how 
to process an upper-layer header or the absence of a Next Header.”


And please let me cite the pseudo-code of section 4.3.1.1 here below, and point 
out that, the normal behavior that implied in the meaning of 
SRv6/SID-List/SRH/Segment-Left, as shown in the S15/S16/S21/S22, is overridden 
by the state of Replication-SID, and hence breaking the SRv6 architecture.

S01. When an SRH is processed {
S02.   If Segments Left is equal to zero {
S03. Proceed to process the next header in the packet,
 whose type is identified by the Next Header field in
 the routing header.
S04.   }
S05.   Else {
S06. If local configuration requires TLV processing {
S07.   Perform TLV processing (see TLV Processing)
S08. }
S09. max_last_entry  =  ( Hdr Ext Len /  2 ) - 1
S10. If  ((Last Entry > max_last_entry) or
S11.  (Segments Left is greater than (Last Entry+1)) {
S12.   Send an ICMP Parameter Problem, Code 0, message to
   the Source Address, pointing to the Segments Left
   field, and discard the packet.
S13. }
S14. Else {
S15.   Decrement Segments Left by 1.
S16.   Copy Segment List[Segments Left] from the SRH to the
   destination address of the IPv6 header.
S17.   If the IPv6 Hop Limit is less than or equal to 1 {
S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in
 Transit message to the Source Address and discard
 the packet.
S19.   }
S20.   Else {
S21. Decrement the Hop Limit by 1
S22. Resubmit the packet to the IPv6 module for transmission
 to the new destination.
S23.   }
S24. }
S25.   }
S26. }


To the chairs:


The authors had never answer my questions ( like “what is the 128bit DCB SRv6 
SID looks like ?” in [4] and many others), but try to use such pieces of 
sentences to argue that the “VPN SID after Replication SID” is a valid solution.

I am very sad and worried about that.



To make my point clear, I had suggested in [A] that we have a comparative 
thinking like this:

What are the benefits of using SRH for VPN SID in multicast instead of using 
DOH ? DOH does not have the restriction in semantics of SRH/RH/SL that is 
conflicting.

What are the benefits of using SRH for VPN SID in multicast instead of using 
Src.DT4 as defined in [6] ? Src.DT4 does not have the restriction in 
semantics of SRH/RH/SL and  can save the encapsulation cost.


Let us think about it in another way  what is the implications of allowing 
an SRH SID-list to carry an identifier like SRv6 DCB SID?
SRH would be abused to carry any information that is not an SRv6 SID in 
SID-List IMO.
Even SRH TLV is more suitable for carrying such “Non SRv6 SID” thing than 
such an abuse of SID-List IMO, not to mention the above two alternatives (using 
DOH or Src.DT4).
Once the abuse of SRH is made by the WGLC document, IMO it will not stop, 
by claiming the  correct use of “SRH”, or even claiming to be superior because 
of “using existing SRH data plane”.


Is my point about “breaking SRv6 architecture” more clear by the above 
comparative thinking and the analysis of “implications” ?


Thanks,
Jingrong.


[A] https://mailarchive.ietf.org/arch/msg/spring/5iLxCBmOrSNqOafiCRYy3BZGvkg/


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: spring 

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

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/zo41ZDrH2Nq_xishIOly8ga19Ns/

[3] https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/

[4] https://mailarchive.ietf.org/arch/msg/spring/ou0V6vmWm4hlAk4I9Cuad1QXzIo/

[5] https://mailarchive.ietf.org/arch/msg/spring/DygdlzN2PiyXkN8RKjy3mb53mYE/

[6] https://datatracker.ietf.org/doc/html/draft-xie-bier-ipv6-mvpn-01

[7] https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-06
[8] 
https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/
[8b] https://mailarchive.ietf.org/arch/msg/spring/x49aMfShzK_mM3wf8_FRLoRgZYo/
[9] https://mailarchive.ietf.org/arch/msg/spring/FyoRJdW2fMx1yVid0ddl8Pz4QeY/





I have browsed the pseudo-code roughly, and I see it is demonstrating my 
concern about “breaking SRv6 architecture by overriding behavior(s) caused by 
the state of Replication SID” is valid.

E.g., The following pseudo-code shows clearly that, the State of Replication 
SID (S11) is overriding the behaviors that an SRv6 architecture should do by 
the meaning of  (SRv6/SRH/SID-list/SL), hence breaking the SRv6 architecture.



S09.   Decrement IPv6 Hop Limit by 1

S10.   Call Replicate(RS, packet)

S11.   If (RS.Node-Role == Leaf or RS.Node-Role == Bud) {

S12. If (IPv6 NH == SRH and Segments Left > 0) {

S13.   Derive packet processing context(PPC) from Segment List[Segments 
Left - 1]

S14. } Else {

S15.   Derive packet processing context(PPC) from FUNCT of Replication SID

S16. }

S17. Remove the outer IPv6 header with all its extension headers

S18. Process the packet in context of PPC

S19.   }





The behavior(s) that the SRv6 architecture(SRH/SID-list/SL) should do, by the 
meaning of  (SRv6/SRH/SID-list/SL),  as I mentioned in previous mail, are very 
well illustrated in the pseudo-code (Step S15/S16/S21/S22) of 
https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst :
S01. When an SRH is processed {
S02.   If Segments Left is equal to zero {
S03. Proceed to process the next header in the packet,
 whose type is identified by the Next Header field in
 the routing header.
S04.   }
S05.   Else {
S06. If local configuration requires TLV processing {
S07.   Perform TLV processing (see TLV Processing)
S08. }
S09. max_last_entry  =  ( Hdr Ext Len /  2 ) - 1
S10. If  ((Last Entry > max_last_entry) or
S11.  (Segments Left is greater than (Last Entry+1)) {
S12.   Send an ICMP Parameter Problem, Code 0, message to
   the Source Address, pointing to the Segments Left
   field, and discard the packet.
S13. }
S14. Else {
S15.   Decrement Segments Left by 1.
S16.   Copy Segment List[Segments Left] from the SRH to the
   destination address of the IPv6 header.
S17.   If the IPv6 Hop Limit is less than or equal to 1 {
S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in
 Transit message to the Source Address and discard
 the packet.
S19.   }
S20.   Else {
S21. Decrement the Hop Limit by 1
S22. Resubmit the packet to the IPv6 module for transmission
 to the new destination.
S23.   }
S24. }
S25.   }
S26. }





Thanks,

Jingrong


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rishabh Parekh
Sent: Saturday, February 18, 2023 8:12 AM
To: James Guichard 
Cc: bruno.decra...@orange.com; SPRING WG 
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Jim,
In addition to RFC 8754 Section 4.3.1, the following text from RFC 8986 Section 
4 also supports the claim the Replication SID is valid within SRv6 

[spring] [EXPERIENCE] //RE: WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Hi Jim and the WG:

Please allow me to provide the [EXPERIENCE], as promised in previous mail,  
that a valid comment may be understood and adopted but may need quite a long 
time.

In July 2019, I comment on SRv6-OAM draft, and the main points there (see [A.1] 
and [A.2] below):
it is easy for an SID to support sending the ICMPv6 packet to CPU, and support 
pinging this SID just the same as pinging a classic IPv6 address.
The normal use of End.DT4 doesn't require an SRH header, while the pinging of 
the End.DT4 need to add an SRH with an End.OTP and the End.DT4. That is 
something bad.

In June 2020, the above comment is understood and adopted by the SRv6-OAM and 
SRv6-PGM document, which was later the RFC9259 and RFC8986 respectively.
The End.OP together with the use of SRH in SRv6-OAM is no longer used in 
SRv6-OAM rev-05. (See [A.3] below).
The modification in SRv6-PGM rev-16 is to make the SRv6 more “smooth” with 
IPv6, instead of using the semantics of SRv6 SID to “override” the behavior of 
normal IPv6 packet. (See the Pseudo-code in Section 4.1 of the rev-16 in [A.4] 
below ).


References:
[A.1] [2019.7.10] [Comments on ] 
https://mailarchive.ietf.org/arch/msg/ipv6/F_FtBGQNE51rL80h23XHmAqdQyY<https://mailarchive.ietf.org/arch/msg/ipv6/F_FtBGQNE51rL80h23XHmAqdQyY/>/<https://mailarchive.ietf.org/arch/msg/ipv6/F_FtBGQNE51rL80h23XHmAqdQyY/>
[A.2] [2019.7.19] [Re: [spring] Comments on 
] 
https://mailarchive.ietf.org/arch/msg/spring/Nwf6EuJvox_RqXStnL3B_Ms5ngY<https://mailarchive.ietf.org/arch/msg/spring/Nwf6EuJvox_RqXStnL3B_Ms5ngY/>/<https://mailarchive.ietf.org/arch/msg/spring/Nwf6EuJvox_RqXStnL3B_Ms5ngY/>
[A.3] [2020.6.12] [SRv6-OAM adopted the above comments] 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-spring-srv6-oam-05
[A.4] [2020.6.27] [SRv6-PGM modified accordingly] 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-srv6-network-programming-16

Thanks,
Jingrong


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 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 Guichard 
Cc: SPRING WG ; bruno.decra...@orange.com; Rishabh Parekh 

Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi Jim, and the WG:

Thank you Jim and the chairs very much for all of your patience to my comments 
on this topic.


For the question: “you believe the proposal breaks the SRv6 architecture as the 
forwarding relies upon local state rather than state carried within the SRH. Do 
I have that right?”:

The short answer is yes. My point is that, the local state of a “Replication 
SID” (which is in DA and acting as active SID), makes the many conflicting 
behaviors when a VPN SID is carried in SRH (and hence after the Replication 
SID).


For the request “If this is the case then you need to be specific in terms of 
which text/sentences in the document are in conflict with which text/sentences 
of existing RFCs.”:

I think I have provided the text/sentences of existing RFCs where the solution 
of this document is conflicting with in [1]. The sentences include:
SRv6(8986): The Segment Routing over IPv6 (SRv6) Network Programming framework 
enables a network operator or an application to specify a packet processing 
program by encoding a sequence of instructions in the IPv6 packet header.
SRH(8754): Segment Routing can be applied to the IPv6 data plane using a new 
type of Routing Extension Header called the Segment Routing Header (SRH).
RH(8200): The Routing header is used by an IPv6 source to list one or more 
intermediate nodes to be "visited" on the way to a packet's destination.
Segment Left(8200): 8-bit unsigned integer.  Number of route segments 
remaining, i.e., number of explicitly listed intermediate nodes still to be 
visited before reaching the final destination.


And the text/sentences in the document is “SIDs after the Replication SID in 
the SRH of a packet.”.

The text/sentences in the document, has been summarized as “VPN SID after 
Replication SID”, and I assume that has been clear through previous discussions.


The “conflicting” is that, normal SRv6  will NOT override the behavior that is 
defined in the term of SRv6/SRH/RH/SL, but the local state of the Replication 
SID does this overriding, hence conflicting.
For an SRv6 packet (S=PE1, D=P1.End.Replicate) (SRH SL=1, VPN SID) received by 
P1, 

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

d be happy to continue the arguement about the “VPN SID in Multicast” 
question,  along with many other questions that is still queued in my mind (as 
I mentioned previously).
It may need time for the authors to understand my comments in my experience 
[EXPERIENCE], and I would try to be patient for the understanding and 
discussion and hope I can get your great patience too.
I would also like to write a draft [DRAFT] to explain in detail about the 
impacts of SRv6-multicast approaches to SRv6 architecture in general for the WG 
to evaluate.


Thanks,
Jingrong


[REFERENCES] Following links are references that I have used in above mail or 
previous mails:

[1] https://mailarchive.ietf.org/arch/msg/spring/659RqpS2eOabwBpist6iH6nGgrw/

[2] https://mailarchive.ietf.org/arch/msg/spring/zo41ZDrH2Nq_xishIOly8ga19Ns/

[3] https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/

[4] https://mailarchive.ietf.org/arch/msg/spring/ou0V6vmWm4hlAk4I9Cuad1QXzIo/

[5] https://mailarchive.ietf.org/arch/msg/spring/DygdlzN2PiyXkN8RKjy3mb53mYE/

[6] https://datatracker.ietf.org/doc/html/draft-xie-bier-ipv6-mvpn-01

[7] https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-06
[8] https://mailarchive.ietf.org/arch/msg/spring/x49aMfShzK_mM3wf8_FRLoRgZYo/
[9] https://mailarchive.ietf.org/arch/msg/spring/FyoRJdW2fMx1yVid0ddl8Pz4QeY/


[EXPERIENCE]: Experience of comments to be understood and adopted in a very 
long time.
--TO BE provided.

[DRAFT]: About impacts of SRv6-multicast approaches to SRv6 architecture.
--TO BE provided.


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@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 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 however 
be revisiting this point in subsequent emails) and focus on bringing closure to 
the technical comments detailed in 
https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%3D=0>.

As I read through your comments Jingrong I think I can summarize your objection 
to be that you believe the proposal breaks the SRv6 architecture as the 
forwarding relies upon local state rather than state carried within the SRH. Do 
I have that right? If this is the case then you need to be specific in terms of 
which text/sentences in the document are in conflict with which text/sentences 
of existing RFCs. As written I think Rishabh’s forwarding example is accurate 
as he describes a lookup on the Replication SID and the action is to either 
update the outer IPv6 address with the downstream nodes address, or 
re-encapsulate the packet with a new IPv6 header and SRH. I might draw your 
attention to  
https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst 
which talks about the definition of future SIDs and their behaviors.

Further your comments appear to me to suggest that the VPN identification 
encapsulated at PE1 acts like a normal VPN SID in the sense that forwarding is 
based upon that IPv6 address. I don’t think that is the intent here; I think 
the SID is used as an identifier for the VPN itself so that the downstream 
nodes are given the correct VPN forwarding context i.e. they are not supposed 
to use that SID to forward the packets back to PE1. Perhaps the authors could 
clarify this point further?

Hi Rishabh, it would be helpful if you could review the comments in 
https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fdda

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

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 related the SR-Rep Segment and the VPN identifier.
The SR-Rep Segment provides the semantics/context for the many conflicting 
behaviors  the behavior of the {SR-Rep Segment + VPN Segment} together,  
and the behavior of normal SRv6.
If it is claimed that this draft is only about SR-rep segment itself, I don’t 
think it is toward to answer the “breaking SRv6 architecture” question.

For the point that “For the SRv6 dataplane, as the IPv6 destination address is 
modified en route …”
I have some similar comments previously, and I still have more comments on this 
topic but they are queued for the “breaking SRv6 architecture” comment above to 
be solved.

Thanks,
Jingrong

[8] https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, February 10, 2023 5:28 PM
To: Rishabh Parekh 
Cc: SPRING WG 
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

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.

--
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.

--
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

--
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.

Hope this helps.
Regards,
--Bruno



Orange Restricted
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of James Guichard
Sent: Tuesday, January 10, 2023 5:04 PM
To: SPRING WG mailto: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 mailto: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 

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Hi Gyan,

I don’t fully understand the “… local block similar to SR-MPLS SRGB called the 
GIB Global Segment ID Block … “.
Let me suppose it is “ … global block similar to SR-MPLS SRGB called the GIB 
Global Segment ID Block …”.

You say SRv6 Prefix SID is something global similar to SR-MPLS SRGB, and SRv6 
Adj-SID is something local and similar to SR-MPLS SRLB, and then VPN SID for 
multicast can be the same as Adj-SID.
That is exactly what I think is wrong and that’s the 2nd part of the “VPN SID 
in multicast” issue  SRv6 DCB SID for Multicast.

Because in Multicast, there are normally more than 1 egress PE, and each egress 
PE will have a unique Locator to allocate the VPN SID even you say it is “local 
SID”, and the SRH can not encode these VPN SIDs.
Comparably, in unicast, each node has a unique Locator to allocate “local SID” 
like 2001:db8:b:2::101 as End.X, it can be encoded in SRH SID List and not 
breaking the SRv6 architecture, though it is not the real practice we normally 
use SRv6 AFAIK.

Back to Multicast, one may claim that, each egress PE node configure the same 
Block and the same Locator and then the same “FUNCT” value, and then it is an 
SRv6 DCB SID.
However, as I questioned in [4] and I repeat it here: what is the 128bit DCB 
SRv6 SID looks like ? ::x:x:x:x:x:x? ff00:x:x:x:x:x:x:x? 
fe08:x:x:x:x:x:x:x? ::127.x.x.x ? (or maybe :::127.x.x.x) ?

Once the above question is answered, I think a conclusion can be reached that 
the SRv6 DCB SID is not an SRv6 SID because it does no longer have the 
“Locator” meaning, and hence break the SRv6 architecture.
Not to mention many other impacts like breaking the meaning of 
SRH/SID-list/Segment-Left/etc, and many conflicting behaviors beyond those have 
already listed in [5].


FYI: The 1st part in the “VPN Sid in multicast” issue is  SRv6 
Upstream-assigned SID for Multicast.
I have described a lot on this 1st part of issue, like the following [5], and I 
also give some suggestions toward solving the issue like the following [6] and 
[8].

[8] https://mailarchive.ietf.org/arch/msg/spring/iEyXYqthZSGNAqrBe3fLA8LKaKo/


Thanks,
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 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-replication-segment


Hi Jingrong

I am not sure this will help clarify.

Within an SRv6 domain a block is allocated for the SRv6 domain B:N::/48 where B 
is the block and N is the locator globally routable within the domain.

The SRv6 topological SID has a local block similar to SR-MPLS SRGB called the 
GIB Global Segment ID Block which the SRv6 locator prefix SID is assigned which 
is the N field made up of 16 bits, 64k global SIDs.

There is also a LIB Local Segment ID similar to SR-MPLS SRLB, which is used to 
dynamically assign SRv6 Adj-Sid End endpoint behavior and also used for L3 VPN 
or MVPN service SID or for L2 VPN EVPN pseudowires SID and has total of 8192 
SIDs.

“ There MAY be SIDs after the Replication SID in the SRH of a packet. These 
SIDs are used to provide additional context for processing a packet locally at 
the node where the Replication SID is the Active Segment. The processing of 
SIDs following the Replication SID MUST NOT forward the SRv6 packet to some 
other node. The restrictions described in this paragraph apply to both 
un-compressed and compressed SRv6 encapsulation.”

My interpretation is the SIDs following the Replication SID are service SIDs, 
maybe related MVPN SIDs on the egress PE to be processed on that node and not 
forwarded to another node.

Hope that helps.

Kind Regards

Gyan
On Thu, Jan 19, 2023 at 9:30 AM Xiejingrong (Jingrong) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi Rishabh, WG:

You say: “Your point [1] (Context SID in SRH), has already been discussed 
back-and-forth a few times in this thread.“
However, My core point that, the VPN SID (either Upstream-assigned or DCB) 
after the Replication SID, is breaking the SRv6 architecture, had never been 
directly answered  but always been ignored (and avoided I guess).
Example-1: Upstream-assigned VPN SID after the Replication SID, there are many 
details I have shown in [1], and there are many questions there. but you had 
always being ignored, and s

[spring] Request for comments on draft-xl-msr6-source-segment-02 //RE: WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

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.

Considering that there may be interests in the WG to learn more about how 
“Source address” could possibly solve the “SRv6 VPN SID in multicast” issue, I 
think it may be useful to read the draft [*] draft-xl-msr6-source-segment-02.

The draft is exactly about using SRv6 VPN SID in Multicast, and has considered 
SRv6-TreeSID already, but hasn’t got reviewed by Spring WG because of some 
reasons, among which is the argument that there is no need for multicast to be 
SRv6-copatible.

Now since there are interests of making SRv6-compatible multicast solution, I 
think it may be a proper time to review this draft.

We request comments on the draft from Spring WG, and remind to pay close 
attention if it has the issue of “breaking SRv6 architecture” that had on the 
WGLC draft.

[*]The draft 
https://www.ietf.org/archive/id/draft-xl-msr6-source-segment-02.html
[*]WGLC draft 
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/

Thanks,
Jingrong


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

/html/draft-xie-bier-ipv6-mvpn-01
[7] https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-06


本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed 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 by phone or email immediately 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 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, is processed. In our 
solution, a transit replication node does not process the SID in SRH. You on 
the other hand have not provided any pointers to back up your claim like any 
MUST clause that mandates processing SRH for a local SID.

For point [3] 
(https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/__;!!NEt6yMaO-gk!DaNN7hKLM7QHvhFUXVLHBjZiskVFZBxVGfqX5_RbBh2rht738yavbsN6sEKXY7k4I5A3GxZ3ZXeEiW5A6dGdlA5KGz6BQtPT$>),
 Jeffrey has addressed it in this response: 
https://mailarchive.ietf.org/arch/msg/spring/0e3eP8W78HOXbvUwDcYajx-LomQ/. The 
gist is that it is justifiably outside of the scope of this document. While it 
is outside the scope, to your point “there is no definition of … DCB in SRv6”, 
an IPv6 address is by nature from a “Domain-wide Common Block” because it is 
globally unique.

Thanks,
-Rishabh

On Fri, Jan 13, 2023 at 11:36 PM Xiejingrong (Jingrong) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
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 simply saying in [2] 
that:
“We have published the next revision of the draft addressing comments so far.”

I have being waiting for the authors to solve the issue #1, and then we can 
discuss the next issues one by one in detail.

But from the claim as shown above, I am fairly unsure if the authors are 
willing to  solve my comments.

Back to my previous comments [3], I want to suggest once again to the WG to 
kindly consider to first exclude SRv6 data plane of this draft from the WGLC 
scope and so we can discuss on SR-MPLS data plane.

[1] https://mailarchive.ietf.org/arch/msg/spring/659RqpS2eOabwBpist6iH6nGgrw/
r
[2] https://mailarchive.ietf.org/arch/msg/spring/zo41ZDrH2Nq_xishIOly8ga19Ns/

[3] https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/

Thanks
Jingrong

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed 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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] 
On Behalf Of James Guichard
Sent: Wednesday, January 11, 2023 12:04 AM
To: SPRING WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto: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 mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: WGLC for draft-ietf-spring-sr-re

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

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 simply saying in [2] 
that:
“We have published the next revision of the draft addressing comments so far.”

I have being waiting for the authors to solve the issue #1, and then we can 
discuss the next issues one by one in detail.

But from the claim as shown above, I am fairly unsure if the authors are 
willing to  solve my comments.

Back to my previous comments [3], I want to suggest once again to the WG to 
kindly consider to first exclude SRv6 data plane of this draft from the WGLC 
scope and so we can discuss on SR-MPLS data plane.

[1] https://mailarchive.ietf.org/arch/msg/spring/659RqpS2eOabwBpist6iH6nGgrw/
r
[2] https://mailarchive.ietf.org/arch/msg/spring/zo41ZDrH2Nq_xishIOly8ga19Ns/

[3] https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/

Thanks
Jingrong

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed 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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 11, 2023 12:04 AM
To: SPRING WG 
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 mailto: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


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Progressing the PBT-M “Zero Overhead property” draft

[Xiejingrong (Jingrong)]

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 telemetry in general, and 
Segment Routing is a solid use case for PBT-M to be adoption.  I like it and 
even prefer it personally.

I feel that, 9326 is a big compromise and entanglement between passport and 
postcard. Please correct me if I understand it wrong.

l  RFC9326 want to be “postcard” mode, as it states: This Option-Type is used 
as a trigger for IOAM data to be directly exported or locally aggregated 
without being pushed into in-flight data packets.

l  RFC9326 reuses RFC9197 as a base, and RFC9197 starts from an “postcard” 
mode, as it states: IOAM records OAM information within the packet while the 
packet traverses a particular network domain.

As I said above, I like and even prefer the idea of PBT-M, so I tend to agree 
with your points below, and I am willing to see the progress of this document.
However, I don’t have that strong POV. I can live with 9326 and PBT-M of this 
document to be parallel, and I would also like to hear the view points from the 
community.

“To make RFC 9326 viable out the gate for any operators to implement,  we 
really need the changes and updates to RFC 9326 described in this draft to be 
progressed.”
“This draft should be and I think the authors of this draft as well as the 
authors of RFC 9326 would as well agree that this draft should be Standards 
Track and update the base specification RFC 9326 for PBT. ”


Best Regards,
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Wednesday, December 14, 2022 11:25 AM
To: IETF IPPM WG ; SPRING WG 
Subject: [spring] Progressing the PBT-M “Zero Overhead property” draft


Dear IPPM WG

RE: Progressing draft-song-ippm-postcard-based-telemetry-15

I would like to provide some important feedback related to the draft and the 
critically of this draft to the industry at large especially with 5G MNOs and 
future soon to be 6G and UPF F1 interface network slicing and IPPM telemetry 
for Flex Algo latency constraint for ultra low latency path for MEC services 
and end to end ultra low latency path instantiation.

My POV as well as others whom I have discussed the draft in and outside the WG 
is that in order to make PBT viable and useful to operators to deploy, the 
changes and improvements described in this draft are very important and not 
just to the IPPM WG but to the industry at large namely for deployments of 
Segment Routing both SR-MPLS and SRv6  and viability of IOAM in-situ telemetry.

This is a huge issue today and PBT RFC 9326 is an attempt to solve the issues 
with telemetry with Segment Routing but unfortunately that is not enough and 
now with this draft, PBT based telemetry with Segment Routing can finally come 
to fruition for all operators around the world wanting to deploy Segment 
Routing.

I think with SR both SR-MPLS and SRv6 MSD and SR-MPLS Maximum readable label 
depth issues and MPLS MNA extensibility discussed in the MPLS Open DT meetings 
are important issues and considerations and with IOAM data with DEX PBT 
solution can possibly resolves the issue with the export with zero in-situ 
overhead philosophy and is a fabulous attempt but with a major hitch.

To make RFC 9326 viable out the gate for any operators to implement,  we really 
need the changes and updates to RFC 9326 described in this draft to be 
progressed.

This draft should be and I think the authors of this draft as well as the 
authors of RFC 9326 would as well agree that this draft should be Standards 
Track and update the base specification RFC 9326 for PBT.

I believe that would be the best path forward for the WG.

All comments are welcome on this important topic.

Many Thanks

Gyan
--

[图像已被发件人删除。]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Issue #1: VPN SID in Multicast //RE: WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

difference, 
and “breaking” the SRv6 that we normally understand it statelessly and 
self-description.


4. Now let me give another example from implementation point:
Suppose the VPN SID1 is installed in the FIB of PE2 [RFC8986], so that when the 
above example packet (SA=PE1, DA=PE2.Replicate){SL=1, VPNSID1}is received by 
PE2, and PE2 proceeds to VPN SID1, lookup VPN SID1 in FIB Entry, and behave to 
not sending this packet back to PE1.
Now, the application on PE2, the SRv6 Ping [RFC9259] is used and a packet 
(SA=PE1, DA=VPNSID1, NH=ICMPv6)(ICMPv6 echo request) is constructed. How does 
this PE2 data plane do  when it lookup VPN SID1 in FIB Entry ? does it send 
this packet to PE1 ?
One may say, when the above example packet (SA=PE1, DA=PE2.Replicate){SL=1, 
VPNSID1}is received by PE2, it does not lookup VPN SID1 in FIB Entry. Then what 
is the correct implementation ? has this VPN SID ever become “active SID” in 
the case ? is this VPN SID really an SRv6 SID semantically?


[1] self-description: RFC5655 is using this word, and I understand it as 
similar to “stateless”. Please correct me if it is not proper for SRv6 SRH/SL.

Thanks,
Jingrong

(Please also read the separate reply to each of your points embedded inline 
below marked with [XJR1223], as I mentioned in the beginning of the mail).

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email 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

Xingrong,
Replies inline @ [RP2]


On Sat, Dec 17, 2022 at 1:34 AM Xiejingrong (Jingrong) 
mailto:40huawei@dmarc.ietf.org>> 
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 encapsulate the received packet in an outer IPv6 header with SRH, as I 
assuming it, where IPv6 {DA = P1.Replicate}, SRH {SL=1, VPNSID1, P1.Replicate} 
so the VPNSID1 is after the Rep SID.
3. P1 receives the packet, with the destination address being P1.End.Replicate, 
replicates the packet and sends to PE2 and PE3, with the destination address 
changed to PE2.End.Replicate and PE3.End.Replicate respectively.
//Look, the active SID is P1.End.Replicate, and the packet of the received 
packet with SRH is meaning, by its semantics in current SRv6 architecture, that 
the packet should then be proceeded to the Next SID (VPN SID1). The Locator of 
the VPN SID1 is PE1, and the packet should go to PE1.  Correct ?

[RP2] SRv6 architecture does not mandate SRH processing for a local SID. From 
RFC 8986:

Section 1 Introduction:
A function is locally defined on the node where it is executed and may range 
from simply moving forward in the segment list to any complex user-defined 
behavior

Section 4  SR Endpoint Behaviors
The list is not exhaustive. In practice, any behavior can be attached to a 
local SID; for example, a node N can bind a SID to a local Virtual Machine (VM) 
or container that can apply any complex processing on the packet, provided 
there is an SRv6 Endpoint Behavior codepoint allocated for the processing.

P1 is a pure Replication Node, it will just replicate incoming packet as 
(SA=PE1, DA=PE2.Replicate){SL=1, VPNSID1} and {SA=PE1, DA=PE3.Replicate){SL=1, 
VPNSID1} to PE2 and PE3 respectively. PE2 and PE3 as Leaf nodes will process 
the SRH and the upper layer header.

[XJR1223] Please see above my reply and more detailed explanation.

//Or maybe one may say, the SRH in step 2 is {SL=0, VPNSID1, P1.Replicate}.  
Then why “hiding” the VPNSID1 in the SRH that is determined not to use (SL=0) ? 
IMO It is breaking SRv6 by the “hiding” things that is not semantically 
suitable in SRv6 SRH.  DOH is a much better choice if, for any reason, the 
source address as I suggested above is not the taste.

[RP2] There is no “hiding” as explained above.
[XJR1223] Good to know that VPNSID1 is not hiding, but explicitly placed in SRH 
with SL=1 to indicating. So we can focus the discussion on above case.

//Or maybe one may say, the VPN SID is allocated from an “Global unique” space 
named “DCB”. I would request the authors and WG to define that since I really 
don’t understand it. Let me cite RFC8986 section 3.2:  “Assign a unique 
B:N::/64 block to each S

[spring] Issue #1: VPN SID in Multicast //RE: WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Hi WG,

It seems like the technical concerns raised in my previous mails are not fully 
understood, or taken seriously toward solving them, as I understand the reply.
To make my comments clear, please allow me to make them one by one, toward 
solving it collaboratively by giving my opinion on each one, and explain why I 
think SRv6 is broken by current proposal.
Thank you Rishabh, and please see my reply to each of your points in the mail 
inline below with [XJR].  Don’t worry if they are not clear, as said they will 
be brought up one by one like below the issue #1.

Issue #1: VPN SID in Multicast.

Topology: Src1PE1P1PE2/PE3Rcv2/Rcv3(connected to PE2/PE3 
respectively)

My Opinion toward solving the technical issue:
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, and advertise them to PE2 and PE3.
2. PE1 encapsulates the received packet in an outer IPv6 header, where the 
destination address is P1.End.Replicate, and the source address is the VPN SID 
1, 2 or 3, determined by the VRF the received packet belonging to.
3. P1 receive the packet, with the destination address being P1.End.Replicate, 
the packet is replicated and sent to PE2 and PE3, with the destination address 
changed to PE2.End.Replicate and PE3.End.Replicate respectively.
4. PE2/PE3 use this VPN SID 1, as in the source address of the packet, to 
determine the VPN of the packet, and do the table lookup in the VPN for the 
decapsulated (inner) packet.
5. PE2/PE3 can ping/traceroute this VPN SID 1/2/3 using RFC9259, or send ICMPv6 
error message back to this VPN SID as a result of an exceptional condition of 
above 3 to 4.


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 encapsulate the received packet in an outer IPv6 header with SRH, as I 
assuming it, where IPv6 {DA = P1.Replicate}, SRH {SL=1, VPNSID1, P1.Replicate} 
so the VPNSID1 is after the Rep SID.
3. P1 receives the packet, with the destination address being P1.End.Replicate, 
replicates the packet and sends to PE2 and PE3, with the destination address 
changed to PE2.End.Replicate and PE3.End.Replicate respectively.
//Look, the active SID is P1.End.Replicate, and the packet of the received 
packet with SRH is meaning, by its semantics in current SRv6 architecture, that 
the packet should then be proceeded to the Next SID (VPN SID1). The Locator of 
the VPN SID1 is PE1, and the packet should go to PE1.  Correct ?
//Or maybe one may say, the SRH in step 2 is {SL=0, VPNSID1, P1.Replicate}.  
Then why “hiding” the VPNSID1 in the SRH that is determined not to use (SL=0) ? 
IMO It is breaking SRv6 by the “hiding” things that is not semantically 
suitable in SRv6 SRH.  DOH is a much better choice if, for any reason, the 
source address as I suggested above is not the taste.
//Or maybe one may say, the VPN SID is allocated from an “Global unique” space 
named “DCB”. I would request the authors and WG to define that since I really 
don’t understand it. Let me cite RFC8986 section 3.2:  “Assign a unique 
B:N::/64 block to each SRv6-enabled node in the domain”.


Thanks,
Jingrong


本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed 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 by phone or email immediately and 
delete it!

From: Rishabh Parekh [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 (Jingrong) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi WG and chairs,

I would like to draw your attention that, the SRv6 Replication SID will break 
SRv6 architecture, scope and restrictions in many aspects.

Though it is still not defined what is the scope of “context”, leaving a big 
“hole” to explain in the future.

 [RP] It is natural to extend the concept of Replication SID as SR-MPLS label 
to a SRv6 Endpoint behavior represented by FUNCT bits of SRv6 SID. I don’t 
think this “… break[s] SRv6 architecture, scope and restrictions in many 
aspects”.
First of this document does not mandate the “context” SID following the SRv6 
Replication SID; it just lays down the purpose and restriction on SIDs 
following the Replication SID. Second, this draft makes it clear that the

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Please allow me to add some notes to my comments below for your understanding:
1. “ICMPv6 error message MUST NOT be originated as a result of receiving … a 
packet destined to an IPv6 multicast address” is from RFC4443, to prevent a 
reflection amplification DDoS attack in my understanding.
2. Upstream-assigned or DCB SRv6 SID:  as mentioned by Rishabh (thank you), 
described in SR P2MP 
MVPN<https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/> draft.
3. Suppose a DCB SRv6 SID, what is the 128bit DCB SRv6 SID looks like ? 
::x:x:x:x:x:x? ff00:x:x:x:x:x:x:x? 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] WGLC for draft-ietf-spring-sr-replication-segment

Hi WG and chairs,

I would like to draw your attention that, the SRv6 Replication SID will break 
SRv6 architecture, scope and restrictions in many aspects.

Though it is still not defined what is the scope of “context”, leaving a big 
“hole” to explain in the future.

But through the past discussions we have known a little about it, for example, 
used as a VPN identifier in multicast scenario.

However, I think the Upstream-assigned SID or “DCB” SID in SRv6 for “context” 
need to be carefully evaluated by the WG.

Firstly, there is no definition of “Upstream-assigned SID” or “DCB” in SRv6.

Secondly, suppose an Ingress PE allocated an “Upstream-assigned SID” from its 
locator, and put the SID into the SID list after the Replication SID, what is 
expected to behave on every replication node to this Upstream-assigned SID ? 
make it an active SID, and then take it as a context ? or send it back to the 
Ingress PE ?

Further, I think there are many other differences between SRv6 data plane and 
MPLS data plane for a “Replication SID” to work in its multicast scenario 
context. For example, how is the “host originating an IPv6 packet” scenario 
(RFC8754,8986) supported ? How does the “ICMPv6 error message MUST NOT be 
originated as a result of receiving … a packet destined to an IPv6 multicast 
address” may be considered ?

In a word, the Replication SID in SRv6 data plane, is far from being a simple 
copy of MPLS data plane.

Note that, SRv6 has its unique characteristic that need to define its specific 
specification, like RFC8754,8986,9259, etc etc.

Also note that, the implementations disclosed in section 4.1 and 4.2 only 
include MPLS data plane. I assume they reflect the fact that Replication SID 
for SRv6 data plane is far from mature. Therefore I request the WG to first 
exclude SRv6 data plane of this draft from the WGLC scope. Then we can focus on 
the MPLS data plane part (Hopefully I can move from SRv6 problems if they are 
noted already, and then I can provide some comments on MPLS soon).

Thanks,
Jingrong


本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed 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 by phone or email immediately and 
delete it!

From: Rishabh Parekh [mailto:risha...@gmail.com]
Sent: Thursday, December 8, 2022 6:52 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: James Guichard 
mailto:james.n.guich...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>; 
spring-cha...@ietf.org<mailto: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 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 relatively 
unique index/offset ) ?
In SRv6 data plane, is the SID an “Upstream-assigned SRv6 SID”, which is 
allocated on Ingress PE and put in the SID list after the replication SID ?

The VPN SID is only required when SR P2MP trees are shared across VPNs. It can 
be upstream assigned or globally assigned (from DCB) as described in SR P2MP 
MVPN<https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/> 
draft. If present, the VPN SID is after the Replication SID. For SR-MPLS, the 
VPN SID SHOULD NOT be assigned from SRGB or SRLB since it is an overlay context,

-Rishabh
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Hi WG and chairs,

I would like to draw your attention that, the SRv6 Replication SID will break 
SRv6 architecture, scope and restrictions in many aspects.

Though it is still not defined what is the scope of “context”, leaving a big 
“hole” to explain in the future.

But through the past discussions we have known a little about it, for example, 
used as a VPN identifier in multicast scenario.

However, I think the Upstream-assigned SID or “DCB” SID in SRv6 for “context” 
need to be carefully evaluated by the WG.

Firstly, there is no definition of “Upstream-assigned SID” or “DCB” in SRv6.

Secondly, suppose an Ingress PE allocated an “Upstream-assigned SID” from its 
locator, and put the SID into the SID list after the Replication SID, what is 
expected to behave on every replication node to this Upstream-assigned SID ? 
make it an active SID, and then take it as a context ? or send it back to the 
Ingress PE ?

Further, I think there are many other differences between SRv6 data plane and 
MPLS data plane for a “Replication SID” to work in its multicast scenario 
context. For example, how is the “host originating an IPv6 packet” scenario 
(RFC8754,8986) supported ? How does the “ICMPv6 error message MUST NOT be 
originated as a result of receiving … a packet destined to an IPv6 multicast 
address” may be considered ?

In a word, the Replication SID in SRv6 data plane, is far from being a simple 
copy of MPLS data plane.

Note that, SRv6 has its unique characteristic that need to define its specific 
specification, like RFC8754,8986,9259, etc etc.

Also note that, the implementations disclosed in section 4.1 and 4.2 only 
include MPLS data plane. I assume they reflect the fact that Replication SID 
for SRv6 data plane is far from mature. Therefore I request the WG to first 
exclude SRv6 data plane of this draft from the WGLC scope. Then we can focus on 
the MPLS data plane part (Hopefully I can move from SRv6 problems if they are 
noted already, and then I can provide some comments on MPLS soon).

Thanks,
Jingrong


本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed 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 by phone or email immediately and 
delete 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 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 relatively 
unique index/offset ) ?
In SRv6 data plane, is the SID an “Upstream-assigned SRv6 SID”, which is 
allocated on Ingress PE and put in the SID list after the replication SID ?

The VPN SID is only required when SR P2MP trees are shared across VPNs. It can 
be upstream assigned or globally assigned (from DCB) as described in SR P2MP 
MVPN<https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/> 
draft. If present, the VPN SID is after the Replication SID. For SR-MPLS, the 
VPN SID SHOULD NOT be assigned from SRGB or SRLB since it is an overlay context,

-Rishabh
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Hi Rishabh,

Thank you for your reply very much.
For MPLS data plane, it may be nice to introduce DCB concept since it is 
different than SRGB or SRLB.
For SRv6 data plane, is it the same as MPLS that has a concept like “DCB” to 
allocate an SRv6 SID and put after the replication SID ?

-Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete 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 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 relatively 
unique index/offset ) ?
In SRv6 data plane, is the SID an “Upstream-assigned SRv6 SID”, which is 
allocated on Ingress PE and put in the SID list after the replication SID ?

The VPN SID is only required when SR P2MP trees are shared across VPNs. It can 
be upstream assigned or globally assigned (from DCB) as described in SR P2MP 
MVPN<https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/> 
draft. If present, the VPN SID is after the Replication SID. For SR-MPLS, the 
VPN SID SHOULD NOT be assigned from SRGB or SRLB since it is an overlay context,

-Rishabh
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

Hi Rishabh,

The first question is solved. Thank you for taking the comment into 
consideration.
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 relatively 
unique index/offset ) ?
In SRv6 data plane, is the SID an “Upstream-assigned SRv6 SID”, which is 
allocated on Ingress PE and put in the SID list after the replication SID ?

Thanks
Jingrong


From: Rishabh 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 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 explain the two things and why MUST NOT ?

SIDs in the segment list guide a packet to a Downstream Node, typically along a 
specific path. For example, the SR-MPLS Node SID of the downstream node in 
segment list can be used for this. An Anycast SID by definition belongs to two 
or more nodes and a packet is forwarded to only one of the nodes in an Anycast 
set. Therefore, Anycast SID of the downstream nodes cannot be used in the 
segment list. I realize now this restriction is really for SIDs identifying the 
downstream node, not for intermediate nodes in path from Replication node to 
the downstream node. I will see if we can make this clear in the next revision 
of the document.

For BGP, we should have specified "BGP PeerSet SID" (RFC 8402 Section 4.2) to 
be exact. The reason is the same as the Anycast SID restriction.

I feel hard to understand how the SIDs after the Replication SID are used. Does 
it mean a “VPN SID” or something like that ?

The SIDs after the Replication SID provide additional context for processing 
the packet at the downstream node. "VPN SID" is one example of a context.

Thanks,
Rishabh.

On Mon, Dec 5, 2022 at 6:54 PM Xiejingrong (Jingrong) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
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 appear in seg list preceding a Replication SID.
Can you please explain the two things and why MUST NOT ?

In Section 2.1, it says below:
  There MAY be SIDs after the
  Replication SID in the segment list of a packet. 
These SIDs are used
  to provide additional context for processing a 
packet locally at the
  node where the Replication SID is the Active 
Segment.  The processing
  of SIDs following the Replication SID MUST NOT 
forward the SR-MPLS
  packet to another node.
In Section 2.2, it says below:
  There MAY be SIDs after the Replication
  SID in the SRH of a packet.  These SIDs are used 
to provide
  additional context for processing a packet 
locally at the node where
  the Replication SID is the Active Segment.  The 
processing of SIDs
  following the Replication SID MUST NOT forward 
the SRv6 packet to
  some other node.  The restrictions described in 
this paragraph apply
  to both un-compressed and compressed SRv6 
encapsulation.
I feel hard to understand how the SIDs after the Replication SID are used. Does 
it mean a “VPN SID” or something like that ?

Thanks
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] 
On Behalf Of James Guichard
Sent: Monday, November 28, 2022 11:10 PM
To: SPRING WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:sprin

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

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 multipoint 
transport behavior statelessly.

This Spring document [1] uses an SRv6 SID and IPv6 extension header.
The MSR6 document [2] uses an SRv6 SID and IPv6 extension header.

This document [1] clearly stated that “...to establish P2MP trees in SR domain”.
The document [3], as the preceding research of MSR6,  stated that, “… the 
BIERv6 domain is the same as SRv6 domain”.

This document [1] clearly demonstrates how the idea of “using a unicast 
forwarding plane to perform multipoint transport” is adopted.
This argument [4] about MSR6 is that “using a unicast forwarding plane to 
perform multipoint transport” is bad/failed idea (please correct me if I 
understand it wrong).

This Spring document[1] has reached its lastcall in the wide IETF community.
The MSR6 document [2], and the preceding research[3], has been blocked  since 
2019(may be earlier than the End.Replicate), and the claim about it had been 
variable over time:

l  Firstly, the claim was that, SRv6 is a new thing and unmature and some 
terriable hijack.

l  And then, the claim was that, it does not comply with BIER architecture.

l  And then, the claim was that, the BIER wg don’t need it or work on it.

l  And then, the claim was that, the MSR6 makes no difference than BIER.

l  And sometimes, the claim was that, using unicast forwarding plane is 
bad/failed (loop).
(Due to the so long timeline of these discussions, I do not have the link on 
each of above claim, but if it is interested, I can try to find them)

Thanks,
Jingrong

[1] 
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
[2] https://datatracker.ietf.org/doc/draft-lx-msr6-rgb-segment/
[3] https://datatracker.ietf.org/doc/html/draft-xie-bier-ipv6-encapsulation-10
[4] https://mailarchive.ietf.org/arch/msg/msr6/eMUWpjSbo3THJLEXe_t1Pt5PTyc/


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: pim [mailto:pim-boun...@ietf.org] On Behalf Of James Guichard
Sent: Tuesday, November 29, 2022 12:26 AM
To: p...@ietf.org
Subject: [pim] Fwd: WGLC for draft-ietf-spring-sr-replication-segment

FYI

Get Outlook for iOS

From: James Guichard 
mailto:james.n.guich...@futurewei.com>>
Sent: Monday, November 28, 2022 10:10 AM
To: SPRING WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org 
mailto: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


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Xiejingrong (Jingrong)]

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 appear in seg list preceding a Replication SID.
Can you please explain the two things and why MUST NOT ?

In Section 2.1, it says below:
  There MAY be SIDs after the
  Replication SID in the segment list of a packet. 
These SIDs are used
  to provide additional context for processing a 
packet locally at the
  node where the Replication SID is the Active 
Segment.  The processing
  of SIDs following the Replication SID MUST NOT 
forward the SR-MPLS
  packet to another node.
In Section 2.2, it says below:
  There MAY be SIDs after the Replication
  SID in the SRH of a packet.  These SIDs are used 
to provide
  additional context for processing a packet 
locally at the node where
  the Replication SID is the Active Segment.  The 
processing of SIDs
  following the Replication SID MUST NOT forward 
the SRv6 packet to
  some other node.  The restrictions described in 
this paragraph apply
  to both un-compressed and compressed SRv6 
encapsulation.
I feel hard to understand how the SIDs after the Replication SID are used. Does 
it mean a “VPN SID” or something like that ?

Thanks
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Monday, November 28, 2022 11:10 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
Subject: [spring] 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


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [IPv6] Pls comment: On core BIER/MSR6 differentiation

[Xiejingrong (Jingrong)]

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 which is another Layer-2.5 technology 
parallel to MPLS, and assuming to configure "bier-non-mpls enable" instead of 
"mpls enable" on every link of a BIER-domain before anything goes).
Architectural: BIER multicast is not IP multicast, and MSR6 is.

Cheers,
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!

-Original Message-
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Toerless Eckert
Sent: Wednesday, October 26, 2022 12:24 AM
To: 6...@ietf.org; m...@ietf.org; p...@ietf.org; spring@ietf.org
Subject: [IPv6] Pls comment: On core BIER/MSR6 differentiation

Dear colleagues

I wanted to explain and get feedback on one of the IMHO core differences 
between MSR6 and BIER which is so far only in one draft-eckert-msr6-rbs, and we 
could not present solutions at IETF115, and this proposed architectural 
difference only got a few seconds during one of the problems slides at the MSR6 
BoF, and i also don't think we have agreed on this point in the MSR6 community.

So:

If i understand BIER, it was designed as a single-forwarding-fits-all network 
layer stateless source-routing multicast solution. To make it applicable to any 
network protocol or other traffic, it encapsulates that trafic end-to-end 
(BFIR-BFER), which it calls flow-overlay.
IMHO, on this aspect, BIER is very much designed like MPLS for the flow overlay 
and SR-MPLS for the source-routing, both of which made that concept popular and 
successful.  Those MPLS network are also the ones where the BIER architecture 
most reasonate with.

But we also have a well established communities in the IETF that did not pick 
this approach to build networks, but wanted where building contrlled networks 
based on IPv6. The first community to do this was of course the IoT community, 
where RFC6554 is the most common source-routing header.
And i do not think these communities would be asked to do MPLS instead of IPv6 
based designs if they would start today.

Then of course there is SRv6 with the SRH source routing header RFC8754 for 
higher speed
IPv6 networks. Those IPv6 networks too where not asked to convert to MPLS when 
they needed to get the benefit of source routing. Instead, we choose the much 
more prudent option to build a common source-routing architecture (Segment 
Routing) and map it to the forwarding/encapsulation paradigm that matches the 
customers existing network design best (MPLS and IPv6): operational and 
architectural. [ An aproach actually i think we should also take in stateless 
multicast:
share everything that can be shared across BIER and MSR6, but not force one 
type of networks to change their overall architecture because the other network 
design was there earlier. I can not fathom how this is even a reasonable 
argument in the IETF (do not use IPv6), but thats what i heard repeatedly. ]

Now enter the multicast side. The ask i heard at and after MSR6 bof is that its 
seemingly ok. for the IETF to ask operators of networks with multiple hundred 
million users who have long ago choosen IPv6 as their network architecture to 
not standardize in the IETF a network forwarding architecture for multicast 
that is aligned with their IPv6 unicast network architecture - but insted 
create a whole new parallel architecture (BIER). This is exactly the opposite 
of how the IETF has build multicast solutions for 20 years (see point 3.5 of 
draft-eckert-msr6-problem-statement). Instead, BIER-WG explains how to 
perfectly tunnel bier over IPv6 links and then IPv6 over BIER, and calls it the 
best fitting way to do source routing end-to-end in an IPv6 network (see point 
3.5.3). This is about as fitting for an
IPv6 network as it was to use IPv4 multicast in support of MVPN in MPLS 
networks. Which indeed the industry asked customer to do. And those of us who 
worked these solutions back then knew what happened (see point 3.5.1). Anyhow, 
i digress.

In any case: MSR6 is meant to be an end-to-end (obviously stateless) 
source-routing solutions for multicast in any (controlled) IPv6 network. And 
like in the unicast solutions, this means that this does not chane the fact 
that it represents an 

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

[Xiejingrong (Jingrong)]

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 ; 6man ; spring@ietf.org; 
6man Chairs <6man-cha...@ietf.org>; draft-ietf-6man-sids.auth...@ietf.org; 
spring-cha...@ietf.org
Subject: Re: 6MAN WGLC: draft-ietf-6man-sids

Hi Jingrong,
  Thanks for your detailed comments. Please find responses inline.

> On Sep 29, 2022, at 5:53 AM, Xiejingrong (Jingrong)  
> wrote:
> 
> 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 source node may be a border router of an SRv6 domain encapsulating a 
> received packet and transform it an SRv6 packet ...
> ==>Therefore I would suggest this sentence to be more aligned with 
> RFC8402/8754/8986.

I agree with both of your characterizations but in either of the cases, the 
outer IPv6 packet in question is what we are dealing with in 6man and the 
source address of the packet would be the address of the node that initiated 
the packet with SRH. Please let me know if this clarifies the point.
[XJR] OK. 

> 
> Section 3 "[RFC8986] defines the Segment List of the SRH as a contiguous 
> array"
> ==>Segment List should be Segments List (Segment change to Segments).

From what I see in the pseudo-code line S14 in Section 4.1, 4.13 and 4.15 of 
RFC8986 I only see "Segment List[Segments Left]”. Can you please let me know 
where you are getting the “Segments List” terminology?
[XJR] Sorry I was confused. You are correct on "Segment List" and "Segments 
Left". 

> ==>[RFC8986] does not defines the Segments Left of SRH, but refer it to 
> RFC8200, which defines the Segments Left of any kind of RH.

> 
> Section 3 "One of the key questions to address is how these SRv6 SID 
> appearing as IPv6 Destination Addresses are perceived and treated by transit 
> nodes".
> ==>I am wondering that if this is also a question need to consider: how a 
> packet with the SRv6 SID appearing as IPv6 DA may be treated by an SRv6 
> endpoint node or even SRv6 source node.

Isn’t that simply SRv6 endpoint behavior? Can you please clarify what you are 
looking for here.
[XJR] My concern is that, when an SRv6 source node ping (RFC9259 ICMPv6-based 
ping) a C-SID List encoded in DA (without an SRH in the packet), the ICMPv6 
checksum may be incorrect along the path until it reach the final destination 
node. 

> 
> Section 4 "The C-SID document describes how to use a single entry in the SRH 
> list as a container for multiple SIDs ..."
> ==>The term "SRH list" is not appeared in the document, or other SRv6 RFCs 
> 8402/8754/8986. I am assuming it is "SID List".

Yes. Good point. I think it might be better to change this to Segment List as 
defined in RFC8754.
[XJR] OK.

> 
> Section 4 "The destination address field of the packet changes at a segment 
> endpoint in a way similar to how the address changes as the result of 
> processing a segment in the SRH".
> ==>Assuming this sentence is describing the change of destination address of 
> a packet without an SRH at segment endpoint, there is a question:
> ==>RFC8200 says in the end of section 3, explaining the meaning of 
> Destination address of an IPv6 header: "128-bit address of the intended 
> recipient of the packet (possibly not the ultimate recipient, if a Routing 
> header is present). See [RFC4291] and Section 4.4."
> ==>Does this document need to clarify on this ? That is to say, when there is 
> no Routing Header present, but the destination address of a packet is changed 
> by a segment endpoint. 

I am not sure there is a condition for "no Routing header to be present" for 
this sentence to be true. i.e. this holds true either way.
[XJR] Yes I mean in the condition that "no Routing header present" in a packet, 
the destination address of the packet is changed by a segment endpoint. Such 
behavior may not aligned well with RFC8200 ? See also the ping case I mentioned 
above.

> 
> Section 4.1 "This draft needs to provide an updated definition for the 
> SegmentsLeft field of the SRH"
> ==>SegmentsLeft should change to Segments Left.
> ==>Since Segments Left defined in RFC8200 is to be updated, should this 
> document be standard track and marked with updating RFC8200 ? 
> ==>Also since segments left is to be up

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

[Xiejingrong (Jingrong)]

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 source node may be a border router of an SRv6 domain encapsulating a 
received packet and transform it an SRv6 packet ...
==>Therefore I would suggest this sentence to be more aligned with 
RFC8402/8754/8986.

Section 3 "[RFC8986] defines the Segment List of the SRH as a contiguous array"
==>Segment List should be Segments List (Segment change to Segments).
==>[RFC8986] does not defines the Segments Left of SRH, but refer it to 
RFC8200, which defines the Segments Left of any kind of RH.

Section 3 "One of the key questions to address is how these SRv6 SID appearing 
as IPv6 Destination Addresses are perceived and treated by transit nodes".
==>I am wondering that if this is also a question need to consider: how a 
packet with the SRv6 SID appearing as IPv6 DA may be treated by an SRv6 
endpoint node or even SRv6 source node.

Section 4 "The C-SID document describes how to use a single entry in the SRH 
list as a container for multiple SIDs ..."
==>The term "SRH list" is not appeared in the document, or other SRv6 RFCs 
8402/8754/8986. I am assuming it is "SID List".

Section 4 "The destination address field of the packet changes at a segment 
endpoint in a way similar to how the address changes as the result of 
processing a segment in the SRH".
==>Assuming this sentence is describing the change of destination address of a 
packet without an SRH at segment endpoint, there is a question:
==>RFC8200 says in the end of section 3, explaining the meaning of Destination 
address of an IPv6 header: "128-bit address of the intended recipient of the 
packet (possibly not the ultimate recipient, if a Routing header is present). 
See [RFC4291] and Section 4.4."
==>Does this document need to clarify on this ? That is to say, when there is 
no Routing Header present, but the destination address of a packet is changed 
by a segment endpoint. 

Section 4.1 "This draft needs to provide an updated definition for the 
SegmentsLeft field of the SRH"
==>SegmentsLeft should change to Segments Left.
==>Since Segments Left defined in RFC8200 is to be updated, should this 
document be standard track and marked with updating RFC8200 ? 
==>Also since segments left is to be updated, should these also be considered: 
https://www.rfc-editor.org/errata/eid7081 and draft-zhou-spring-srh-le-change ?

Section 5 " it might be prudent to allocate some address space that explicitly 
signals that ..."
==>Considering that, SRv6 node may be a router or a host, and signals may be 
more preferred for router but less preferred for host. Does this need to be 
clarified ?

Section 6 "IANA is requested to assign a /16 address block"
==>Is this a determined proposal to use a /16 address block from "Reserved by 
IETF" range of IPv6 address space ? Will such a usage be mandatory or optional 
for compressed-SRv6 only or even for all SRv6 ?

Thanks
Jingrong

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is listed 
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 by phone or email immediately and 
delete it!


-Original Message-
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Jen Linkova
Sent: Saturday, September 17, 2022 4:00 PM
To: 6man ; spring@ietf.org
Cc: 6man Chairs <6man-cha...@ietf.org>; draft-ietf-6man-sids.auth...@ietf.org; 
spring-cha...@ietf.org
Subject: 6MAN WGLC: draft-ietf-6man-sids

Hello,

This email starts the 6man Working Group Last Call for the "Segment Identifiers 
in SRv6" draft (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids).

The WGLC ends on Tue, Oct 4, 23:59:59 UTC.

 As the document is closely related to the work in the SPRING WG, we'd like the 
SPRING WG to review the document and discuss the following
questions:

- the action items required from SPRING (Section 4.1 and 4.2 of the draft, 
https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4)
[*]. Would it make sense to merge those open issues with the 'Open Issues' 
section of the SPRING document?
-  whether the document needs more guidance regarding routability of
/16 or such requirements shall belong to some other document?  In particular,  
shall we specify that it MUST NOT be in the DFZ? Or setting 'Globally Reachable 
= false' in the registry should be sufficient? The current idea is that the 

Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

[Xiejingrong (Jingrong)]

Hello Eduard,

Thank you for reading and the positive feedback on this draft.
Your interpretation in the first sentence is basically correct but incomplete.
This draft is about how to expose transport service / capabilities for 
consumption by overlay networks, and this point is very precisely caught(twice) 
in your mail.
The exposing of the transport service to overlay network outside is abstracted 
as an "Interface", and is proposed to use SRv6 in this draft.
However, the transport service is not limited to SRv6-based transport service, 
but can be implemented independently of the Interface spec, for example, can be 
implemented using SRv6 or MPLS.

For the suggestion to clarify the scope, I would think about how to clarify, 
and send the proposed text to mailing-list for discussion.

Before this, I would like to share my points and hope it useful to understand 
the draft for you all.

1) Currently SRv6 SIDs are mainly used inside a TN, and hence the "Net-PGM 
Instruction" is an appropriate description, and it is easy to understand as the 
limited-domain is TN.

2) The draft is describing an "Net-PGM Interface" that is exposed outside a TN. 
Once exposed, the use of the SRv6 SID is in the "Overlay network", and hence 
the limited-domain is the Overlay network.

3) The Overlay network is an administrative domain, and the SRv6 domain is only 
part of the Overlay network.
   For example, in the figure in 
https://mailarchive.ietf.org/arch/msg/spring/Y21yvJO-I2ex-8VNSjoDbWA9qCk/ , the 
CPE1, CPE2 and the exposed Interface of TN1 is an SRv6 domain, but CPE3 is not 
the SRv6 domain.

4) An Overlay network may uses N Transport-Networks, and there could be N SRv6 
domains, each surrounding a TN.


Regards,
Jingrong

From: Eduard Metz [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 Using SRv6 
(draft-xie-spring-srv6-npi-for-overlay)

Hello Jingrong,

I haven't read your draft in detail yet, but the question of how to expose SRv6 
based transport service / capabilities for consumption by overlay networks I 
think is an interesting one.

I'm not sure whether the reference figure (5) already conflicts with "limited 
domain", assuming one would expose such services only to a controlled set of 
CPE I would say it doesn't. I have to agree with others who commented that the 
scope of the draft is not fully clear though. It suggests to aim to solve 
"interdomain" cases, while in the solution part the focus seems to be again on 
the question of how to expose services.

It would help if the scope is clarified.
By the way, I interpreted the scope as described in the first sentence above, 
is this correct?

cheers,
  Eduard



On Mon, Mar 14, 2022 at 4:17 PM Andrew Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>> 
wrote:
Jingrong,

Limited Domain (in my view) refers to a domain where all points are under 
single administrative control.  I.E the source, destination and anything in the 
middle must fall under the same administrative control, otherwise, you are not 
within the limited domain.  This can be extended using encapsulation 
(tunneling) where the packet is encapsulated and preferably cryptographically 
protected, such that any intermediate networks outside of the same 
administrative control cannot, either by error or deliberate action, act on the 
information contained within the routing headers.

Anything else would run into issues with section 8.2 of RFC8402.

Thanks

Andrew


From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Xiejingrong (Jingrong)
Sent: Monday, March 14, 2022 10:16 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>; Andrew 
Alston - IETF mailto:andrew-i...@liquid.tech>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Tom Hill 
mailto:t...@ninjabadger.net>>
Subject: Re: [spring] Network Programming Interface for Provisioning of 
Underlay Services to Overlay Networks Using SRv6 
(draft-xie-spring-srv6-npi-for-overlay)

Hi,

I think I now understand better the concern about "the use of SIDs over the 
public Internet".
In my previous mail, the SID2/SID3 used between CPE2-Internet-CPE3 is to 
explain the layering model (over vs across), but it is not the proposal of the 
draft.
The draft is talking about the interface (name NPI) that overlay networks use 
to access the underlying network in the last mile.
There may be an Access Network (AN) in the last mile, and the AN may also 
connect to Internet backbone and/or multiple underlying networks, but it is 
distinct from the "open Internet".
Make more sense if the AN can enhance (if no way to enforce) not to leak the 
SRv6 BSID to Internet backbone or other TNs ?

For the control plane

Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

[Xiejingrong (Jingrong)]

Hi,

I think I now understand better the concern about "the use of SIDs over the 
public Internet".
In my previous mail, the SID2/SID3 used between CPE2-Internet-CPE3 is to 
explain the layering model (over vs across), but it is not the proposal of the 
draft.
The draft is talking about the interface (name NPI) that overlay networks use 
to access the underlying network in the last mile.
There may be an Access Network (AN) in the last mile, and the AN may also 
connect to Internet backbone and/or multiple underlying networks, but it is 
distinct from the "open Internet".
Make more sense if the AN can enhance (if no way to enforce) not to leak the 
SRv6 BSID to Internet backbone or other TNs ?

For the control plane, it is still not clear if a controller is required, but 
one thing I considered is to use an IETF standard protocol because the PE need 
to implement 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 Networks Using SRv6 
(draft-xie-spring-srv6-npi-for-overlay)

Hi Jingrong

I reads the draft and was trying to understand the problem statement as well as 
the solution.

So I believe the problem statement is how to interconnect desperate sites over 
the internet using a managed IPSEC VPN or SDWAN solution or managed MPLS and 
complexity of provisioning CE attachment.

The solution is an automated solution using SRv6 over the internet using BSID.  
This involves running SRv6 over the internet, however SRv6 is limited to closed 
domains.  It appears an E2E pseudowire is used in provisioning the service.  
Have you though of using NG L2 VPN EVPN all or single active multi home over 
SRv6.

Does all the provisioning use a PCE / SDN controller?


Thanks

Gyan

On Thu, Mar 10, 2022 at 9:59 AM Andrew Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>> 
wrote:
Hi Jingrong,

I’m struggling to entirely understand this.  I think the question for me is – 
if you are sending packets with SID’s over the open internet – are you 
encapsulating those packets and is this encapsulation cryptographically 
protected – I.E the SID’s are not visible outside of the encapsulation, to 
preserve the limited domain.

Limited domains are typically extended via tunnel mechanisms, very often with 
cryptographic protection, hence the question

Thanks

Andrew


From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, March 10, 2022 9:40 AM
To: Tom Hill mailto:t...@ninjabadger.net>>; 
spring@ietf.org<mailto: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 Tom,

Thanks for reading the draft and raise discussions.

In the proposal the SRv6 domain is the overlay network, belonging to one 
administrative domain -- the overlay network operator(say ONO).

For your concern about use of SIDs "across" the public Internet. Let me try to 
explain using following figure (hope it works):

CPE1 CPE2 CPE3
+ + + +
| ++ | | +--+ |
+---[1] TN1 [1]---+ +---+ Internet |---+
++ +--+

In the perspective of the ONO, it has the following SIDs:
SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO.
SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, marked 
[1] in the figure).
The ONO can use these SIDs, and I would think they are all "in the overlay 
network", and are running "Over the Internet".

You mentioned in the last sentence "the use of SIDs over the public Internet". 
That is what I am modeling above.

Thanks
Jingrong


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: spring@ietf.org<mailto: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 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-ov
> erlay
> <https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-o
> verlay>
>
> Please comment and send any feedback.
>
> I would like to discuss this document over e-mail/mail-list.


I'm concerned that this draft is explicitly violating the concept of
SRv6 as a protocol that operates within a Limited Domain.

As per Section 3.2 of this 

Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

[Xiejingrong (Jingrong)]

Hi Tom,

Thanks for reading the draft and raise discussions.

In the proposal the SRv6 domain is the overlay network, belonging to one 
administrative domain -- the overlay network operator(say ONO). 

For your concern about use of SIDs "across" the public Internet. Let me try to 
explain using following figure (hope it works):

CPE1CPE2 CPE3
 +  +  +  +
 |++|  |   +--+   |
 +---[1] TN1  [1]---+  +---+ Internet |---+
  ++   +--+ 

In the perspective of the ONO, it has the following SIDs:
SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO.
SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, marked 
[1] in the figure).
The ONO can use these SIDs, and I would think they are all "in the overlay 
network", and are running "Over the Internet". 

You mentioned in the last sentence "the use of SIDs over the public Internet". 
That is what I am modeling above.

Thanks
Jingrong


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Tom Hill
Sent: Wednesday, March 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 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-ov
> erlay 
> <https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-o
> verlay>
> 
> Please comment and send any feedback.
> 
> I would like to discuss this document over e-mail/mail-list.


I'm concerned that this draft is explicitly violating the concept of
SRv6 as a protocol that operates within a Limited Domain.

As per Section 3.2 of this draft, "... the network operator of AN, TN and 
Internet can be different from each other."

Further, "In some scenarios, the AN can be an Internet exchange provider
(IXP) independent of ISP and NSP. In some other scenarios, the AN can be an ISP 
that running Internet backbone as well."

This would read to me that the proposal is explicitly intended to be 
inter-domain, and not at all limited to any one administrative domain. 
Additionally, I cannot determine if the draft implicitly requires the use of 
SIDs across the public Internet?

Could I ask for some clarification on the scope of the draft, with respect to 
Limited Domains, and also the use of SIDs over the public Internet?

Kind regards,

--
Tom

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

[Xiejingrong (Jingrong)]

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 comment and send any feedback.



I would like to discuss this document over e-mail/mail-list.



Best Regards,

Jingrong Xie




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Xiejingrong (Jingrong)]

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: Friday, October 1, 2021 10:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[Xiejingrong (Jingrong)]

The reason to support the adoption is that, these two documents had been 
discussed thoroughly, and had led to the conclusion from WG to work on solution 
to compressing segment routing over IPv6.

I think it's time to adoption the documents to progress this work.

Thanks for the hard work 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-requirement - 
draft-srcompdt-spring-compression-analysis

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<mailto:bruno.decra...@orange.com>
Sent: Tuesday, September 7, 2021 9:13 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

Dear WG,


The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still 
individual documents.
We believe it's now time for the WG to consider taking ownership of those two 
documents.
Note that, especially for those two documents, WG adoption does not necessarily 
mean RFC publication in particular if it turns out that the benefit of long 
term archive would not justify the WG and IESG effort to finalize those two 
documents.


This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis


After review of the document(s) please indicate support (or not) for WG 
adoption of the document(s) to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this 
is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on the document(s), please state this explicitly. 
This gives the chairs an indication of the energy level of people in the 
working group willing to work on the document.

Thanks!

Jim, Bruno & Joel


_



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

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[Xiejingrong (Jingrong)]

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-requirement - 
draft-srcompdt-spring-compression-analysis

Dear WG,


The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still 
individual documents.
We believe it's now time for the WG to consider taking ownership of those two 
documents.
Note that, especially for those two documents, WG adoption does not necessarily 
mean RFC publication in particular if it turns out that the benefit of long 
term archive would not justify the WG and IESG effort to finalize those two 
documents.


This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis


After review of the document(s) please indicate support (or not) for WG 
adoption of the document(s) to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this 
is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on the document(s), please state this explicitly. 
This gives the chairs an indication of the energy level of people in the 
working group willing to work on the document.

Thanks!

Jim, Bruno & Joel


_



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

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

[Xiejingrong (Jingrong)]

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 address from the :::127/104 range", and 
Section 4.1.4 "the loopback address ::1/128 for IPv6", are they different cases 
or same case ?

Thanks
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Thursday, October 22, 2020 8:52 PM
To: spring@ietf.org
Cc: ippm-cha...@ietf.org; spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Dear WG:

This message starts a 3 week WG adoption call for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 
12th 2020. Please note that this document has several changes from v-10 that 
were requested by the SPRING and IPPM chairs. For this reason, the chairs have 
extended the adoption call for an additional week to allow the WG enough time 
to review these changes before deciding on WG adoption.

Some background:

Several review comments were received previously for document 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and 
IPPM chairs considered those comments, and upon review of this version of the 
document, determined the following:


  *   The SPRING document should describe only the procedures relevant to 
SPRING with pointers to non-SPRING document/s that define any extensions. 
Several extensions including Control Code Field Extension for TWAMP Light 
Messages, Loss Measurement Query Message Extensions, and Loss Measurement 
Response Message Extensions were included in 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and should be 
removed from the SPRING document.
  *   The TWAMP extensions included in 
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should be 
described in a new document published in the IPPM WG.

These conclusions were discussed with the authors of  
https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result of 
which is the publication of the following two documents:


  *   https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The 
subject of this WG adoption call.
  *   https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This 
document will be progressed (if determined by the WG) within the IPPM WG.

After review of the SPRING document please indicate support (or not) for WG 
adoption to the mailing list. Please also provide comments/reasons for that 
support (or lack thereof) as silence will not be considered as consent.

Finally, the chairs would like to thank the authors for their efforts in this 
matter.

Thanks!

Jim, Bruno, & Joel





___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Erik Kline's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Xiejingrong (Jingrong)]

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; Joel Halpern 
; spring-cha...@ietf.org; 
draft-ietf-spring-srv6-network-programm...@ietf.org
Subject: Re: [spring] Erik Kline's Discuss on 
draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Hi Erik,

Thank you for your review. Please see inline with [PC].

Regards,
Pablo.

-Original Message-
From: Erik Kline via Datatracker  
Sent: jueves, 24 de septiembre de 2020 8:41
To: The IESG 
Cc: draft-ietf-spring-srv6-network-programm...@ietf.org; 
spring-cha...@ietf.org; spring@ietf.org; Bruno Decraene 
; Joel Halpern ; 
j...@joelhalpern.com
Subject: Erik Kline's Discuss on draft-ietf-spring-srv6-network-programming-20: 
(with DISCUSS and COMMENT)

Erik Kline has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-20: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/



--
DISCUSS:
--

I support Alvaro's and others' discuss points.  I have only a few points that I 
think are easily cleared.

[ section 3.2 ]

* I'm a bit concerned about this first example, as it might give the mistaken
  impression that fc00::/7 is free for anyone to carve up as they wish
  (I say this regardless of what this operator may or may not have done).

  Per 4193, operators are supposed to generate random /48s from fd00::/8.

  I think this is easily corrected though, and I'd suggest:

  OLD:

  .  The provider historically deployed IPv6 and assigned
  infrastructure addresses from a portion of the fc00::/7 prefix.  They
  further subdivided the prefix into three /48 prefixes (Country X,
  Country Y, Country Z) to support their SRv6 infrastructure.  From
  those /48 prefixes each router is assigned a /64 prefix from which
  all SIDs of that router are allocated.

  NEW:

  .  The provider historically deployed IPv6 and assigned
  infrastructure addresses from ULA space [RFC 4193].  They specifically
  allocated three /48 prefixes (Country X, Country Y, Country Z) to
  support their SRv6 infrastructure.  From those /48 prefixes each router
  was assigned a /64 prefix from which all SIDs of that router are allocated.
[PC] Ack. Replaced text with your suggestion in rev21.

[ section 4.16.2 ]

* I'm not sure I understand what the value of specifying USP is.  This looks
  to me like an implementation detail and seems unnecessary.  In all cases
  where the S03 code block is entered it's the processing of the remainder of
  the inner packet that's important, I would think.

  I guess, what's the value of specifying the way in which an implementation
  can begin to process the next header?  Is this for chained SRHs and thus
  resubmitting the inner SRH to the same SID processing (8200 says that the
  RH 'should appear at most once', but that's as strong as the text gets)?

[PC] We have use-cases where the packets with SRH may be destined to 
applications or host implementations running in containers. The USP flavor is 
useful to remove the consumed SRH from the extension header chain before 
sending over to the application stack – we’ve seen this with smartNICs. As such 
the perspective on externally observability may differ and hence we believe it 
is needed to specify this.
[XJR] It is still implementation-related to me after you clarified with your 
case. If you are capable of doing USP, please do it yourself. Why boring 1000 
remote routers in an IGP domain by advertising this capability to them ?

[ section 4.16.3 ]

* This too seems like an implementation detail, and it's not clear what it's
  adding to the document.  But I must be misunderstanding something.

[PC] The USD flavor specifically enables the de-encapsulation of inner IP 
packet and its further forwarding (consider use-case like TI-LFA where 
encapsulation is done on the PLR and de-encapsulation has to be done on the 
last node of the repair list). In this case the PLR node that is crafting the 
SID list wants to ensure that the last segment in the repair list is able to 
perform decapsulation.
[XJR] It is implementation detail to me too. USD flavor SHOULD/MUST be 
supported for compliance with RFC8200 IMO.

[ section 7 ]

* What flow label is included in hashing 

Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Xiejingrong (Jingrong)]

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; Joel Halpern 
; spring-cha...@ietf.org; 
draft-ietf-spring-srv6-network-programm...@ietf.org
Subject: Re: [spring] Benjamin Kaduk's Discuss on 
draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Hi Benjamin,

Thank you for your time and review. Please see inline with [PC].

Regards,
Pablo.

-Original Message-
From: Benjamin Kaduk via Datatracker 
Sent: jueves, 24 de septiembre de 2020 9:52
To: The IESG 
Cc: draft-ietf-spring-srv6-network-programm...@ietf.org; 
spring-cha...@ietf.org; spring@ietf.org; Bruno Decraene 
; Joel Halpern ; 
j...@joelhalpern.com
Subject: Benjamin Kaduk's Discuss on 
draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-20: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/



--
DISCUSS:
--

[edited to remove nonsensical point that had crept in about the SRH being a new 
extension header; it's "just" a routing header]

The current requirement that IANA-assigned SRv6 Endpoint Behavior codepoints 
are used, with no range reserved for local assignment, seems to be inviting 
codepoint squatting from the nominally reserved range.
Why is there an absolute requirement for registration (even FCFS) without 
ranges for local or experimental use?  (What are the various reserved ranges 
reserved for?) [PC] I agree with you that a range for local use would come 
useful. Hence, we’ve carved 2k entries of the registry for Private Use.
The Reserved range (half of the 65k registry) is for future allocation by IETF. 
Future RFCs might decide how to use that.

The (normative) pseudocode does not seem to handle the case when the SRH is 
omitted for the degenerate case where there is only a single segment, or for 
the PSP flavor.
[PC] Each one of the pseudocodes provides the SRH processing and the 
Upper-Layer processing. If there is no SRH, then the SRH processing is not 
executed, but the Upper-layer Header processing is. This is the same as in 
RFC8754.

The pseudocode for the PSP and USP procedures seem incorrect -- Hdr Ext Len is 
measured in units of 8 octets, and does not include the first 8 octets of the 
extension header, but Payload Length is measured in octets.  Literally 
decreasing the Payload Length by the Hdr Ext Len value will produce a malformed 
IPv6 packet.
[PC] Indeed. Fixed.
[XJR] Seems still not correct in rev-21. " Hdr Ext Len is measured in units of 
8 octets, and does not include the first 8 octets of the extension header".

If "PSP operation is deterministically controlled by the SR Source Node", why 
do we need to define behavior codepoints that (for example) use both PSP and 
USP?  I don't see how there is full determinism in this case while being 
different from the "PSP only" flavor.
[PC] In order for the PSP behavior to be executed there must happen two things. 
First, the SR Source Node must instruct it wants to use the PSP behavior. This 
is done by using an SRv6 SID associated with a behavior that support the PSP 
flavor (either End with PSP alone, or End with PSP in combination of other). 
Then, the second thing is that the received packet at the node it must have a 
SL value of 1, that during processing is decremented to 0. (In other words, it 
must be the penultimate segment). If both conditions are given, then lines 
S14.2-S14.4 of the pseudocode are executed.
[XJR] The method to define a behavior codepoint for every possible combination 
is very overwhelming. Looking at section 10.2.1 of rev-21, there are 8 
codepoints for End/Ent.X/End.T each when there are 3 flavors. How about 4 
flavors or 5 flavors then ???

There are numerous factual errors and un/under-specified protocol behavior (see 
COMMENT), including: how to set the outer Hop Limit (multiple instances), the 
order of segments in the SRH, specification of headend behavior by reference to 
informal example, L2 frame en/decapsulation procedures, and the "Opaque" note 
for endpoint behavior 65535.
[PC] I’ll comment on each point in the comment.

Re: [spring] Understanding the replication draft

[Xiejingrong (Jingrong)]

(Though it is in a PIM WG draft (cc’ed), but the terminologies in RFC8402 are 
used and are the key to understand, so I would  expect points from the SPRING 
WG).

Hi Rishabh,

Thanks for your response!

Let me try to understand the applicability of SRv6 first, and move to the other 
points afterwards.

I read the appendix A.1 in , and still have 
difficulty to understand the processing of multicast packet.

   o  R2, as Leaf, performs NEXT operation, pops T-SID1 label and
  delivers the payload.  For replication to R6, R2 performs a PUSH
  operation of N-SID6, to send  label stack to R3.
  R3 is the penultimate hop for N-SID6; it performs penultimate hop
  popping, which corresponds to the NEXT operation and the packet is
  then sent to R6 with  in the label stack.  For replication
  to R7, R2 performs a PUSH operation of N-SID7, to send
   label stack to R4, one of IGP ECMP nexthops
  towards R7.  R4 is the penultimate hop for N-SID6; it performs
  penultimate hop popping, which corresponds to the NEXT operation
  and the packet is then sent to R7 with  in the label
  stack.

When considering SRv6, The “PUSH operation of N-SID6” and the “PUSH operation 
of N-SID7” are not clear to me.

Seems that  and  are only for SR-MPLS, where 
T-SID1 is locally meaningful, and N-SID is globally reachable.

I try to understand what’s the shape of each packet – pkt12, pkt23, pkt36, 
pkt25, pkt47 in this example when using SRv6.

R3(pkt36)R6
/
 (pkt23)
  /
R1(pkt12)R2(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 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: [spring] Understanding the replication draft

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 west-east protocol like IGP/BGP,
and then the north-south controller (like PCE) can use the “Replication-ID” and 
“Node-ID” only, but don’t need to use “Replication-SID” when populating the 
“Tree” information to each “Replication Node” ?
In that way, the Controller doesn’t need to allocate (and manage) each of the 
Replication-SID (Say 1000 Replication-SID)  for  each Replication Node (Say 100 
nodes).

As we try to make the distinction clear in the draft, Replication segment is a 
logical segment that needs to be explicitly instantiated on the node either by 
PCE or by some other mechanism (maybe local config?). The Replication SID has 
to be assigned when the Replication segment (with a Replication-ID) is created 
on the node. Note Replication Segments can be created and deleted over time. 
and So, there is no pre-allocated block of Replication SIDs that can be 
announced in IGP or BGP. Effectively, the entity managing Replication segments 
has to manage the Replication SIDs.

2)   About the Replication Segment illustration.
The rev-04 add a section “Illustration of a Replication Segment” in appendix, 
it is very clear and useful.
To me, the “Replication State” is more like a “forwarding state”, and I think 
it will be helpful to understand the whole solution if:
a) there is a description/Illustration about the building procedure of the 
“forwarding state”  What’s the information each Replication Node receives 
from the controller, and how each node builds its own forwarding state.
b) there is a description/Illustration about the processing of multicast packet 
on the whole path of the P2MP tree.

Illustrations of how packets and handed on a P2MP tree built by stitching 
Replication segments have been added in latest revision 02 of PIM WG draft: 
https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
We have drafts on PCEP and BGP protocol extensions to instantiate Replication 
segments.



3)   About the applicability of SR-MPLS and SRv6.
The rev-04 says “Replication segments apply equally to both SR-MPLS and SRv6 
instantiations of Segment Routing.”.
I am not sure if this document will cover SRv6 as well, but if it does, then I 
would like to see the same level of consideration as SR-MPLS.


 Yes, we will have the same level of details for SRv6 Replication too.

-Rishabh
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for draft-raza-spring-sr-policy-yang

[Xiejingrong (Jingrong)]

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] WG Adoption Call for draft-raza-spring-sr-policy-yang

Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-raza-spring-sr-policy-yang/ ending 
Monday 27th July 2020.

Please speak up if you support or oppose adopting this document into the WG.. 
Please also provide comments/reasons for that support (or lack thereof). 
Silence will not be considered consent.

Thanks!

Jim, Joel & Bruno



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang

[Xiejingrong (Jingrong)]

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: [spring] WG Adoption Call for draft-raza-spring-srv6-yang

Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-raza-spring-srv6-yang/ ending Monday 
27th July 2020.

Please speak up if you support or oppose adopting this document into the WG.. 
Please also provide comments/reasons for that support (or lack thereof). 
Silence will not be considered consent.

Thanks!

Jim, Joel & Bruno





___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Xiejingrong (Jingrong)]

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...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending 
Wednesday 29th July 2020.

Please speak up if you support or oppose adopting this document into the WG.. 
Please also provide comments/reasons for that support (or lack thereof). 
Silence will not be considered consent.

Thanks!

Jim, Joel & Bruno



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Understanding the replication draft

[Xiejingrong (Jingrong)]

Hi Rishabh,

Thank you very much for the reply.
The words you used like P2MP service/P2MP transport, upstream label/DCB, last 
SID/BoS  and their distinctions all match my dictionary, so it’s now very clear 
to me. Sincerely appreciate!

I have some further comments in detail:


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 west-east protocol like IGP/BGP,
and then the north-south controller (like PCE) can use the “Replication-ID” and 
“Node-ID” only, but don’t need to use “Replication-SID” when populating the 
“Tree” information to each “Replication Node” ?
In that way, the Controller doesn’t need to allocate (and manage) each of the 
Replication-SID (Say 1000 Replication-SID)  for  each Replication Node (Say 100 
nodes).


2)   About the Replication Segment illustration.
The rev-04 add a section “Illustration of a Replication Segment” in appendix, 
it is very clear and useful.
To me, the “Replication State” is more like a “forwarding state”, and I think 
it will be helpful to understand the whole solution if:
a) there is a description/Illustration about the building procedure of the 
“forwarding state”  What’s the information each Replication Node receives 
from the controller, and how each node builds its own forwarding state.
b) there is a description/Illustration about the processing of multicast packet 
on the whole path of the P2MP tree.


3)   About the applicability of SR-MPLS and SRv6.
The rev-04 says “Replication segments apply equally to both SR-MPLS and SRv6 
instantiations of Segment Routing.”.
I am not sure if this document 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; spring@ietf.org; Alexander 
Vainshtein 
Subject: Re: [spring] Understanding the replication draft

Jingrong,
As I had explained to Jeff Tantsura earlier in the thread, with P2MP services 
realized by P2MP trees, VPN label is NOT part of the label stack since egress 
(leaf nodes of P2MP trees) of the P2MP service MAY have different VPN labels 
for same context. For P2MP services, it is normal to use the top transport 
label (Replication SID in this case) as implicit context for the service. Of 
course, this implies one-to-one association between P2MP transport and service.

There are techniques, using upstream label allocation or DCB (domain wide 
context blocks), where the same VPN label can be assigned to the service on all 
the egress nodes. In this case, the P2MP transports can be shared across P2MP 
services (at a set of egress nodes) and the VPN label can appear after the 
Replication SID as we have indicated in the PIM WG draft. But, the VPN label is 
not a SID and, IMO, the statement "Replication SID must be last SID" still 
holds but it is not at the bottom of the stack. We can clarify this when we 
publish the WG document.

-Rishabh

On Tue, Jul 14, 2020 at 4:55 AM Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>> wrote:
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 a 
packet like this: { Replication SID, (VPN Label, IPv4/IPv6 C-multicast packet) 
} ?

In my understanding, with an imagined topology comprising of Replication Node 
R1/R2/R3/R4, the picture is like this:

The Replication Node R2 receives such a packet (from R1), sees the Replication 
SID on the “Top” of the label stack,  performs the corresponding action of 
“replication”,  replicates the packet to downstream Replication Nodes R3 and 
R4, SWAPs the Replication SID to Replication SID and Replication 
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) }.

Thanks
Jingrong

From: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] 
On Behalf Of Rishabh Parekh
Sent: Saturday, July 11, 2020 4:46 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: Dhruv Dhody mailto:dhruv.i...@gmail.com>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
spring@ietf.org<mailto:spring@ietf.org>; Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Subject: Re: [spring] Understanding the replication draft

All,
We have posted revision 
04<https://tools.iet

Re: [spring] Understanding the replication draft

[Xiejingrong (Jingrong)]

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 a 
packet like this: { Replication SID, (VPN Label, IPv4/IPv6 C-multicast packet) 
} ?

In my understanding, with an imagined topology comprising of Replication Node 
R1/R2/R3/R4, the picture is like this:

The Replication Node R2 receives such a packet (from R1), sees the Replication 
SID on the “Top” of the label stack,  performs the corresponding action of 
“replication”,  replicates the packet to downstream Replication Nodes R3 and 
R4, SWAPs the Replication SID to Replication SID and Replication 
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) }.

Thanks
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rishabh Parekh
Sent: Saturday, July 11, 2020 4:46 AM
To: Jeff Tantsura 
Cc: Dhruv Dhody ; bruno.decra...@orange.com; 
spring@ietf.org; Alexander Vainshtein 
Subject: Re: [spring] Understanding the replication draft

All,
We have posted revision 
04 of 
the draft. This addresses comments on this thread and adds an example 
illustrating replication segment. Diff from rev 03:  
https://tinyurl.com/y96ueb9h

Some WG  members also wanted to understand how Replication segments are 
stitched together to form a P2MP tree based on SR P2MP policy in the PIM draft. 
We have posted revision 
02 of PIM P2MP 
policy draft that adds examples of how these things tie together. I hope that 
helps clarify the relationship. Diff from rev 01: https://tinyurl.com/yban2jp6

Please review,
-Rishabh

On Tue, Jul 7, 2020 at 2:16 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Thanks Rishabh!
+1 to the above comments and looking forward to the updated draft.

Cheers,
Jeff
On Jul 7, 2020, 7:35 AM -0700, Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>, wrote:

Dhruv, Bruno and all,
Regarding the statement " What is missing in the spring I-D is some very high 
level discussion in terms of architecture on how replication segment and SR 
P2MP policy come together" - I cannot agree more.

My 2c,
Sasha

Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@ecitele.com


-Original Message-
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Dhruv Dhody
Sent: Tuesday, July 7, 2020 1:02 PM
To: bruno.decra...@orange.com
Cc: spring@ietf.org
Subject: Re: [spring] Understanding the replication draft

Hi Bruno,

Yes, thanks! I was just making sure that we have an agreement that PIM is the 
right place to define SR P2MP Policy.

What is missing in the spring I-D is some very high level discussion in terms 
of architecture on how replication segment and SR P2MP policy come together. 
The current I-D tries to define a replication segment as an independent entity 
that could be used on its own but it makes it difficult to visualize without 
some high level text or an example.

Thanks!
Dhruv

On Tue, Jul 7, 2020 at 3:12 PM 
mailto:bruno.decra...@orange.com>> wrote:
>
> Hi Dhruv,
>
> > -Original Message-
> > From: spring 
> > [mailto:spring-boun...@ietf.org] On Behalf 
> > Of Dhruv
> > Dhody
> > Subject: Re: [spring] Understanding the replication draft
> >
> > Hi WG,
> >
> > Reading the I-D and based on the discussion on this thread I believe
> > more description is required. As Joel pointed out, clarity on what
> > is legal/illegal (or out of scope for now) is needed.
>
> I leave this for the authors to reply.
>
> > I have no strong opinion if that needs to be done before or after adoption!
> >
> > I do not follow PIM closely and just realized that the SR P2MP
> > Policy in the PIM I-D [1] is adopted by the PIM WG, but not yet posted [2].
> > I wanted to make sure that it has been decided that PIM is the right
> > place to define SR P2MP policy (discussed either in the WG and/or
> > between chairs/AD)?
>
> draft-voyer-pim-sr-p2mp-policy-00 is to be worked in the PIM WG.
> The PIM WG is waiting for the SPRING WG to adopt 
> draft-voyer-spring-sr-replication-segment, since the -pim- document has a 
> dependency on the -spring- document.
>
> Quoting the PIM chairs: "We have solid support to adopt this draft.. [...] We 
> are waiting to hear back from the spring chairs as to the wg status of the 
> local replication draft of which your draft is dependent.. So please hold off 
> on submitting the new draft-ietf-pim-sr-p2mp-policy 

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Xiejingrong (Jingrong)]

Hi Ron,
Agreed ICMP is an upper-layer header that should be consistent with the 
SRv6-OAM draft [1], and I guess you may have also noticed the same.
Please see the proposed text I have just posted.

Regards,
Jingrong

[1] https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-05


From: Ron 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 message?

Ron




Juniper Business Use Only
From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Xiejingrong (Jingrong)
Sent: Sunday, June 14, 2020 10:29 PM
To: Aijun Wang mailto:wang...@chinatelecom.cn>>; 
i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

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.

Thanks
Jingrong


From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: i...@ietf.org<mailto:i...@ietf.org>; 
spring@ietf.org<mailto:spr...@ietf..org>
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8754*section-4.3.1.2__;Iw!!NEt6yMaO-gk!TQj3lWlbJi1xnhmD0skSC1Qbp_vkkYT77iE2zA_6hLItZqr8eZxbW1IoKhFgaBkD$>)
 describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}
And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15*section-9.1__;Iw!!NEt6yMaO-gk!TQj3lWlbJi1xnhmD0skSC1Qbp_vkkYT77iE2zA_6hLItZqr8eZxbW1IoKiVOq5HR$>),
 one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Proposed text for discussion//RE: About the upper layer header processing in RFC8754(SRH)

[Xiejingrong (Jingrong)]

Hi, WGs,
Following is the Proposed text for updating Section 4.3.1.2 of RFC8754. 

   The next header in the packet in S03 of section 4.3.1.1 of the
  document could be an IPv6 extension header or an IPv6 Upper-layer
   header.  Herein named Following-header for short in this section.

   If the Following-header is a designated upper-layer header(DULH) of
   the SRv6 SID, the packet should be forwarded according to the
   Designated-Forwarding Method (DFM) of the SRv6 SID.  The designated
   upper-layer header of an SRv6 SID should be specified by each type of
   SRv6 SID.  An SRv6 SID MAY has zero, one, or more than one designated
   upper-layer headers.  For example:

   1) an SRv6 SID may expect IPv4 header as its designated upper-layer
   header.

   2) an SRv6 SID may expect either IPv6 header or IPv4 header as its
   designated upper-layer header.

   3) an SRv6 SID may expect Ethernet header as its designated upper-
   layer header.

   4) an SRv6 SID may not expect any header as its designated upper-
   layer header.

   The Designated-Forwarding method of the SRv6 SID should be specified
   by each type of SRv6 SID if the designated upper-layer header of the
   SRv6 SID is not NULL.

   If the Following-header is not the designated upper-layer header of
   the SRv6 SID, and the Following-header is allowed by local
   configuration (e.g.  ICMPv6), then process the upper-layer header.

   If the Following-header is not the designated upper-layer header of
   the SRv6 SID, and the Following-header is not allowed by local
   configuration (e.g.  Default), then the packet should be discarded,
   and an ICMPv6 error message should be sent to the Source Address of
   the packet.  The ICMPv6 error message has an Error code (4) "SR
   Upper-layer Header Error", pointer set to the offset of the upper-
   layer header.

   The following pseudocode illustrates the above process:

  IF (Following-header is the DULH of the SRv6 SID) {
Execute the Designated-Forwarding Method of the SRv6 SID.
  }
  ELSE IF (Following-header is allowed by local configuration) {
Process the Upper-layer header.
  }
  ELSE {
Send an ICMP parameter problem message to the Source Address and
discard the packet.  Error code (4) "SR Upper-layer
Header Error", pointer set to the offset of the upper-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 header processing in RFC8754(SRH)

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.

Thanks
Jingrong


From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: i...@ietf.org<mailto:i...@ietf.org>; 
spring@ietf.org<mailto:spr...@ietf..org>
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2<https://tools.ietf.org/html/rfc8754#section-4.3.1.2>)
 describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}
And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1),
 one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] About the upper layer header processing in RFC8754(SRH)

[Xiejingrong (Jingrong)]

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.

Thanks
Jingrong


From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: i...@ietf.org; spring@ietf.org
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 
4.3.1.2(https://tools.ietf.org/html/rfc8754#section-4.3.1.2) describes the 
process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
   local configuration permits {
 Perform IPv6 decapsulation
 Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ..
}
And in network programming draft section 
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1),
 one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the 
network program draft,  does it need to update the section 4.3.1.2 of RFC8754 
to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] How CRH support SFC/Segment Endpoint option?

[Xiejingrong (Jingrong)]

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 verbatim first DOH must be placed before RH hence to 
have more then one DOH in a packet RH is mandatory
2nd good question. I saw no less than 2 RFCs that have 3 DOHs in it 
optionally.
I believe there could be more than one DOH in a packet without mandatory of 
requiring DOH before RH,  per below [1] (a higher level observation of IPv6 
design IMO, not just the “recommended” text).

What exactly tells the router to process or not to process last 4 headers ? Is 
there a rule anywhere that unless RH is present and segments left = 0 
destination must not follow next header in RH ?
3rd good question. A router does NOT check/assume/guarantee the “8200 
recommended order” at all IMO (would you do that?). Once a packet with the DA 
being the IPv6 address of a node is received, the node just “catch” it to its 
local-process.
I believe below [2]  is another higher level observation of IPv6 design IMO 
about “EH order” from implementation view, not just the “recommended order” 
text.

In summary, I believe the “recommended order” of RFC8200 does not make a 
proposal superior than others at all.

Thanks
Jingrong


[1] RFC8200
   Defining new IPv6 extension headers is not recommended, unless there
   are no existing IPv6 extension headers that can be used by specifying
   a new option for that IPv6 extension header.  A proposal to specify a
   new IPv6 extension header must include a detailed technical
   explanation of why an existing IPv6 extension header can not be used
   for the desired new function.  See [RFC6564] for additional
   background information.

   Instead of defining new extension headers, it is recommended that the
   Destination Options header is used to carry optional information that
   must be examined only by a packet's destination node(s), because they
   provide better handling and backward compatibility.

[2] RFC8200
   When more than one extension header is used in the same packet, it is
   recommended that those headers appear in the following order:

   If and when other extension headers are defined, their ordering
   constraints relative to the above listed headers must be specified.

   IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation.



From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, May 25, 2020 4:57 PM
To: Ron Bonica 
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Hi Ron,

So what in your opinion would happen with the below if there is no Routing 
Header at all and I still modify DA at each segment endpoint ?

Can I still put two Destination options ?

Or reading the RFC8200 verbatim first DOH must be placed before RH hence to 
have more then one DOH in a packet RH is mandatory ?

If so can it contain only 4 octets and no type specific data (so called be a 
NULL RH) ?

What exactly tells the router to process or not to process last 4 headers ? Is 
there a rule anywhere that unless RH is present and segments left = 0 
destination must not follow next header in RH ?

Thank you,
R.


IPv6 extension header are ordered as follows:

- Headers processed at every node along the delivery path
- Hop-by-hop
- Headers processed at every segment endpoint
- Destination options
- Routing header
- Headers processed at the ultimate destination only
- Fragment header
- Authentication header
- ESP header
- Destination Options header

Note that the Destination Options header is the only extension header that can 
appear twice in a packet. The Destination Options header must immediately 
precede the Routing header or the upper-0layer header.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] IPv6 DOH order facts and thoughts//RE: How CRH support SFC/Segment Endpoint option?

[Xiejingrong (Jingrong)]

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 RFC6275)  
This does NOT follow the “recommended” order of 8200.
The Home Address option is carried by the Destination Option extension header 
(Next Header value = 60).
The Home Address option MUST be placed as follows:
   o  After the routing header, if that header is present
   o  Before the Fragment Header, if that header is present

EXAMPLE2: 7837 requires DOH before Frag/AH/ESP!  This does NOT follow the 
“recommended” order of 8200.
   The CDO SHOULD be placed as the first option in the Destination
   Option header before the AH [RFC4302] and/or Encapsulating Security
   Payload (ESP) [RFC4303] (if present).

Text about “EH order” from RFC8200:
   When more than one extension header is used in the same packet, it is
   recommended that those headers appear in the following order:

   If and when other extension headers are defined, their ordering
   constraints relative to the above listed headers must be specified.

   IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation.

There are some words for the 8200 recommended order:  “recommended”, “strongly 
advised …. Adhere to the above recommended order”
There are some other words for the other side: “their ordering constraints …. 
must be specified”, “IPv6 nodes must accept and attempt to process extension 
headers in any order”.

My reading of this text (inheritance of RFC1883/2460):

(1) It is the responsibility of those who want to design solution based on 
IPv6 EH to define the order of IPv6 EH, and to tell why the “ordering 
constraints” of the proposal is.

(2) The “recommended order” of RFC8200 does not make a proposal superior 
than others IMO.


Additional comments to  “DOH will be examined at each segment endpoint hop if 
DOH is present.”:
I agree and I’d like to add an additional note IMO to this:
The DOH could be used alone (without a following RH) to be processed by a 
“segment endpoint”, as long as the DA of a packet is the IPv6 address of the 
“segment endpoint” node!
The BIERv6 design is a case of this, use DOH alone (without a following RH) in 
common case, and requires DOH carrying a BIER option is located after RH if 
present and before Fragmentation/AH/ESP if present.
https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06
Again please feel welcome to take this into discussion and consideration!


Thanks
Jingrong


From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, May 25, 2020 5:33 AM
To: Tom Herbert 
Cc: Ron Bonica ; spring@ietf.org; 6man 
<6...@ietf.org>
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?

Hi Tom,

Thank you !

That confirms my understanding ie that DOH will be examined at each segment 
endpoint hop if DOH is present.

So just like PSSI or TPF suggest a build in filtering (for example by target 
ID) is required to avoid misuse.

Kind regards,
Robert.


Robert,

Look at Destination Options before the routing header in RFC8200.
These are intended to be processed at every intermediate destination
in the routing header and precede any fragment header.

Tom




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Joel,
I guarantee you there is case the performance penalty is more than 90%, only if 
the box send the IPv6 packet with RH or EH to the slow path (just to be 
compatible with RFC8200)!
And I think that's common even for not very old box.

Thanks
Jingrong

-Original Message-
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 is to 
ignore it.  Which is required by 8200.

Skipping the SRH is not a 50% performance penalty in any situation.

Yours,
Joel

On 3/4/2020 8:36 AM, Xiejingrong (Jingrong) wrote:
> 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 guess the benefits may be around 50%?
> While for the real network, the incremental deployment may be much more 
> important  It is determining, from 1(success) to 0(fail) or vice versa!
> No matter how good a feature you provided, it just doesn't work on the 
> network with a bunch of PEs that is not capable of SRH, then it is useless.
> 
> **Maybe my previously suggested text can be referenced** This has some 
> very important benefits for deployment in some networks when the final 
> tunnel end point is a lower-end node which is not capable of 
> processing the SRH for reasons like the hardware is overloaded or 
> unable to upgraded to process well with SRH.
> 
> In case the final tunnel endpoint router is fully capable of the 
> functionality of SRH and the SRv6-NP defined in this document, it is 
> recommended not to use the PSP.
> **End for reference**
> 
> Thanks
> Jingrong
> 
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. 
> Halpern
> Sent: Wednesday, March 4, 2020 4:34 PM
> To: Ketan Talaulikar (ketant) ; 
> bruno.decra...@orange.com; spring@ietf.org
> Subject: Re: [spring] WGLC - 
> draft-ietf-spring-srv6-network-programming
> 
> Given that we are talking about the ultimate node, all that it is being asked 
> to do is ignore the SRH.  Whether it ignores it because it uses the option 
> 8200 permits to ignore things which are understood, or ignores it because 
> SL=0, it is required to be able to ignore it.
> In either the encapsulated case or the native termination case, the 
> result of ignoring it is that the proper things will happen.  The IP 
> header will be removed, and what is enclosed will be processed.  (In 
> the native case, the upper layer header.  In the encapsulated case, 
> the inner header.)
> 
> So I am still confused as to what the advantage to any node is of doing more 
> work in the preceding node, work that is much more than the act of ignoring 
> the header in the final node.  The SRH removal does not remove the expensive 
> part of the work, namely the need to decapsulate and process the inner header.
> 
> Yours,
> Joel
> 
> 
> On 3/4/2020 3:27 AM, Ketan Talaulikar (ketant) wrote:
>> Hi Joel,
>>
>> I would not like to misquote Bruno, but his conclusion on this topic 
>> was very logical, practical and nuanced (again most likely comes from 
>> working with a network operator).
>>
>> /QOUTE/
>>
>> /My take is that PSP is an _optional data plane optimization_. 
>> Judging its level of usefulness is _very hardware and implementation 
>> dependent_.
>> It may range anywhere from "not needed" to "required for my platform"
>> (deployed if you are network operator, or been sold if you are a 
>> vendor), with possible intermediate points along _"n% packet 
>> processing gain", or "required when combined with a specific other 
>> feature"_. I don't think that the SPRING WG can really evaluate this 
>> point (lack of hardware knowledge, lack of detailed information on 
>> the hardwares). The fact that this has been implemented by some 
>> platforms and deployed by some operators, is, to me, an indication 
>> that it is useful for those cases. (I believe that an English proverb 
>> is *"the proof of the pudding is in the eating"*. Although I'm 
>> certainly missing part of its meaning and culture, in it's literal 
>> reading, it seems to apply)./
>>
>> /UNQOUTE/
>>
>> I don’t believe we need to get into the details of the 18 [1] 
>> publicly disclosed (I understand there are more

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

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 guess the benefits may be around 50%?
While for the real network, the incremental deployment may be much more 
important  It is determining, from 1(success) to 0(fail) or vice versa!
No matter how good a feature you provided, it just doesn't work on the network 
with a bunch of PEs that is not capable of SRH, then it is useless.

**Maybe my previously suggested text can be referenced**
This has some very important benefits for deployment in some networks when the
final tunnel end point is a lower-end node which is not capable of processing
the SRH for reasons like the hardware is overloaded or unable to upgraded to
process well with SRH.

In case the final tunnel endpoint router is fully capable of the functionality
of SRH and the SRv6-NP defined in this document, it is recommended not to use
the PSP.
**End for reference**

Thanks
Jingrong

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Wednesday, March 4, 2020 4:34 PM
To: Ketan Talaulikar (ketant) ; 
bruno.decra...@orange.com; spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Given that we are talking about the ultimate node, all that it is being asked 
to do is ignore the SRH.  Whether it ignores it because it uses the option 8200 
permits to ignore things which are understood, or ignores it because SL=0, it 
is required to be able to ignore it.
In either the encapsulated case or the native termination case, the result of 
ignoring it is that the proper things will happen.  The IP header will be 
removed, and what is enclosed will be processed.  (In the native case, the 
upper layer header.  In the encapsulated case, the inner header.)

So I am still confused as to what the advantage to any node is of doing more 
work in the preceding node, work that is much more than the act of ignoring the 
header in the final node.  The SRH removal does not remove the expensive part 
of the work, namely the need to decapsulate and process the inner header.

Yours,
Joel


On 3/4/2020 3:27 AM, Ketan Talaulikar (ketant) wrote:
> Hi Joel,
> 
> I would not like to misquote Bruno, but his conclusion on this topic 
> was very logical, practical and nuanced (again most likely comes from 
> working with a network operator).
> 
> /QOUTE/
> 
> /My take is that PSP is an _optional data plane optimization_. Judging 
> its level of usefulness is _very hardware and implementation dependent_.
> It may range anywhere from "not needed" to "required for my platform" 
> (deployed if you are network operator, or been sold if you are a 
> vendor), with possible intermediate points along _"n% packet 
> processing gain", or "required when combined with a specific other 
> feature"_. I don't think that the SPRING WG can really evaluate this 
> point (lack of hardware knowledge, lack of detailed information on the 
> hardwares). The fact that this has been implemented by some platforms 
> and deployed by some operators, is, to me, an indication that it is 
> useful for those cases. (I believe that an English proverb is *"the 
> proof of the pudding is in the eating"*. Although I'm certainly 
> missing part of its meaning and culture, in it's literal reading, it 
> seems to apply)./
> 
> /UNQOUTE/
> 
> I don’t believe we need to get into the details of the 18 [1] publicly 
> disclosed (I understand there are more) hardware implementations from 
> multiple vendors to debate the gains from PSP. I don’t believe that is 
> appropriate for an IETF mailing list or pursuant to IETF policy or 
> practice (as you say)?
> 
> Again, I like to make the point of how/why HBH processing was made 
> optional based on real world considerations when moving from RFC2460 
> to RFC8200. So options are good and necessary!
> 
> That said, let us turn the tables around.  There is no technical 
> reason for not allowing PSP with SRH – all the ones that have been 
> brought up have been answered and clarified in the text as well as on the 
> mailer.
> So I fail to understand the resistance of “the other side (including 
> yourself)”.
> 
> Therefore, I would suggest we go ahead with the declared Spring WG 
> consensus.
> 
> Thanks,
> 
> Ketan
> 
> [1]
> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-st
> atus-05#section-4.2
> 
> -Original Message-
> From: Joel Halpern Direct 
> Sent: 04 March 2020 13:26
> To: Ketan Talaulikar (ketant) ; 
> bruno.decra...@orange.com; Martin Vigoureux 
> ; spring@ietf.org
> Subject: Re: [spring] WGLC - 
> draft-ietf-spring-srv6-network-programming
> 
> Bruno's statement, which you chose to quote, was that all it takes is 
> for one person to find something useful.  I 

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

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.

Even the proposed text by myself were all summarized from the long discussion 
that already there months before.

Going back further, my knowledge about the benefits of the PSP also came from 
the long discussion, as I said admittedly "benefits that people have already 
said seems notable to me".
https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0/
It was almost 3 months before!

I don’t see how the editorial changes, based on the long discussion 3 months 
before, can affect at all the decision on whether to move forward the I-D.

BTW: I see rev-12 was just posted, and I am happy to see more of my proposed 
text are taken, though these text are just words in the list for 3 months. 
Maybe 1 minute is enough to get through the diff link.
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-12

Thanks,
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mark Smith
Sent: Tuesday, March 3, 2020 5:40 AM
To: Martin Vigoureux 
Cc: SPRING WG ; 6MAN <6...@ietf.org>; 
draft-ietf-spring-srv6-network-programming 

Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

This -11 draft was posted at 3:53 am Melbourne, Australia time, and this 
declaration of consensus was at 5:35 am Melbourne, Australia time.

Sometimes I'm awake at those hours, but not last night. I did not have an 
opportunity to review the changes.


Regards,
Mark.



On Tue, 3 Mar 2020, 05:53 Martin Vigoureux, 
mailto:martin.vigour...@nokia.com>> wrote:
WG,

as I had indicated in a previous message I am the one evaluating
consensus for this WG LC.

I have carefully read the discussions on the list. I acknowledge that
disagreements were expressed regarding what a particular piece of text
of RFC 8200 says, and on which this document builds to propose an
optional capability. Since RFC 8200 is not a product of the SPRING WG, I
have paid specific attention to the messages ([1], [2], and [3]) sent by
the responsible AD of 6MAN and of RFC8200.

My overall conclusion is that there is support and rough consensus to
move this document to the next stage.

Bruno will handle the immediate next steps.


Martin


[1]
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
[2]
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
[3]
https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/

Le 2019-12-05 à 18:15, 
bruno.decra...@orange.com a écrit :
> Hello SPRING,
>
> This email starts a two weeks Working Group Last Call on
> draft-ietf-spring-srv6-network-programming [1].
>
> Please read this document if you haven't read the most recent version,
> and send your comments to the SPRING WG list, no later than December 20.
>
> You may copy the 6MAN WG for IPv6 related comment, but consider not
> duplicating emails on the 6MAN mailing list for the comments which are
> only spring specifics.
>
> 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.
>
> This may help avoiding that the thread become specific to this point and
> that other points get forgotten (or that the thread get converted into
> parallel independent discussions)
>
> Thank you,
>
> Bruno
>
> [1]
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05
>
> _
>
> 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
>

___

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Gyan,
What revision are you reading ?
I found the 4.21.1 only in its very early revision (-00 and -01).
There is only 4.16 and the PSP is introduced in 4.16.1 in the latest draft is 
rev-11 : https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming
And I think the explanation of “A penultimate SR Segment Endpoint Node” in the 
latest rev is helpful to understand better:
   SR Segment Endpoint Nodes receive the IPv6 packet with the
   Destination Address field of the IPv6 Header equal to its SID
   address.  A penultimate SR Segment Endpoint Node is one that, as part
   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 Hinden ; spring@ietf.org; 神明達哉 

Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming


Hi Jingrong

I am following what you displayed and it makes sense. In section 4.21.1 for the 
PSP flavor what was confusing was it said that the End.X with PSP flavor can 
pop the SRH.  The way it’s written,  to me it reads that any P router can pop 
the SRH when the last SID is written to the DA. So if the SRH SID list happens 
to not steer to the egress PE and ended a few hops early,  and If PSP is true 
then the SRH could be popped early on any P node.  Maybe I am reading to far 
into the verbiage.  I think since End.X could be any P transit router what I am 
saying could happen.

4.21.1<https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21.1>.
  PSP: Penultimate Segment Pop of the SRH





   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,

   the following instructions must be added:



 1.   IF updated SL = 0 & PSP is TRUE

 2.  pop the top SRH ;; Ref1









   Ref1: The received SRH had SL=1.  When the last SID is written in the

   DA, the End, End.X and End.T functions with the PSP flavour pop the

   first (top-most) SRH.  Subsequent stacked SRH's may be present but

   are not processed as part of the function.

At each hop each node copies the SID to DA and updates the SL = SL -1

I am depicting an incoming SL value to each node and then each node updates the 
SL pointer along the path hop by hop.

PSP mode

CE1[PE1{SL=2} - P2--{SL=1} -P3--pop--PE4]CE2

PSP disabled (USP)

CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 pop]CE2

USD  (USD) - Decapsulation & forward native packet payload to customer CE

CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 dencap]CE2

Thanks

Gyan

On Sun, Mar 1, 2020 at 7:59 PM Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>> wrote:
Hi Gyan,
In my understanding, PSP is used right in a P node, works for both End and 
End.X ( I haven’t known End.T very well yet).

Suppose:
CE1[PE1P2P3PE4]CE2
PE1 encapsulation the customer packet with an outer IPv6 header and an SRH, the 
packet arriving P2 will be:
(SA=PE1, DA=P2) (SL=2, PE4, P3, P2)  (customer-packet)

Then, the packet arriving P3 will be:
(SA=PE1, DA=P3) (SL=1, PE4, P3, P2)  
(customer-packet)

In Non-PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (SL=0, PE4, P3, P2)  
(customer-packet)

In PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (customer-packet)

For you assumption, “Since every PE in an SR domain both SRv6 or SR-MPLS 
identical to MPLS would be both a SR source node and final destination node of 
an LSP.”
I don’t think that’s always true, you can find an example I was recently 
thinking about in another mail: 
VMTORSpineSuperspine[PE1P2P3PE4]subscribers.
Even if it is true for some network, the capability to handle the SRH on a 
receiving packet is different than the encapsulation of an outer IPv6 header 
with an SRH header.
Sending (with encapsulation) and receiving (with 
recognizing/processing/demultiplexing),  they are not necessarily the same  
like the things to fragment and assembly.
A PE may be well capable of encapsulation everything (like BFD template), but 
may fail to process a little thing that it is unrecognized.

It may just drop 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<mailto:hayabusa...@gmail.com>]
Sent: Monday, March 2, 2020 4:20 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: 6...@ietf.org<mailto:6...@ietf.org>; Bob Hinden 
mailto:bob.hin...@gmail.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; 神明達哉 
mailto:jin...@wide.ad

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Gyan,
In my understanding, PSP is used right in a P node, works for both End and 
End.X ( I haven’t known End.T very well yet).

Suppose:
CE1[PE1P2P3PE4]CE2
PE1 encapsulation the customer packet with an outer IPv6 header and an SRH, the 
packet arriving P2 will be:
(SA=PE1, DA=P2) (SL=2, PE4, P3, P2)  (customer-packet)

Then, the packet arriving P3 will be:
(SA=PE1, DA=P3) (SL=1, PE4, P3, P2)  
(customer-packet)

In Non-PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (SL=0, PE4, P3, P2)  
(customer-packet)

In PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (customer-packet)

For you assumption, “Since every PE in an SR domain both SRv6 or SR-MPLS 
identical to MPLS would be both a SR source node and final destination node of 
an LSP.”
I don’t think that’s always true, you can find an example I was recently 
thinking about in another mail: 
VMTORSpineSuperspine[PE1P2P3PE4]subscribers.
Even if it is true for some network, the capability to handle the SRH on a 
receiving packet is different than the encapsulation of an outer IPv6 header 
with an SRH header.
Sending (with encapsulation) and receiving (with 
recognizing/processing/demultiplexing),  they are not necessarily the same  
like the things to fragment and assembly.
A PE may be well capable of encapsulation everything (like BFD template), but 
may fail to process a little thing that it is unrecognized.

It may just drop 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 (Jingrong) 
Cc: 6...@ietf.org; Bob Hinden ; spring@ietf.org; 神明達哉 

Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming


Hi Jingrong,


Can you help provide some clarification on the use cases for PSP flavor with 
end.X and end.T functions.

Under Ref1 where it mentions end.X and end.T functions to use PSP knob  as well 
if desired.

How would that work with any P node using the PSP function?


https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21


4.21.1<https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21.1>.
  PSP: Penultimate Segment Pop of the SRH





   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,

   the following instructions must be added:



 1.   IF updated SL = 0 & PSP is TRUE

 2.  pop the top SRH ;; Ref1


Ref1: The received SRH had SL=1.  When the last SID is written in the

   DA, the End, End.X and End.T functions with the PSP flavour pop the

   first (top-most) SRH.  Subsequent stacked SRH's may be present but

   are not processed as part of the function.

Also trying to understand the reason given for PSP function for legacy final 
destination egress PE not being SRv6 capable.

Since every PE in an SR domain both SRv6 or SR-MPLS identical to MPLS would be 
both a SR source node and final destination node of an LSP.  I am using the 
MPLS term LSP with SR as the concept of FEC destination which now is a prefix 
SID still exists that all traffic to egress final destination  PE is forwarded 
to.

Since LSPs built to FEC destination are uni directional as they are with MPLS  
and that would be the case as well 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) 
mailto:xiejingr...@huawei.com>> wrote:
Got it.
Thanks for your clarification of your point.

Jingrong

-Original Message-
From: 神明達哉 [mailto:jin...@wide.ad.jp<mailto:jin...@wide.ad.jp>]
Sent: Saturday, February 29, 2020 9:28 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: Ted Lemon mailto:mel...@fugue.com>>; Pablo Camarillo 
(pcamaril) mailto:pcama...@cisco.com>>; Brian E Carpenter 
mailto:brian.e.carpen...@gmail.com>>; Bob Hinden 
mailto:bob.hin...@gmail.com>>; Joel M. Halpern 
mailto:j...@joelhalpern.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

At Fri, 28 Feb 2020 07:54:28 +,
"Xiejingrong (Jingrong)" 
mailto:xiejingr...@huawei.com>> wrote:

> The design of PSP for the benefits of deployment is based on the
> understanding that it does not violate section 4 of RFC8200. In case
> the RFC8200 text 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

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-ietf-spring-srv6-network-programming

Hi Jingrong:

Read your content of SRH header again, I May have a mistake, the routers of 
rtA-rtB-rtC are not listed in longer SRH in your case;

Ok, it is right for your description, I think.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Sunday, March 1, 2020 4:24 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

I suppose “it (DCGW) *is* the penultimate endpoint in the SRH encapsulated by 
VM”.

The packet will look like this when the SRH is updated (but not deleted):
(SA=VM, DA=subscriber) (SL=0, subscriber, DCGW, SuperSpine, Spine, TOR) 
(payload).

The packet will look like this when 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) 
mailto:xiejingr...@huawei.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong:

You may have some misunderstandings of my point of view. It seems that you are 
considering the situation where the source and destination addresses of the 
initial packet from VM belong to the same srv6 domain;
In your example, I don't think DCGW has the right to pop SRH, because it (DCGW) 
is not the last or the penultimate endpoint in the SRH encapsulated by VM. We 
can NOT break basic RH processing rule as defined in SRH draft.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, 
SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending 
to the subscriber for 3 benefits:

(1) Save bandwidth needed to carrying this SRH through SP network

(2) Not boring subscribers to deal with SRH.

(3) Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
s

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Weibin,

I suppose “it (DCGW) *is* the penultimate endpoint in the SRH encapsulated by 
VM”.

The packet will look like this when the SRH is updated (but not deleted):
(SA=VM, DA=subscriber) (SL=0, subscriber, DCGW, SuperSpine, Spine, TOR) 
(payload).

The packet will look like this when 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 to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong:

You may have some misunderstandings of my point of view. It seems that you are 
considering the situation where the source and destination addresses of the 
initial packet from VM belong to the same srv6 domain;
In your example, I don't think DCGW has the right to pop SRH, because it (DCGW) 
is not the last or the penultimate endpoint in the SRH encapsulated by VM. We 
can NOT break basic RH processing rule as defined in SRH draft.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, 
SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending 
to the subscriber for 3 benefits:

(1) Save bandwidth needed to carrying this SRH through SP network

(2) Not boring subscribers to deal with SRH.

(3) Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
same, so there is nothing wrong for PSP in some ways, It is not necessary for 
segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Yes, this is essentially what my second paragraph said. So we agree as to what 
our point of disagreement is :-) and I think we can leave it there until there 
is something new to discuss.

—John

On Feb 29, 2020, at 3:55 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

John,

So for some packet's final destination is the one located in the most inner 
header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encode

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

o interpret “ultimate destination” 
as meaning “the destination depicted in the outer IPv6 header," regardless of 
where the packet is along the source route. Right? So, status quo ante. (I 
think I could defend my reading as being objectively correct based on nothing 
more than the words as written, but that’s beside the point — once we get to 
the stage of spec-lawyering, we have all lost.)

I suppose the choice here remains as it always has been: accept that natural 
language can often be interpreted differently by different readers (especially 
those motivated to reach different interpretations) and leave it at that, 
resolving such differences when they arise through IETF process; or work to 
craft ever more precise language, accepting the consequence that we have to do 
extra work and our specs become more unwieldy as a result. In this particular 
case, I guess an excruciatingly precise definition of “ultimate destination” 
may be the key to resolving ambiguity.

—John

On Feb 29, 2020, at 1:25 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi John,

I respectfully will disagree with your assessment.

Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 
operation. If this would be deprecated, moved to historic or made illegal - 
games over. But if this is still legal then ultimate destination for a packet 
is what it listed in outer IPv6 header DA. That's pretty basic. Now what the 
destination in the header will do with the packet is completely different story.

Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." Of 
course it can. You are looking flat .. If you look at different layers the same 
node is in fact acting in multiple roles - I can easily count 3 but with TI-LFA 
it could be  even more.

The same node is ultimate destination for the outer header
in the same time
The same node is penultimate destination for SR path
in the same time
The same node is just regular IPv6 transit from the perspective of the original 
non encapsulated packet

Kind regards,
R.










On Sat, Feb 29, 2020 at 6:46 PM John Scudder 
mailto:j...@juniper.net>> wrote:
Robert,

I think your comment (emphasis added):

we are dealing here with an *encapsulated* packet which has as its ultimate 
destination SR node X. That SR node X is to perform or not PSP.

Is wrong. It contradicts everything else that’s been said in the hundreds of 
messages that have gone before, not to mention the plain language of 
draft-ietf-spring-srv6-network-programming-10. The word “penultimate” itself is 
enough to prove this: by definition a node can’t be both the penultimate, and 
the ultimate, node. It’s a contradiction in terms, like saying 0 equals 1.

Now, if node X were to remove the RH and perform the decapsulation that would 
be a different story, but the whole point of PSP is that X removes the RH and 
then sends the encapsulated packet on to Y which performs the decapsulation. 
(This point was made in one of the other threads recently, but I’ve lost track 
of by whom and which thread.) As far as I can tell, this non-controversial 
behavior is described in 4.16.3 of the draft and referred to as “USD”.

—John

On Feb 29, 2020, at 6:06 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Dear Jinmei,

Even if RFC8200 section 4 text would say:

 "Extension headers cannot be added to a packet after it has left its source 
node and extension headers cannot be removed from a packet until it has arrived 
at its ultimate destination".

PSP would be still not be violating anything said in this sentence. Reason 
being is that we are dealing here with an *encapsulated* packet which has as 
its ultimate destination SR node X. That SR node X is to perform or not PSP. So 
it is still fully compliant with the specification.

IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4 really 
mandates you to look at segments_left before processing the packet or it is 
equally legal to look at that value after local processing occurs. Definition 
says:



  Segments Left   8-bit unsigned integer.  Number of route

  segments remaining, i.e., number of explicitly

  listed intermediate nodes still to be visited

  before reaching the final destination.

which to me really means that as long as you recognize given routing header 
type you can decrement this value and if zero remove it.

Besides that is a minor detail - as NPG draft could be updated to say:


 S14.1.   If (Segments Left Before Local Decrement == 1) {

 S14.2.  Update the Next Header field in the preceding header to the

Next Header value of the 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 神明

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

 I could defend my reading as being objectively correct based on nothing 
more than the words as written, but that’s beside the point — once we get to 
the stage of spec-lawyering, we have all lost.)

I suppose the choice here remains as it always has been: accept that natural 
language can often be interpreted differently by different readers (especially 
those motivated to reach different interpretations) and leave it at that, 
resolving such differences when they arise through IETF process; or work to 
craft ever more precise language, accepting the consequence that we have to do 
extra work and our specs become more unwieldy as a result. In this particular 
case, I guess an excruciatingly precise definition of “ultimate destination” 
may be the key to resolving ambiguity.

—John

On Feb 29, 2020, at 1:25 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi John,

I respectfully will disagree with your assessment.

Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 
operation. If this would be deprecated, moved to historic or made illegal - 
games over. But if this is still legal then ultimate destination for a packet 
is what it listed in outer IPv6 header DA. That's pretty basic. Now what the 
destination in the header will do with the packet is completely different story.

Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." Of 
course it can. You are looking flat .. If you look at different layers the same 
node is in fact acting in multiple roles - I can easily count 3 but with TI-LFA 
it could be  even more.

The same node is ultimate destination for the outer header
in the same time
The same node is penultimate destination for SR path
in the same time
The same node is just regular IPv6 transit from the perspective of the original 
non encapsulated packet

Kind regards,
R.










On Sat, Feb 29, 2020 at 6:46 PM John Scudder 
mailto:j...@juniper.net>> wrote:
Robert,

I think your comment (emphasis added):

we are dealing here with an *encapsulated* packet which has as its ultimate 
destination SR node X. That SR node X is to perform or not PSP.

Is wrong. It contradicts everything else that’s been said in the hundreds of 
messages that have gone before, not to mention the plain language of 
draft-ietf-spring-srv6-network-programming-10. The word “penultimate” itself is 
enough to prove this: by definition a node can’t be both the penultimate, and 
the ultimate, node. It’s a contradiction in terms, like saying 0 equals 1.

Now, if node X were to remove the RH and perform the decapsulation that would 
be a different story, but the whole point of PSP is that X removes the RH and 
then sends the encapsulated packet on to Y which performs the decapsulation. 
(This point was made in one of the other threads recently, but I’ve lost track 
of by whom and which thread.) As far as I can tell, this non-controversial 
behavior is described in 4.16.3 of the draft and referred to as “USD”.

—John

On Feb 29, 2020, at 6:06 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Dear Jinmei,

Even if RFC8200 section 4 text would say:

 "Extension headers cannot be added to a packet after it has left its source 
node and extension headers cannot be removed from a packet until it has arrived 
at its ultimate destination".

PSP would be still not be violating anything said in this sentence. Reason 
being is that we are dealing here with an *encapsulated* packet which has as 
its ultimate destination SR node X. That SR node X is to perform or not PSP. So 
it is still fully compliant with the specification.

IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4 really 
mandates you to look at segments_left before processing the packet or it is 
equally legal to look at that value after local processing occurs. Definition 
says:



  Segments Left   8-bit unsigned integer.  Number of route

  segments remaining, i.e., number of explicitly

  listed intermediate nodes still to be visited

  before reaching the final destination.

which to me really means that as long as you recognize given routing header 
type you can decrement this value and if zero remove it.

Besides that is a minor detail - as NPG draft could be updated to say:


 S14.1.   If (Segments Left Before Local Decrement == 1) {

 S14.2.  Update the Next Header field in the preceding header to the

Next Header value of the 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 2020 07:54:28 +,
"Xiejingrong (Jingrong)" 
mailto:xiejingr...@huawei..com>> wrote:

> The design of PSP for the

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

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 ; 
spring@ietf.org; 6...@ietf.org
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

At Fri, 28 Feb 2020 07:54:28 +,
"Xiejingrong (Jingrong)"  wrote:

> The design of PSP for the benefits of deployment is based on the 
> understanding that it does not violate section 4 of RFC8200. In case 
> the RFC8200 text may be modified in the future, the PSP may also need to 
> change accordingly.

No, it violates Section 4 of RFC8200.  It's a pity that we have to discuss it 
at this level due to the poor editorial work then (I was also responsible for 
that as one of those reviewing the bis draft), but anyone who involved the 
discussion should know the intent of this text intended to say (borrowing from 
Ron's text) "Extension headers cannot be added to a packet after it has left 
the its source node and extension headers cannot be removed from a packet until 
it has arrived at its ultimate destination".  It might look "an attempt of 
blocking an innovation by a small group of vocal fundamentalists", but if you 
see the responses without a bias, you'd notice that even some of those who seem 
neutral about the underlying SRv6 matter interpret the text that way.

I'd also note that simply because PSP violates RFC8200 doesn't immediately mean 
it (PSP) "needs to change".  It can update RFC8200 with explaining why it's 
necessary and justified.  That's what I requested as you summarized:

> Jinmei: it should say it updates this part of RFC8200 and explain why it's 
> justified.

And, since PSP at least wouldn't break PMTUD, I guess the update proposal will 
have much more chance to be accepted than a proposal including EH insertion.  
On the other hand, pretending there's no violation will certainly trigger many 
appeals and objections at the IETF last call (I'll certainly object to it).  In 
the end, it can easily take much longer, or even fail, than formally claiming 
an update to RFC8200.

--
JINMEI, Tatuya
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Got it.
So the gap may be the 'protocol spec' and the 'code/implementation reality'.
"a non-SRV6 capable router receives SRV6 with segments-left == 0" may have many 
reasons not implemented this well  If Segments Left is zero, the node must 
ignore the Routing header with an unrecognized Routing Type value.
It may just drop 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.
I guess the proposal of PSP is only to solve that kind 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 ; Xiejingrong (Jingrong) 
; Ted Lemon ; Pablo Camarillo 
(pcamaril) ; 神明達哉 ; Joel M. Halpern 
; spring@ietf.org; 6...@ietf.org
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Brian,

> On Feb 28, 2020, at 2:46 PM, Brian E Carpenter  
> wrote:
> 
> Hi Jingrong,
> 
> Thanks for your suggestion.
> 
>> so that the tunnel endpoint
>> router (C) doesn't have to deal with SRH.
> 
> Actually, why does this matter? RFC8200 already handles this case:
> 
>   If, while processing a received packet, a node encounters a Routing
>   header with an unrecognized Routing Type value, the required behavior
>   of the node depends on the value of the Segments Left field, as
>   follows:
> 
>  If Segments Left is zero, the node must ignore the Routing header
>  and proceed to process the next header in the packet, whose type
>  is identified by the Next Header field in the Routing header.
> 
> If a non-SRV6 capable router receives SRV6 with segments-left == 0, it 
> must ignore it. (So why is PSP needed at all?)

Good point and question.   This is why there is a common base format for all 
IPv6 routing headers, it allows for this case.

Bob


> 
> Regards
>   Brian
> 
> On 28-Feb-20 20:54, Xiejingrong (Jingrong) wrote:
>> 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?
>> 
>> 
>> 
>> Jinmei: it should say it updates this part of RFC8200 and explain why it's 
>> justified.
>> 
>> 
>> 
>> Joel: it would seem that there ought to be a good reason for including PSP, 
>> rather than claiming that objectors need to motivate removing it.
>> 
>> 
>> 
>> Bob: There seems to be questions about its relationship with RFC8200.  I am 
>> not seeing this as being resolved.
>> 
>> 
>> 
>> As far as I understand the concern and the draft, I may have the following 
>> proposed text, though I don’t know if that will help to close or narrow the 
>> gap:
>> 
>> 
>> 
>> Proposed text to explicitly explain the PSP at the end of 4.16.1 
>> of rev-10
>> 
>> 
>> 
>> Note that, the SRH is used in an X-in-IP6 tunnel end point case, that 
>> is, router (A)
>> 
>> imposes an SRH, and a Penultimate Segment router (B) removes the SRH 
>> before
>> 
>> this packet goes to the tunnel end point router (C), so that the 
>> tunnel endpoint
>> 
>> router (C) doesn't have to deal with SRH.
>> 
>> 
>> 
>> This has some very important benefits for deployment in some networks 
>> when the
>> 
>> final tunnel end point is a lower-end node which is not capable of 
>> processing
>> 
>> the SRH for reasons like the hardware is overloaded or unable to 
>> upgraded to
>> 
>> process well with SRH.
>> 
>> 
>> 
>> The use of SRH with AH by an SR source node, and processing at a SR 
>> Penultimate
>> 
>> segment endpoint node is not defined in 
>> 
>> 
>> or in this document.
>> 
>> 
>> 
>> The use of PSP does not impact the MTU Considerations defined in 
>> section 5.3 of
>> 
>> .
>> 
>> 
>> 
>> The design of PSP for the benefits of deployment is based on the 
>> understanding
>> 
>> that it does not violate section 4 of RFC8200. In case the RFC8200 
>> text may be
>> 
>> modified in the future, t

[spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[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?

Jinmei: it should say it updates this part of RFC8200 and explain why it's 
justified.

Joel: it would seem that there ought to be a good reason for including PSP, 
rather than claiming that objectors need to motivate removing it.

Bob: There seems to be questions about its relationship with RFC8200.  I am not 
seeing this as being resolved.

As far as I understand the concern and the draft, I may have the following 
proposed text, though I don’t know if that will help to close or narrow the gap:

Proposed text to explicitly explain the PSP at the end of 4.16.1 of 
rev-10

Note that, the SRH is used in an X-in-IP6 tunnel end point case, that is, 
router (A)
imposes an SRH, and a Penultimate Segment router (B) removes the SRH before
this packet goes to the tunnel end point router (C), so that the tunnel endpoint
router (C) doesn't have to deal with SRH.

This has some very important benefits for deployment in some networks when the
final tunnel end point is a lower-end node which is not capable of processing
the SRH for reasons like the hardware is overloaded or unable to upgraded to
process well with SRH.

The use of SRH with AH by an SR source node, and processing at a SR Penultimate
segment endpoint node is not defined in 
or in this document.

The use of PSP does not impact the MTU Considerations defined in section 5.3 of
.

The design of PSP for the benefits of deployment is based on the understanding
that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
modified in the future, the PSP may also need to change accordingly.

In case the final tunnel endpoint router is fully capable of the functionality
of SRH and the SRv6-NP defined in this document, it is recommended not to use
the PSP.

***End

Thanks
Jingrong


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Friday, February 28, 2020 4:55 AM
To: Pablo Camarillo (pcamaril) 
Cc: spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - 
draft-ietf-spring-srv6-network-programming

On Feb 27, 2020, at 3:38 PM, Pablo Camarillo (pcamaril) 
mailto:pcama...@cisco.com>> wrote:
The discussion that we are having is about PSP which has nothing to do with 
that.

So, there is text in the document that addresses Brian’s question?

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

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 even covered by their fictional interpretation of RFC8200.


RFC8200:
   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

Isn't the word 'reaches' clear? A packet with the destination address owing to 
node B 'reaches' the node B. 

How can this be claimed again violation 8200 after 2 months? 

I remember that, Bob, Joel and many others had clarified this very clearly 2 
months before, which led to the errata, saying 'clarifying' 8200.

look at the errata
Section 4 says:
   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.
It should say:
   Extension headers (except for the Hop-by-Hop Options header, or a 
   Destination Options header preceding a Routing header) are not processed,
   inserted, or deleted by any node along a packet's delivery path, until the
   packet reaches the final destination node (or each of the set of final
   destination nodes, in the case of multicast).

So do you think the RFC8200 had made so big a mistake without awareness of the 
distinction of 'destination' and 'final destination' for 25 years since 1883 ?
And the folks that had been participated in the meantime had been made the same 
mistake for 25 years since 1883?
I can find the word 'reaches', 'destination' and 'final destination' in RFC1883 
clearly, and I assume this distinction had been well aware of since 1883.


Thanks
Jingrong

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Is srv6 PSP a good idea

[Xiejingrong (Jingrong)]

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 draft, then I think it's 
backward for interoperation.

RFC4301:
3.2.  How IPsec Works

   IPsec uses two protocols to provide traffic security services --
   Authentication Header (AH) and Encapsulating Security Payload (ESP).
   Both protocols are described in detail in their respective RFCs
   [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

Thanks,
Jingrong

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mark Smith
Sent: Wednesday, February 26, 2020 8:31 AM
To: Pablo Camarillo (pcamaril) 
Cc: Ron Bonica ; spring@ietf.org; Joel M. Halpern 

Subject: Re: [spring] Is srv6 PSP a good idea

Hi Pablo,

On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)  
wrote:
>
>  Hi Ron,
>
> I guess we are making some progress here but going in some circles. So far we 
> have moved from “this violates RFC8200” to “there are no use-cases or 
> benefits” to “this is complex for an ASIC” to “what is the benefit again” and 
> now back to “this is complex for an ASIC”.
>

As far as I know, the next header field in both the IPv6 fixed header and in 
extension headers is immutable while the packet is travelling within the 
network, as is the payload length field in the IPv6 base fixed header.

Nothing in RFC 8200 modifies those fields while the packet is in flight between 
the packet's original source and final destination, nor is there anything in 
RFC 8200 that specifies how to do those modifications and any other discussion 
about the consequences and considerations when doing so.


The IPsec AH header is providing integrity checking over fields in the
IPv6 packet that shouldn't be being modified while the packet is within the 
network. What is and isn't protected by AH can be seen to be a specification of 
what processing on a packet can and cannot occur while it is in flight across 
the network towards its final destination.

Therefore, AH is really a quality assurance mechanism for the network packet 
processing that RFC 8200 specifies. The processing of the packet by the network 
with or without the use of AH should be the same. AH should really only be 
necessary if there is a belief that the network is likely not to be processing 
packets in accordance to RFC 8200, either accidentally or intentionally.


Per RFC4302 (IPsec AH),  the following section explicitly states which fields 
in the IPv6 header are immutable and are to be protected by AH:


3.3.3.1.2.  ICV Computation for IPv6

3.3.3.1.2.1.  Base Header Fields

   The IPv6 base header fields are classified as follows:

Immutable
   Version
   Payload Length
   Next Header
   Source Address
   Destination Address (without Routing Extension Header)

   Mutable but predictable
   Destination Address (with Routing Extension Header)

   Mutable (zeroed prior to ICV calculation)
   DSCP (6 bits, see RFC2474 [NBBB98])
   ECN (2 bits, see RFC3168 [RFB01])
   Flow Label (*)
   Hop Limit

(*) The flow label described in AHv1 was mutable, and in
RFC 2460 [DH98] was potentially mutable.  To retain
compatibility with existing AH implementations, the
flow label is not included in the ICV in AHv2.




> As for how easy or not something is, the PSP behavior has been implemented 
> and deployed (running code). The use-cases have been described and positively 
> reinforced by operators. I don't think there is any further explanation to 
> provide.
>

"Just because you can do something, doesn't mean you should."

How much troubleshooting experience have they had with this?

I think a very important factor is how easy something is to troubleshoot - how 
obvious is the mechanism works; is the mechanism consistent with existing 
behaviours i.e. the principle of least surprise (removing EHs at an 
intermediary hop certainly isn't in IPv6, even if the intermediary hop as the 
packet's current DA); when it inevitably fails, how obvious is it where the 
fault is likely to be; and how quickly can a typical fault be rectified.



Regards,
Mark.




> Happy Holidays,
> Pablo.
>
>
> -Original Message-
> From: Ron Bonica 
> Date: Tuesday, 17 December 2019 at 16:06
> To: "Pablo Camarillo (pcamaril)" , "Joel M. 
> Halpern" , "spring@ietf.org" 
> Subject: RE: [spring] Is srv6 PSP a good idea
>
> 

Re: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early Allocation Call

[Xiejingrong (Jingrong)]

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" registry.

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-9.1

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-5.3

https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml



In parallel of the Working Group Last Call which is currently running, the 
authors are requesting for early code point allocation from IANA as 
implementations are under way.



The criteria for early allocation are:

   a.  The code points must be from a space designated as "RFC

   Required", "IETF Review", or "Standards Action".  Additionally,

   requests for early assignment of code points from a

   "Specification Required" registry are allowed if the

   specification will be published as an RFC.



   b.  The format, semantics, processing, and other rules related to

   handling the protocol entities defined by the code points

   (henceforth called "specifications") must be adequately described

   in an Internet-Draft.



   c.  The specifications of these code points must be stable; i.e., if

   there is a change, implementations based on the earlier and later

   specifications must be seamlessly interoperable.



   d.  The Working Group chairs and Area Directors (ADs) judge that

   there is sufficient interest in the community for early (pre-RFC)

   implementation and deployment, or that failure to make an early

   allocation might lead to contention for the code point in the

   field.

https://tools.ietf.org/html/rfc7120#section-2



I believe the above conditions are met. (minus the AD judgement which is 
further down in the process)



As a reminder, this topic has mainly been discussed following IETF 105 
(Montréal) both during the meeting and on the mailing list.

During IETF 106 it has been discussed in the IntArea WG. 
https://datatracker.ietf.org/meeting/106/proceedings#intarea



Note that this code point is not to be specific to SRv6. Depending on AD 
guidance, this specific code point even be moved from 
draft-ietf-spring-srv6-network-programming into a specific 1 page draft.



If you support early adoption,  please include “support” along with any 
comments about the draft’s technical solution.



If you do not support early allocation, please include “no support” in your 
email and indicate why.



Thank you,

--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

Re: [spring] Is srv6 PSP a good idea

[Xiejingrong (Jingrong)]

Hi Joel,

Regrading this question:
Do you have any comments on what appears to be the significant increase
in complexity on the device performing PSP? 

I think the removal of some bytes from an packet header is a common case 
without any significant increasing complexity for a long time.
For example, a Layer-2 switch receives an ethernet frame from a port with a 
vlan tag, and forwards/switches it to another port without a vlan tag, then it 
strips the 2 bytes of vlan tag value and 2 bytes of 0x8100. The 4 bytes are in 
the middle of the ethernet header and the ip header, which otherwise would not 
need to be stripped if it's the case from a tag port to another tag port.

I found this in my book, "Network system design using network processors" by 
Douglas E. Comer 2004.
On page 38 "4.12 Operation and Data Chaining", introduced modern NICs use a 
technique known as “operation chaining or command chaining” instead of 
operating on a single large buffer.
Which makes me believe that, the removal of some bytes from some packet header 
(L2 or L3 header), would not cause the 1500 bytes of packet be moved, but 
instead a very basic function that various packet processors have solved very 
long ago as a basic function of "header/packet modification".

Hope the above understanding is right.

Thanks
Jingrong


From: spring [spring-boun...@ietf.org] on behalf of Joel M. Halpern 
[j...@joelhalpern.com]
Sent: Wednesday, December 11, 2019 22:15
To: spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea

Thank you Jingrong for providing some of the other motivations.  Two
furhter comments.

As far as I know, the only savings on the end box is the processing for
noticing the SRH, noticing that SL is 0 and there are no relevant TLVs,
and then moving on.

If the actual end device is not part of the SR domain, I assume that
encapsulation would have been used, so I think it is reasoanble to
assume that in the PSP case the end device is SR capable.

Do you have any comments on what appears to be the 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 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 delivery/demultiplex the packet to the right overlay service.
> (1.2) example 1, the final destination may need to handle the DOH after the 
> RH.
> (1.3) example 2, the final destination may need to do the assembly of 
> fragmented packets.
> (1.4) example 3, the final destination may need to do AH/ESP after the 
> Fragmentation Header.
> (1.5) example 4, the final destination may need to deliver the packet to the 
> right overlay service.
>
> (2) support the incremental deployment when final destination(s) do not 
> process/recognize SRH. This benefit can be notable for the following sub 
> reasons.
> (2.1) A core router may (fan-out) connected with a big number of low-end 
> routers that do not support SRH but support tunnel-end/service-demultiplex 
> function of SRv6.
>
> Thanks
> Jingrong
>
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Wednesday, December 11, 2019 10:55 AM
> To: spring@ietf.org
> Subject: [spring] Is srv6 PSP a good idea
>
> For purposes of this thread, even if you think PSP violates RFC 8200, let us 
> assume that it is legal.
>
> As I understand it, the PSP situation is:
> o the packet arrives at the place (let's not argue about whether SIDs are 
> locators) identified by the SID in the destination address field o that SID 
> is the next to last SID in the SID list o that sid is marked as / known to be 
> PSP o at the intended place in the processing pseudocode, the last (first) 
> entry in the SRH is copied into the destination IPv6 address field of the 
> packet
> -> The SRH being used is then removed from the packet.
>
> In order to evaluate whether this is a good idea, we have to have some idea 
> of the benefit.  It may be that I am missing some of the benefit, and I would 
> appreciate clarification.
> As far as I can tell, the benefit of this removal is that in exchange for 
> this node doing the work of removing the SRH, the final node in the SRH does 
> not have to process the SRH at all, as it has been removed.
>
> I have trouble seeing how that work tradeoff can be beneficial.
> Removing bytes from the middle of a packet is a complex operation.
> Doi

Re: [spring] Is srv6 PSP a good idea

[Xiejingrong (Jingrong)]

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 delivery/demultiplex the packet to the right overlay service.
(1.2) example 1, the final destination may need to handle the DOH after the RH.
(1.3) example 2, the final destination may need to do the assembly of 
fragmented packets.
(1.4) example 3, the final destination may need to do AH/ESP after the 
Fragmentation Header.
(1.5) example 4, the final destination may need to deliver the packet to the 
right overlay service.

(2) support the incremental deployment when final destination(s) do not 
process/recognize SRH. This benefit can be notable for the following sub 
reasons.
(2.1) A core router may (fan-out) connected with a big number of low-end 
routers that do not support SRH but support tunnel-end/service-demultiplex 
function of SRv6.

Thanks
Jingrong

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: Wednesday, December 11, 2019 10:55 AM
To: spring@ietf.org
Subject: [spring] Is srv6 PSP a good idea

For purposes of this thread, even if you think PSP violates RFC 8200, let us 
assume that it is legal.

As I understand it, the PSP situation is:
o the packet arrives at the place (let's not argue about whether SIDs are 
locators) identified by the SID in the destination address field o that SID is 
the next to last SID in the SID list o that sid is marked as / known to be PSP 
o at the intended place in the processing pseudocode, the last (first) entry in 
the SRH is copied into the destination IPv6 address field of the packet
-> The SRH being used is then removed from the packet.

In order to evaluate whether this is a good idea, we have to have some idea of 
the benefit.  It may be that I am missing some of the benefit, and I would 
appreciate clarification.
As far as I can tell, the benefit of this removal is that in exchange for this 
node doing the work of removing the SRH, the final node in the SRH does not 
have to process the SRH at all, as it has been removed.

I have trouble seeing how that work tradeoff can be beneficial. 
Removing bytes from the middle of a packet is a complex operation. 
Doing so in Silicon (we expect this to be done in the fast path of significant 
forwarders as I understand it) requires very special provision.  Even in 
software, removing bytes from the middle of a packet requires somewhere between 
some and a lot of extra work.  It is distinctly NOT free.

In contrast, we have assumed that the work of processing SRH itself is 
tractable, since otherwise all of SRv6 would be problematic.  So why is this 
necessary.

Yours,
Joel

PS: Note that both the MPLS case and the encapsulation case are very different 
in that the material being removed is at the front of the IP packet.  Pop or 
prepend are MUCH easier than middle-removal (or middle-insertion).

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

+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.  When an Authentication 
header is present
 Line 576:   before reaching the final 
destination.
 Line 650:present, the Destination Address of concern is that of 
the final
 Line 838:  The Fragment header is not present in the final, 
reassembled
 Line 1130:  Address used in the pseudo-header is that of the 
final

Thanks
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, December 11, 2019 8:56 AM
To: Joel M. Halpern 
Cc: Fernando Gont ; SPRING WG List ; 
6...@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming


Bravo Joel !



On Wed, Dec 11, 2019 at 1:49 AM Joel M. Halpern 
mailto:j...@joelhalpern.com>> wrote:
Fernando, I really wish I could agree with you.
But I can't.

In 8200, it is clear that the meaning fo "Destination Address" for an
IPv6 packet is the value placed in the IPv6 destination address field.
the fact that if we had looked ahead we might have said something
different does not change what words we chose to use.  If I am going to
insist (as I have in other contexts) that other folks live with the
words we compromised on in 8200, then I have to live myself with the
words we compromised on in 8200.

I have concerns about whether PSP is a good design.  I am trying to
write a useful note on the topic.  (And without such a note, I can not
expect anyone to care about thoughts in my head.)   But I can not and
will not claim that PSP violates RFC 8200.

Yours,
Joel

On 12/10/2019 6:16 PM, Fernando Gont wrote:
> Bruno,
>
> On 10/12/19 13:18, 
> bruno.decra...@orange.com wrote:
>> Fernando,
>>
>> Thank you for spelling out your comment, plus on the WGLC thread.
>> More in-line
>>
>>> Bruno,
>>>
>>> On 5/12/19 12:15, 
>>> bruno.decra...@orange.com wrote:
>>> []>
 This email starts a two weeks Working Group Last Call on
 draft-ietf-spring-srv6-network-programming [1].



 Please read this document if you haven't read the most recent version,
 and send your comments to the SPRING WG list, no later than December 20.



 You may copy the 6MAN WG for IPv6 related comment, but consider not
 duplicating emails on the 6MAN mailing list for the comments which are
 only spring specifics.



 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.

 This may help avoiding that the thread become specific to this point and
 that other points get forgotten (or that the thread get converted into
 parallel independent discussions)
>>>
>>> Penultimate Segment Popping describes/specifies the removal of a SRH at
>>> a place other than the final destination of the packet.
>>>
>>> Such behavior violates RFC8200, which specifies:
>>>
>> > Extension headers (except for the Hop-by-Hop Options header) are not
>> > processed, inserted, or deleted by any node along a packet's delivery
>> > path, until the packet reaches the node (or each of the set of nodes,
>> > in the case of multicast) identified in the Destination Address field
>> > of the IPv6 header.
>>>
>>> Note, of course, that the reference of "Destination Address" in RFC8200
>>> is clearly the final destination of the packet -- for instance, RFC8200
>>
>> I hear and can understand your reading of RFC8200.
>
> Could you please check RFC8200, and tell me what other possible
> interpretation of "Destination Address" you might have, in the context
> of RFC8200.
>
> RFC8200 does not even specify any routing header types. SO...where's the
> ambiguity?
>
>
>
>> At minimum, I think that we can agree that there is another reading, as 
>> expressed by other WG participants, and hence I disagree with "of course".
>
> No, I argue that there is not. IN fact, I argue that folks have been
> following that strategy for way too long, and that's quite frustrating.
>
>
>
>> Personally, I understand "Destination Address" as "Destination Address field 
>> of the IPv6 header." as indicated explicitly in the text quoted.
>
> The quoted text is from RFC8200. In the context of RFC8200 the
> Destination Address can only contain the ultimate destination of the
> packet. Where's the ambiguity?
>
> And let me ask you, as chair, another question, that will lead you to
> the same place: is IPv6 and end to end protocol?
>
>
> The fact that I may claim that RFC8200 contains a receipe for BBQ does
> not actually mean that that's the case.
>
>
>
>> I'm fine with having this clarified 

[spring] draft-voyer-spring-sr-replication-segment-00 //RE: draft-voyer-spring-sr-p2mp-policy-03

[Xiejingrong (Jingrong)]

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. Instead, it 
"stitches multiple replication segments in an SR domain" seems going opposite 
to your suggestion.

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 replication segments in an SR domain" is creating a multicast tree.
For simple comparison, mLDP is exactly such thing of "stitching multiple 
replication segments in a domain".

You said "in particular the handling of topology changes and the avoidance of 
loops"
But once the "stitching multiple replication segments in an SR domain" is 
considered/allowed/recommended by SPRING, such topology change things may have 
to be brought to consideration, I am afraid.


Thanks
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, August 01, 2019 9:48 PM
To: SPRING WG List 
Subject: [spring] draft-voyer-spring-sr-p2mp-policy-03

Hi authors,

You have requested WG adoption for draft-voyer-spring-sr-p2mp-policy
https://tools.ietf.org/html/draft-voyer-spring-sr-p2mp-policy-03

Reviewing the document, I'd like to propose a simplification along two 
directions:

a)  Re-use the existing SR-policy framework as much as possible

b)  Define the SR replication policy only (aka spray) and make the Tree-SID 
as out of scope.

"a" would allow to simplify the text of the draft, enforces that the sr-policy 
framework is consistent, re-uses all existing behavior from SR-policy. In 
short, the SR replication policy may possibly be defined as replicating over N  
SR-policies.
"b" would remove the specification of Tree-SID. I would argue that Tree-SID is 
not adequately specified in this document, but rather left to the 
controller/PCE. Also the SPRING WG is not really chartered nor have the 
expertise to define a specification creating a multicast tree (in particular 
the handling of topology changes and the avoidance of loops). Note that you can 
still introduce the Tree-SID name if you want, e.g. saying can one can built 
one using one or multiple SR replication policies, but specifying that this is 
out of scope of this document.

Please let me know what you think about this.

On a side note, although this can be addressed after WG adoption, it would be 
good if the reader of the section "Security Considerations" had the impression 
that the security considerations have really been considered. E.g. the policies 
been locally configured so it seems like there is room for configuring 
inconsistent policies on two nodes, creating a multicast forwarding loops. 
(Unless may be if you provide enough restrictions in the specification of the 
SR-replication policy). I'm not necessarily asking for a solution, but at least 
mentioning the issue.

Thanks,
Regards,
--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

Re: [spring] Request for WG adoption of draft-dong-spring-sr-for-enhanced-vpn-05

[Xiejingrong (Jingrong)]

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 Of Loa Andersson
Sent: Monday, October 21, 2019 6:33 PM
To: spring@ietf.org
Cc: Dongjie (Jimmy) ; spring-cha...@ietf.org; li zhenqiang 

Subject: Re: [spring] Request for WG adoption of 
draft-dong-spring-sr-for-enhanced-vpn-05

WG,

I reviewed this document before the last version, my comments have been 
addressed and I think this is ready for adoption as a working grouo document.

/Loa

On 2019-10-21 12:16, li zhenqiang wrote:
> Hello all and chairs,
> 
> I support the adoption poll as a co-author. I believe the doc is 
> mature enough to be a wg item.
> 
> Best Regards,
> Zhenqiang Li
> --
> --
> li_zhenqi...@hotmail.com
> 
> *From:* Dongjie (Jimmy) 
> *Date:* 2019-10-21 13:21
> *To:* 'SPRING WG List' 
> *CC:* spring-cha...@ietf.org 
> *Subject:* [spring] Request for WG adoption of
> draft-dong-spring-sr-for-enhanced-vpn-05
> Dear WG and Chairs,
> A new revision of draft-dong-spring-sr-for-enhanced-vpn has been
> uploaded to resolve some recently received comments. This document
> describes the Segment Routing based mechanism to provide enhanced
> VPN, which aligns with the enhanced VPN (VPN)+ framework document in
> TEAS WG. The mechanism could be used to enable transport network
> slicing for 5G.
> The major changes compared to the -04 version are:
>    1. Update the draft template.
>    2. Add reference to the definition of network slicing in 3GPP
> TS23.501 and the definition of transport network slicing in
> draft-ietf-teas-enhanced-vpn-03 respectively.
>    3. Editorial changes in several sections to clarify and improve
> the readability.
>    4. Change some coauthors' affiliation and mail address.
> This update shows that the major content of this draft has become
> stable and solid, thus the authors would like to request the WG to
> consider the adoption of this document.
> Comments are always welcome. Thanks.
> Best regards,
> Jie
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Wednesday, October 16, 2019 3:28 PM
> To: Takuya Miyasaka ; Zhenqiang Li
> ; Fengwei Qin
> ; Stewart Bryant
> ; Yongqing Zhu ;
> Dongjie (Jimmy) 
> Subject: New Version Notification for
> draft-dong-spring-sr-for-enhanced-vpn-05.txt
> A new version of I-D, draft-dong-spring-sr-for-enhanced-vpn-05.txt
> has been successfully submitted by Jie Dong and posted to the IETF
> repository.
> Name: draft-dong-spring-sr-for-enhanced-vpn
> Revision: 05
> Title: Segment Routing for Enhanced VPN Service
> Document date: 2019-10-16
> Group: Individual Submission
> Pages: 20
> URL:   
> 
> https://www.ietf.org/internet-drafts/draft-dong-spring-sr-for-enhanced-vpn-05.txt
> Status:
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/
> Htmlized:  
> https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-05
> Htmlized:  
> 
> https://datatracker.ietf..org/doc/html/draft-dong-spring-sr-for-enhanced-vpn
> Diff:  
> https://www.ietf.org/rfcdiff?url2=draft-dong-spring-sr-for-enhanced-vpn-05
> Abstract:
>     Enhanced VPN (VPN+) is an enhancement to VPN services to enable
> it to
>     support the needs of new applications, particularly applications
> that
>     are associated with 5G services.  These applications require better
>     isolation from both control and data plane's perspective and have
>     more stringent performance requirements than can be provided with
>     overlay VPNs.  The characteristics of an enhanced VPN as
> perceived by
>     its tenant needs to be comparable to those of a dedicated private
>     network.  This requires tight integration between the overlay
> VPN and
>     the underlay network topology and resources in a scalable
> manner.  An
>     enhanced VPN may form the underpinning of 5G network slicing, but
>     will also be of use in its own right.  This document describes
> how to
>     use segment routing based mechanisms to provide the enhanced VPN
>     service with the required network topology and resources.  The
>     overall mechanism of providing segment routing based enhanced VPN
>     service is also described.  The proposed mechanism is applicable to
>     both segment routing with MPLS data plane (SR-MPLS) and segment
>