Re: [spring] IPR Call for draft-ietf-spring-segment-routing-policy

[Luay Jalil]

I am not aware of any undisclosed IPR related to this document

Luay

On Sun, Apr 11, 2021 at 5:34 AM James Guichard <
james.n.guich...@futurewei.com> wrote:

> Hi Authors, Contributors, WG
>
>
>
> Authors of draft-ietf-spring-segment-routing-policy have asked for WG last
> call. In preparation of the WGLC this email starts a poll for IPR.
>
>
>
> If you are aware of IPR that applies to
> draft-ietf-spring-segment-routing-policy please respond to this email and
> keep the mailing list in copy.
>
> If you are aware of IPR, please indicate whether it has been disclosed in
> accordance to the IETF IPR rules (detailed are described in RFCs 3979,
> 4879, 3669 and 5378).
>
>
>
> If you are an *author or contributor* please respond to this email, on the
> SPRING mailing list, regardless of whether or not you're aware of any IPR.
>
> If you are not an author or contributor, please explicitly respond only if
> you're aware of IPR that has not yet been disclosed.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
>
>
>
>
>
>
> ___
> 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] IPR Call for draft-ietf-spring-segment-routing-policy

[Jose Liste (jliste)]

Hello,
I am not aware of any undisclosed IPR associated with this draft

Regards,
Jose

From: spring  On Behalf Of James Guichard
Sent: Sunday, April 11, 2021 3:34 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org
Subject: [spring] IPR Call for draft-ietf-spring-segment-routing-policy

Hi Authors, Contributors, WG

Authors of draft-ietf-spring-segment-routing-policy have asked for WG last 
call. In preparation of the WGLC this email starts a poll for IPR.

If you are aware of IPR that applies to 
draft-ietf-spring-segment-routing-policy please respond to this email and keep 
the mailing list in copy.
If you are aware of IPR, please indicate whether it has been disclosed in 
accordance to the IETF IPR rules (detailed are described in RFCs 3979, 4879, 
3669 and 5378).

If you are an *author or contributor* please respond to this email, on the 
SPRING mailing list, regardless of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if 
you're aware of IPR that has not yet been disclosed.

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/



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

Re: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[Jeffrey (Zhaohui) Zhang]

Hi Rishabh,

Thanks for chiming in on the End behavior point!

Hi Fan,

Please see zzh2 below for other points.

From: Rishabh Parekh 
Sent: Wednesday, April 14, 2021 3:10 PM
To: Yangfan (IP Standard) 
Cc: Jeffrey (Zhaohui) Zhang ; Gengxuesong (Geng Xuesong) 
; Rishabh Parekh (riparekh) ; 
Arvind Venkateswaran (arvvenka) ; spring@ietf.org
Subject: Re: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[External Email. Be cautious of content]

Fan,


Zzh> RFC 8986 does specify additional flavors of End and End.X function with 
USP, PSP and USD behaviors which are modifications to base End and End.X 
function; exactly what we are proposing here – enhancing Replication Segment to 
add (FI,SN) when required.

Fan>> can you explain more? I don’t see correlation between flavors and adding 
(FI,SN).

Fan>> after seeing all these “if, then” shown above, I even feel more strongly 
to support separating two segments. ☺ In RFC8986, there is no single Endpoint 
behavior having such “if, then” structure to specify different functions.



RP> What Jeffrey means is RFC 8986 already has a precedent of defining 
functionality, End and End.X, with slight modifications to basic behavior – 
these are the PSP, USP and USD variants. An implementation that supports these 
flavors has to have “if-then-else” logic to deal with active SIDs for End and 
End.X segments with different flavors.

RP> We are proposing the same approach here; modify base Replication segment 
behavior to add (FI,SN) if required. Also note that the definition of 
Replication segment already has “if-then-else” built in to deal with 
decapsulation on a Leaf node, or replication to downstream nodes, or to do both 
on a Bud node.



-Rishabh

On Thu, Apr 8, 2021 at 6:25 AM Yangfan (IP Standard) 
mailto:shirley.yang...@huawei.com>> wrote:
Hi Jeffrey,
Apology for being so late to reply. Please see inline starts with Fan>>.

Cheers,
Fan

发件人: spring [mailto:spring-boun...@ietf.org] 代表 
Jeffrey (Zhaohui) Zhang
发送时间: 2021年3月30日 5:06
收件人: Yangfan (IP Standard) 
mailto:shirley.yang...@huawei.com>>; Gengxuesong 
(Geng Xuesong) mailto:gengxues...@huawei.com>>; 
'Rishabh Parekh (riparekh)' mailto:ripar...@cisco.com>>; 
'Arvind Venkateswaran (arvvenka)' 
mailto:arvve...@cisco.com>>; 
spring@ietf.org
主题: Re: [spring] Comments on draft-geng-spring-sr-redundancy-protection

Hi Fan,

Please see zzh> below.

From: Yangfan (IP Standard) 
mailto:shirley.yang...@huawei.com>>
Sent: Friday, March 26, 2021 11:58 PM
To: Jeffrey (Zhaohui) Zhang 
mailto:zzhang=40juniper@dmarc.ietf.org>>;
 Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>>; 
spring@ietf.org; Rishabh Parekh (riparekh) 
mailto:ripar...@cisco.com>>; Arvind Venkateswaran 
(arvvenka) mailto:arvve...@cisco.com>>
Subject: 答复: Comments on draft-geng-spring-sr-redundancy-protection


Hi Jeffrey,



Thank you for the comments, please see the reply inline starts with [FY#].



Cheers,

Fan





-邮件原件-
发件人: spring [mailto:spring-boun...@ietf.org] 代表 Jeffrey (Zhaohui) Zhang
发送时间: 2021年3月26日 3:19
收件人: Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>>; 
spring@ietf.org; Rishabh Parekh (riparekh) 
mailto:ripar...@cisco.com>>; Arvind Venkateswaran 
(arvvenka) mailto:arvve...@cisco.com>>
主题: [spring] Comments on draft-geng-spring-sr-redundancy-protection



Hi Xuesong, Mach, Fan,



Some comments/questions on the proposal.



1. We don't need an additional "redundancy segment" for the replication 
semantics. Existing "replication segment" 
(draft-ietf-spring-sr-replication-segment) can be used as is, especially for 
the scenario where the original header already carries (FI, SN) information.

--[FY1]: three considerations here:

a). For the scenario you mentioned, that is correct, redundancy segment and 
replication segment share a common behavior of "packet duplication". The 
significant difference between two segments is the behavior of adding FI and 
SN. Unfortunately, there is no application in SRv6 required to carry (FI,SN) 
information in IPv6 header, which results in a more common scenario is where 
the original packet doesn't carry (FI, SN). So the current design of redundancy 
segment is based on this scenario.



Zzh> Since the presentation talked about scenario where the (FI, SN) 
information is already carried, it is fair to discuss that in my initial 
comments; I understand that you want to focus on the other scenario, and that’s 
fine – see later comments below.



Fan>> I read the draft of replication segment, and have two questions if 
replication segment is used in redundancy protection.

1) I believe merging node should be as the downstream node, since the nodes in 
precedence of merging node should not be redundancy protection aware. In this 
case, there will be at least two identical downstream nodes. In replication 
segment, there is no definition of such a 

Re: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[Rishabh Parekh]

Fan,

Zzh> RFC 8986 does specify additional flavors of End and End.X function
with USP, PSP and USD behaviors which are modifications to base End and
End.X function; exactly what we are proposing here – enhancing Replication
Segment to add (FI,SN) when required.

Fan>> can you explain more? I don’t see correlation between flavors and
adding (FI,SN).

Fan>> after seeing all these “if, then” shown above, I even feel more
strongly to support separating two segments. J In RFC8986, there is no
single Endpoint behavior having such “if, then” structure to specify
different functions.



RP> What Jeffrey means is RFC 8986 already has a precedent of defining
functionality, End and End.X, with slight modifications to basic behavior –
these are the PSP, USP and USD variants. An implementation that supports
these flavors has to have “if-then-else” logic to deal with active SIDs for
End and End.X segments with different flavors.

RP> We are proposing the same approach here; modify base Replication
segment behavior to add (FI,SN) if required. Also note that the definition
of Replication segment already has “if-then-else” built in to deal with
decapsulation on a Leaf node, or replication to downstream nodes, or to do
both on a Bud node.


-Rishabh


On Thu, Apr 8, 2021 at 6:25 AM Yangfan (IP Standard) <
shirley.yang...@huawei.com> wrote:

> Hi Jeffrey,
>
> Apology for being so late to reply. Please see inline starts with Fan>>.
>
>
>
> Cheers,
>
> Fan
>
>
>
> *发件人:* spring [mailto:spring-boun...@ietf.org] *代表 *Jeffrey (Zhaohui)
> Zhang
> *发送时间:* 2021年3月30日 5:06
> *收件人:* Yangfan (IP Standard) ; Gengxuesong
> (Geng Xuesong) ; 'Rishabh Parekh (riparekh)' <
> ripar...@cisco.com>; 'Arvind Venkateswaran (arvvenka)' ;
> spring@ietf.org
> *主题:* Re: [spring] Comments on draft-geng-spring-sr-redundancy-protection
>
>
>
> Hi Fan,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Yangfan (IP Standard) 
> *Sent:* Friday, March 26, 2021 11:58 PM
> *To:* Jeffrey (Zhaohui) Zhang ;
> Gengxuesong (Geng Xuesong) ; spring@ietf.org;
> Rishabh Parekh (riparekh) ; Arvind Venkateswaran
> (arvvenka) 
> *Subject:* 答复: Comments on draft-geng-spring-sr-redundancy-protection
>
>
>
> Hi Jeffrey,
>
>
>
> Thank you for the comments, please see the reply inline starts with [FY#].
>
>
>
> Cheers,
>
> Fan
>
>
>
>
>
> -邮件原件-
> 发件人: spring [mailto:spring-boun...@ietf.org ] 代表
> Jeffrey (Zhaohui) Zhang
> 发送时间: 2021年3月26日 3:19
> 收件人: Gengxuesong (Geng Xuesong) ; spring@ietf.org;
> Rishabh Parekh (riparekh) ; Arvind Venkateswaran
> (arvvenka) 
> 主题: [spring] Comments on draft-geng-spring-sr-redundancy-protection
>
>
>
> Hi Xuesong, Mach, Fan,
>
>
>
> Some comments/questions on the proposal.
>
>
>
> 1. We don't need an additional "redundancy segment" for the replication
> semantics. Existing "replication segment"
> (draft-ietf-spring-sr-replication-segment) can be used as is, especially
> for the scenario where the original header already carries (FI, SN)
> information.
>
> --[FY1]: three considerations here:
>
> a). For the scenario you mentioned, that is correct, redundancy segment
> and replication segment share a common behavior of "packet duplication".
> The significant difference between two segments is the behavior of adding
> FI and SN. Unfortunately, there is no application in SRv6 required to carry
> (FI,SN) information in IPv6 header, which results in a more common scenario
> is where the original packet doesn't carry (FI, SN). So the current design
> of redundancy segment is based on this scenario.
>
>
>
> Zzh> Since the presentation talked about scenario where the (FI, SN)
> information is already carried, it is fair to discuss that in my initial
> comments; I understand that you want to focus on the other scenario, and
> that’s fine – see later comments below.
>
>
>
> Fan>> I read the draft of replication segment, and have two questions if
> replication segment is used in redundancy protection.
>
> 1) I believe merging node should be as the downstream node, since the
> nodes in precedence of merging node should not be redundancy protection
> aware. In this case, there will be at least two identical downstream nodes.
> In replication segment, there is no definition of such a situation.
>
> 2) The draft states replication SID MUST only appear as the ultimate SID
> in a SID list. What if the merging node is not the last node of the SRv6
> E2E path?
>
>
>
> b). Even though IPv6 flow label could be encapsulated in header, it is
> used for ECMP or fragmentation, redundancy protection cannot simply reuse
> it since flow ID allocation has dependency on the merging node capability.
>
>
>
> Zzh> IPv6 flow label is irrelevant here – it’s not discussed in either
> your draft/presentation or in my comments – so we can ignore this.
>
> Fan>> I mentioned IPv6 flow label coz we had this discussion in DetNet WG.
> I agree we can come back to this thread when it is needed.
>
>
> 

Re: [spring] IPR Call for draft-ietf-spring-segment-routing-policy

[Paul Mattes]

I am not aware of any undisclosed IPR related to this document.

   pdm

From: spring  On Behalf Of James Guichard
Sent: Sunday, April 11, 2021 5:34 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org
Subject: [EXTERNAL] [spring] IPR Call for 
draft-ietf-spring-segment-routing-policy

Hi Authors, Contributors, WG

Authors of draft-ietf-spring-segment-routing-policy have asked for WG last 
call. In preparation of the WGLC this email starts a poll for IPR.

If you are aware of IPR that applies to 
draft-ietf-spring-segment-routing-policy please respond to this email and keep 
the mailing list in copy.
If you are aware of IPR, please indicate whether it has been disclosed in 
accordance to the IETF IPR rules (detailed are described in RFCs 3979, 4879, 
3669 and 5378).

If you are an *author or contributor* please respond to this email, on the 
SPRING mailing list, regardless of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if 
you're aware of IPR that has not yet been disclosed.

Thanks!

Jim, Joel & Bruno

[1] 
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/



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

Re: [spring] IPR Call for draft-ietf-spring-segment-routing-policy

[Kamran Raza (skraza)]

Hello Jim/Chairs,

I am not aware of any IPR related to this document other than the ones that 
have been already disclosed.
Rgds
--
Kamran

From: spring  on behalf of James Guichard 

Date: Sunday, April 11, 2021 at 6:34 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
Subject: [spring] IPR Call for draft-ietf-spring-segment-routing-policy
Hi Authors, Contributors, WG

Authors of draft-ietf-spring-segment-routing-policy have asked for WG last 
call. In preparation of the WGLC this email starts a poll for IPR.

If you are aware of IPR that applies to 
draft-ietf-spring-segment-routing-policy please respond to this email and keep 
the mailing list in copy.
If you are aware of IPR, please indicate whether it has been disclosed in 
accordance to the IETF IPR rules (detailed are described in RFCs 3979, 4879, 
3669 and 5378).

If you are an *author or contributor* please respond to this email, on the 
SPRING mailing list, regardless of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if 
you're aware of IPR that has not yet been disclosed.

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/



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

Re: [spring] IPR Call for draft-ietf-spring-segment-routing-policy

[Francois Clad (fclad)]

Hi Jim, chairs,

I am not aware of any undisclosed IPR related to this document.

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Sunday, 11 April 2021 at 12:34
To: SPRING WG 
Cc: spring-cha...@ietf.org 
Subject: [spring] IPR Call for draft-ietf-spring-segment-routing-policy
Hi Authors, Contributors, WG

Authors of draft-ietf-spring-segment-routing-policy have asked for WG last 
call. In preparation of the WGLC this email starts a poll for IPR.

If you are aware of IPR that applies to 
draft-ietf-spring-segment-routing-policy please respond to this email and keep 
the mailing list in copy.
If you are aware of IPR, please indicate whether it has been disclosed in 
accordance to the IETF IPR rules (detailed are described in RFCs 3979, 4879, 
3669 and 5378).

If you are an *author or contributor* please respond to this email, on the 
SPRING mailing list, regardless of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if 
you're aware of IPR that has not yet been disclosed.

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/



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

Re: [spring] operator requirements for draft-srcompdt-spring-compression-requirement

[Martin Horneffer]

Hi Weiqiang,

thank you for looking into it!

Concerning address aggregation and SID summarization you are probably 
right: When keeping the reqirements generic 4.2.4 should cover the 
requirement of "address aggregation".
In my eyes, creating another company-wide concept for SID delegation and 
reservation as we once did for IPv6 addresses, which needs to take care 
of all requiements and growth potential of every single network domain 
and service area, looks like a nightmare. But technically you are 
perfetcly correct.


So please ignore point 4.3.5 from my suggestion.

Best regards, Martin

Am 12.04.21 um 04:23 schrieb Weiqiang Cheng:

Hi Martin,
Thanks a lot for your suggestions.
Design team will discuss them and feedback you soon.
We also hope WG members can discuss the comments together.
A quick question, do you think whether Address Aggregation requirement has been covered 
by existed "4.2.4. SID summarization" ?

B.R.
Weiqiang Cheng



-邮件原件-
发件人: spring [mailto:spring-boun...@ietf.org] 代表 Martin Horneffer
发送时间: 2021年4月7日 20:47
收件人: spring@ietf.org
主题: [spring] operator requirements for 
draft-srcompdt-spring-compression-requirement

Dear srcomp dt, and spring wg,

thanks a lot for the enormous effort to collect and describe all the
requirements for compression mechanisms, and for already starting the
analysis! A true work of merit.

  From an operator’s point of view I would like to add two requirements
that I believe to be crucial to any kind of new overarching
architecture: address management and address aggregation.

In my eyes, SRv6 does have the great potential to allow a new
architectures that span many still separate network domains (access,
aggregation, backbone, service areas, etc) and greatly simplify and
streamline their operation. However, in order to allow this in an
already existing operator environment, I really see these two points as
essential.

This probably has already been covered by Dirk’s mail below, and I tried
to make the point during the IETF109 session, but probably wasn’t clear
enough. I haven’t seen any discussion of it yet.


In any case I tried to find a wording that might be suitable for
addition to the requirements document. There are of course many ways to
tackle the issue, and this is just one attempt. Please let me know what
you think of it.

Best regards,
Martin


Proposed additions for draft-srcompdt-spring-compression-requirement:

4.3.4.  Number Resource Management

 Description: The compression mechanism SHOULD fit into existing IPv6
address structures. It SHOULD NOT require management of a new kind of
number resource that needs to be coordinated for all network domains
that potentially could be connected to each other. Network domains
rather take existing parts of their address space to provide their local
functions, while staying fully interoperable with all other domains.

 Rationale: In larger organizations different network domains (e.g.
access, aggregation, backbone, service areas) are managed by different
organizational units. Number resources such as IP addresses and numeric
identifiers must be organized in a way, that a) makes sure that every
network domain gets enough resources (e.g. address space) to meet its
needs, and b) conflicts between domains are prevented. Network operators
have solved this problem for resources such as IPv4 and IPv6 addresses
already and can relatively easily base new technology on this. On the
other hand introducing new types of number resources might impose
serious costs on all affected organizational units and thus seriously
impede the introduction of the related technology.

 Metric: The compression mechanism fits into existing IPv6 address
structures. It does not require management of a new kind of number
resource that needs to be coordinated for all network domains that are
potentially involved.

4.3.5.  Address Aggregation

 Description: The compression mechanism MUST support address
aggregation between network domains. It SHOULD support address
aggregation within a domain.

 Rationale: In larger organizations with multiple network domains and
related organizational units it is effectively impossible to exactly
foresee and plan the accumulated scale requirements for any reasonable
future. Domain overarching architectures will fail if they do not apply
serious aggregation of addresses at least at the borders between network
domains.

 Metric: The compression mechanism allows address aggregation at
least between network domains, and at as many additional levels as possible.





Am 19.11.20 um 16:46 schrieb Dirk Steinberg:

Hello SPRING WG,

I have read the SRComp design team requirements draft
and would like to comment.

I truly believe that a SID compression scheme MUST integrate into the
existing SRv6 framework. Otherwise it does not make much sense,
or said another way, it will not be a SID compression scheme for SRv6
at all but another animal altogether.

SID compression should 

Re: [spring] IPR Call for draft-ietf-spring-segment-routing-policy

[Voyer, Daniel]

Hi,

I am not aware of any IPR related to this document other than the ones that 
have been already disclosed.


Thanks
Dan

From: spring  on behalf of James Guichard 

Date: Sunday, April 11, 2021 at 6:34 AM
To: SPRING WG 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] IPR Call for draft-ietf-spring-segment-routing-policy

Hi Authors, Contributors, WG

Authors of draft-ietf-spring-segment-routing-policy have asked for WG last 
call. In preparation of the WGLC this email starts a poll for IPR.

If you are aware of IPR that applies to 
draft-ietf-spring-segment-routing-policy please respond to this email and keep 
the mailing list in copy.
If you are aware of IPR, please indicate whether it has been disclosed in 
accordance to the IETF IPR rules (detailed are described in RFCs 3979, 4879, 
3669 and 5378).

If you are an *author or contributor* please respond to this email, on the 
SPRING mailing list, regardless of whether or not you're aware of any IPR.
If you are not an author or contributor, please explicitly respond only if 
you're aware of IPR that has not yet been disclosed.

Thanks!

Jim, Joel & Bruno

[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/



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