Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Takuya Miyasaka]

Hi Ron,

I think this new SRv6 endpoint behavior is very useful to connect an 
SRv6 island and an SR-MPLS island. I have two comments.


In this draft, you introduced the End.DTM as a new "segment type", but 
according to draft-ietf-spring-srv6-network-programming draft I think 
this should be "endpoint behavior".


Section.1 says "The arguments determine MPLS-label stack contents and 
Transport Class of the MPLS Tunnel." I was interested in this feature, 
but there is no detailed description in Section.4. Could you elaborate 
on this feature in the future version? I also want to clarify the 
meaning of "Transport Class of the MPLS Tunnel".


Thanks,
Takuya

On 2021/02/08 1:46, Ron Bonica wrote:

Please review and comment


Juniper Business Use Only


-Original Message-
From: internet-dra...@ietf.org 
Sent: Sunday, February 7, 2021 11:41 AM
To: Greg Mirsky ; Peng Shaofu
; Ron Bonica ; Shaofu Peng
; Shraddha Hegde ; EXT-
zhang.zh...@zte.com.cn 
Subject: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name:   draft-bonica-spring-srv6-end-dtm
Revision:   01
Title:  The SRv6 END.DTM Segment Type
Document date:  2021-02-07
Group:  Individual Submission
Pages:  7
URL:   https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt
Status: https://datatracker.ietf.org/doc/draft-bonica-spring-srv6-end-dtm
Htmlized:  
https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm
Htmlized:  https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01
Diff:  https://www.ietf.org/rfcdiff?url2=draft-bonica-spring-srv6-end-dtm-01

Abstract:
This document describes a new SRv6 segment type, called END.DTM.  The
END.DTM segment type supports inter-working between SRv6 and SR-MPLS.
Like any segment type, END.DTM contains a function and arguments.
The function causes the processing SRv6 node to remove an SRv6 header
and impose an SR-MPLS label stack.  The arguments determine MPLS-
label stack contents.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
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] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Dongjie (Jimmy)]

Hi Shunsuke,

Thanks a lot for your review and comments. Please see some replies inline:

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Shunsuke Homma
Sent: Tuesday, February 9, 2021 12:05 AM
To: James Guichard 
Cc: spring@ietf.org; spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi WG,

I think that this document is good enough as starting point for the WG, and I 
support the adoption. There are many drafts related to network slice with SR 
(e.g., SR + Flex-algo, draft-bestbar-spring-scalable-ns, etc.) and I hope it 
will be clarified which is the best in future work.

[Jie] Thanks for your support.

The following are my comments to the draft.
- The example describes three isolated VTNs. I assume (hard) isolation will 
cause split loss, and oversubscription will be sometimes needed. Hence, it may 
be better to allow a resource-aware SID to belong to multiple VTNs.

[Jie] In the context of SR based VTN, each resource-aware SID is associated 
with one VTN. Multiple services which are mapped to the same VTN can use the 
same group of SIDs to guide the packet forwarding, thus  a resource-aware SID 
and the associated resources can be shared by multiple services.

- From network slicing (i.e., NaaS model) perspective, I assume visibility will 
be especially important. As one more important requirement, network operators 
want to provide only information of the VTN whose customer uses to that 
customer. For example, if a customer gets VTN information with BGP-LS, some 
mechanisms to prevent to leak other VTNs information in BGP-LS would be needed.

[Jie] Yes, depends on the operator’s policy, the amount and the granularity of 
information exposed to a customer should be controlled. The considerations 
about this is described in section 3.5 VTN Visibility to Customer. The required 
control plane mechanism can be based on  BGP-LS mechanism in RFC7752 (and the 
in progress draft-7752bis), some extension may be introduced if needed.

- There is a typo in figure2. The adj-SID of the link from 203 to 204 in green 
VTN should be 2002.

[Jie] Thanks for catching the typo. We will fix it in next revision.

Best regards,
Jie

Regards,

Shunsuke

On Wed, Jan 27, 2021 at 8:47 PM James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:
Dear WG:

This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending 
February 10th 2021.

After review of the document please indicate support (or not) for WG adoption 
to the mailing list and if you are willing to work on the document, please 
state this explicitly. This gives the chairs an indication of the energy level 
of people in the working group willing to work on this document. 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.

Thanks!

Jim, Bruno & Joel



___
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] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Yingzhen Qu]

Hi,

I support the WG adoption of this draft, and I believe it’s a good starting 
point for the WG to work on this topic, and see how existing technologies can 
be integrated to provide new capabilities.

Resource reservation has always been a controversial topic, whether it is 
needed, or efficient, or can it scale? Can we just deliver low latency service 
with high bandwidth? All these are valid questions, as a WG we can continue to 
improve the solutions and make the deployments easier. As Adrian said the 
market will decide whether this is the right technology or the right timing. 

So I support the adoption of this draft and I’m willing to work on it.

Thanks,
Yingzhen


>  
>  
> From: spring  On Behalf Of James Guichard
> Sent: Wednesday, January 27, 2021 5:47 AM
> 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 message starts a 2 week WG adoption call for 
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ 
>  
> ending February 10th 2021.
>  
> After review of the document please indicate support (or not) for WG adoption 
> to the mailing list and if you are willing to work on the document, please 
> state this explicitly. This gives the chairs an indication of the energy 
> level of people in the working group willing to work on this document. 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.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
>  
> ___
> 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] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Loa Andersson]

Jeff,


On 08/02/2021 14:51, Jeff Tantsura wrote:

Hi Ron,

Very useful document, thanks!

Question wrt processing:
As described in the draft:
“A SID instance is associated with SR-MPLS label stack and outgoing interface.”

I’d think that outgoing interface would be recursively resolved based on the 
top SID (and could change based on topological semantics).
Could you please elaborate?


What exactly do yo mean by "recursively"?

/Loa


Thanks!


Cheers,
Jeff


On Feb 7, 2021, at 08:46, Ron Bonica  
wrote:


Please review and comment


Juniper Business Use Only


-Original Message-
From: internet-dra...@ietf.org 
Sent: Sunday, February 7, 2021 11:41 AM
To: Greg Mirsky ; Peng Shaofu
; Ron Bonica ; Shaofu Peng
; Shraddha Hegde ; EXT-
zhang.zh...@zte.com.cn 
Subject: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name:   draft-bonica-spring-srv6-end-dtm
Revision:   01
Title:  The SRv6 END.DTM Segment Type
Document date:  2021-02-07
Group:  Individual Submission
Pages:  7
URL:   https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt
Status: https://datatracker.ietf.org/doc/draft-bonica-spring-srv6-end-dtm
Htmlized:  
https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm
Htmlized:  https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01
Diff:  https://www.ietf.org/rfcdiff?url2=draft-bonica-spring-srv6-end-dtm-01

Abstract:
   This document describes a new SRv6 segment type, called END.DTM.  The
   END.DTM segment type supports inter-working between SRv6 and SR-MPLS.
   Like any segment type, END.DTM contains a function and arguments.
   The function causes the processing SRv6 node to remove an SRv6 header
   and impose an SR-MPLS label stack.  The arguments determine MPLS-
   label stack contents.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
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



--

Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

___
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

[chen.ran]

Hi WG,



 


What are the advantages of this draft compared with other drafts? (such as 
draft-bestbar-spring-scalable-ns, draft-peng-lsr-network-slicing),and is it 
just explain the concept of virtual SR network beyond the concept of 
resource-aware SID? 


Many people are thinking about how to realize slicing in the network and made 
many contributions. Although I am originally a co-author of draft 
draft-peng-lsr-network-slicing, I think so far 
draft-bestbar-spring-scalable-ns, comparatively speaking, is to grasp the 
essence of the problem, and have a complete thoughts.






So, I do not think draft-dong-spring-sr-for-enhanced-vpn is now ready to become 
a working group draft.






Best Regards,


Ran







原始邮件



发件人：JamesGuichard
收件人：spring@ietf.org;
抄送人：spring-cha...@ietf.org;
日 期 ：2021年01月27日 19:47
主 题 ：[spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn


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

 

Dear WG:


 


This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending 
February 10th 2021.


 


After review of the document please indicate support (or not) for WG adoption 
to the mailing list and if you are willing to work on the document, please 
state this explicitly. This gives the chairs an indication of the energy level 
of people in the working group willing to work on this document. 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.


 


Thanks!


 


Jim, Bruno & Joel___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] more on IDs for slices

[BRUNGARD, DEBORAH A]

Hi,

Not sure if you are aware, there was a BoF proposed on using an identifier to 
signal user requirements (APN) in a slice, APN BoF. It was decided it would be 
better to first have it further discussed at IETF110's RTGWG as it would allow 
for a broader coverage:
https://www.ietf.org/blog/ietf110-bofs/

Considering the current discussion in spring and the work already on-going in 
teas on IDs and "what is a slice", and to help focus the discussion at the 
meeting, I wanted to bring the following drafts to your attention. I have asked 
the authors to help us understand the gaps with the on-going work not being 
addressed and what new work is needed. The authors have done a lot of work, 
this is just a selection:

https://www.ietf.org/archive/id/draft-peng-apn-scope-gap-analysis-00.txt
https://www.ietf.org/archive/id/draft-li-apn-framework-01.txt
https://www.ietf.org/archive/id/draft-li-apn-problem-statement-usecases-01.txt

If you search documents on APN, you will find more.

Happy reading,
Deborah

___
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

[Shunsuke Homma]

Hi WG,

I think that this document is good enough as starting point for the WG, and
I support the adoption. There are many drafts related to network slice with
SR (e.g., SR + Flex-algo, draft-bestbar-spring-scalable-ns, etc.) and I
hope it will be clarified which is the best in future work.

The following are my comments to the draft.
- The example describes three isolated VTNs. I assume (hard) isolation will
cause split loss, and oversubscription will be sometimes needed. Hence, it
may be better to allow a resource-aware SID to belong to multiple VTNs.

- From network slicing (i.e., NaaS model) perspective, I assume visibility
will be especially important. As one more important requirement, network
operators want to provide only information of the VTN whose customer uses
to that customer. For example, if a customer gets VTN information with
BGP-LS, some mechanisms to prevent to leak other VTNs information in BGP-LS
would be needed.

- There is a typo in figure2. The adj-SID of the link from 203 to 204 in
green VTN should be 2002.

Regards,

Shunsuke

On Wed, Jan 27, 2021 at 8:47 PM James Guichard <
james.n.guich...@futurewei.com> wrote:

> Dear WG:
>
>
>
> This message starts a 2 week WG adoption call for
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/
> ending February 10th 2021.
>
>
>
> After review of the document please indicate support (or not) for WG
> adoption to the mailing list and if you are willing to work on the
> document, please state this explicitly. This gives the chairs an indication
> of the energy level of people in the working group willing to work on this
> document. 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.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
>
>
> ___
> 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] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Tarek Saad]

I agree with Shaofu. A slice aggregate is independent of the forwarding plane 
(i.e. it is not a virtual network). A single flex-algo (that defines a 
forwarding plane) can be sliced into multiple slice-aggregates. If per slice 
SIDs are used, it allows IGP to share the forwarding next-hops for each of 
those slice SIDs (i.e., makes determining SID next-hop independent of # of 
slice-aggregates). This was described in detail in 
draft-bestbar-spring-scalable-ns. It’s good to see 
draft-dong-spring-sr-for-enhanced-vpn has incorporated this change from 
draft-bestbar-spring-scalable-ns in its latest rev.

Regards,
Tarek


On 2/6/21, 10:53 PM, "spring on behalf of 
peng.sha...@zte.com.cn" 
mailto:spring-boun...@ietf.org> on behalf of 
peng.sha...@zte.com.cn> wrote:




Hi WG/authors,



I have to point out that the VTN-ID in draft-dong-spring-sr-for-enhanced-vpn is 
actually the AII in draft-peng-teas-network-slicing, just a new name. That can 
be seen from the evolution of the historical versions of the these two drafts.



I draw your attention to draft draft-peng-teas-network-slicing which analyzes 
in detail the reasons for the introduction of slice identifier (AII) in the 
network, and maintains the resource partition of each slice and the allocation 
of SID per AII in the network. All this happened before 
draft-dong-spring-sr-for-enhanced-vpn.



In addition, the idea that multiple slices share the same virtual topology 
(such as flex-algo) is also copied from draft-bestbar-teas-ns-packet, which can 
significantly reduce the state in the network, especially without maintaining 
SPT per slice, which means that multiple SIDs per slice can share the 
forwarding action of SPT per VN and at the same time can do resource guarantee 
by SID per slice (or slice-id in packet).



Thus, from a purely technical point of view, I see no reason for this document 
to be adopted.



Regards,

PSF






原始邮件
发件人：JamesGuichard
收件人：spring@ietf.org;
抄送人：spring-cha...@ietf.org;
日 期 ：2021年01月27日 19:47
主 题 ：[spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Dear WG:

This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending 
February 10th 2021.

After review of the document please indicate support (or not) for WG adoption 
to the mailing list and if you are willing to work on the document, please 
state this explicitly. This gives the chairs an indication of the energy level 
of people in the working group willing to work on this document. 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.

Thanks!

Jim, Bruno & Joel







Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring