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

[Weiqiang Cheng]

I support the adoption of this document.

It provides a generic and useful enhancement to SR, and the document is in
good shape. 

 

B.R.

Weiqiang Cheng

 

发件人: spring [mailto:spring-boun...@ietf.org] 代表 James Guichard
发送时间: 2020年7月15日 19:17
收件人: spring@ietf.org
抄送: spring-cha...@ietf.org
主题: [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

[spring] FW: New Version Notification for draft-ietf-6man-spring-srv6-oam-07.txt

[Zafar Ali (zali)]

Dear WG,

The updated version fixes a couple of references.
There is no other change in this revision.

Thanks

Regards … Zafar (on behalf of the co-authors)

From: "internet-dra...@ietf.org" 
Date: Monday, July 27, 2020 at 1:22 AM
To: "Clarence Filsfils (cfilsfil)" , Mach Chen 
, Satoru Matsushima , 
"Zafar Ali (zali)" , Daniel Voyer 
Subject: New Version Notification for draft-ietf-6man-spring-srv6-oam-07.txt


A new version of I-D, draft-ietf-6man-spring-srv6-oam-07.txt
has been successfully submitted by Zafar Ali and posted to the
IETF repository.

Name:   draft-ietf-6man-spring-srv6-oam
Revision:  07
Title:  Operations, Administration, and Maintenance (OAM) 
in Segment Routing Networks with IPv6 Data plane (SRv6)
Document date:2020-07-26
Group:  6man
Pages:   22
URL:
https://www.ietf.org/internet-drafts/draft-ietf-6man-spring-srv6-oam-07.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
Htmlized:   https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-07
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-spring-srv6-oam-07

Abstract:
   This document describes how the existing IPv6 OAM mechanisms can be
   used in an SRv6 network.  The document also introduces enhancements
   for OAM mechanisms for SRv6 networks.




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] I-D Action: draft-ietf-spring-sr-yang-18.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the 
IETF.

Title   : YANG Data Model for Segment Routing
Authors : Stephane Litkowski
  Yingzhen Qu
  Acee Lindem
  Pushpasis Sarkar
  Jeff Tantsura
Filename: draft-ietf-spring-sr-yang-18.txt
Pages   : 33
Date: 2020-07-26

Abstract:
   This document defines a YANG data model for segment routing
   configuration and operation, which is to be augmented by different
   segment routing data planes.  The document also defines a YANG model
   that is intended to be used on network elements to configure or
   operate segment routing MPLS data plane, as well as some generic
   containers to be reused by IGP protocol modules to support segment
   routing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-sr-yang-18
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-18


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

I support the adoption of this draft. The proposal provides a useful extension 
of SR regarding network resources.

I have the following suggestions for the authors to consider:

  *   The draft is very slicing/virtual network focused, however the proposal 
can be used in generic cases, e.g. with SR-TE. I’d suggest adding some text or 
use cases, or as a special case of a virtual network.
  *   About scalability especially in SR-MPLS, the label range is limited. It’s 
mentioned in section 2.1, but could use some elaborations.

Thanks,
Yingzhen

From: spring  on behalf of James Guichard 

Date: Wednesday, July 15, 2020 at 4:17 AM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Resent-From: 

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] General Proxy behavior in SR Service Programming

[Joel Halpern Direct]

In the shared memory case, indeed, it is very reasonable to look at the 
proxy as an arm of the function.
In SFC, we do look at it (the proxy as an arm of the SF) that way more 
generally.  We can do that because the SFC architecture calls that out.


Given that the other cases do involve network transfer of packets, and 
thus are visible, and given that neither the SR architecture, the MPLS 
architecture, nor the SR architecture call out such things, it seems 
that we need to be explicit.  To be clear, I think it is a very 
reasonable approach.   Much mroe reasonable, for example, than NAT in 
its various incarnations.  All I am asking is that we state explicitly 
that we understand that as an architectural component this violates 
existing rules, and does so over a limited scope so as to preserve the 
desired / needed behavior over the larger scope.  The one thing we may 
need to be clear about is the degree of proximity required between the 
SF and its serving proxy.  If we treat this as legitimate arbitrary 
networking, it gets out of hand.


Yours,
Joel

On 7/26/2020 3:33 PM, Francois Clad (fclad) wrote:

Hi Joel,

Thank you for your email.

A proxy and its associated SF can be seen from the network as a single entity: 
a packet enters this entity from the network, gets processed by the SF, and 
exits towards the network. The packet modifications that occur between the 
entry and exit of this entity are compliant with existing standards.

Whatever happens between the proxy and SF is internal processing and invisible 
to the network. However, a network operator or controller needs some 
information about the proxy’s internal behavior to determine an appropriate 
SID-list through the SF and possibly configure the proxy.

Cheers,
Francois


On 25/07/2020 20:23, "spring on behalf of Joel M. Halpern" 
 wrote:

 

 Let me start by saying that I understand and support what the draft is
 trying to do.  While I like SFC, I am under no illusions that it is or
 should be the only answer to service chaining / service programming.

 Further, I understand what the proxies are for.  They seem necessary.
 To deploy this stuff, we have to be able to work with older equipment.
 Proxies seem the best way to do so.

 The document is even clear that  proxy is a new kind of thing.  Good.

 In order to do its job, and as I read this document, the SR proxies (of
 various kinds) violate the rules for MPLS processing, SRH processing,
 and IPv6 processing at various points.  They have to.

 It seems to me that we need to accept this requirement, and state it
 clearly.  Most likely, this would suggest that we will want some form of
 signoff from the MPLS and 6man working groups that these violations, for
 these specific reasons, are acceptable to the community.  Personally, I
 would rather have the discussion soon, rather than pretending it is a
 non-issue and having the discussion during IETF last call.

 Maybe I am misreading, and things are less conflicted.  That would be 
great.

 Yours,
 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] Dynamic Proxy in SR service programming

[Joel M. Halpern]

Thank you.  I think it would help if this were spelled out more clearly 
in the draft.


Yours,
Joel

On 7/26/2020 3:32 PM, Francois Clad (fclad) wrote:

Hi Joel,

Thank you for your email.

At high-level, the dynamic proxy combines a caching mechanism with a mapping 
scheme that associates cache entries to packets or flows.

There are many possible mapping schemes, each has pros and cons that make it 
more suitable in some environments and less in others. This I-D describes a 
simple one, which is interface-based (or VLAN-based), and implies that a 
dynamic proxy SID is used in a single SID-list at a time. This makes it 
particularly suitable for container-based environments, where VNFs are spawned 
on a per-SFC basis.

In different environments, other mapping techniques could be used, such as 
those described in draft-song-sfc-legacy-sf-mapping.

Cheers,
Francois


On 26/07/2020 02:57, "spring on behalf of Joel M. Halpern" 
 wrote:

 Thank you.  That does clarify, and it would probably be good to be
 explicit in the document.  (The restriction makes sense, we just need to
 be clear.)

 Yours,
 Joel

 On 7/25/2020 8:31 PM, Stefano Salsano wrote:
 > Il 2020-07-25 19:49, Joel M. Halpern ha scritto:
 >> 
 >>
 >> In looking at the description of the dyanmic proxy behavior, I was
 >> reminded of a problem that the SFC working group wrestled with and
 >> never resolved to our satisfaction.  (In the SFC case, since we were
 >> not specifying the behavior of the proxy, we could leave it to
 >> implementors.   This document seems to be more specific.)
 >>
 >> As I understand the draft, the dyanicm proxy for a non-SR aware
 >> service function can be handling packets subject ot multiple service
 >> policies. That is desirable.  These separate policies will have
 >> separate cache entries.  Also good.
 >> But as far as I can tell, the re-attachment of the cached header to
 >> the returned packet (from the non-SR aware SF) is done based on first
 >> come, first cache.
 >
 > Hi Joel,
 >
 > I'm speaking as an author of draft-ietf-spring-sr-service-programming-02
 > (but I do not know if my opinion is agreed by all the authors)
 >
 > my understanding of the dynamic proxy scenario is that a given "non-SR
 > aware service function" (aka "legacy VNF") can be associated with a
 > single Service Chain at a given time
 >
 > so you can dynamically change the Service Chain by sending a Packet-2
 > with a different SR policy with respect to Packet-1, but this is meant
 > to change the Service Chain for the following packets of the flow,
 > rather than to operate on a packet-by-packet basis
 >
 > you are right that operating on a packet-by-packet basis leads to
 > inconsistent behavior!
 >
 > In draft-ietf-spring-sr-service-programming-02, the following limitation
 > is associated to the static SR proxy, but it also applies to the dynamic
 > proxy:
 >
 > However, a static SR proxy
 > segment can be used in only one service policy at a time.  As opposed
 > to most other segment types, a static SR proxy segment is bound to a
 > unique list of segments, which represents a directed SR service
 > policy.  This is due to the cached SR information being defined in
 > the segment configuration.  This limitation only prevents multiple
 > segment lists from using the same static SR proxy segment at the same
 > time, but a single segment list can be shared by any number of
 > traffic flows.
 >
 > This is he description of the dynamic proxy:
 >
 > The dynamic proxy is an improvement over the static proxy that
 > dynamically learns the SR information before removing it from the
 > incoming traffic.
 >
 > Maybe it would be better to explicitly clarify that the same limitation
 > of the static SR proxy is applicable: "only one service policy at a
 > time"... the difference is that you can change this association
 > dynamically, e.g. in the order of few seconds but NOT on a
 > packet-by-packet basis
 >
 > hope that it clarifies...
 >
 > ciao
 > Stefano
 >
 >
 >> What happens if, due to differences in internal processing, packets
 >> from different service policies get swapped in time.  So packets go in
 >> Packet-1, Packet-2, but come out Packet-2, Packet-1.  The text seems
 >> to result in the proxy reattaching the SR information to the wrong
 >> packets?
 >>
 >> Am I misreading the text?
 >>
 >> Depending upon ones, reading, this may apply to a case where a single
 >> device is service as multiple static proxies for a single non-SR aware
 >> SF.  It was not clear if that was intended to be allowed, but if so
 >> the same issue would seem to apply.
 >>
 >> 

Re: [spring] General Proxy behavior in SR Service Programming

[Francois Clad (fclad)]

Hi Joel,

Thank you for your email.

A proxy and its associated SF can be seen from the network as a single entity: 
a packet enters this entity from the network, gets processed by the SF, and 
exits towards the network. The packet modifications that occur between the 
entry and exit of this entity are compliant with existing standards.

Whatever happens between the proxy and SF is internal processing and invisible 
to the network. However, a network operator or controller needs some 
information about the proxy’s internal behavior to determine an appropriate 
SID-list through the SF and possibly configure the proxy.

Cheers,
Francois


On 25/07/2020 20:23, "spring on behalf of Joel M. Halpern" 
 wrote:



Let me start by saying that I understand and support what the draft is 
trying to do.  While I like SFC, I am under no illusions that it is or 
should be the only answer to service chaining / service programming.

Further, I understand what the proxies are for.  They seem necessary. 
To deploy this stuff, we have to be able to work with older equipment. 
Proxies seem the best way to do so.

The document is even clear that  proxy is a new kind of thing.  Good.

In order to do its job, and as I read this document, the SR proxies (of 
various kinds) violate the rules for MPLS processing, SRH processing, 
and IPv6 processing at various points.  They have to.

It seems to me that we need to accept this requirement, and state it 
clearly.  Most likely, this would suggest that we will want some form of 
signoff from the MPLS and 6man working groups that these violations, for 
these specific reasons, are acceptable to the community.  Personally, I 
would rather have the discussion soon, rather than pretending it is a 
non-issue and having the discussion during IETF last call.

Maybe I am misreading, and things are less conflicted.  That would be great.

Yours,
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] Dynamic Proxy in SR service programming

[Francois Clad (fclad)]

Hi Joel,

Thank you for your email.

At high-level, the dynamic proxy combines a caching mechanism with a mapping 
scheme that associates cache entries to packets or flows.

There are many possible mapping schemes, each has pros and cons that make it 
more suitable in some environments and less in others. This I-D describes a 
simple one, which is interface-based (or VLAN-based), and implies that a 
dynamic proxy SID is used in a single SID-list at a time. This makes it 
particularly suitable for container-based environments, where VNFs are spawned 
on a per-SFC basis.

In different environments, other mapping techniques could be used, such as 
those described in draft-song-sfc-legacy-sf-mapping.

Cheers,
Francois


On 26/07/2020 02:57, "spring on behalf of Joel M. Halpern" 
 wrote:

Thank you.  That does clarify, and it would probably be good to be 
explicit in the document.  (The restriction makes sense, we just need to 
be clear.)

Yours,
Joel

On 7/25/2020 8:31 PM, Stefano Salsano wrote:
> Il 2020-07-25 19:49, Joel M. Halpern ha scritto:
>> 
>>
>> In looking at the description of the dyanmic proxy behavior, I was 
>> reminded of a problem that the SFC working group wrestled with and 
>> never resolved to our satisfaction.  (In the SFC case, since we were 
>> not specifying the behavior of the proxy, we could leave it to 
>> implementors.   This document seems to be more specific.)
>>
>> As I understand the draft, the dyanicm proxy for a non-SR aware 
>> service function can be handling packets subject ot multiple service 
>> policies. That is desirable.  These separate policies will have 
>> separate cache entries.  Also good.
>> But as far as I can tell, the re-attachment of the cached header to 
>> the returned packet (from the non-SR aware SF) is done based on first 
>> come, first cache.
> 
> Hi Joel,
> 
> I'm speaking as an author of draft-ietf-spring-sr-service-programming-02 
> (but I do not know if my opinion is agreed by all the authors)
> 
> my understanding of the dynamic proxy scenario is that a given "non-SR 
> aware service function" (aka "legacy VNF") can be associated with a 
> single Service Chain at a given time
> 
> so you can dynamically change the Service Chain by sending a Packet-2 
> with a different SR policy with respect to Packet-1, but this is meant 
> to change the Service Chain for the following packets of the flow, 
> rather than to operate on a packet-by-packet basis
> 
> you are right that operating on a packet-by-packet basis leads to 
> inconsistent behavior!
> 
> In draft-ietf-spring-sr-service-programming-02, the following limitation 
> is associated to the static SR proxy, but it also applies to the dynamic 
> proxy:
> 
> However, a static SR proxy
> segment can be used in only one service policy at a time.  As opposed
> to most other segment types, a static SR proxy segment is bound to a
> unique list of segments, which represents a directed SR service
> policy.  This is due to the cached SR information being defined in
> the segment configuration.  This limitation only prevents multiple
> segment lists from using the same static SR proxy segment at the same
> time, but a single segment list can be shared by any number of
> traffic flows.
> 
> This is he description of the dynamic proxy:
> 
> The dynamic proxy is an improvement over the static proxy that
> dynamically learns the SR information before removing it from the
> incoming traffic.
> 
> Maybe it would be better to explicitly clarify that the same limitation 
> of the static SR proxy is applicable: "only one service policy at a 
> time"... the difference is that you can change this association 
> dynamically, e.g. in the order of few seconds but NOT on a 
> packet-by-packet basis
> 
> hope that it clarifies...
> 
> ciao
> Stefano
> 
> 
>> What happens if, due to differences in internal processing, packets 
>> from different service policies get swapped in time.  So packets go in 
>> Packet-1, Packet-2, but come out Packet-2, Packet-1.  The text seems 
>> to result in the proxy reattaching the SR information to the wrong 
>> packets?
>>
>> Am I misreading the text?
>>
>> Depending upon ones, reading, this may apply to a case where a single 
>> device is service as multiple static proxies for a single non-SR aware 
>> SF.  It was not clear if that was intended to be allowed, but if so 
>> the same issue would seem to apply.
>>
>> Yours,
>> Joel
>> 
>>
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
> 

[spring] I-D Action: draft-ietf-spring-sr-replication-segment-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the 
IETF.

Title   : SR Replication Segment for Multi-point Service 
Delivery
Authors : Daniel Voyer (editor)
  Clarence Filsfils
  Rishabh Parekh
  Hooman Bidgoli
  Zhaohui Zhang
Filename: draft-ietf-spring-sr-replication-segment-00.txt
Pages   : 10
Date: 2020-07-26

Abstract:
   This document describes the SR Replication segment for Multi-point
   service delivery.  A SR Replication segment allows a packet to be
   replicated from a replication node to downstream nodes.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-sr-replication-segment-00
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment-00


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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