Subject: Regaining Focus on SRv6 and SRv6+

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Sep 2019 13:07:57 +0000

Folks,

We have explored many facets of SRv6 and SRv6, sometime passionately. I think that this exploration is a good thing. In the words of Tolkien, "All who wander are not lost."

But it may be time to refocus on the following:

  *   For many operators, SRv6 is not deployable unless the problem of header length is addressed
  *   Many objections the uSID proposal remain unanswered
  *   SRv6+ offers an alternative solution

Given these three facts, I think that it would be a mistake to discontinue work on SRv6+.

                                                                                   Ron

Juniper Business Use Only

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 15:33:06 +0200

Dear Ron,

I think you forgot few main points in the summary:

* Many operators use SR-MPLS successfully and it has been both standardized
and successfully deployed in the network with interoperable implementations

* The overhead on the data plane of SRv6+ is very comparable to overhead of
SR-MPLS

* The control plane extensions BGP, IGP are available for SR-MPLS and non
are available for SRv6+

* SRv6+ requires a new mapping of SIDs to prefixes to be distributed by
control plane

* If operators choose not to use MPLS transport SR-MPLS can be easily
transported over IPv4 or IPv6 vanilla data plane

* Extensions for additional applications like L3VPNs or L2VPNs will require
another set of protocol and implementation changes.

* If there are vendors who do not want to provide SR-MPLS SID mapping to
IPv6 addresses in their control planes let's focus standardization and
industry work in this direction.

With all of the above I think it would be a serious mistake - at this point
of time - to continue work on SRv6+ in the IETF.

Thank you,
Robert.

On Fri, Sep 6, 2019 at 3:08 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Folks,
>
>
>
> We have explored many facets of SRv6 and SRv6, sometime passionately. I
> think that this exploration is a good thing. In the words of Tolkien, “All
> who wander are not lost.”
>
>
>
>    - For many operators, SRv6 is not deployable unless the problem of
>    header length is addressed
>    - Many objections the uSID proposal remain unanswered
>    - SRv6+ offers an alternative solution
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tarek Saad <[email-masked]>
Date: Fri, 6 Sep 2019 14:03:08 +0000

Hi Robert,

>> * If operators choose not to use MPLS transport SR-MPLS can be easily transported over IPv4 or IPv6 vanilla data plane
I’m little confused about the above argument – given it starts with don’t want to use MPLS, can you clarify?

Regards,
Tarek

From: spring <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, September 6, 2019 at 9:33 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Dear Ron,

* Many operators use SR-MPLS successfully and it has been both standardized and successfully deployed in the network with interoperable implementations

* The overhead on the data plane of SRv6+ is very comparable to overhead of SR-MPLS

* The control plane extensions BGP, IGP are available for SR-MPLS and non are available for SRv6+

* SRv6+ requires a new mapping of SIDs to prefixes to be distributed by control plane

* If operators choose not to use MPLS transport SR-MPLS can be easily transported over IPv4 or IPv6 vanilla data plane

* Extensions for additional applications like L3VPNs or L2VPNs will require another set of protocol and implementation changes.

* If there are vendors who do not want to provide SR-MPLS SID mapping to IPv6 addresses in their control planes let's focus standardization and industry work in this direction.

With all of the above I think it would be a serious mistake - at this point of time - to continue work on SRv6+ in the IETF.

Thank you,
Robert.

On Fri, Sep 6, 2019 at 3:08 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Folks,

We have explored many facets of SRv6 and SRv6, sometime passionately. I think that this exploration is a good thing. In the words of Tolkien, “All who wander are not lost.”

· For many operators, SRv6 is not deployable unless the problem of header length is addressed

· Many objections the uSID proposal remain unanswered

· SRv6+ offers an alternative solution

                                                                                   Ron

[email-masked]<mailto:[email-masked]>

---

From: Tarek Saad <[email-masked]>
Date: Fri, 6 Sep 2019 14:15:41 +0000

Robert,

If I understand your elaborate response, you hint to keeping MPLS as demux for services and native IPv4/IPv6 for transport.. which may not address bunch that religiously don’t want to enable MPLS.
OK, but how about traffic engineering (or source routing) in native IPv6 transport? Seems SRv6+ solves that there – and vanilla IPv4/v6 does not.

Regards,
Tarek

From: Robert Raszuk <[email-masked]>
Date: Friday, September 6, 2019 at 10:09 AM
To: Tarek Saad <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Please see my elaborated note on that ...

https://mailarchive.ietf.org/arch/msg/spring/qvRUp8SC2cWeIE5UhhU9aKGtpHM

Cheers,
R.

On Fri, Sep 6, 2019 at 4:03 PM Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Regards,
Tarek

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 6, 2019 at 9:33 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Dear Ron,

Thank you,
Robert.

• For many operators, SRv6 is not deployable unless the problem of header length is addressed

• Many objections the uSID proposal remain unanswered

• SRv6+ offers an alternative solution

                                                                                   Ron

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 16:09:00 +0200

Cheers,
R.

On Fri, Sep 6, 2019 at 4:03 PM Tarek Saad <[email-masked]> wrote:

> *From: *spring <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Friday, September 6, 2019 at 9:33 AM
> *To: *Ron Bonica <rbonica=[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [spring] Regaining Focus on SRv6 and SRv6+
>
>
>
> Dear Ron,
>
>
>
> * Many operators use SR-MPLS successfully and it has been both
> standardized and successfully deployed in the network with interoperable
> implementations
>
>
>
> * Extensions for additional applications like L3VPNs or L2VPNs will
> require another set of protocol and implementation changes.
>
>
>
> With all of the above I think it would be a serious mistake - at this
> point of time - to continue work on SRv6+ in the IETF.
>
>
>
> Thank you,
>
> Robert.
>
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2019 16:36:47 +0200

Hi Tarek,

> OK, but how about traffic engineering (or source routing) in native IPv6
transport?

SRv6 or for that matter SRv6+ works on the basis of swapping dst address in
the packets. So except segment endpoints all other routers in the domain
are basic IPv6 nodes. It is native IPv6 transport.

So I look at SR as a service enhancing transport not a transport itself. It
is IMO very very bad idea to think of SR as a new transport.

If you take that view of SR-MPLS_over_IP your SIDs are just 20 bits
strings. The bits sitting are SRH or CRH or just behind UDP header
of rfc7510 are the exact same bits.

So what technically seems to be trivial by various religious and
philosophical perspectives is being blown out of proportions with complete
loss of real technical details under the hood.

Cheers,
R.

On Fri, Sep 6, 2019 at 4:16 PM Tarek Saad <[email-masked]> wrote:

> Robert,
>
>
>
> If I understand your elaborate response, you hint to keeping MPLS as demux
> for services and native IPv4/IPv6 for transport.. which may not address
> bunch that religiously don’t want to enable MPLS.
>
> OK, but how about traffic engineering (or source routing) in native IPv6
> transport? Seems SRv6+ solves that there – and vanilla IPv4/v6 does not.
>
>
>
> Regards,
>
> Tarek
>
>
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Friday, September 6, 2019 at 10:09 AM
> *To: *Tarek Saad <[email-masked]>
> *Cc: *Ron Bonica <rbonica=[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> On Fri, Sep 6, 2019 at 4:03 PM Tarek Saad <tsaad.net@gmail..com
> <[email-masked]>> wrote:
>
> Hi Robert,
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Huzhibo <[email-masked]>
Date: Sat, 7 Sep 2019 04:57:34 +0000

Hi Robert:

Agree with you.
SRv6 is a completely different technology from SR MPLS. The biggest difference is that SRv6's Sid itself has routing capabilities. For example, it is aggregatable, it is programmable, it is globally unique over a larger scope. of. Sid's routing capabilities bring many benefits to the network. For example: network scalability, reliability, and simplified Overlay programming. So, I think that any optimization we do for SRv6 should not sacrifice Sid's own routing capabilities. If we just want to solve the interoperability problem between MPLS network and IP network, we can solve this problem in the field of SR MPLS.

Thank you,
Zhibo

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, September 06, 2019 9:33 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Dear Ron,

Thank you,
Robert.

                                                                                   Ron

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Sep 2019 16:04:19 +1000

> SRv6 is a completely different technology from SR MPLS. The biggest difference is that SRv6's Sid itself has routing capabilities. For example, it is aggregatable, it is programmable, it is globall…

Does any network need a SID space that is literally bigger than the
combination of both the current and and any possible future IPv6
unicast address space?

It's tempting to write up SR over IPv4, because IPv4 is currently a
far more commodity technology than both MPLS and IPv6, probably on
some metrics in the order of one or more magnitudes, well known, well
proven, well understood, would leverage existing IPv4 implementations
of which there are many, and would have only have 32 bit SIDs, so the
tunnelling overhead cost would be much lower than 128 bit SIDs as a
result of using IPv6 addresses for SIDs.

> On Fri, Sep 6, 2019 at 3:08 PM Ron Bonica <rbonica=[email-masked]> wrote:
>
> Folks,
>
>
>
> For many operators, SRv6 is not deployable unless the problem of header length is addressed
> Many objections the uSID proposal remain unanswered
> SRv6+ offers an alternative solution
>
>
>

---

From: Huzhibo <[email-masked]>
Date: Sat, 7 Sep 2019 08:08:13 +0000

Hi Mark:
I don't think it's a good idea to implement SR with IPv4.
1: Sid must be globally unique within a large range to achieve unobstructed routing capabilities, so we need at least 16 Bit to identify the node. It also needs to mark the device's Function, which also requires 12~16 Bit. So I think Sid needs at least 32 Bits. Considering that for aggregation, we need to make some planning for the node ID designation, which will waste some Bit. In addition, the implementation of the Function may require some additional parameters, so it is likely to exceed 32 Bit.
2: IPv4 does not have an extension header definition, which actually introduces some factors that are not compatible with normal IPv4.
3: The evolution of IPv4 to IPv6 is a big trend, and we must prepare for the future.

Thank you
Zhibo
-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Saturday, September 07, 2019 2:04 PM
To: Huzhibo <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

> SRv6 is a completely different technology from SR MPLS. The biggest difference is that SRv6's Sid itself has routing capabilities. For example, it is aggregatable, it is programmable, it is globall…

Does any network need a SID space that is literally bigger than the combination of both the current and and any possible future IPv6 unicast address space?

It's tempting to write up SR over IPv4, because IPv4 is currently a far more commodity technology than both MPLS and IPv6, probably on some metrics in the order of one or more magnitudes, well known, well proven, well understood, would leverage existing IPv4 implementations of which there are many, and would have only have 32 bit SIDs, so the tunnelling overhead cost would be much lower than 128 bit SIDs as a result of using IPv6 addresses for SIDs.

> standardized and successfully deployed in the network with 
> interoperable implementations
>
>
>
> For many operators, SRv6 is not deployable unless the problem of 
> header length is addressed Many objections the uSID proposal remain 
> unanswered

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Sep 2019 19:35:37 +1000

Hi,

On Sat, 7 Sep 2019 at 18:08, Huzhibo <[email-masked]> wrote:
> 1: Sid must be globally unique within a large range to achieve unobstructed routing capabilities,

20 bit MPLS label values are not globally unique. Why is this not a
problem for SR over MPLS?

I'm not sure what you mean by "global" because I've seen in passing
that "global" in SR means "global" to the local network. We in the
IPv6 world consider "global" to mean the global Internet - RFC 2374,
"An IPv6 Aggregatable Global Unicast Address Format".

If you mean actual global, then surely MPLS 20 bit labels would be
creating even more problems for SR?

 >so we need at least 16 Bit to identify the node.

In closed network you could have the entire IPv4 unicast address space
to identify nodes.

> It also needs to mark the device's Function, which also requires 12~16 Bit. So I think Sid needs at least 32 Bits. Considering that for aggregation, we need to make some planning for the node ID designation, which will waste some Bit. In addition, the implementation of the Function may require some additional parameters, so it is likely to exceed 32 Bit.

Again, SR over MPLS and 20 bits for SIDs?

More broadly, where is the analysis of the size of the SID space
required for SR functions that is independent of the underlying
carriage protocol identifiers?

How do we know how many underlying protocol identifier bits are too
small, too big or good enough?

MPLS 20 bit labels are sounding too small for SIDs from what you've
said above, where as IPv6 128 bit addresses are too big because of the
overhead they incur when using them as SIDs.

What is the minimum and maximum number of bits acceptable for a SID?

> 2: IPv4 does not have an extension header definition, which actually introduces some factors that are not compatible with normal IPv4.

That's not entirely correct. IPv4 has options. IPv6 EHs are a more
generalised version of them.

Tom Herbert is proposing IPv6 equivalent IPv4 EH's here:

"IPv4 Extension Headers and Flow Label"
https://tools.ietf.org/html/draft-herbert-ipv4-eh-01

> 3: The evolution of IPv4 to IPv6 is a big trend, and we must prepare for the future.

I think reusing IPv4 for SR is entirely valid if it provides enough
significant advantages over IPv6 over SR.

I do believe it that fundamentally it would be better to have a single
layer 3 protocol in a network, however give me a choice of EH
insertion or using IPv4 for SR, and I'll take SR over IPv4 every day
of the week.

The SR over IPv4 packets would have source addresses in them that
identify the device that performed the SR functions as IPv6-in-IPv4
encapsulation would be used.

EH insertion is entirely anonymous. If something breaks, you have no
idea of which device inserted the EH. That's a potential
troubleshooting nightmare, in particular if the packet transited a
number of ASes over the Internet, and you have to contact each one to
determine if they're inserting EHs or not. That's potentially weeks of
troubleshooting, and weeks of angry customers, and likely much lost
business.

If the future of network automation involves automated troubleshooting
and fault rectification, then I'd guess resolving faults involving
anonymous EH insertion would make automating troubleshooting quite
hard if not impossible in some scenarios. On the other hand, if
actions have attribution through identifying source addresses, I think
automating troubleshooting would be far easier. Troubleshooting is
much easier if you're able to start with already knowing who did what.

EH insertion sounds to me like it is breaking a fundamental principle
of trying to avoid sending something unexpected and that the receiver
will be confused by.

"Be conservative in what you send, ..."

Regards,
Mark.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 11:56:46 +0200

> It's tempting to write up SR over IPv4

You don't have to write anything ... it is already written and looks like
moving fwd :)

https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07

Thx,
R.

On Sat, Sep 7, 2019 at 8:05 AM Mark Smith <[email-masked]> wrote:

> > SRv6 is a completely different technology from SR MPLS. The biggest
> difference is that SRv6's Sid itself has routing capabilities. For example,
> it is aggregatable, it is programmable, it is globally unique over a larger
> scope. of. Sid's routing capabilities bring many benefits to the network.
> For example: network scalability, reliability, and simplified Overlay
> programming. So, I think that any optimization we do for SRv6 should not
> sacrifice Sid's own routing capabilities. If we just want to solve the
> interoperability problem between MPLS network and IP network, we can solve
> this problem in the field of SR MPLS.
> >
> >
>

---

From: Huzhibo <[email-masked]>
Date: Sat, 7 Sep 2019 10:46:24 +0000

1：If you mean actual global, then surely MPLS 20 bit labels would be
creating even more problems for SR?
————this is why we must using sr over bgp lsp for a inter as path，we must using two labels or more to express a e2e path。if you have a global id you need not do this。and then，I think sid should express two mean。where to go，what to do。go can reach everywhere，do can do anything。

sorry，I will reply the rest part when I can use google translate。

thank you
ZHIBO
--------------------------------------------------
胡志波 Hu Zhibo
Mobile: +86-18618192287<tel:+86-18618192287>
Email: [email-masked]<mailto:[email-masked]>
发件人：Mark Smith <[email-masked]>
收件人：Huzhibo <[email-masked]>
抄 送：Robert Raszuk <[email-masked]>;Ron Bonica <rbonica=[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>
时间：2019-09-07 17:36:11
主题Re: [spring] Regaining Focus on SRv6 and SRv6+

Hi,

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Sep 2019 21:13:57 +1000

On Sat, 7 Sep 2019 at 19:56, Robert Raszuk <[email-masked]> wrote:
> You don't have to write anything ... it is already written and looks like moving fwd :)
>

That's tunnelling MPLS over SR over IPv4. I'm talking about native SR
over IPv4 e.g. "SRv4".

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 13:32:03 +0200

/* Adjusting the subject to reflect the topic */

Ok ... I looked at the new wave of mails in wrong order :)

I like this proposal:

And have absolutely nothing against progressing it further - it looks on
the surface to be more efficient then sr-mpls over IP - but how many bits
are we saving needs to be calculated to state if cost of introducing new
encoding justifies the additional control plane, protocol and platform
efforts

In fact if we would get to the consensus of using SRH with SID & BSID to be
of fixed 20 bits it can reuse a lot of mechanism build for sr-mpls in any
commercial router.

 It is just a bit amazing that insertion of EHs into IPv4 would be less
problematic that in the case of IPv6 :) Maybe due to allowed fragmentation.

As to the host dropping packets due to unknown protocol - let's observe
that SR domain would clean such EH before passing packets further.

Many thx,
R.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 7 Sep 2019 12:48:30 +0100

Robert,

cc: line trimmed.

I believe this proposal is out of scope for the ipv6 working group.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 14:16:53 +0200

I agree. RTWG could be IMHO #1 option.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 7 Sep 2019 14:32:51 +0000

Hi,

I agree on Huzhibo on his observation on SRv6 SIDs and their benefit for scaling, among other aspects he mentioned.

CRH based solution, on the other hand, inherits all the characteristics of a “mapping table” based solution, including scaling. Here is a partial list:

MPLS over UDP Redone:

Many have pointed out that CRH does all this to achieve what can be achieved using already defined, adopted, and deployed specification. Like Dirk mentioned: "No need to re-invent MPLS over UDP using a different encapsulation inappropriately named "SRv6+".

Please see:

Comments from Dirk: https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM

Many emails from Robert, including https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo

Need for new Routing Extension Header for SR:

Not to mention the need for defining a new routing extension header for Segment Routing. Where 6man working group has defined SRH: the work started in March 2014. The 6man WG spent a lot of efforts (1000s of email, dozens of document revision, dozens of IETF presentations, control plan work that is adopted by multiple workgroups, etc.). Not to mention - Implementation on 12 hardware platforms, including Merchant Silicon. Multiple providers have deployed the SRv6 network programming solution and its SRH encapsulation with line-rate performance carrying a significant amount of commercial traffic. Several independent public interoperability reports documenting successful interoperability of implementation from multiple vendors exist. In this regard, please also see Like Dan's email: https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4.

Need for Control Plane Extensions for all protocols:

All the routing protocols require extensions to carry the mapping table.

Changes in BGP, ISIS, OSPF, BGP-LS, PCE, etc. and all control plan protocols are required. Some extension has been already proposed and were presented at IETF105.

Not to mention new extensions for manageability.

OAM:

We have already established on this mailing tread that MPLS like OAM tool kit is also needed for debuggability.

ICMP error processing does not work for CRH.

Incomplete Solution/ TI-LFA:

The CRH solution is incomplete. E.g., it does not talk about TI-LFA and how protection works with O(50 msec) performance in this solution.

Scaling:

Overall, CRH based solution does not scale in a large-scale network.

  *   In a large-scale multi-domain interconnect, a seamless MPLS like solution is needed for the CRH to work. Specifically, the CRH suffers from the large label stack and protection/ convergence challenges.
  *   CRH based solution will also impact the size of the FIB. It requires a SID to IPv6 address mapping table (not to mention lookup). This requires more memory and causes FIB scaling issues. Not to mention, the code complexity in an IP implementation.
  *   Similar to FIB, RIB will need to introduce a new route table/entry type for ID mapping in case of CRH. That requires more memory and causes RIB scaling issues. Not to mention, the code complexity in an IP implementation.
  *   Etc.

Performance:

I also agree with Cheng Li https://mailarchive.ietf.org/arch/msg/spring/XK0F40oEuZv-3ule-X5685d_6Mc, “I don’t think the performance of processing TLVs in DOH will be good, seems very complicated.”

I agree and to add the need for processing multiple extension headers.

Ecosystem:

CRH has no ecosystem, no public proof of concept on hardware with linerate performance. SRv6 and SRH based implementation has a large ecosystem. The SRv6 ecosystem includes several open-source implementations: (Linux: Kernel and srext module, FD.io<http://fd.io/>: VPP, Apps: Snort, iptables and nftables, tcpdump and Wireshark). All this took the industry over 5 years to get to that level of maturity and adoption.

Summary:

In summary, nothing adds up; it makes no sense.

It will take more than hijacking an email thread for the authors of CRH to justify why 6man should define a new routing extension header for Segment Routing.

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Huzhibo <[email-masked]>
Date: Saturday, September 7, 2019 at 12:58 AM
To: Robert Raszuk <[email-masked]>, Ron Bonica <rbonica=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Regaining Focus on SRv6 and SRv6+

Hi Robert:

Agree with you.

Thank you,
Zhibo

Dear Ron,

Thank you,
Robert.

                                                                                   Ron

---

From: Lee Howard <[email-masked]>
Date: Sat, 7 Sep 2019 11:01:52 -0400

IPv4 is dying. Let it go gracefully.

I'm completely opposed to any extensions to the IPv4 specification. By 
the time the feature set is code complpete, QA'd, and ready for general 
release, 80% of the world will be using IPv6.

Specific to this case, I have a very hard time understanding the 
business/engineering case where it would be optimal to implement these 
extensions rather than deploy IPv6, where they already exist.

Lee

On 9/7/19 7:32 AM, Robert Raszuk wrote:
> And have absolutely nothing against progressing it further - it looks 
> on the surface to be more efficient then sr-mpls over IP - but how 
> many bits are we saving needs to be calculated to state if cost of 
> introducing new encoding justifies the additional control plane, 
> protocol and platform efforts
>
> In fact if we would get to the consensus of using SRH with SID & BSID 
> to be of fixed 20 bits it can reuse a lot of mechanism build for 
> sr-mpls in any commercial router.
>
>  It is just a bit amazing that insertion of EHs into IPv4 would be 
> less problematic that in the case of IPv6 :) Maybe due to allowed 
> fragmentation.
>
> As to the host dropping packets due to unknown protocol - let's 
> observe that SR domain would clean such EH before passing packets 
> further.
>
> Many thx,
> R.
>
>
>
> On Sat, Sep 7, 2019 at 1:14 PM Mark Smith <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Sat, 7 Sep 2019 at 19:56, Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >

---

From: Xiejingrong <[email-masked]>
Date: Sat, 7 Sep 2019 15:39:29 +0000

+1.
I didn't see the possibility of handling packets with EH in fast path without the indication of SRv6 SID in the preceding FIB lookup. This is uniquely introduced in SRH and SRv6 networking programming draft.
The only 'problem' rising on the list, the V6 TI LFA,  has been uniquely considered in the SRv6 for long, and has the encap scheme at the bottom line, if the EH insertion need some more tech discussion.
I didn't see any advantage or benefit of another v6 encapsulation for SR.

Thanks
Jingrong
From:Zafar Ali (zali) <[email-masked]>
To:Huzhibo <[email-masked]>;Robert Raszuk <[email-masked]>;Ron Bonica <rbonica=[email-masked]>
Cc:spring <[email-masked]>;6man <[email-masked]>
Date:2019-09-07 22:33:40
SubjectRe: [spring] Regaining Focus on SRv6 and SRv6+

Hi,

MPLS over UDP Redone:

Please see:

OAM:

Scaling:

Performance:

Ecosystem:

Summary:

Thanks

Regards … Zafar

Hi Robert:

Agree with you.

Thank you,
Zhibo

Dear Ron,

Thank you,
Robert.

                                                                                   Ron

---

From: Tom Herbert <[email-masked]>
Date: Sat, 7 Sep 2019 09:13:26 -0700

> IPv4 is dying. Let it go gracefully.
Hi Lee,

IPv4 has been "dying" for thirty years. I'd call that a slow death! :-)

> I'm completely opposed to any extensions to the IPv4 specification. By the time the feature set is code complpete, QA'd, and ready for general release, 80% of the world will be using IPv6.
>
> Specific to this case, I have a very hard time understanding the business/engineering case where it would be optimal to implement these extensions rather than deploy IPv6, where they already exist.

The fact is that there are still many deployments of IPv4 and they
need to be maintained. We can't force users to switch to IPv6 in any
timeframe of our choosing and neither is it responsible to abandon
them. Regardless of what IETF says, vendors will still support their
customers that choose to stay on IPv4. A good example of necessary
support is IOAM. IOAM is useful, but not just for IPv6 it would also
be useful in an IPv4 network. So the IPPM group, which is specifying
IOAM, is working on a way to add IOAM information into IPv4.

The idea of IOAM is that intermediate nodes in a path add their
information to packets in flight, and other nodes consume the
information. Sounds familiar? This sort of thing is exactly what
Hop-by-Hop Options are designed to do. But HBH options are currently
unavailable in IPv4 and there really is no defined and robust
mechanism in IPv4 that provides the functionality. IPv4 options are
limited and long considered dead, proposals to put data inside UDP
encapsulations that intermediate nodes consume or set are problematic.
The one technique that *might* work is a new GRE Ethertype that does
nothing more than carry an IOAM header and a next header-- something
like IP-GRE-IOAM-IP-... Effectively, this is adding extension headers
to GRE that are identified by an EtherType as opposed to an IP
protocol number. IMO, this is an abysmal hack! But, it's conceivable
it could be made to work with enough effort. That also raises the
spectre of another problem. If the GRE hack works for IPv4 then it
works IPv6 as well, so a properly lazy protocol developer may use the
GRE method in IPv6 as well to save development and support costs. So
even though there is a right solution for IPv6, the wrong solution
might be used for expediency. In other words, this could be another
case of people doing things in IPv6 like they did in IPv4 instead of
leveraging the capabilities of IPv6-- thereby undermining the IPv6
effort.

So the idea of IPv4 extension headers is to bring something useful
from IPv6 into IPv4 for once. In this way IOAM, for instance, can use
the same and correct solution across both protocols. Also, since the
protocol number space is the same for IPv4 and IPv6, support for
extension headers in IPv4 does not change the core IPv4 specification,
it is enabling use of new IP protocol numbers (something pointed out
by Brian Trammel). It should also be noted that IPv4 already supports
AH and ESP so there is already precedent for IPv4 carrying extension
headers.

Tom

> And have absolutely nothing against progressing it further - it looks on the surface to be more efficient then sr-mpls over IP - but how many bits are we saving needs to be calculated to state if cost of introducing new encoding justifies the additional control plane, protocol and platform efforts
>
> In fact if we would get to the consensus of using SRH with SID & BSID to be of fixed 20 bits it can reuse a lot of mechanism build for sr-mpls in any commercial router.
>
>  It is just a bit amazing that insertion of EHs into IPv4 would be less problematic that in the case of IPv6 :) Maybe due to allowed fragmentation.
>
> As to the host dropping packets due to unknown protocol - let's observe that SR domain would clean such EH before passing packets further.
>
> Many thx,
> R.
>
>
>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 7 Sep 2019 09:41:03 -0700

> Given these three facts, I think that it would be a mistake to discontinue work on SRv6+.
+ 1

I'd suggest a fourth fact. The packet format of SRv6+ is much simpler
than SRv6 and the protocol works better with existing mechanisms and
protocols of IPv6 like Destination and HBH options, as well as AH. It
doesn't depend on extension header insertion and there's no need to
have multiple routing headers in the same packet.

Tom

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Sep 2019 12:58:56 -0400

Can someone give an example or use case of when SR insertion would be required by an intermediary node in an SRv6 domain?

Sometimes when dealing with complex subjects and discussions for me it makes sense to start with basics and work your way back up to reasons why decisions were made for a protocol or specifications.

So the main business justification and driver in the advent for SPRING WG and SR-MPLS for Service Providers is to be able to Traffic engineer and color L3 vpn flows natively without complexity that exists today with adding separate loopback for ibgp FEC destinations to provide per-vrf TE feature.  There maybe others but I believe that has always been the major pitfall with mpls.

So now with Spring WG SR-MPLS provides label stacking source route capabilities so L3 VPN’s can be naively TE’ed via FRR or Ti LFA 50ms fast reroute capability that was missing with MPLS.

Fast forwarding to SRv6 and what that provides via SRH IPv6 destination swapping in source routing native traffic engineering not only for new green field Service Provider MPLS core’s but for the internet as well as enterprises with now being able to extend the SRv6 domain ubiquitously to any part of the network from Data center to Access now having traffic engineering capabilities which is very powerful and is why SRv6 should be and is on the standards and not Experimental track.  SRv6 also with the inherent traffic engineering capabilities for any node on the network that can be part of the SRv6 domain really make IPv6 a must and more attractive and a bigger push I believe industry wide for all enterprises worldwide to migrate quickly to IPv6 so they can reap the benefits of SRv6.

Back to the SR insertion just thinking outside the box but from a use case standpoint where SR insertion would be beneficial an thinking maybe for TE tunnel stitching done LDP over TE for end to end targeted LDP session protection now with that same tunnel stitching using SRv6 if you had to stitch SRv6 tunnels together within an SR domain that would require SR insertion as any egress PE node along the path doing a USP or PSP would now have to be capable of performing SR insertion.

There maybe other critical use cases and that is why the Spring WG has the stance of SR insertion being mandatory.

I think when the SRv6 programming RFCs were written that violated the 6man WG RFC 8200 with EH only being allowed by the source node to insert EH and no other node when Spring WG decided to make this a requirement for SRv6 functionality they should have asked for 6man WG consensus approval and at that time RFC 8200 could have been updated to allow this one exception for EH for SR insertion by and node along the path.  Unfortunately this was not done that way from the beginning and now we are trying to fix what should have been fixed from the beginning.

Regards,

Gyan S. Mishra
IT Network Engineering & Technology 
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

Sent from my iPhone

> On Sep 7, 2019, at 11:39 AM, Xiejingrong <[email-masked]> wrote:
> 
> +1.
> In a large-scale multi-domain interconnect, a seamless MPLS like solution is needed for the CRH to work. Specifically, the CRH suffers from the large label stack and protection/ convergence challenges.  
> CRH based solution will also impact the size of the FIB. It requires a SID to IPv6 address mapping table (not to mention lookup). This requires more memory and causes FIB scaling issues. Not to mention, the code complexity in an IP implementation. 
> Similar to FIB, RIB will need to introduce a new route table/entry type for ID mapping in case of CRH. That requires more memory and causes RIB scaling issues. Not to mention, the code complexity in an IP implementation. 
> Etc.
>  
> Performance:
>  
> CRH has no ecosystem, no public proof of concept on hardware with linerate performance. SRv6 and SRH based implementation has a large ecosystem. The SRv6 ecosystem includes several open-source implementations: (Linux: Kernel and srext module, FD.io: VPP, Apps: Snort, iptables and nftables, tcpdump and Wireshark). All this took the industry over 5 years to get to that level of maturity and adoption. 
>  
> Summary:
>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 7 Sep 2019 10:23:10 -0700

> On Sep 7, 2019, at 4:48 AM, Nick Hilliard <[email-masked]> wrote:
> 

I agree.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Sat, 7 Sep 2019 10:27:06 -0700

Tom, Lee,

Please take this discussion elsewhere.  It’s out of scope for the IPv6 list.

Bob

> On Sep 7, 2019, at 9:13 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 19:54:08 +0200

> It doesn't depend on extension header insertion

Nothing depends on extension header insertion ... SRH insertion is an
optional optimization.

> and there's no need to have multiple routing headers in the same packet.

Really ?

If I am doing SRv6+ in my network for TE and want to to do TI-LFA how would
I not end up with 3 IPv6 fixed headers and two Dest Option EHs and two CRH
EHs in the packet under protection ?

But this is just tip of the ugliness iceberg ...

All required extensions to protocols developed in to name just a few
already proposed by SRv6+ authors: IDR, LSR, BESS and 6MAN WG to support
the new mapping (which is other then nomenclature close to SR-MPLS mapping)
will require real development resources.

OAM in spite of few claims from Ron that "just works" is not addressed and
does require even more extensions.

Then last I will not be able to use SRv6+ for my deployment needs in the
global IPv6 overlay I am running simply that within my overlay I do not
plan to run any control plane. Underlay basic reachability provided by
third parties is all I need to construct optimal paths. So any protocol
which requires new signalling to distribute mapping is non starter.

At the end we should learn from others ... (hint SDWANs) and avoid mistakes
of the past (hint: LDP).

Many thx,
R.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 7 Sep 2019 14:19:26 -0700

Robert,

You've chosen to selectively comment on only parts of what I wrote,
not the main thesis which is that SRV6 packet format is more complex
than SRV6+.

The most obvious difference, besides SID size, is that SRV6 contains
TLVs and SRV6+ doesn't. I don't believe that this was ever needed, HBH
and destination already exist in RC8200 and could have been used as
they will be in SRV6+. Similarly, AH could have been used instead of
defining SR specific HMAC. Furthermore, several implementations of
SRV6 are listed in draft-ietf-6man-segment-routing-header-22; all
except one have the words "no TLV processing". The exception is Linux,
which doesn't not implement SR TLVs per the standard and wouldn't
interoperate with an implementation that is conformant (I have looked
at the Linux code and in fact have suggested a fix). So the claim that
SRV6 is mature and deployed is suspect considering there doesn't seem
to be proper support for TLVs which is a major part of the protocol.

Based on this analysis, I believe my statement that SRV6 format is
more complex than SRV6+ is factual. It's my opinion that SRV6,
particularly because of TLVs, is overly complex.

Tom

On Sat, Sep 7, 2019 at 10:54 AM Robert Raszuk <[email-masked]> wrote:
> Nothing depends on extension header insertion ... SRH insertion is an optional optimization.
>
> If I am doing SRv6+ in my network for TE and want to to do TI-LFA how would I not end up with 3 IPv6 fixed headers and two Dest Option EHs and two CRH EHs in the packet under protection ?
>
> All required extensions to protocols developed in to name just a few already proposed by SRv6+ authors: IDR, LSR, BESS and 6MAN WG to support the new mapping (which is other then nomenclature close to SR-MPLS mapping) will require real development resources.
>
> OAM in spite of few claims from Ron that "just works" is not addressed and does require even more extensions.
>
> Then last I will not be able to use SRv6+ for my deployment needs in the global IPv6 overlay I am running simply that within my overlay I do not plan to run any control plane. Underlay basic reachability provided by third parties is all I need to construct optimal paths. So any protocol which requires new signalling to distribute mapping is non starter.
>
> At the end we should learn from others ... (hint SDWANs) and avoid mistakes of the past (hint: LDP).
>
> Many thx,
> R.
>
>
>
>
>
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 7 Sep 2019 21:52:16 +0000

Robert,

Tom is correct. In SRv6+, there is never any need for one packet to contain two routing headers. SRv6+ relies on prepending, in all cases, including TI-LFA.

Because the CRH is short, this works just fine.

I don't understand your comment about two destination headers. You might want to rethink that.

                                                                     Ron

From: Robert Raszuk <[email-masked]>
Sent: Saturday, September 7, 2019 1:54 PM
To: Tom Herbert <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Really ?

At the end we should learn from others .... (hint SDWANs) and avoid mistakes of the past (hint: LDP).

Many thx,
R.

On Sat, Sep 7, 2019 at 6:41 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica
+ 1

Tom

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!XdaMALbhFo4TNFver8v6Zwv5qIQ2mxR2PiQiwPTEJ31TLT5m9oxN8yritKT7Pxrp$>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!XdaMALbhFo4TNFver8v6Zwv5qIQ2mxR2PiQiwPTEJ31TLT5m9oxN8yritAkWNZwq$>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 23:54:01 +0200

Dear Tom,

> TLVs and SRV6+ doesn't.

I was hoping you know that this is not true at all so I skipped commenting
on that aspect.

Folks promoting SRv6+ are smart and they know how to sell stuff which looks
simple and innocent on the surface like concept of CRH with just fixed
label/sid list while hide all complexity under the deep cover and only show
little corners of it here and there hoping no one will connect the dots.

So what you call "complexity" has been just moved from routing header to
destination options header and will be defined in number of different
documents piece by piece.

Just please take a look at the proposal describing per path service
instructions encoding. It does have Type Length and Value so to me looks
like TLV structure going into IPv6 header.

4 <https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06#section-4>.
The PPSI Option

   The PPSI Option contains the following fields:

   o  Option Type: 8-bit selector.  PPSI option.  Value TBD by IANA.
      (Suggested value: 144).  See Note below.

   o  Opt Data Len - 8-bit unsigned integer.  Length of the option, in
      octets, excluding the Option Type and Option Length fields.  This
      field MUST be set to 4.
   o  PPSI identifier - (32-bit selector).  Identifies a PPSI.

REF: https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06

That TLV value comes from Destination Options and Hop-by-Hop Options
registry which effectively is already full. It is 8 bit register with 3
first bits taken for identification so remaining are 5 bits. Now from that
remaining 5 bits (32 values) only 5 values are left for allocation.

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml

So they noticed that and just at the last rev of the VPN extenstion renamed
what originally was called *VPN Context Information Option* to PPSI as it
was very obvious that with 5 remaining values there is no room for new
types for other service instructions.

Now the plan is to nest under PPSI TLV in a sub-TLV format any potential
new service instructions.

Now I will leave it as the exercise for the reader to judge which approach
is more complex.

Is it to put the cards on the table and play open by clearly defining SRv6
SRH with SIDs and functions or to play such poker with IETF WGs ?

Thx,
R.

On Sat, Sep 7, 2019 at 11:19 PM Tom Herbert <[email-masked]> wrote:

> > If I am doing SRv6+ in my network for TE and want to to do TI-LFA how
> would I not end up with 3 IPv6 fixed headers and two Dest Option EHs and
> two CRH EHs in the packet under protection ?
> >
> >> > We have explored many facets of SRv6 and SRv6, sometime passionately.
> I think that this exploration is a good thing. In the words of Tolkien,
> “All who wander are not lost.”
> >> >
> >> >
> >> >

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 8 Sep 2019 00:05:39 +0200

Ron,

> SRv6+ relies on prepending

Interesting ... can you elaborate how you will do TI-LFA with SRv6+ ? If
you have slides showing packet format when TI-LFA is performed in the
middle of SRv6+ domain please just kindly fell free to share a pointer to
it.

> I don’t understand your comment about two destination headers

And I do not understand what you may not understand. Is your "prepending"
the same what some may consider "insertion" then ?

Thx,
R.

On Sat, Sep 7, 2019 at 11:52 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Robert,
>
>
>
> Tom is correct. In SRv6+, there is never any need for one packet to
> contain two routing headers. SRv6+ relies on prepending, in all cases,
> including TI-LFA.
>
>
>
> I don’t understand your comment about two destination headers. You might
> want to rethink that.
>
>
>
>                                                                      Ron
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Saturday, September 7, 2019 1:54 PM
> *To:* Tom Herbert <[email-masked]>
> *Cc:* Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [spring] Regaining Focus on SRv6 and SRv6+
>
>
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!XdaMALbhFo4TNFver8v6Zwv5qIQ2mxR2PiQiwPTEJ31TLT5m9oxN8yritKT7Pxrp$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!XdaMALbhFo4TNFver8v6Zwv5qIQ2mxR2PiQiwPTEJ31TLT5m9oxN8yritAkWNZwq$>
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 7 Sep 2019 22:31:11 +0000

Robert,

You may need to rethink your argument. (That is, except for the part where you said that I was smart!)

The SRv6+ PPSI does replaces something int SRv6. But it does not replace the SRH's tags, flags or TLVs. It replaces the low order bits in the last SID. More specially, it identifies a function to be executed by SR egress node. It replaces functions like END.DT4, END.DT6, END.DX4, END.DX6, etc.)

As Tom says,  the CRH is much simpler to parse that the SRH. It contains only five fields, four of which are mandated by RFC 8200. (The other is the SID list.)

Unlike TLVs, the PPSI is fixed length (32 bits). It identifies an instruction to be executed on the SR egress node. Carries the same information as an MPLS service label or the low order bits of the final SID in as SRv6 SID list.

What you say about the IPv6 Option registry being nearly full may be a bit of an exaggeration. This is because the CHG bit is meaningful of hop-by-hop options, but is totally meaningless for Destination options. So, for destination options, the IPv6 option registry is actually 6 bits wide.

                                                                        Ron

Sent: Saturday, September 7, 2019 5:54 PM

Dear Tom,

> The most obvious difference, besides SID size, is that SRV6 contains

I was hoping you know that this is not true at all so I skipped commenting on that aspect.

Folks promoting SRv6+ are smart and they know how to sell stuff which looks simple and innocent on the surface like concept of CRH with just fixed label/sid list while hide all complexity under the deep cover and only show little corners of it here and there hoping no one will connect the dots.

So what you call "complexity" has been just moved from routing header to destination options header and will be defined in number of different documents piece by piece.

Just please take a look at the proposal describing per path service instructions encoding. It does have Type Length and Value so to me looks like TLV structure going into IPv6 header.

4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06*section-4__;Iw!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9VJXmGie$>.  The PPSI Option

      field MUST be set to 4.

REF: https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9dfFF-MI$>

That TLV value comes from Destination Options and Hop-by-Hop Options registry which effectively is already full. It is 8 bit register with 3 first bits taken for identification so remaining are 5 bits. Now from that remaining 5 bits (32 values) only 5 values are left for allocation..

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9V9FULVl$>

So they noticed that and just at the last rev of the VPN extenstion renamed what originally was called VPN Context Information Option to PPSI as it was very obvious that with 5 remaining values there is no room for new types for other service instructions.

Now the plan is to nest under PPSI TLV in a sub-TLV format any potential new service instructions.

Now I will leave it as the exercise for the reader to judge which approach is more complex.

Is it to put the cards on the table and play open by clearly defining SRv6 SRH with SIDs and functions or to play such poker with IETF WGs ?

Thx,
R.

On Sat, Sep 7, 2019 at 11:19 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Tom

On Sat, Sep 7, 2019 at 10:54 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9RFWajEZ$>
>> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9YjolzkW$>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 7 Sep 2019 22:40:50 +0000

Robert,

I don't have slides, but it should be pretty easy to describe. Rather than inserting a second Routing header between the IPv6 header and the existing router, Arv6+ the following:

  *   Update SL and the IPv6 destination address, if required
  *   Prepend an IPv6 header with its own Routing header

Also, I don't understand your comment about a packet with two SRv6+ Destination Options headers. I can't think of a situation where that ever happens.

                                                                                            Ron

From: Robert Raszuk <[email-masked]>
Sent: Saturday, September 7, 2019 6:06 PM
To: Ron Bonica <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Ron,

> SRv6+ relies on prepending

Interesting ... can you elaborate how you will do TI-LFA with SRv6+ ? If you have slides showing packet format when TI-LFA is performed in the middle of SRv6+ domain please just kindly fell free to share a pointer to it.

> I don't understand your comment about two destination headers

And I do not understand what you may not understand. Is your "prepending" the same what some may consider "insertion" then ?

Thx,
R.

On Sat, Sep 7, 2019 at 11:52 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                     Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, September 7, 2019 1:54 PM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Really ?

Many thx,
R.

+ 1

Tom

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!SOWprbKRa0W6SRURXfpr9dxa4D5a-kglw9RZB_d_5dbCFgTF_OFbf2d0jVaRm6Jj$>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 8 Sep 2019 00:54:52 +0200

Hey Ron,

You may need to rethink your argument. (That is, except for the part where
> you said that I was smart!)
>

;-)

> The SRv6+ PPSI does replaces something int SRv6. But it does not replace
> the SRH’s tags, flags or TLVs. It replaces the low order bits in the last
> SID. More specially, it identifies a function to be executed by SR egress
> node. It replaces functions like END.DT4, END.DT6, END.DX4, END.DX6, etc.)
>
>
>
> As Tom says,  the CRH is much simpler to parse that the SRH. It contains
> only five fields, four of which are mandated by RFC 8200. (The other is the
> SID list.)
>

The point is that CRH alone is not enough to make any jugement about SRv6+
complexity.

> Unlike TLVs, the PPSI is fixed length (32 bits). It identifies an
> instruction to be executed on the SR egress node. Carries the same
> information as an MPLS service label or the low order bits of the final SID
> in as SRv6 SID list.
>

When you can provide pointer to SFC document describing how it would work
with SRv6+ similar to
https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-00 which
does require many elements from SRH we will resume the discussion.

What you say about the IPv6 Option registry being nearly full may be a bit
> of an exaggeration. This is because the CHG bit is meaningful of hop-by-hop
> options, but is totally meaningless for Destination options. So, for
> destination options, the IPv6 option registry is actually 6 bits wide.
>

Are you proposing to split this registry into two ? to get 32 more values
for your destination options types ? And then what ?

Best,
R.

PS from your last mail ...

> Prepend an IPv6 header with its own Routing header

So this is exactly what I was concluding. The packet under TI-LFA
protection in SRv6+ will end up with three IPv6 fixed headers, min two CRH
headers, and anywhere from zero to two (depending on the functions
required) Dest Options header before Routing Header.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 7 Sep 2019 19:01:10 -0400

With regard to service chaining, with either SRv6 or SRv6+, the 
interoperable mechanism for service function chaining is to carry NSH. 
Carrying the content of the NSH header in SRv6 SRH PDUs, while 
technically doable, is complexity that is not needed.

Yours,
Joel

On 9/7/2019 6:54 PM, Robert Raszuk wrote:
>     ____
>     The SRv6+ PPSI does replaces something int SRv6. But it does not
>     replace the SRH’s tags, flags or TLVs. It replaces the low order
>     bits in the last SID. More specially, it identifies a function to be
>     executed by SR egress node. It replaces functions like END.DT4,
>     END.DT6, END.DX4, END.DX6, etc.)____
> 
>     __ __
> 
>     As Tom says,  the CRH is much simpler to parse that the SRH. It
>     contains only five fields, four of which are mandated by RFC 8200.
>     (The other is the SID list.)
> 
> 
> 
> The point is that CRH alone is not enough to make any jugement about 
> SRv6+ complexity.
> 
> 
>     ____
> 
>     information as an MPLS service label or the low order bits of the
>     final SID in as SRv6 SID list.
> 
> 
> When you can provide pointer to SFC document describing how it would 
> work with SRv6+ similar to 
>     What you say about the IPv6 Option registry being nearly full may be
>     a bit of an exaggeration. This is because the CHG bit is meaningful
>     of hop-by-hop options, but is totally meaningless for Destination
>     options. So, for destination options, the IPv6 option registry is
>     actually 6 bits wide.
> 
> 
> Are you proposing to split this registry into two ? to get 32 more 
> values for your destination options types ? And then what ?
> 
> Best,
> R.
> 
> protection in SRv6+ will end up with three IPv6 fixed headers, min two 
> CRH headers, and anywhere from zero to two (depending on the functions

---

From: Xiejingrong <[email-masked]>
Date: Sun, 8 Sep 2019 00:54:43 +0000

the CHG bit is meaningful of hop-by-hop options, but is totally meaningless for Destination options.

CHG is meaningful for both.
Also I think the use of unique last-5bits of option is just a week recommendation.  There is still enough space of 8bit if needed. It's not necessary to change interpretation of CHG.

Thanks
Jingrong
From:Ron Bonica <rbonica=[email-masked]>
To:Robert Raszuk <[email-masked]>;Tom Herbert <[email-masked]>
Cc:spring <[email-masked]>;6man <[email-masked]>
Date:2019-09-08 06:32:00
SubjectRE: [spring] Regaining Focus on SRv6 and SRv6+

Robert,

The SRv6+ PPSI does replaces something int SRv6. But it does not replace the SRH’s tags, flags or TLVs. It replaces the low order bits in the last SID. More specially, it identifies a function to be executed by SR egress node. It replaces functions like END.DT4, END.DT6, END.DX4, END.DX6, etc.)

                                                                        Ron

Dear Tom,

      field MUST be set to 4.

https://www..iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9V9FULVl$>

Thx,
R.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 Sep 2019 13:07:46 +0200

> observe that SR domain would clean such EH before passing packets 

When I learned IPv4 existed it was already very late to suggest anything 
to it.  I learned that many things were designed into it at its origin, 
but few things got actually deployed.

The example of loose source route, and strict source route, was given as 
an example that people tried to do but it never worked at scale.  So it 
got filtered and disappeared.

I think now that any new such thing added beyond the simplest things in 
IP, like just destination and source, will be discarded later.

(even for IPv6, I struggle with Traffic Class vs Flow Label: where to 
put an emergency flag?  were it there to be just one field instead of 
two, my choice would be much easier.  The end user of this emergency 
flag asks this for 2 years now, and I still ponder over it, telling him 
to not worry and just send twice the emergency message.)

Alex

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 9 Sep 2019 14:22:31 +0000

Agree with Jingrong.

Suddenly, I am thinking about a question:
Does SRv6+ bring new value to the networking beyond SRv6?  What's the purpose? To compress the Routing header? Then we have many options to do that. Why a new RH with brand new routing scheme?

Let's do the standard works together once again, another 5 years? No!  I think we should solve the problem based on the existing solution, instead of  creating a new mechanism.

>From the aspect of information theory, what's the new info added by SRv6+? What is that for? These are the questions should be answered.

If we would like to provide an efficient encoding format, that is all right. Please don't compare the length of RH only, since the length of DOH TLVs should be counted as well.
BTW, we already have C-SID, uSID and I believe there may be more options.

I don't think moving info from SRv6 SIDs to DOH TLVs is a good choice. Bad Performance of processing TLVs in DOH, and terrible scalability since only 5 reserved types, or the 37 types when the CHG bit is reused. Also, how many bytes can be reduced by CRH. If you compare with C-SID, you will be surprised that C-SID provides a more efficient encoding mechanism for SRv6 than CRH.

The first DOH works for the destinations encoded in RH does not mean the info CAN NOT be carried in RH for per-segment processing.

How about let's focus on how to reduce the overhead of SRv6, that will be very helpful.

Best Regards,
Cheng

From: spring [mailto:[email-masked]] On Behalf Of Xiejingrong
Sent: Sunday, September 08, 2019 8:55 AM
To: Ron Bonica <rbonica=[email-masked]>; Robert Raszuk <[email-masked]>; Tom Herbert <[email-masked]>
Cc: spring <[email-masked]>; 6man <[email-masked]>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Thanks
Jingrong
From:Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
To:Robert Raszuk <[email-masked]<mailto:[email-masked]>>;Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc:spring <[email-masked]<mailto:[email-masked]>>;6man <[email-masked]<mailto:[email-masked]>>
Date:2019-09-08 06:32:00
SubjectRE: [spring] Regaining Focus on SRv6 and SRv6+

Robert,

                                                                        Ron

Dear Tom,

      field MUST be set to 4.

https://www...iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9V9FULVl$>

Thx,
R.

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2019 16:34:05 +0200

Hi Cheng,

Very spot on and accurate comments !

I could only add one additional and final point. Some people call SRv6+ an
"innovation" and any honest comments about are immediately turned into an
attempt to either stop or to make very difficult " to innovate in IETF.

If taking shipping for years mapping based technology of SR-MPLS, mangling
bits around, wrapping it into new control plane extensions, splitting SIDs
from functions into two different  extension headers to claim that CRH is
now so slim etc ... is call  technology innovation - then IETF should
revisit policy of taking any proposal into its formal process.

Kind regards,
Robert.

On Mon, Sep 9, 2019 at 4:23 PM Chengli (Cheng Li) <[email-masked]>
wrote:

> Does SRv6+ bring new value to the networking beyond SRv6?  What’s the
> purpose? To compress the Routing header? Then we have many options to do
> that. Why a new RH with brand new routing scheme?
>
>
>
> Let's do the standard works together once again, another 5 years? No!  I
> think we should solve the problem based on the existing solution, instead
> of  creating a new mechanism.
>
>
>
> From the aspect of information theory, what’s the new info added by SRv6+?
> What is that for? These are the questions should be answered.
>
>
>
> If we would like to provide an efficient encoding format, that is all
> right. Please don’t compare the length of RH only, since the length of DOH
> TLVs should be counted as well.
>
> I don’t think moving info from SRv6 SIDs to DOH TLVs is a good choice. Bad
> Performance of processing TLVs in DOH, and terrible scalability since only
> 5 reserved types, or the 37 types when the CHG bit is reused. Also, how
> many bytes can be reduced by CRH. If you compare with C-SID, you will be
> surprised that C-SID provides a more efficient encoding mechanism for SRv6
> than CRH.
>
>
>
> The first DOH works for the destinations encoded in RH does not mean the
> info CAN NOT be carried in RH for per-segment processing.
>
>
>
> How about let’s focus on how to reduce the overhead of SRv6, that will be
> very helpful.
>
>
>
> Best Regards,
>
> Cheng
>
>
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of *Xiejingrong
> *Sent:* Sunday, September 08, 2019 8:55 AM
> *To:* Ron Bonica <rbonica=[email-masked]>; Robert Raszuk <
> [email-masked]>; Tom Herbert <[email-masked]>
> *Cc:* spring <[email-masked]>; 6man <[email-masked]>
> Also I think the use of unique last-5bits of option is just a week
> recommendation.  There is still enough space of 8bit if needed. It's not
> necessary to change interpretation of CHG.
>
> Thanks
> Jingrong
>
> *From:*Ron Bonica <rbonica=[email-masked]>
>
> *To:*Robert Raszuk <[email-masked]>;Tom Herbert <[email-masked]>
>
> *Cc:*spring <[email-masked]>;6man <[email-masked]>
>
> *Date:*2019-09-08 06:32:00
>
> *Subject*RE: [spring] Regaining Focus on SRv6 and SRv6+
>
>
>
> Robert,
>
>
>
> *Sent:* Saturday, September 7, 2019 5:54 PM
> Folks promoting SRv6+ are smart and they know how to sell stuff which
> looks simple and innocent on the surface like concept of CRH with just
> fixed label/sid list while hide all complexity under the deep cover and
> only show little corners of it here and there hoping no one will connect
> the dots.
>
>
>
> 4
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06*section-4__;Iw!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9VJXmGie$>.
> The PPSI Option
>
>
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9dfFF-MI$>
>
>
>
> remaining 5 bits (32 values) only 5 values are left for allocation..
>
>
>
> https://www....iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
> <https://urldefense.com/v3/__https:/www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9V9FULVl$>
>
>
>
>
> So they noticed that and just at the last rev of the VPN extenstion
> renamed what originally was called *VPN Context Information Option* to
> PPSI as it was very obvious that with 5 remaining values there is no room
> for new types for other service instructions.
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9RFWajEZ$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9YjolzkW$>
>
>
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 9 Sep 2019 15:04:15 +0000

Hi Ron,

Do you mean the function like END.B6.Encaps defined in https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-4.15?

To me, It is really good to discuss do we need a function like END.B6.Insert, that is fine. But It does not mean Encapsulation is a benefit of CRH, since it is a sub-set of SRv6.

Based on this sub-set, let's discuss do we need to do EH-Insertion, that will be very helpful to solve the problem.

Best Regards,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Sunday, September 08, 2019 6:41 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [spring] Regaining Focus on SRv6 and SRv6+

Robert,

-          Update SL and the IPv6 destination address, if required
-          Prepend an IPv6 header with its own Routing header

                                                                                            Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, September 7, 2019 6:06 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+

Ron,

Thx,
R.

                                                                     Ron

Really ?

Many thx,
R.

+ 1

Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Sep 2019 08:07:58 -0700

On Sat, Sep 7, 2019, 2:54 PM Robert Raszuk <[email-masked]> wrote:

> 4 <https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06#section-4>.  The PPSI Option
>

Robert,

I believe you are misinterpreting option number allocations. The whole
number needs to be unique, not just the low order 5 bits. PSSI option type
has act bits 10 and chg bit 0, so high order bits are 100. There are four
numbers assigned with those bits which leaves 28 that are unassigned if I'm
reading it right.

In any case, I don't believe option number space being exhausted is why
TLVs are in SRV6 (if it was a problem, we'd want a general solution instead
of point solution just for SRV6). The reasons why TLVs were need in SRV6,
as opposed to using DO or HBH, are unclear to me. I think it's some feeling
that there are options inherent to the SID list, it makes it easier to
ignore options, and maybe some amount of "not invented here".

Tom

>> > Then last I will not be able to use SRv6+ for my deployment needs in
>> the global IPv6 overlay I am running simply that within my overlay I do not
>> >> > We have explored many facets of SRv6 and SRv6, sometime
>> passionately. I think that this exploration is a good thing. In the words
>> of Tolkien, “All who wander are not lost.”
>> >> >
>> >> >
>> >> >

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2019 17:16:04 +0200

> ignore options, and maybe some amount of "not invented here"
>

I think it is useful to keep new functionality under one type - if for
nothing else then for easy filtering on the domian egress and ingress.

If you split this into N EH types then further nest some functions even
further it becomes very difficult by the operator to filter it.

To your very last point - if getting new EH type takes over 5 years - sorry
but this is not a velocity any operator can accept in order to make his
service better then competition the new paradigm of easily programmable
data plane.

Many thx,
Robert.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Sep 2019 18:00:20 +0000

+1

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Saturday, September 7, 2019 7:01 PM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+ - Service Chaining

With regard to service chaining, with either SRv6 or SRv6+, the interoperable mechanism for service function chaining is to carry NSH. 
Carrying the content of the NSH header in SRv6 SRH PDUs, while technically doable, is complexity that is not needed.

Yours,
Joel

On 9/7/2019 6:54 PM, Robert Raszuk wrote:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-xuclad-s
> pring-sr-service-chaining-00__;!8WoA6RjC81c!WOcr-ODRlejYVFb3cQeWtWE2yCWadubHStL7Tseto4hBUS9BwX-5S91En356M2wC$  which does require many elements from SRH we will resume the discussion.
> 
> 
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!WOcr-ODRlejYVFb3cQeWtWE2yCWadubHStL7Tseto4hBUS9BwX-5S9
> 1En06Jp28j$

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!WOcr-ODRlejYVFb3cQeWtWE2yCWadubHStL7Tseto4hBUS9BwX-5S91En06Jp28j$
--------------------------------------------------------------------

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 9 Sep 2019 19:35:13 +0100

Without commenting on the specific technical proposal.

IPv4 is still critical infrastructure in many organizations.

We have to maintain it until its natural death. If we neglect the 
maintenance, or worse try to euthanise it, it will end up either 
explicitly or implicitly being maintained by another organization.

We would thus be wise to actively maintain IPv4 for as long as users 
need us to, rather than to risk loosing control of it and its future 
developments.

- Stewart

On 07/09/2019 16:01, Lee Howard wrote:
>> Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Sep 2019 23:40:52 +0300

Hello, Gyan,

On 7/9/19 19:58, Gyan Mishra wrote:
[...]
> 
> I think when the SRv6 programming RFCs were written that violated the
> 6man WG RFC 8200 with EH only being allowed by the source node to insert
> EH and no other node when Spring WG decided to make this a requirement
> for SRv6 functionality they should have asked for 6man WG consensus
> approval and at that time RFC 8200 could have been updated to allow this
> one exception for EH for SR insertion by and node along the path.
>  Unfortunately this was not done that way from the beginning and now we
> are trying to fix what should have been fixed from the beginning.

The above is incorrect. EH insertion *was* discussed in 6man. And the
text that explicitly banned EH insertion was added in response to the
proponents of EH-insertion claiming that RFC2460 was ambiguous in this
respect.

We are not trying to fix anything. You cannot fix what's not broken. If
anything, folks are asking for a (major) modification in IPv6 -- with
the proposal failing to answer trivial questions such as "What problem
are we trying to solve?" and "Why are not we solving the problem in
standards-compliant ways?".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Sep 2019 23:50:07 +0300

> got filtered and disappeared.

SSR and LSR have well known security implications -- hence the
filtering. SImilarly, RHT0 was obsoleted for the same reason.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Tue, 10 Sep 2019 08:40:53 -0700

On Mon, Sep 9, 2019 at 8:16 AM Robert Raszuk <[email-masked]> wrote:
>
>
>> In any case, I don't believe option number space being exhausted is why TLVs are in SRV6 (if it was a problem, we'd want a general solution instead of point solution just for SRV6). The reasons why TLVs were need in SRV6, as opposed to using DO or HBH, are unclear to me. I think it's some feeling that there are options inherent to the SID list, it makes it easier to ignore options, and maybe some amount of "not invented here"
>
>
> I think it is useful to keep new functionality under one type - if for nothing else then for easy filtering on the domian egress and ingress.
>
> If you split this into N EH types then further nest some functions even further it becomes very difficult by the operator to filter it.
>
> To your very last point - if getting new EH type takes over 5 years - sorry but this is not a velocity any operator can accept in order to make his service better then competition the new paradigm of easily programmable data plane.
>
Robert,

You might want to consider the possibility that the length of time it
takes to standardize a protocol is proportional to its complexity and
divergence from existing standards. I believe that was the case of SRH
judging by the long discussion of it in 6man where much of that was
focused on peripheral functionality like the aforementioned TLVs as
well as trying to nail down the mutability requirements of the
protocol.

Tom

---

From: Fred Baker <[email-masked]>
Date: Fri, 13 Sep 2019 22:34:55 +0300

The funny thing, in my mind, is that I agree with both of you.

I guess at least part of the question is "what does it mean to maintain IPv4?" If it means creating something that is not backwards-compatible with existing-and-deployed IPv4, such as an IPv4 Extension Header, then we're not "fixing" IPv4, we are creating yet another new protocol which we will then somehow need to put to death. If, on the other hand, it can be put into an option that a node can skip if it doesn't understand it, I don't think that is going to hurt IPv6 deployment any more than bone-headed "there is just no **** way I'm going to deploy IPv6" does. The latter is what I see in a lot of enterprise deployments.

> On Sep 9, 2019, at 9:35 PM, Stewart Bryant <[email-masked]> wrote:
> 
> We have to maintain it until its natural death. If we neglect the maintenance, or worse try to euthanise it, it will end up either explicitly or implicitly being maintained by another organization.
> 
> We would thus be wise to actively maintain IPv4 for as long as users need us to, rather than to risk loosing control of it and its future developments.
> 
> - Stewart
> 
> 
>>> On Sat, Sep 7, 2019 at 1:14 PM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
>>>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 13 Sep 2019 13:10:31 -0700

> I guess at least part of the question is "what does it mean to maintain IPv4?" If it means creating something that is not backwards-compatible with existing-and-deployed IPv4, such as an IPv4 Exten…
Fred,

That's well said.

The problem I see is that the answer to just move to IPv6 seems to
assumed an idealized reality that doesn't exist. If we can't improve
IPv4 then people will find other ways to achieve the necessary
functionality (similar to how NAT was created?). A specific example
relating to extension headers is the proposal to hack up GRE to
effectively implement extension headers in an EtherType
(draft-weis-ippm-ioam-eth-02). I'm pretty sure everyone will agree
that this is a stunning hack and a complete abuse of EtherTypes, but
nevertheless it does seem to be plausible as solution for IOAM in
IPv4. I find it hard to believe that accepting a hack like this is a
good tradeoff for upholding the letter of the law.

I will be posting an update to the IPv4 EH draft shortly (to int-area
list). This will significantly narrow the immediate use cases and is
much less ambitious (this will only enable HBH and DO in IPv4). The
concept of using SR EH in IPv4 will be out of scope for that draft,
but presumably many of the principles could apply.

Tom