[spring] 回复： IPR call for draft-hegde-spring-node-protection-for-sr-te-paths

[徐小虎(义先)]

 

I am not aware of any IPR related to this draft.

xiaohu





来自钉钉专属商务邮箱--
发件人：
日　期：2020年07月30日 20:24:35
收件人：spring@ietf.org; 
draft-hegde-spring-node-protection-for-sr-te-pa...@ietf.org
主　题：[spring] IPR call for draft-hegde-spring-node-protection-for-sr-te-paths


Hi Authors, SPRING WG,
 
Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have asked 
for WG adoption.
 
This email starts a poll for IPR.
 
If you are aware of IPR that applies to 
draft-hegde-spring-node-protection-for-sr-te-paths please respond to this email.
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,
Regards,
Bruno, Jim, Joel
 
[1]  
https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07
  
_

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] Limited domains ...

[徐小虎(义先)]

It makes sense of using source routing across the Internet. For example, using 
source routing for traffic steering across edge networks just like Akamai's 
SureRoute which is a limited domain over the Internet indeed. In that case, 
it's necessary to protect the source route information carried within packets 
by some means (e.g., indirection), in other words, it'd better not to directly 
carry the source routes in the form of an IP address list within the source 
routed packets. BTW, it may be worthwhile to consider the scenario where the 
source routed packets need to traverse both IPv4 and IPv6 Internet along the 
path towards their final destinations.

Of course, whether using CRH or RFC8663 is purely a matter of personal 
preference from my point of view, just like someone prefers to use VXLAN rather 
than MPLS-over-UDP (http://tools.ietf.org/html/rfc7510) for network 
virtualization, and someone prefers to use EVPN rather than Virtual Subnet 
(https://tools.ietf.org/html/rfc7814) which is fully built on the mature 
MPLS/BGP L3VPN (https://tools.ietf.org/html/rfc4364) for pure Layer3-based 
overlays. 

Best regards,
Xiaohu





--
From:Robert Raszuk 
Send Time:2020年5月28日(星期四) 06:40
To:Zafar Ali (zali) 
Cc:Ron Bonica ; spring@ietf.org 
; 6man <6...@ietf.org>; Brian E Carpenter 
; Andrew Alston 
Subject:[spring] Limited domains ...

/*adjusting subject */

> The scope of CRH is “limited domain” and not the “Internet”.  

Well that is only what the document under adoption call says. 

However we have all seen described use cases over Internet  ... so much of 
limited domain. Explanation given is that "limited domain" does not to be 
continuous ... very clever indeed ! 

I am observing this point as my use case is also over Internet. 

So if I apply any RH on my application host_1 carry it over Internet to my 
server host_2 clearly those two hosts create a "limited domain". 

Maybe we should just drop right here this "limited domain" restriction/scope 
for any solution being discussed here ? 

Thx,
R.

On Thu, May 28, 2020 at 12:32 AM Zafar Ali (zali)  wrote:
Hi, 
 
The authors of CRH has already have multiple drafts and more CP/ DP changes 
will be required. E.g., it will require 
ISIS changes (draft-bonica-lsr-crh-isis-extensions)
To carry VPN information (draft-bonica-6man-vpn-dest-opt) 
For SFC (draft-bonica-6man-seg-end-opt)
BGP changes (draft-alston-spring-crh-bgp-signalling, 
draft-ssangli-idr-bgp-vpn-srv6-plus)
PCEP extension (TBA)
OAM for debugging the mapping table
Yang interface 
More to come  
 
The scope of CRH is “limited domain” and not the “Internet”. 
 
Given this, where the IETF community discuss how these so-called “building 
blocks” fits together? 
 
If author’s claim is that the home for the architecture work is not Spring, 
then the authors should create a BoF in routing area to first defined 
architecture, use-case and requirements. 
This is the hard worked everyone else did before the CRH authors. 
Why they are looking for a short cut? 
 
CRH is a “major” change and outside the scope of 6man charter. 
It should follow the proper IETF review process. 
 
Why CRH authors are trying to “skip the queue” and “skip the routing area”? 
 
Thanks
 
Regards … Zafar

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

Re: [spring] [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

[徐小虎(义先)]

In addition, the performance routing paradigm could actually be deployed in the 
EPE scenario as well where both capacity-aware TE capability and 
performance-aware TE capability are desired. More specifically, since there are 
two routing tables, one contains vanilla routes which are used for 
capacity-aware routing purpose and the other contains performance routes which 
are used for performance-aware routing purpose, which are manipulated by the 
EPE controller via the BGP-LU and the performance routing SAFIs respectively, 
traffic with different QoS class but designated for the same destination could 
be forwarded to different ISP peers according to different routing tables. 

In this way, it allows cloud providers to provide differentiated Internet 
connectivity service to their tenants. For example, high-priority traffic 
originated from gold tenants could be forwarded according to the performance 
routing table while the remaining traffic would be forwarded according to the 
vanilla routing table, as a result, the former is forwarded along a low-latency 
path while the latter is forwarded along a high-latency path. 

Best regards,
Xiaohu


--
From:徐小虎(义先) 
Send Time:2019年10月15日(星期二) 17:57
To:SPRING WG List 
Cc:idr 
Subject:Re: [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt


Hi all,

I just recently realized that the performance routing mechanism as described in 
this draft could facilitate the deployment of segment routing across multiple 
ASes of an administrative entity where low-latency SR paths across ASes are 
needed for carrying latency-sensitive and high-priority traffic. In this way, 
there is no need to resort to centralized TE controllers for calculating 
low-latency paths across ASes. 

Any comments and suggestions are welcome.

Best regards,
Xiaohu





--
From:internet-drafts 
Send Time:2019年10月14日(星期一) 13:09
To:i-d-announce 
Cc:idr 
Subject:[Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Performance-based BGP Routing Mechanism
Authors : Xiaohu Xu
  Shraddha Hegde
  Ketan Talaulikar
  Mohamed Boucadair
  Christian Jacquenet
 Filename: draft-ietf-idr-performance-routing-02.txt
 Pages   : 10
 Date: 2019-10-13

Abstract:
   The current BGP specification doesn't use network performance metrics
   (e.g., network latency) in the route selection decision process.
   This document describes a performance-based BGP routing mechanism in
   which network latency metric is taken as one of the route selection
   criteria.  This routing mechanism is useful for those server
   providers with global reach to deliver low-latency network
   connectivity services to their customers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-performance-routing/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-performance-routing-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-performance-routing-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-performance-routing-02


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/

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

Re: [spring] [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

[徐小虎(义先)]

Hi all,

I just recently realized that the performance routing mechanism as described in 
this draft could facilitate the deployment of segment routing across multiple 
ASes of an administrative entity where low-latency SR paths across ASes are 
needed for carrying latency-sensitive and high-priority traffic. In this way, 
there is no need to resort to centralized TE controllers for calculating 
low-latency paths across ASes. 

Any comments and suggestions are welcome.

Best regards,
Xiaohu






--
From:internet-drafts 
Send Time:2019年10月14日(星期一) 13:09
To:i-d-announce 
Cc:idr 
Subject:[Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

Title   : Performance-based BGP Routing Mechanism
Authors : Xiaohu Xu
  Shraddha Hegde
  Ketan Talaulikar
  Mohamed Boucadair
  Christian Jacquenet
 Filename: draft-ietf-idr-performance-routing-02.txt
 Pages   : 10
 Date: 2019-10-13

Abstract:
   The current BGP specification doesn't use network performance metrics
   (e.g., network latency) in the route selection decision process.
   This document describes a performance-based BGP routing mechanism in
   which network latency metric is taken as one of the route selection
   criteria.  This routing mechanism is useful for those server
   providers with global reach to deliver low-latency network
   connectivity services to their customers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-performance-routing/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-performance-routing-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-performance-routing-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-performance-routing-02


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/

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

Re: [spring] Beyond SRv6.

[徐小虎(义先)]

IMHO, the situation of SR-MPLS for IPv6 is much similar with that of LDP for 
IPv6. As long as there is a strong market demand of upgrading the WAN to IPv6, 
IPv6 LDP will be widely supported by vendors in the end. However, 6PE is still 
a practical and long-life solution.

Best regards,
Xiaohu







--
From:Andrew Alston 
Send Time:2019年8月7日(星期三) 16:36
To:徐小虎(义先) ; spring ; Rob 
Shakir ; SPRING WG List 
Subject:RE: [spring] Beyond SRv6.

Yes and no – because that assumption assumes that we will not see a growth of 
in the requirement where I have a need to actually working with steering inside 
those islands – as the temp solution you are correct.  As a long term solution 
– with the abandonment of SR-MPLS by certain vendors in the context of IPv6 I 
see a situation where I’m going to be forced into some form of SRv6 on those 
intermediate nodes.

At that point it still leaves me in a case of needing SRv6 in some form on the 
intermediate sections – and SRv6 is still not an option – my proposal to stitch 
is a temp solution – SRv6 in whatever form I see as becoming a mandatory part 
of life – now – if I had both USID and CRH as options and the stitching as an 
intermediate – once that becomes reality – I can then simply purchase based on 
the choice I’m making to handle what I need.  The alternative is to accept the 
fact that because of the entrenchment issues I have referred to – we end in a 
scenario where the drafts both stall – the vendors continue their development – 
and I believe that will happen – and I end up making a decision to use what 
effectively becomes proprietary non-standardized protocols from the vendor that 
supports that which I choose.  Then – I stitch back and forth between that 
proprietary protocol at the edges.  This is doable – but its far from desirable 
– because I’d rather be stitching between standardized protocols in this case 
than what is proprietary.

Basically – what I am saying here is – I see a scenario where we find common 
ground – we accept both things on the track towards standardization – and then 
let the operators decide which to use – and we work towards an inter-op draft 
between the two - because the alternative is that both stall within the 
framework of the IETF – and because of customer demand – both end up getting 
implemented in proprietary form – and we end up with some kinda weird inter-op 
between proprietary protocols – that doesn’t work for anyone, and it actually 
creates a situation where I have to consider limiting vendors in use on the 
network to that which works for me because I don’t have standardized methods of 
inter-op – because one or both of the protocols aren’t standardized.

That’s my take on it anyway – and it’s not unprecedented – in MOST technologies 
we have multiple alternatives – and we find a way to inter-operate between them 
– two IGP’s (OSPF and ISIS), Multiple methods of signaling (LDP vs RSVP as an 
example), etc etc etc.  This is good for consumer choice – and good for the 
operators. 

Andrew



From: spring  On Behalf Of ???(??)
Sent: Wednesday, 7 August 2019 10:26
To: spring ; Rob Shakir 
; SPRING WG List 
Subject: Re: [spring] Beyond SRv6.
Hi Andrew,

Thanks a lot for sharing your valuable opinions regarding SRv6 and SR-MPLS. 

You said "...Our solution we’re working towards where we need SRv6 in the 
absence of SR-MPLS is stitch SR-MPLS to SRv6 through packet encapsulation – 
effectively use an SR-MPLS binding label to trigger a packet encapsulation to 
V6 with CRH – route across the segments that do not support SR-MPLS using 
standard V6 routing – and use a destination option to trigger decapsulation as 
it hits the next SR-MPLS supporting network segment.  The advantage of this 
approach is that while it doesn’t allow granular steering through the 
intermediate network segment – it does preserve the SR-MPLS label stack end to 
end and in effect creates a form of lose routing over that segment while 
preserving the SR-MPLS label stack.   Effectively this is similar to using 
SR-MPLS over UDP or GRE – we’re just working on coming up with a defined way to 
stitch between native SR-MPLS and UDP/GRE/Whatever..." 

It seems that the only scenario where you MAY need SRv6 is to connect two 
SR-MPLS islands over IPv6 networks. If so, I wonder whether the approach as 
described in (https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07) is 
good enough for your scenario.

Best regards,
Xiaohu




--
From:Andrew Alston 
Send Time:2019年8月7日(星期三) 12:16
To:Rob Shakir ; SPRING WG List 

Subject:Re: [spring] Beyond SRv6.

Thanks Rob,

So – Firstly let’s start with the use cases.  Our biggest requirement for any 
of this is about traffic steering and about removal of V4 from the network in 
the long term.  Our entire motivation for getting involved in SR in the first 
place initially revol

Re: [spring] Beyond SRv6.

[徐小虎(义先)]

Hi Andrew,

Thanks a lot for sharing your valuable opinions regarding SRv6 and SR-MPLS. 

You said "...Our solution we’re working towards where we need SRv6 in the 
absence of SR-MPLS is stitch SR-MPLS to SRv6 through packet encapsulation – 
effectively use an SR-MPLS binding label to trigger a packet encapsulation to 
V6 with CRH – route across the segments that do not support SR-MPLS using 
standard V6 routing – and use a destination option to trigger decapsulation as 
it hits the next SR-MPLS supporting network segment.  The advantage of this 
approach is that while it doesn’t allow granular steering through the 
intermediate network segment – it does preserve the SR-MPLS label stack end to 
end and in effect creates a form of lose routing over that segment while 
preserving the SR-MPLS label stack.   Effectively this is similar to using 
SR-MPLS over UDP or GRE – we’re just working on coming up with a defined way to 
stitch between native SR-MPLS and UDP/GRE/Whatever..." 

It seems that the only scenario where you MAY need SRv6 is to connect two 
SR-MPLS islands over IPv6 networks. If so, I wonder whether the approach as 
described in (https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07) is 
good enough for your scenario.

Best regards,
Xiaohu





--
From:Andrew Alston 
Send Time:2019年8月7日(星期三) 12:16
To:Rob Shakir ; SPRING WG List 

Subject:Re: [spring] Beyond SRv6.

Thanks Rob,

So – Firstly let’s start with the use cases.  Our biggest requirement for any 
of this is about traffic steering and about removal of V4 from the network in 
the long term.  Our entire motivation for getting involved in SR in the first 
place initially revolved around the fact that in our view LDPv6 was pretty much 
still born – and the lack of MPLS feature parity with IPv6 was causing us 
significant problems.  We hoped that SR would eventually resolve much of this.  
Now – in that case SR-MPLS would have been just fine and frankly speaking – we 
were entirely happy with pure SR-MPLS and I’m on record saying that I didn’t 
see much of a use case for SRv6 at all.

We then got to a situation however, where we hit an implementation problem.  At 
least one vendor categorically stated to us that they would not support SR-MPLS 
as relates to V6 – and if we wanted SR with V6 – SRv6 was what we were going to 
have to have.  Since then I’ve had another vendor send me a very similar 
message.  This left us with a problem – and so on to SRv6 we came.  In looking 
at SRv6 though and the traffic patterns on our network and based on various 
factors – the overhead imposed by SRv6 in its original form is simply 
untenable.  We did some analysis on the actual traffic patterns on our network, 
and dependent on depth of the SID stack and the particular segment of the 
network and the types of traffic – we calculated an increase in utilization of 
between 5% on the low end and 19% on the upper end.  That – simply doesn’t work 
for us.

Secondly – We have fairly major concerns about using V6 addresses in an 
“overloaded manner”  Effectively, we prefer V6 addresses to be exactly that – 
addresses used to address nodes.  We have a concern that attempting to pack 
more and more functionality into the address space could result in unknown and 
unintended consequences.  It also from an operational perspective in our view 
creates more complexity.   The merging of programmability and routing and other 
such things directly into the address creates a wider failure domain where 
hitting a bug on one thing could impact a lot more than just routing etc.  

So – moving on to the two proposed drafts.  We got involved in CRH because it 
solved three major problems we were facing.
 
It gave us a form of SR that allowed us to do traffic steering and meet our use 
cases when it became clear that SR-MPLS probably wasn’t going to work for us 
because of resistance from certain vendors and their clearly stated positions
It solved the problem of overhead we saw on SRv6
It left the address space de-coupled from routing and programmability – which 
we believe creates additional issues as stated above.  It also allows 
relatively easy expansion to support inter-domain SR using BGP signaling – and 
because of the immutability of the extension header allowed full end to end 
path visibility at any point in the network.

Now – if I have to compare what is proposed with CRH with what is proposed by 
USID from our perspective.  Firstly – I’m at a loss as to how USID and 
programmability of intermediate nodes are actually going to work.  In CRH – you 
have a destination option that contains both either per segment service 
instructions or per service instructions or both.  

So now – on to looking at USID.  
 
Firstly – we believe that USID actually compromises network programmability.  
In USID – if you’re compressing the routing header and avoiding carrying the 
entire 128bit SID across the network – 

[spring] Fw: WG Adoption Call: draft-xuclad-spring-sr-service-programming

[徐小虎(义先)]

Hi Stewart, Hamid, Himanshu, Luis, Jeff, Martin, Dirk and Gaurav,

Please respond to the IPR poll of draft-xuclad-spring-sr-service-programming as 
contributors. Thanks.

Best regards,
Xiaohu

--
From:Rob Shakir 
Send Time:2019年8月5日(星期一) 06:12
To:SPRING WG List 
Subject:Re: [spring] WG Adoption Call: 
draft-xuclad-spring-sr-service-programming

SPRING,

Thanks for the review of this document. As with the other document, apologies 
for the delay in following up. Based on the mailing list replies, SPRING will 
adopt this document once the IPR poll has been completed.

Authors - the following contributors have not yet responded to the IPR poll:

D Steinberg
G Dawra
S Bryant
H Assarpour
H Shah
L Contreras
J Tantsura
M Vigoureux
We can't make a more pointed follow up as these contributors do not have their 
addresses listed in this draft, whilst not required -- they are appreciated for 
us to be able to follow up on those that have contributed material to drafts. 
Your assistance with following up here would be greatly appreciated.

Thanks,
r.
On Wed, Jun 26, 2019 at 11:13 PM Rob Shakir  wrote:

Hi SPRING WG,

This email initiates a two week working group adoption call for 
draft-xuclad-spring-sr-service-programming.. This follows the discussion that 
we had in the last few IETF meetings, and particularly the focused discussion 
we had at IETF 104 regarding service chaining and SPRING.

Please indicate your support, comments, or objections for adopting this draft 
by Wednesday July 10th, 2019. We are particularly interested in hearing from WG 
members who are not authors of this draft, and those folks that are willing to 
spend time working on this draft after adoption.

We are also looking for volunteers who can provide a technical review of the 
content of the draft at a later stage of its progress through the working group 
(e.g., before WGLC).

In parallel - we'll send an IPR poll to the working group and authors. The 
currently disclosed IPR can be found in the datatracker.

Thanks!
Rob & Bruno.

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

Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

[徐小虎(义先)]

Hi Linda,

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as 
to indicate the preferred path? For more details, please read 
https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3

Best regards,
Xiaohu


--
From:Linda Dunbar 
Send Time:2019年7月9日(星期二) 06:26
To:Linda Dunbar ; SPRING WG 
Subject:Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

  
Sorry, I meant to ask:
When the SDWAN edge nodes are  NOT directly connected to the PEs of SR domain, 
is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate 
the desired SR Path? 
 
Linda
From: spring  On Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG 
Subject: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?  
SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN 
bandwidth from multiple service providers to get better WAN bandwidth 
management, visibility & control. 
Because of the ephemeral property of the selected Cloud DCs, an enterprise or 
its network service provider may not have the direct links to the Cloud DCs 
that are optimal for hosting the enterprise’s specific workloads/Apps. Under 
those circumstances, SD-WAN is a very flexible choice to interconnect the 
enterprise on-premises data centers & branch offices to its desired Cloud DCs...
However, SD-WAN paths over public internet can have unpredictable performance, 
especially over long distances and cross state/country boundaries. Therefore, 
it is highly desirable to place as much as possible the portion of SD-WAN paths 
over service provider VPN (e.g. enterprise’s existing VPN) that have guaranteed 
SLA and to minimize the distance/segments over public internet.
https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ 
describes a method to enforce a SD-WAN path’s head-end selected route 
traversing through a list of specific nodes of multiple network segments 
without requiring the nodes in each network segments to have the intelligence 
(or maintaining states) of selecting next hop or next segments.
When a SR domain has multiple PEs with ports facing the external networks (such 
as the public internet or LTE termination), SD-WAN paths can traverse the SR 
domain via different ingress/egress PEs resulting in different E2E performance. 
 
Even with the same ingress/egress, some flows may need different segments 
across the SR Domain. It is not practical, or even possible, for PEs to 
determine which Apps’ flows should egress. 
Segment Routing can be used to steer packets (or path) to traverse the explicit 
egress node, or explicit segments through the SR Domain based on the SLA 
requested by the SD-WAN head-end nodes.
 
When the SDWAN edge nodes are directly connected to the PEs of SR domain, is it 
appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the 
desired SR Path? 
 
We are looking for feedback, criticisms, or suggestion on the the proposed 
approach. 
 
Thank you, 
Linda___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR Poll: draft-xuclad-spring-sr-service-programming

[徐小虎(义先)]

I don't know all IPR related to this doc.

Best regards,
Xiaohu


--
From:Rob Shakir 
Send Time:2019年6月27日(星期四) 14:14
To:draft-xuclad-spring-sr-service-programming 
; SPRING WG List 

Subject:[spring] IPR Poll: draft-xuclad-spring-sr-service-programming

Hi Authors, SPRING WG,

In parallel to the call for working group adoption for 
draft-xuclad-spring-sr-service-programming we would like to poll for IPR.

If you are aware of IPR that applies to draft-xuclad-sr-service-programming 
please respond to this email. 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 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..

This document will not advance into the working group until such time as we 
have received IPR confirmations from all authors and contributors.

Thanks!
Rob & Bruno   ___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

[徐小虎(义先)]

I support the adoption of this draft.

Xiaohu


--
From:bruno.decraene 
Send Time:2019年2月20日(星期三) 17:03
To:SPRING WG 
Cc:draft-cheng-spring-mpls-path-segm...@ietf.org 

Subject:[spring] Working Group Adoption Call for 
draft-cheng-spring-mpls-path-segment

Hi SPRING WG,

This email initiates a two week call for working group adoption for 
draft-cheng-spring-mpls-path-segment.

Please indicate your support, comments, or objection, for adopting this draft 
as a working group item by March 6th 2019.
We are particularly interested in hearing from working group members that are 
not co-authors of this draft.
We are also looking for volunteers who would be ready to perform a technical 
review of this work at some later stage, such as before or during WG the last 
call.

Additionally, there are currently 7 authors listed on this document. Please 
trim this to <= 5 front-page authors, utilising a "Contributors" section if 
required for the others. An approach to achieving this would be to list ~2 
editors as the front-page authors.

In parallel to this adoption call, I will send an IPR call for this document. 
We will need all authors and contributors to confirm their IPR position on this 
document.

(1) https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment

Thanks,
--Bruno & Rob.


_

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___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[徐小虎(义先)]

If I understood it correctly, draft-wang-lsr-ospf-prefix-originator-ext-00 is 
an OSPF counterpart of RFC7794 from the perspective of correlation of prefixes 
and their originator in the inter-area scenario. As such, these two drafts are 
useful for the usage of ELC in the inter-area scenario.

As for the inter-AS scenario, IMHO, BGP LSP over SR LSP is the best choice. In 
other words, I doubt the necessity of advertising the ELC across ASes VIA IGP 
REDISTRIBUTION.

Best regards,
Xiaohu
--
From:Les Ginsberg (ginsberg) 
Send Time:2018年11月20日(星期二) 14:52
To:Aijun Wang ; stephane.litkow...@orange.com 
; l...@ietf.org 
Cc:spring@ietf.org 
Subject:Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc


Aijun –

In the inter-AS case, what is needed is to know ELC of the originating node. 
Simply knowing who the originator of an advertisement is not sufficient.

If ELC is advertised as a node capability, then a controller with access to 
BGP-LS database for both ASs could determine ELC by piecing together the node 
capability advertisement and the prefix advertisement w originating router-id.

But what Stephane has proposed for the inter-AS case is a way to know ELC in 
the absence of a controller.
This means nodes in AS #1 need to have ELC capability info for nodes in AS #2.
As there is no way to redistribute IGP Node Capability advertisements between 
different IGP instances, the alternative is to advertise ELC associated with a 
prefix advertisement since the prefix advertisement can be redistributed 
between IGP instances.
Knowing the originator of the prefix is necessary, but it is not sufficient.

Hope this is clear.

Les



From: Aijun Wang  
Sent: Monday, November 19, 2018 10:41 PM
To: Les Ginsberg (ginsberg) ; 
stephane.litkow...@orange.com; l...@ietf.org
Cc: spring@ietf.org
Subject: 答复: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Hi, Les and Stephane:

https://tools.ietf.org/html/draft-wang-lsr-ospf-prefix-originator-ext-00 is 
trying to solve what you are concerning for.
As you said, ELC/ERLD are functionally node capabilities, but when we try to 
send traffic, we should consider the prefixes itself.
The above draft proposal to add prefix originator to address this. After 
getting this information, the receiver can then build the relationship between 
prefixes and ELC/ERLD.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
发送时间: 2018年11月20日 2:00
收件人:  stephane.litkow...@orange.com; l...@ietf..org
抄送: spring@ietf.org
主题: Re: [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Stephane –

The use case for this proposal is to support inter-AS scenarios in the absence 
of a controller.
If the WG agrees that this use case needs to be addressed I believe the 
proposal below is a good and viable compromise.

I say “compromise” because – as you mention below – ELC/ELRD are functionally 
node capabilities. But the inter-AS use case requires signaling between AS’s 
and the vehicle we have for doing that is a prefix advertisement. The 
compromise is to advertise ELC associated with a prefix – but not do so for 
ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or 
redistributed, the ELC associated to the prefix MUST also be 
leaked/redistributed.”.

   Les


From: Lsr  On Behalf Of stephane.litkow...@orange.com
Sent: Friday, November 09, 2018 6:30 AM
To: l...@ietf.org
Cc: spring@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Hi WG,
Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.
Following this discussion, we are coming with the following proposal that the 
WG need to validate:
The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not 
want to have an ERLD per linecard).
However IGPs may advertise prefixes that are not belonging to the node itself 
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a 
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.
When an ingress node pushes an entropy label below a segment  it must ensure 
that the tail-end of the segment is entropy label capable otherwise packets 
will be dropped.
As a consequence, when prefixes are redistributed, the entropy label capability 
of the node who has firstly originated the prefix, should be 

Re: [spring] [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

[徐小虎(义先)]

Why not directly use the BGP over SR model just like the BGP over LDP model?

Best regards,
Xiaohu


--
From:stephane.litkowski 
Send Time:2018年11月20日(星期二) 15:20
To:徐小虎(义先) ; Lsr ; 
l...@ietf.org 
Cc:spring@ietf.org 
Subject:Re: [spring] [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc


Hi all,

The use case is without TE. And this is how network designs are working today, 
and I do not see any valid reason to complexify and change the existing designs 
by introducing controllers or BGP-LS.
We have to accommodate with what is deployed today and the proposed change is 
quite simple.

Brgds,

From:徐小虎(义先) [mailto:xiaohu@alibaba-inc.com] 
Sent: Tuesday, November 20, 2018 03:16
To: Lsr; LITKOWSKI Stephane OBS/OINIS; l...@ietf.org
Cc: spring@ietf.org
Subject: Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Hi all,

IMHO, it seems a little bit odd to support inter-AS TE scenarios in the absence 
of a controller. If the inter-AS scenario is not for the TE purpose, would the 
(inter-AS) BGP-initiated LSP over (intra-AS) SR-initiated LSP be good enough 
(just like what we have done before in the LDP era, i.e., the BGP-initiated LSP 
over LDP-initiated LSP)?

Best regards,
Xiaohu
 
--
From:Les Ginsberg (ginsberg) 
Send Time:2018年11月20日(星期二) 02:00
To:stephane.litkow...@orange.com ; l...@ietf.org 

Cc:spring@ietf.org 
Subject:Re: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Stephane –

The use case for this proposal is to support inter-AS scenarios in the absence 
of a controller.
If the WG agrees that this use case needs to be addressed I believe the 
proposal below is a good and viable compromise.

I say “compromise” because – as you mention below – ELC/ELRD are functionally 
node capabilities. But the inter-AS use case requires signaling between AS’s 
and the vehicle we have for doing that is a prefix advertisement. The 
compromise is to advertise ELC associated with a prefix – but not do so for 
ERLD.
This seems reasonable to me.

One change to what you state below – I think “when a prefix is leaked or 
redistributed, the ELC associated to the prefix MUST also be 
leaked/redistributed.”.

   Les


From: Lsr  On Behalf Of stephane.litkow...@orange.com
Sent: Friday, November 09, 2018 6:30 AM
To: l...@ietf.org
Cc: spring@ietf.org
Subject: [Lsr] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc

Hi WG,

Some discussions occurred on the mailing list on how to encode the entropy 
label capability for SR but we hadn’t found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have 
participated to this discussion.

Following this discussion, we are coming with the following proposal that the 
WG need to validate:

The entropy label capability is still considered as a per node property (for 
simplicity reason, we do not want to have an ELC per linecard).
The ERLD is considered as a per node property (for simplicity reason, we do not 
want to have an ERLD per linecard).

However IGPs may advertise prefixes that are not belonging to the node itself 
in addition to the local prefixes of the nodes.
A typical use case is when two IGP domains (running the same protocol or a 
different one) are redistributing routes between each other.
The inter-area use case is also creating a similar situation.

When an ingress node pushes an entropy label below a segment  it must ensure 
that the tail-end of the segment is entropy label capable otherwise packets 
will be dropped.

As a consequence, when prefixes are redistributed, the entropy label capability 
of the node who has firstly originated the prefix, should be associated to the 
prefix during the redistribution.

In terms of encoding, we propose to associate an entropy label capability for 
each prefix advertised by a node.
The entropy label capability will be encoded as part of the Prefix Attributes 
IGP extension (RFC7794 and RFC7684).
The entropy label capability may be set for local prefixes (e.g. loopbacks) by 
a local configuration and for leaked/redistributed prefixes. When a prefix is 
leaked or redistributed, the ELC associated to the prefix may be also 
leaked/redistributed.

An ingress should set the entropy label below a Node/Prefix segment only if the 
prefix associated to the Node/Prefix segment as the ELC set in the Prefix 
Attributes.
An ingress should set the entropy label below an Adjacency segment only if the 
adjacent neighbor of the node that has advertised the Adj SID is advertising an 
ERLD (and so is entropy label capable).

For the binding SID, as IGPs are not involved in the signaling of the binding 
SID, there is nothing to do in these drafts. 


Let us know your comments/feedback on this proposal so we can progress these 
documents.

Re: [spring] Signalling ERLD (ISIS, OSPF and BGP-LS)

[徐小虎(义先)]

If I understand it correctly, according to the ELC concept originated from 
RFC6790 (see below), the ELC itself doesn't mean the ELC originator should be 
capable of using the EL for load-balancing. It just means the egress of the 
tunnel advertising that capability is capable of popping the ELI/EI.

5.  Signaling for Entropy Labels

   An egress LSR Y can signal to ingress LSR(s) its ability to process
   entropy labels (henceforth called "Entropy Label Capability" or ELC)
   on a given tunnel.  In particular, even if Y signals an implicit null
   label, indicating that PHP is to be performed, Y MUST be prepared to
   pop the ELI and EL.

The ELC is only required for tunnel egress nodes. The EL-based load-balancing 
capability is only required for intermediate nodes and tunnel ingress nodes. In 
other words, the ERLD doesn't equal to the combination of ELC and RLD. RFC6790 
allows ingress nodes to insert an ELI/EL pair as long as the tunnel egress has 
advertised the ELC. In the case where SR-IGP is just used as a replacement of 
LDP, why should the egress node be required to advertise its RLD in addition to 
the ELC before the ingress being able to impose an ELI/EL? Furthermore, 
although the major use case of RLD is entropy label-based load-balancing at the 
current stage, nobody can promise this is the only use case of RLD as well in 
the future. In a word, it seems better to advertise the RLD and ELC 
independently from the flexibility perspective.

Best regards,
Xiaohu

--
From:Van De Velde, Gunter (Nokia - BE/Antwerp) 
Send Time:2018年6月13日(星期三) 16:25
To:Ketan Talaulikar (ketant) ; i...@ietf.org ; 
l...@ietf.org ; spring@ietf.org 
Subject:Re: [spring] Signalling ERLD (ISIS, OSPF and BGP-LS)

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic 
motivation.

The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is 
available, then ELC can be implicitly assumed. No pragmatic reason to signal 
separately, as it just make things more complex then should be. 

>From a holistic perspective having something similar, yet different, in both 
>IGP and BGP-LS encoding 
seems to make little sense and only bring confusion (router/controller 
implementers and network operators). 

The ways to address this in IGP and BGP-LS going forward:
1) do nothing and leave all as it is (it has potential to create massive 
confusion) 
2) only signal ERLD TLV in IGP and BGP
3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of 
ELC TLV compared to option (2)) 
4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more 
complex as option (2))

I believe that option (2) is the best option:
* it bring the needed readable label depth value to operators 
* most simple solution for implementers (routers and controller)  
* easy to understand with no confusion
* is compliant with draft-ietf-mpls-spring-entropy-label-10

G/

-Original Message-
From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

The difference in IGP signalling seems to be because the ELC is a capability 
which is advertised differently than ERLD which is a limit. Are you saying that 
ELC does not have value by itself without the ERLD?

IMHO it makes sense to retain ELC as capability of the router (as specified in 
the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. 
This way we have the flexibility of signalling ERLD both per node and per 
ingress link/LC level.

Thanks,
Ketan

-Original Message-
From: Idr  On Behalf Of Van De Velde, Gunter (Nokia - 
BE/Antwerp)
Sent: 12 June 2018 19:28
To: i...@ietf.org; l...@ietf.org; spring@ietf.org
Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is 
need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is 
signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that 
should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon 
(https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
* What are the plans to request IANA code points for these drafts?
* (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK 
ERLD is not of any value at all, is that a correct assumption?)

G/


-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 12, 2018 15:25
To: i-d-annou...@ietf.org
Cc: 

Re: [spring] draft-xu-mpls-sr-over-ip

[徐小虎(义先)]

Hi Loa,

I don't know any IPR related to this draft.

Best regards,
Xiaohu


--
From:Loa Andersson 
Send Time:2018年6月7日(星期四) 18:15
To:m...@ietf.org 
Cc:spring@ietf.org ; mpls-cha...@ietf.org 
; draft-xu-mpls-sr-over...@ietf.org 

Subject:[spring] draft-xu-mpls-sr-over-ip

Working Group,

We are currently preparing draft draft-xu-mpls-sr-over-ip for working
group adoption.

Part of this preparation is to do an IPR poll.

This mail is to start the IPR poll.

Are you aware of any IPR that applies to draft-xu-mpls-sr-over-ip?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There are currently no IPR disclosures against draft-xu-mpls-sr-over-ip.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS WG mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.

We have copied this mail to the SPRING wg mailing list for information.
If you receive this mail over the SPRING wg mailing list, and are aware
of IPRs that apply to the draft, please notify the MPLS wg list.


/Loa
  mpls wg co-chair
-- 


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

___
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 Last Call for draft-ietf-spring-segment-routing-mpls-13

[徐小虎(义先)]

Hi all,

I have read this doc and support the publication.

Xiaohu


--
From:bruno.decraene 
Send Time:2018年6月8日(星期五) 00:52
To:SPRING WG List 
Cc:draft-ietf-spring-segment-routing-m...@ietf.org 

Subject:Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13


Hi all,

A quick update on the status of this WGLC:

- All the authors have responded about IPR (thank you!). Still missing replies 
from some contributors (Wim, Edward, Igor, Saku). I’ve sent them a reminder 
this Monday.
- Two people (Zafar, Adrian) have responded supporting publication.
- No opposition.
- Two persons have sent comments (Adrian, myself). Thanks Adrian.
- Authors have not replied to any comment so far.
- The WGLC period was scheduled to end tomorrow.

I wish we had more support, reviews, and authors’ involvement to reply to 
reviews.

The WGLC is extended by a week. Please review the document and send your 
comments to the list, no later than *June 15*

Thank you,
--Bruno

From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] 
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: draft-ietf-spring-segment-routing-m...@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13
Hello Working Group,

This email starts a Working Group Last Call on 
draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and 
ready for a final working group review.

Please read this document if you haven't read the most recent version yet, and 
send your comments to the list, no later than *June 08*.
 
As a reminder, this document had already passed a WGLC more than a year ago on 
version -06 [2], had been sent to the AD but then returned to the WG.
Since then, the document has significantly changed, so please read it again. In 
particular, it now includes the resolution in case of incoming label collision. 
Hence it killed draft-ietf-spring-conflict-resolution.
 
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd.. Thank you Shraddha.
- Martin, our AD, has agreed to evaluate the WG consensus.

Thank you,
Bruno, Rob
 
[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
[2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
 
_
 
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.
_

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

[spring] 回复： Working Group Adoption Call for draft-filsfils-spring-segment-routing-policy

[徐小虎(义先)]

I support the adoption.

Xiaohu 





来自钉钉专属商务邮箱--发件人：Rob
 Shakir日　期：2018年05月16日 23:20:22收件人：SPRING WG 
List主　题：[spring] Working Group Adoption Call for 
draft-filsfils-spring-segment-routing-policyHi SPRING WG,
This email initiates a two week call for working group adoption for 
draft-filsfils-spring-segment-routing-policy. Please indicate your support, or 
otherwise, for adopting this draft as a working group item by 30th May 2018. We 
are particularly interested in hearing from working group members that are not 
co-authors of this draft.
As part of the discussions of adopting this draft into SPRING with the ADs and 
chairs of other WGs, there are a number of requests to the authors.
1. Please clarify in the text traffic steering with "SR policy" and its 
relationship to other traffic engineering functions. It seems to me that this 
work is generally describing how one selects and steers traffic into policies, 
rather than path calculation. Additional clarification of whether this is the 
case (or not), would be welcome to ensure that the relationship with other work 
is clear. We would ask the authors to consider whether sections 14.1-14.4 are 
required scope of this document.
2.. Consider what the core content of this document is, and how it can be make 
as concise and clear as possible. There are some specific suggestions that can 
be made here, but we would like to see this discussed with the working group.
Additionally, there are currently 17 authors listed on this document. Please 
trim this to <= 5 front-page authors, utilising a "Contributors" section if 
required for the others.. An approach to achieving this would be to list ~2 
editors as the front-page authors.
In parallel to this adoption call, I will send an IPR call for this document. 
We will need all 17 authors to confirm their IPR position on this document.
Thanks,Bruno & Rob.

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

Re: [spring] Request WG adoption for draft-xuclad-spring-sr-service-chaining-01

[徐小虎(义先)]

Hi SPRING WG co-chairs,
I wonder what the current status of this WG adoption request.
Best 
regards,Xiaohu--From:徐小虎(义先)
 <xiaohu@alibaba-inc.com>Send Time:2018年4月4日(星期三) 09:45To:SPRING WG List 
<spring@ietf.org>Cc:s...@ietf.org <s...@ietf.org>Subject:Request WG adoption 
for draft-xuclad-spring-sr-service-chaining-01

Hi SPRING WG co-chairs,
We authors believe this draft 
(https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01) has 
been stable enough and therefore we would like to request a WG adoption call 
for it.
We believe this work belongs to SPRING WG since the concept of service segment 
has been mentioned in the Segment Routing architecture from day one and the 
approaches as described in this draft are exactly to leverage the stateless 
source routing capability of segment routing to achieve a stateless SFC. To 
some extent, SFC can be looked as a special case of source routing as it 
requires the selected traffic to traverse an ordered list of service nodes.

We believe the SFC WG review is still needed after the adoption since we still 
hope to reuse the NSH for some special purposes (e.g., use it as a metadata 
container). 
BTW, implementations based on this draft have existed, as noted in section 8 of 
the draft.
Best regards,Xiaohu (on behalf of coauthors)




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

[spring] For the fairness and justice of the IETF culture//Re: [mpls] What to do with draft-ietf-mpls-sfc-00.txt

[徐小虎(义先)]

Hi all,

 
As I had pointed out before, this draft describes two MPLS-based SFC
approaches: one is how to encode the NSH info, more specifically, the SPI
and SI info by two MPLS labels, which is still a stateful SFC mechanism
just like NSH; another is how to leverage the MPLS-SR to realize a
stateless SFC (see section 6).

 
It has been pointed out by many people that section 6 of the draft copies
the
idea of (https://tools.ietf.org/html/draft-xu-mpls-service-chaining)
without any technology contribution except replacing “MPLS Segment
Routing” by “Label Stack”. Funnily, one author of draft-ietf-mpls-sfc
had inadvertently admitted
"using a different name for the same thing is not so clever" (see
https://mailarchive.ietf.org/arch/msg/mpls/y7FTc38ysVf6PyJlA04MEFSN9nc) in
another thread. 

IMHO, the indulgence towards such behavior of copying
ideas of existing drafts with word tricks would seriously trample
underfoot the fairness and justice of the IETF culture. At least, it would
badly damage the interest and enthusiasm of IETF participants, especially
newcomers and non-native speakers of English.

Best regards,
Xiaohu
 


在 2018/4/5 上午1:05， "mpls on behalf of Adrian Farrel"
 写入:

>WG,
>
>Would it help if we added use cases to this document? Usually, the IESG
>frowns
>on use cases, but it sounds as though this document needs some further
>explanation.
>
>Of course, not everyone likes every proposed use case. Some will say, "I
>don't
>need that." Others will say, "I have another way, or I prefer a different
>way,
>of achieving that."
>
>Adding such a section would allow the inclusion of some text saying
>(something
>like) "A use case is to achieve SFC in an MPLS-SR network, but that is
>discussed
>in draft-xuclad-spring-sr-service-chaining."
>
>
>Additionally, I have been wondering how to handle the discussion of using
>this
>function in a brownfield network. Normally we don't tell people in our
>specs how
>to build their boxes - we make protocol specs not design documents.
>However, if
>in addition to how I would build this, I can see a (somewhat clunky)
>method to
>achieve this function in existing platforms, would it be worth adding
>that?
>
>Cheers,
>Adrian
>
>> -Original Message-
>> From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of internet-
>> dra...@ietf.org
>> Sent: 04 April 2018 10:28
>> To: i-d-annou...@ietf.org
>> Cc: m...@ietf.org
>> Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-00.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>> This draft is a work item of the Multiprotocol Label Switching WG of
>>the IETF.
>> 
>> Title   : An MPLS-Based Forwarding Plane for Service
>>Function
>Chaining
>> Authors : Adrian Farrel
>>   Stewart Bryant
>>   John Drake
>>  Filename: draft-ietf-mpls-sfc-00.txt
>>  Pages   : 24
>>  Date: 2018-03-28
>> 
>> Abstract:
>>Service Function Chaining (SFC) is the process of directing packets
>>through a network so that they can be acted on by an ordered set of
>>abstract service functions before being delivered to the intended
>>destination.  An architecture for SFC is defined in RFC7665.
>> 
>>The Network Service Header (NSH) can be inserted into packets to
>>steer them along a specific path to realize a Service Function Chain.
>> 
>>Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
>>technology that uses labels placed in a packet in a label stack to
>>identify the forwarding actions to be taken at each hop through a
>>network.  Actions may include swapping or popping the labels as well,
>>as using the labels to determine the next hop for forwarding the
>>packet.  Labels may also be used to establish the context under which
>>the packet is forwarded.
>> 
>>This document describes how Service Function Chaining can be achieved
>>in an MPLS network by means of a logical representation of the NSH in
>>an MPLS label stack.  It does not deprecate or replace the NSH, but
>>acknowledges that there may be a need for an interim deployment of
>>SFC functionality in brownfield networks.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-mpls-sfc-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-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/
>> 
>> ___
>> mpls mailing list
>> m...@ietf.org
>> 

[spring] Request WG adoption for draft-xuclad-spring-sr-service-chaining-01

[徐小虎(义先)]

Hi SPRING WG co-chairs,

We authors believe this draft
(https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01) has
been stable enough and therefore we would like to request a WG adoption call
for it.

We believe this work belongs to SPRING WG since the concept of service
segment has been mentioned in the Segment Routing architecture from day one
and the approaches as described in this draft are exactly to leverage the
stateless source routing capability of segment routing to achieve a
stateless SFC. To some extent, SFC can be looked as a special case of source
routing as it requires the selected traffic to traverse an ordered list of
service nodes.


We believe the SFC WG review is still needed after the adoption since we
still hope to reuse the NSH for some special purposes (e.g., use it as a
metadata container).

BTW, implementations based on this draft have existed, as noted in section 8
of the draft.

Best regards,
Xiaohu (on behalf of coauthors)







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

[spring] using a different name for the same thing is not so clever :-) really?

[徐小虎(义先)]

Hi Adrian,
Please see my comments inline with 
[Xiaohu]--Adrian
 Farrel 2018年3月22日(星期四) 22:32Ruediger.Geib 
; spring Re: [spring] What is "TE" 
and the rechartering discussion
Hey Ruediger,

Our agreement may be so complete that we may get mistaken for each other in the
corridor.

Using a different name for different things is wise.
Of course, using a different name for the same thing is not so clever :-) So
digging a little to make sure we know what each group is talking about will
still be helpful.
[Xiaohu] I couldn't agree more. However, I still see that some people are happy 
to write drafts by using different name for the same thing which has been 
described in the existing drafts many years before:
One example is Section 6 of https://tools.ietf.org/html/draft-farrel-mpls-sfc 
vs https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03 (note that 
this draft has been merged into 
https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00).
Best regards,Xiaohu

Adrian

> -Original Message-
> From: ruediger.g...@telekom.de [mailto:ruediger.g...@telekom.de]
> Sent: 22 March 2018 13:36
> To: adr...@olddog.co.uk; spring@ietf.org
> Subject: AW: [spring] What is "TE" and the rechartering discussion
> 
> Hi Adrian,
> 
> that's a fair proposal, I think. In addition, it may help to avoid the term
"Traffic
> Engineering" when rechartering Spring. Spring needs to recharter now. I didn't
> see any emails on the list which advised against Spring policy routing and the
> related OAM mechanisms as future work items.
> 
> Regards,
> 
> Ruediger
> 
> -Ursprüngliche Nachricht-
> Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Adrian Farrel
> Gesendet: Donnerstag, 22. März 2018 14:08
> An: spring@ietf.org
> Betreff: [spring] What is "TE" and the rechartering discussion
> 
> There *might* be some disconnect between:
> - What TEAS means by "TE"
> - What TEAS is perceived to mean by "TE"
> - What Spring means by "TE"
> - What Spring is perceived to mean by "TE"
> 
> An option (although it would slow the discussion a bit - it might speed it in
the
> long term) would be to try to clarify these points with a draft or a joint
discussion
> session.
> Of course, that MUST NOT delay or derail the development of protocol
> specifications, but I think the discussion about where work should be done is
a
> distraction: until that decision has been made (by the chairs and ADs) we
should
> write drafts and we should discuss them on any and all mailing lists where
people
> lurk who could help us get the work right.
> 
> Adrian
> 
> ___
> 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 mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] 答复: [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[徐小虎(义先)]

Hi Robin,
It sounds reasonable and fair. 
Best regards,Xiaohu
--Lizhenbin 
<lizhen...@huawei.com>2018年3月15日(星期四) 15:48徐小虎(义先) 
<xiaohu@alibaba-inc.com>; spring <spring-boun...@ietf.org>; Francois Clad 
(fclad) <fc...@cisco.com>; adr...@olddog.co.uk <adr...@olddog.co.uk>mpls 
<m...@ietf.org>; SPRING WG List <spring@ietf.org>; s...@ietf.org 
<s...@ietf.org>[spring] 答复: [mpls][sfc] The MPLS WG has placed 
draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
I have read draft-xuclad-spring-sr-service-chaining and draft-farrel-mpls-sfc. 
In essence the SR-MPLS SFC solutions proposed in the two drafts are
 similar. I think the easiest way to solve the confliction is to remove the 
section 6 of draft-farrel-mpls-sfc, then the updated draft goes on for MPLS WG 
adoption. 发件人: mpls [mailto:mpls-boun...@ietf.org]
代表 徐小虎(义先)
发送时间: 2018年3月14日 9:35
收件人: spring <spring-boun...@ietf.org>; Francois Clad (fclad) <fc...@cisco.com>; 
adr...@olddog.co.uk
抄送: mpls <m...@ietf.org>; SPRING WG List <spring@ietf.org>; s...@ietf.org
主题: Re: [mpls] [spring] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "Call For Adoption By WG Issued"  Jim, 
--James N 
Guichard <james.n.guich...@huawei.com>2018年3月14日(星期三)
 03:00Francois Clad (fclad) <fc...@cisco.com>;
adr...@olddog.co.uk <adr...@olddog.co.uk>mpls <m...@ietf.org>; SPRING WG List 
<spring@ietf.org>;
s...@ietf.org <s...@ietf.org>Re: [spring] [mpls] [sfc] The MPLS WG has placed 
draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Francois, 
One comment below .. From: mpls [mailto:mpls-boun...@ietf.org]
On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: adr...@olddog.co.uk
Cc: mpls <m...@ietf.org>; SPRING WG List <spring@ietf.org>;
s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued" Hi Adrian, On 9 Mar 2018, at 10:17, 
Adrian Farrel <adr...@olddog.co.uk> wrote: I, too, hope we can move to a 
technical discussion of the differences between the proposals
 The issue is that, from a technical point of view, there is no difference 
between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the 
solution that was originally documented in draft-xu-mpls-service-chaining, as
 Xiaohu pointed out several times. Jim> as far as I can tell this is not 
exactly true.. draft-xu-mpls-service-chaining-00 talks about using an MPLS 
label to identify a service segment. Draft-farrel-mpls-sfc talks about using 2 
labels, an SFC context label and an SF label, to essentially mimic NSH 
behavior. The authors of that draft even go as far as to say (about the context 
label) “.. using the semantics of the SPI is exactly as defined in [RFC8300]”  
which is exactly what you state you don’t want to do in 
draft-xuclad-spring-sr-service-chaining. Therefore I am not sure how you can 
come to the conclusion that there is no difference between the two solutions. 
  draft-xu* talks about using 2 labels as well, see Section 3.1 of  
https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03#page-7. The only 
difference that I can find is draft-farrel* interpretes  "node segment label" 
as "context label".  BTW, this reminds me of almost the same thing just 
happened between 
https://tools.ietf.org/html/draft-xu-mpls-unified-source-routing-instruction-04 
and https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-03#page-5 where 
the latter interpretes "label stack" as "instruction stack".  Xiaohu Jim

Considering that draft-xu-mpls-service-chaining was submitted almost one year 
before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in 
section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, 
which is now draft-xuclad-spring-sr-service-chaining.


To be fair to draft-xu-mpls-service-chaining, I believe that 
draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing 
towards WG adoption.


Thanks,

Francois  and not spend time thrashing around in IETF politics. I'm sure the 
ADs will help us understand what is written in the various WG charters, so our
 best next step would be to read (you know, like all the words :-) what is in 
the drafts. However, since Zafar ascribes to me something that I did not say 
and that is not recorded in the minutes, perhaps I can set that straight. He 
said... > From IETF process viewpoint, this call for adaption is like putting 
the "cart ahead of the horse."> MPLS WG comes last in the process after there 
is an agreement from Spring and SFC groups> on the need for MPLS data plane 
changes prop

[spring] What's the consensus among co-chairs and ADs regarding the better place for the SR-MPLS-over-IP work?

[徐小虎(义先)]

Dear co-chairs and ADs,
Alvaro as an AD said at last IETF meeting that let's wait and decide (on the 
better place for the SR-MPLS-over-IP work) (see 
https://datatracker.ietf.org/meeting/100/materials/minutes-100-spring), I 
wonder whether a rough consensus has been reached among co-chairs and ADs.
Best regards,Xiaohu___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[徐小虎(义先)]

Jim,
--James N 
Guichard <james.n.guich...@huawei.com>2018年3月14日(星期三) 03:00Francois Clad 
(fclad) <fc...@cisco.com>; adr...@olddog.co.uk <adr...@olddog.co.uk>mpls 
<m...@ietf.org>; SPRING WG List <spring@ietf.org>; s...@ietf.org 
<s...@ietf.org>Re: [spring] [mpls] [sfc] The MPLS WG has placed 
draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
Hi Francois, One comment below .. From: mpls [mailto:mpls-boun...@ietf.org]
On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: adr...@olddog.co.uk
Cc: mpls <m...@ietf.org>; SPRING WG List <spring@ietf.org>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued" Hi Adrian,

On 9 Mar 2018, at 10:17, Adrian Farrel <adr...@olddog.co.uk> wrote: I, too, 
hope we can move to a technical discussion of the differences between the 
proposals
 The issue is that, from a technical point of view, there is no difference 
between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the 
solution that was originally documented in draft-xu-mpls-service-chaining, as 
Xiaohu
 pointed out several times. Jim> as far as I can tell this is not exactly 
true.. draft-xu-mpls-service-chaining-00 talks about using an MPLS label to 
identify a service segment. Draft-farrel-mpls-sfc talks about using 2 labels, 
an SFC context label and an SF label, to essentially mimic NSH behavior. The 
authors of that draft even go as far as to say (about the context label) “.. 
using the semantics of the SPI is exactly as defined in [RFC8300]”  which is 
exactly what you state you don’t want to do in 
draft-xuclad-spring-sr-service-chaining. Therefore I am not sure how you can 
come to the conclusion that there is no difference between the two solutions.
  draft-xu* talks about using 2 labels as well, see Section 3.1 of  
https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03#page-7. The only 
difference that I can find is draft-farrel* interpretes  "node segment label" 
as "context label". 
BTW, this reminds me of almost the same thing just happened between 
https://tools.ietf.org/html/draft-xu-mpls-unified-source-routing-instruction-04 
and https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-03#page-5 where 
the latter interpretes "label stack" as "instruction stack". 
Xiaohu
Jim


Considering that draft-xu-mpls-service-chaining was submitted almost one year 
before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in 
section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, 
which is now draft-xuclad-spring-sr-service-chaining.


To be fair to draft-xu-mpls-service-chaining, I believe that 
draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing 
towards WG adoption.


Thanks,

Francois 

and not spend time thrashing around in IETF politics. I'm sure the ADs will 
help us understand what is written in the various WG charters, so our best next 
step
 would be to read (you know, like all the words :-) what is in the drafts. 
However, since Zafar ascribes to me something that I did not say and that is 
not recorded in the minutes, perhaps I can set that straight. He said... > From 
IETF process viewpoint, this call for adaption is like putting the "cart ahead 
of the horse."> MPLS WG comes last in the process after there is an agreement 
from Spring and SFC groups> on the need for MPLS data plane changes proposed by 
the draft. I raised this point at the mic> at SFC WG meeting at IETF100 and 
Adrian agreed to it. I.e., MPLS WG comes at the last stage> in the process; 
expert to review this work does not sit in the MPLS WG. According to the 
minutes, Zafar said... | Zafar Ali: before defining the solution, is this the 
right approach in SFC? Starting| in MPLS WG is wrong thing to do. And I 
responded... | Adrian: This was already presented in SFC WG today. In the SFC 
WG I said... | - The draft discusses how MPLS can be used for SFC. It is being 
discussed in the|MPLS working group.| - We are looking at environments in 
which deployed MPLS routers can be used|for creating an SFC, rather than 
using NSH. If you want my opinion:- The SFC WG is chartered to work on NSH 
only- The MPLS WG is chartered to work on MPLS- This draft asks for MPLS code 
points so can only be in MPLS- This draft must be reviewed in SFC and SPRING as 
it progresses and   certainly at WG last call Adrian From: mpls
 [mailto:mpls-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; s...@ietf.org; draft-farrel-mpls-sfc; mpls-chairs; 
mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "C

[spring] 回复：[mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[徐小虎(义先)]

Hi all, 
As I had pointed out at the last IETF meeting, section 6 of this draft has an 
serious overlap with 
https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03 that has now been 
updated by 
https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01 with a 
merge with draft-clad-spring-segment-routing-service-chaining.
Hence, I'm very interesting to know the intention of such rewritting of a given 
mechanism that has been described in another draft. Is there any special 
nutrition?
Best 
regards,Xiaohu--发件人：IETF
 Secretariat 发送时间：2018年3月6日(星期二) 
22:09收件人：draft-farrel-mpls-sfc ; mpls 
; mpls-chairs 主　题：[mpls] The MPLS WG has 
placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

The MPLS WG has placed draft-farrel-mpls-sfc in state
Call For Adoption By WG Issued (entered by Loa Andersson)

The document is available at
https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/

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

[spring] 转发：New Version Notification for draft-xu-mpls-sr-over-ip-00.txt

[徐小虎(义先)]

Hi all,
This draft is the merge of the following two drafts:
1) 
https://datatracker.ietf.org/doc/draft-xu-mpls-unified-source-routing-instruction/2)
 https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/
Any comments and suggestions are welcome.
Best regards,Xiaohu (on behalf of all 
co-authors)--发件人：internet-drafts
 <internet-dra...@ietf.org>发送时间：2018年3月1日(星期四) 15:10收件人：Ahmed Bashandy 
<basha...@cisco.com>; Wim Henderickx <wim.henderi...@nokia.com>; Zhenbin Li 
<lizhen...@huawei.com>; Stewart Bryant <stewart.bry...@gmail.com>; Adrian 
Farrel <afar...@juniper.net>; 徐小虎(义先) <xiaohu@alibaba-inc.com>主　题：New 
Version Notification for draft-xu-mpls-sr-over-ip-00.txt

A new version of I-D, draft-xu-mpls-sr-over-ip-00.txt
has been successfully submitted by Xiaohu Xu and posted to the
IETF repository.

Name:  draft-xu-mpls-sr-over-ip
Revision: 00
Title:  SR-MPLS over IP
Document date: 2018-03-01
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/internet-drafts/draft-xu-mpls-sr-over-ip-00.txt
Status: https://datatracker.ietf.org/doc/draft-xu-mpls-sr-over-ip/
Htmlized:   https://tools.ietf.org/html/draft-xu-mpls-sr-over-ip-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-xu-mpls-sr-over-ip-00


Abstract:
   MPLS Segment Routing (SR-MPLS in short) is an MPLS data plane-based
   source routing paradigm in which the sender of a packet is allowed to
   partially or completely specify the route the packet takes through
   the network by imposing stacked MPLS labels on the packet.  SR-MPLS
   could be leveraged to realize a source routing mechanism across MPLS,
   IPv4, and IPv6 data planes by using an MPLS label stack as a source
   routing instruction set while preserving backward compatibility with
   SR-MPLS.

   This document describes how SR-MPLS capable routers and IP-only
   routers can seamlessly co-exist and interoperate through the use of
   SR-MPLS label stacks and IP encapsulation/tunnelling such as MPLS-in-
   UDP [RFC7510].



  


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