You are technically correct that the SR Architecture document does not
require the separation of topological behavior from service behavior.
On the other hand, MANY of us have notied, and tried to find solutions
for, the fact that the overloading of IP addresses for both identity and
location causes significant problems. Further overloading the same
thing with service semantics as well makes this problem worse. So yes,
there are plenty of good reasons to be concerned about this overloading.
Yours,
Joel
On 9/10/2019 11:45 PM, Satoru Matsushima wrote:
Hi Aijun,
But the concept of SRv6+ is more clear than the SRv6(topology/service
instruction separation;
The SR architecture never require such things. See RFC8402:
“Abstract
Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called
"segments". A segment can represent any instruction, topological or
service based.”
“3.1.3 <https://tools.ietf.org/html/rfc8402#section-3.1.3>. SRv6
When SR is used over the IPv6 data plane:
o A Prefix-SID is an IPv6 address.
o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node
addresses are not SRv6 SIDs by default.”
different instruction carried in different IPv6 EH). It conforms to
RFC8200 as well, seems will be less resisted within 6man WG.
SRH conforms RFC8200.
Will such enhancements accelerate the deployment of SR related
technologies in service provider network? Anyway it is called SRv6+ J.
SRH has already accelerated SRv6 deployments.
Best regards,
—satoru
We have our own solutions for the similar scenarios that the SR
technologies aims to solve, but will also keep eye on the advance of
SR/SRv6/SRv6+ technologies.
Best Regards.
Aijun Wang
China Telecom
*发件人:*spring-boun...@ietf.org <mailto:spring-boun...@ietf.org>
[mailto:spring-boun...@ietf.org] *代表 *Robert Raszuk
*发送时间:*2019年9月11日1:34
*收件人:*Sander Steffann
*抄送:*Ron Bonica; SPRING WG List; Andrew Alston; James Guichard;
Shraddha Hegde; Rob Shakir; Zafar Ali (zali); Voyer, Daniel
*主题:*Re: [spring] Going back to the original question for the Spring
WG (was: Re: Beyond SRv6.)
Hi Sander,
You keep saying SRv6 is complex. But it is only as complex as you are
going to make it or as you will need it to be.
No one is mandating you to do any network programming or to use
multiple TLVs. If you just need to use SR for basic TE you insert one
or two SIDs and you are done. If you want to also enable L3VPN you
configure it in pretty much identical way regardless if this is SRv6
or SRv6+.
I know I am not going to convince you, but just for the record it is
worh to note that what get's send on the wire is only the information
what you as the vendor need. The fact that spec has prepared encoding
to also be useful for not only you but other operators does not make
the solution "complex". Otherwise we will end up with protocol per
customer which would be pretty bad I am afraid.
See many people say BGP is complex .... and it is the same here - BGP
is as complex as you require it to be. You can enable BGP 1/1 with 4
lines of config. But if you need other address families if you need
fancy policy you have all required tools for that on your keyboard.
- - -
Now point about SRv6+ ... see writing a drafts for it easy, Further
even writing interop draft with SRv6 is also not that complex - day or
two and you submit. But please tell me why any vendor who has been
working in open IETF process on any new service for over 5 years now
would have to put a lot of development resources on the table to
develop data plane and control plane enhancements for essentially
subset of functionality at best ?
It is nothing about anyone's good will or not ... it is all about
limited resources. Features and extensions are not added to any vendor
based on the RFC translation engine. It is pretty difficult and
painful process. So without huge market demand behind it I would be
highly surprised if any vendor who committed to SRv6 already would now
take real on support for SRv6+.
Thank you,
R.
On Tue, Sep 10, 2019 at 6:21 PM Sander Steffann <san...@steffann.nl
<mailto:san...@steffann..nl>> wrote:
Hi,
> No. And that is why I want SRv6+ to move forward, to avoid getting
trapped in the SRv6 walled garden.
>
> The way IETF works (at least in vast majority of WGs) is that if you do not like a specific element of a solution or if something is missing from any solution during WG process - you contribute to it to either fix it or to make sure the WG product is the best possible.
>
> So nothing prevented you for all the years IETF has been dealing with SRv6 process to take an active part in its standardization.
>
> Asking for adoption of solution which brings nothing new to already shipping solution of SR-MPLS when it would travel over IPv4 or IPv6 is at best counterproductive.
No, something that today can do the same as SR-MPLS but over IPv6,
with lots of space for future expansion, is something I like to
see. Using IPv6 instead of MPLS already gives the benefit of
unifying transport technologies. I'm not waiting for something
feature packed with so many knobs and "special" (read: header
insertion, bit shifting etc) that it will be much harder to work with.
> It is like now you would be asking to adopt some individual drafts which
woke up and defined new data plane and new control plane for services you are
running in your network - and call those MPLS+, L2VPN+, L3VPN+ and mVPN+ without
any new functionality.
That "without any new functionality" isn't exactly true either…
> Would it make sense ?
If those data plane and control plane drafts provide an easier way
to do those things? Most definitely yes.
It's the measuring progress by how many features and "cool" things
are added that is a problem here. Progress also include making
technology easier to manage, easier to understand, easier to
debug, more accessible to average network engineers.
Antoine de Saint Exupéry was right: “Perfection is achieved, not
when there is nothing more to add, but when there is nothing left
to take away.”
Cheers,
Sander
_______________________________________________
spring mailing list
spring@ietf.org <mailto: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
