Subject: Header Insertion and TI-FA

From: Ron Bonica <[email-masked]>
Date: Mon, 11 May 2020 12:57:24 +0000

Folks,

Happy Monday!

As I was painting this weekend, I remembered that the use-case for IPv6 Header insertion is TI-LFA. This made the following questions come to mind:

  *   How does TI-LFA work when the original packet already contains a routing header? Will it insert a second, so that the packet has two routing headers?
  *   How does TI-LFA work when the node directly upstream of the link (i.e., the PLR) is not a segment endpoint? Will it insert an routing header? Is that consistent with 8200?

                                                                                                                        Ron

Juniper Business Use Only

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 11 May 2020 09:35:32 -0400

Hi Ron

I was thinking the same this past weekend as well.

So at the PLR node which could be any transit P router in the core.  So to
create that bypass transit path FRR link and node protection Next Next hop
(NNH) path around the  failed node or link, an EH header is inserted in
flight on the PLR node to the merge point PQ node for the bypass flow 50ms
failover.

So the agreement we came up with end of last year with Spring, is to add a
6in6 encapsulation along with EH insertion of the type 4 SRH header at the
PLR node to the merge point PQ node to be in compliance with RFC 8200.  The
additional encapsulation would in essence appear like the SRv6 source node
performing the encapsulation.

I looked in the PGM and SRH draft but I could not find the verbiage of the
update to add to additional 6in6 encapsulatio

So how would the packet look now?

IPv6 6in6 encapsulation- SR source node
EH SRH type 4 inserted (steering packet PGM)
IPv6 6in6 encapsulation - PLR node
EH SRH type 4 inserted ( steer to merge point PQ node)
Payload

At the merge point PQ node the EH SRH header is removed.

Packet is now steered via the original SRH header inserted at the SRv6
source node to the PSP node.

PSP pseudocode
SL== 1 ;  SL = SL -1 ; decrement pointer
Remove EH SRH header

Forward packet to USP egress PE end node.

USP egress PE endpoint SL=O

USD - remove 6in6 encapsulation
Send packet to IPv6 routing engine L3 vpn
End.x function processing

Spring - Please provide section within PGM that has the verbiage of the
6in6 encapsulation at the PLR node.

Thanks

Gyan

On Mon, May 11, 2020 at 8:57 AM Ron Bonica <rbonica=
[email-masked]> wrote:

> Folks,
>
>
>
> Happy Monday!
>
>
>
> As I was painting this weekend, I remembered that the use-case for IPv6
> Header insertion is TI-LFA. This made the following questions come to mind:
>
>
>
>    - How does TI-LFA work when the original packet already contains a
>    routing header? Will it insert a second, so that the packet has two routing
>    headers?
>    - How does TI-LFA work when the node directly upstream of the link
>    (i.e., the PLR) is not a segment endpoint? Will it insert an routing
>    header? Is that consistent with 8200?
>
>
>
>
>       Ron
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 11 May 2020 09:41:33 -0400

Sorry on the merge point PQ node I forgot to mention removal of the
additional 6in6 encapsulation added at PLR node.  Fixed.

At the merge point PQ node the “6in6 encapsulation” and EH SRH header added
at the PLR node is now removed.

PSP pseudocode

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Mon, 11 May 2020 14:07:00 +0000

Gyan,

If TI-LFA needs a 6in6 encapsulation anyway, why go through the extra pain of normalizing header insertion for the special case where the PLR is a segment endpoint?

                                                                                      Ron

Juniper Business Use Only
From: Gyan Mishra <[email-masked]>
Sent: Monday, May 11, 2020 9:36 AM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Header Insertion and TI-FA

[External Email. Be cautious of content]

Hi Ron

So at the PLR node which could be any transit P router in the core.  So to create that bypass transit path FRR link and node protection Next Next hop (NNH) path around the  failed node or link, an EH header is inserted in flight on the PLR node to the merge point PQ node for the bypass flow 50ms failover.

So the agreement we came up with end of last year with Spring, is to add a 6in6 encapsulation along with EH insertion of the type 4 SRH header at the PLR node to the merge point PQ node to be in compliance with RFC 8200.  The additional encapsulation would in essence appear like the SRv6 source node performing the encapsulation.

I looked in the PGM and SRH draft but I could not find the verbiage of the update to add to additional 6in6 encapsulatio

Packet is now steered via the original SRH header inserted at the SRv6 source node to the PSP node.

PSP pseudocode

Spring - Please provide section within PGM that has the verbiage of the 6in6 encapsulation at the PLR node.

Thanks

Gyan

On Mon, May 11, 2020 at 8:57 AM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Happy Monday!

                                                                                                                        Ron

Juniper Business Use Only
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VCe2LOAZEHCCva900dxo71Vh9AfYqiSYViBZFO2MQS1wcWunfq6LTcc_ZqyBKxU2$>
--------------------------------------------------------------------
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 May 2020 16:38:55 +0200

Hi Ron,

> normalizing header insertion for the special case where the PLR is a
segment endpoint

When an operator is serious about good data plane protection with TI-LFA
all nodes in the network will be enabled for SR. The less overhead required
for the protection the better. You may just not have a room for adding
additional 40 bytes to each packet at each potential PLR without
fragmentation.

Regarding all of your other TI-LFA related questions - I am sure Krzysztof
will be happy to answer them for you internally :)  After all this is what
your public demo was all about ....

Best,
Robert,

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 May 2020 07:48:36 -0700

> As I was painting this weekend, I remembered that the use-case for IPv6 Header insertion is TI-LFA. This made the following questions come to mind:

Ron,

There is at least one other use case for IPv6 Header insertion, that
being IOAM. For example, an operator may wish to collect per packet
statistics as packets traverse its network. An ingress router would
insert headers containing IOAM, routers would annotate the
information, and the egress router is expected to consume and remove
the headers. The big difference between this use case and SR is that
there's no source routing involved so the ingress router doesn't
necessarily know what the egress router is, hence the ingress router
wouldn't know the right destination address to use in encapsulation.

I believe that this is currently being developed and maybe even being
deployed, but not under the auspices of IETF. Frankly, figuring out
how to do header insertion in a sensible and standard way would be a
step up from some of the methods being proposed. The most egregious
proposal I've seen was one in which the ingress router would place the
IOAM information in the TCP payload and then use diff serv bits to
indicate the TCP payload is modified. Of course the day a network
fails to remove the inserted information this completely breaks TCP!

This use case makes me think the WG should consider how to make header
insertion safe and viable.

Tom
>
>
> How does TI-LFA work when the original packet already contains a routing header? Will it insert a second, so that the packet has two routing headers?
> How does TI-LFA work when the node directly upstream of the link (i.e., the PLR) is not a segment endpoint? Will it insert an routing header? Is that consistent with 8200?
>
>
>
>                                                                                                                         Ron
>
>
>
>
>
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 May 2020 08:05:04 -0700

On Mon, May 11, 2020 at 7:42 AM Robert Raszuk <[email-masked]> wrote:
>
> Hi Ron,
>
> > normalizing header insertion for the special case where the PLR is a segment endpoint
>
> When an operator is serious about good data plane protection with TI-LFA all nodes in the network will be enabled for SR. The less overhead required for the protection the better. You may just not have a room for adding additional 40 bytes to each packet at each potential PLR without fragmentation.

Robert,

Considering that SRH already carries a list of IPv6 addresses which
could create hundreds of bytes of overhead, the argument that an
additional forty byte header is the problem seems trite to me. Besides
that, it's not really an additional forty bytes being added to the
packet. The destination address in the encapsulating header saves one
address in the SID list, so that takes encapsulation down to
twenty-four bytes of additional overhead. If the address of the node
inserting the header is needed in inserted data, like for correct
handling of ICMP, that would be reflected in source address so the
overhead difference of encapsulation would only be eight bytes.

Tom

>
> Regarding all of your other TI-LFA related questions - I am sure Krzysztof will be happy to answer them for you internally :)  After all this is what your public demo was all about ....
>
> Best,
> Robert,
>

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Mon, 11 May 2020 17:07:11 +0200

Hi Robert,

If we have prepend, why bother with insertion at all? Prepend (6in6 encap) is much cleaner, IMHO.

Regards,
Krzysztof

> On 2020 -May-11, at 16:38, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Ron,
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 11 May 2020 12:01:30 -0400

Krzysztof

So you agree with what I stated as the workaround.

Please read through exactly what I stated as the complete workaround.

If we are all in agreement with the prepend (6in6) encap) workaround can we
have the PGM draft updated to reflect.

All

With regards to the 6MAN appeal,  the issues were PSP and this issue with
TI-LFA from what I recall.

Was their any other issue outside of these two mentioned in the appeal that
we need to address and come up with a workaround?

Thank you

Gyan

On Mon, May 11, 2020 at 11:09 AM Krzysztof Szarkowicz <[email-masked]>
wrote:

> > Regarding all of your other TI-LFA related questions - I am sure
> Krzysztof will be happy to answer them for you internally :)  After all
> this is what your public demo was all about ....
> >
> > Best,
> > Robert,
> >
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 11 May 2020 17:10:30 +0000

Gyan,

SRH insertion is NOT part of draft-ietf-spring-srv6-network-programming-15.
(SRH insertion is documented in draft-filsfils-spring-srv6-net-pgm-insertion-02 with a normative reference to draft-voyer-6man-extension-header-insertion-08).

> Spring - Please provide section within PGM that has the verbiage of the 6in6 encapsulation

This is already in the net-pgm draft (since rev 00). Please see https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-5 .

Thanks,
Pablo.

From: ipv6 <[email-masked]> On Behalf Of Gyan Mishra
Sent: lunes, 11 de mayo de 2020 18:02
To: Krzysztof Szarkowicz <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; 6man <[email-masked]>
Subject: Re: Header Insertion and TI-FA

Krzysztof

If we are all in agreement with the prepend (6in6) encap) workaround can we have the PGM draft updated to reflect.

All

With regards to the 6MAN appeal,  the issues were PSP and this issue with TI-LFA from what I recall.

Was their any other issue outside of these two mentioned in the appeal that we need to address and come up with a workaround?

Thank you

Gyan

On Mon, May 11, 2020 at 11:09 AM Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Regards,
Krzysztof

> On 2020 -May-11, at 16:38, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Ron,
>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 11 May 2020 19:35:21 +0000

Correct me if I am wrong – but – removal is still in there – which violates exactly the same section of text and breaks things like the AH?

Or are we saying – its ok to only half violate the text? 😊

Andrew

From: ipv6 <[email-masked]> on behalf of "Pablo Camarillo (pcamaril)" <pcamaril=[email-masked]>
Date: Monday, 11 May 2020 at 20:13
To: Gyan Mishra <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Header Insertion and TI-FA

Gyan,

> Spring - Please provide section within PGM that has the verbiage of the 6in6 encapsulation

This is already in the net-pgm draft (since rev 00). Please see https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-5<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-5> .

Thanks,
Pablo.

Krzysztof

All

Thank you

Gyan

Regards,
Krzysztof

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 11 May 2020 20:04:28 +0000

Hi Pablo,

While I fully realize that running code is not mandatory in the IETF – there have been numerous assertions about what is harmful and not harmful etc, and coupled with the deployment draft, I presume there is running code from the perspective of the authors.

Would you be prepared to disclose the release of code where SRH and this functionality is actually implemented – since I’d like to run a series of verification tests against it to test the effects on my network and I’m sure others would be interested in doing the same.  I can also then test against the Juniper implementation as tested at the EANTC and run my own inter-op tests and test the real effects this has on the network in a manner that makes sense.

Obviously however testing against a single vendor code is not ideal – and since the assertions are being made and in light of the deployment draft – I am figuring that you must actually have running code that is in the field? (I know on all code versions I have tested that are GA I have yet to see any SRH on any packet capture that I have done – hence I have been unable to do any verification testing myself against the claims made)

Thanks

Andrew

Gyan,

Thanks,
Pablo.

Krzysztof

All

Thank you

Gyan

Regards,
Krzysztof

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 May 2020 08:36:31 +1200

> <rbonica=[email-masked]> wrote:

This is confusing. For me, that was yesterday ;-)

> insertion safe and viable.

Unless I'm missing something, that would require a reworking of the last
sentence of this paragraph in RFC8200:

      o  The Upper-Layer Packet Length in the pseudo-header is the
         length of the upper-layer header and data (e.g., TCP header
         plus TCP data).  Some upper-layer protocols carry their own
         length information (e.g., the Length field in the UDP header);
         for such protocols, that is the length used in the pseudo-
         header.  Other protocols (such as TCP) do not carry their own
         length information, in which case the length used in the
         pseudo-header is the Payload Length from the IPv6 header, minus
         the length of any extension headers present between the IPv6
         header and the upper-layer header.

And some changes to the IPSec/AH rules about mutable fields, of course.

I'm not sure this is feasible without changing the IP version number.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 May 2020 06:37:23 +1000

On Tue, 12 May 2020, 00:50 Tom Herbert, <[email-masked]> wrote:

> the headers.

Have a review of this draft. EH insertion is not proposed for IOAM.

Deployment Considerations for In-situ OAM with IPv6 Options
https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-deployment-02

My suggestion for that draft was the "IP-in-IPv6 encapsulation with ULA"
section.

If the IOAM nodes are a link-layer adjacent and contiguous through the IOAM
domain, which I think will be likely in a lot of deployments, then the
outer tunnel addressing could be Link-Local Addresses, and the IPv6 tunnels
are implicit as LLAs are required for all IPv6 interfaces.

An even lower overhead option in this scenario is to carry the IOAM header
directly after the link-layer header, similar to how the MPLS label stack
is encoded after the link-layer header, before the IP header.

That would mean defining an IOAM link-layer type value for the IOAM header,
however there aren't many link-layers, and an Ethertype for the IOAM header
is already being defined:

"Ethernet Encapsulation for In-situ OAM Data"
https://tools.ietf.org/html/draft-weis-ippm-ioam-eth-02

I'll email Frank again about this as I haven't heard anything since I
emailed him before.

> The big difference between this use case and SR is that

The model to have in mind is how packets are mapped onto MPLS LSPs and how
packets are mapped onto link-layer next hops. Destination address route
table lookup specifying next IPv6 hop and corresponding link-layer
encapsulation and next hop link-layer address. In this case the outer IPv6
tunnels between IOAM nodes are virtual link-layers.

> insertion safe and viable.

There's a need for a layer 2.5 local networking protocol that has smaller
headers (and smaller addressing) than IPv6, that won't cause problems if it
leaks because it is not the Internet's protocol, because all this EH
insertion debate and pain is caused by people wanting to use IPv6, but not
wanting to pay the IPv6 internetworking protocol overhead. They're trying
to have their cake and eat it too.

MPLS framing is an example of something that suits requirement ("MPLS" here
is not implying the "MPLS Family" of protocols (RSVP, LDP etc.) that are
apparently the actual cause of the problem that SR is trying to solve).
There could be other options.

So people need to either accept the IPv6 overhead trade-off to get the
commodity benefits of IPv6, or be willing to deploy a lower overhead local
network protocol to carry that local information in their network.

EH insertion is a hack and will always be a hack, and anything that tries
to work around its issues will also going to be a hack. Decommodified IPv6
due to hacks is not commodity IPv6.

Regards,
Mark.

> Tom
> >
> >
> > How does TI-LFA work when the original packet already contains a routing
> header? Will it insert a second, so that the packet has two routing headers?
> > How does TI-LFA work when the node directly upstream of the link (i.e.,
> the PLR) is not a segment endpoint? Will it insert an routing header? Is
> that consistent with 8200?
> >
> >
> >
> >
>                                                Ron
> >
> >
> >
> >
> >
> >

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 May 2020 22:43:17 +0200

> I'm not sure this is feasible without changing the IP version number.

How about IPv6+ ?

Thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 11 May 2020 17:38:55 -0400

Andrew

I believe how we get around AH issue from a customer endpoint flow is that
the customer flow is tunneled, h.encap,  so sits in the payloadend to end
customer packet remains unaltered so their is no impact to end to end
customer flows if AH is used by any endpoint customer cuz. As far as the
outer header H.encap that happens on the SR source or TI-LFA merge point
the closer domain intra or inter domain SRv6 comes into play and if the
operator tries to use AH instead of ESP the operator that would be broken.
The operator would have to aware to not try to use AH and to use ESP
instead.

In SRH section 5 intra SR

https://tools.ietf.org/html/rfc8754

An operator of an SR domain may choose to delegate SRH addition to a
   host node within the SR domain and delegate validation of the
   contents of any SRH to a more trusted router or switch attached to
   the host.  Consider a top-of-rack switch T connected to host H via
   interface I.  H receives an SRH (SRH1) with a computed HMAC via some
   SDN method outside the scope of this document.  H classifies traffic
   it sources and adds SRH1 to traffic requiring a specific Service
   Level Agreement (SLA).  T is configured with an IACL on I requiring
   verification of the SRH for any packet destined to the SID block of
   the SR domain (S/s).  T checks and verifies that SRH1 is valid and
   contains an HMAC TLV; T then verifies the HMAC.

   An operator of the SR domain may choose to have all segments in the
   SR domain verify the HMAC.  This mechanism would verify that the SRH
   Segment List is not modified while traversing the SR domain.

Since the 6in6 encapsulation outer header that is prepended at the PLR node
is completely removed along with the EH SRH inserted by the merge point
along the FRR bypass path.

>From what I can tell TI-LFA if implemented per the PGM draft should be in
compliance with RFC 8200.

I believe I have a capture where EH SRH header is inserted - will try to
dig up.

There is a concept called BE L3VPN and with that configuration SRH is not
present.

I believe one of the benefits of SRv6 is being able to support on hardware
that is not SRv6 capable on any node even the Ingress and egress PEs and
just use the standard IPv6 data plane.

I believe the BE L3VPN feature is enabled default so no SRH is present.
This may vary from vendor to vendor.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-02

Kind regards

Gyan

On Mon, May 11, 2020 at 3:35 PM Andrew Alston <
[email-masked]> wrote:

> Correct me if I am wrong – but – removal is still in there – which
> violates exactly the same section of text and breaks things like the AH?
>
>
>
> *From: *ipv6 <[email-masked]> on behalf of "Pablo Camarillo
> (pcamaril)" <pcamaril=[email-masked]>
> *Date: *Monday, 11 May 2020 at 20:13
> *To: *Gyan Mishra <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: Header Insertion and TI-FA
>
>
>
> Gyan,
>
>
>
> (SRH insertion is documented in
> draft-filsfils-spring-srv6-net-pgm-insertion-02 with a normative reference
> to draft-voyer-6man-extension-header-insertion-08).
>
>
>
> 6in6 encapsulation
> This is already in the net-pgm draft (since rev 00). Please see
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-5
> .
>
>
>
> Thanks,
>
> Pablo.
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Gyan Mishra
> *Sent:* lunes, 11 de mayo de 2020 18:02
> *To:* Krzysztof Szarkowicz <[email-masked]>
> *Cc:* Ron Bonica <rbonica=[email-masked]>; 6man <
> [email-masked]>
> *Subject:* Re: Header Insertion and TI-FA
>
>
>
>
>
> Krzysztof
>
>
>
> If we are all in agreement with the prepend (6in6) encap) workaround can
> we have the PGM draft updated to reflect.
>
>
>
> All
>
>
>
> Was their any other issue outside of these two mentioned in the appeal
> that we need to address and come up with a workaround?
>
>
>
> Thank you
>
>
>
> Gyan
>
>
>
> On Mon, May 11, 2020 at 11:09 AM Krzysztof Szarkowicz <
> [email-masked]> wrote:
>
> Hi Robert,
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 May 2020 08:10:44 +1000

> SRH insertion is NOT part of draft-ietf-spring-srv6-network-programming-15.

Removal is, and it is just as much of a hack as EH insertion is.

> On Mon, May 11, 2020 at 11:09 AM Krzysztof Szarkowicz <[email-masked]> wrote:
>
> Hi Robert,
>

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 11 May 2020 23:57:19 +0100

>     I'm not sure this is feasible without changing the IP version number.

the IP version number is maintained in an IANA registry:

https://www.iana.org/assignments/version-numbers/version-numbers.xhtml

So there's no such thing as IPv6+. The version number is integer-only.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 May 2020 17:27:29 -0700

> https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-deployment-02
Mark,

For IOAM the assumption is that not all packets are necessarily
annotated for measurement and that both annotated and non-annotated
packets need to follow the same path in order for the the measurements
to be useful. This is one of the motivations for hacking the the TCP
payload, it doesn't change how the packet is routed since ECMP should
be unaffected. It also works equivalently in IPv4 and does invoke any
external mechnisms like MPLS, additional routing information, or link
layer addressing.

> My suggestion for that draft was the "IP-in-IPv6 encapsulation with ULA" section.
>
> If the IOAM nodes are a link-layer adjacent and contiguous through the IOAM domain, which I think will be likely in a lot of deployments, then the outer tunnel addressing could be Link-Local Addresses, and the IPv6 tunnels are implicit as LLAs are required for all IPv6 interfaces.
>
> An even lower overhead option in this scenario is to carry the IOAM header directly after the link-layer header, similar to how the MPLS label stack is encoded after the link-layer header, before the IP header.
>
> That would mean defining an IOAM link-layer type value for the IOAM header, however there aren't many link-layers, and an Ethertype for the IOAM header is already being defined:
>
> I'll email Frank again about this as I haven't heard anything since I emailed him before.
>
>>
> The model to have in mind is how packets are mapped onto MPLS LSPs and how packets are mapped onto link-layer next hops. Destination address route table lookup specifying next IPv6 hop and corresponding link-layer encapsulation and next hop link-layer address. In this case the outer IPv6 tunnels between IOAM nodes are virtual link-layers.
>
>
>>
> There's a need for a layer 2.5 local networking protocol that has smaller headers (and smaller addressing) than IPv6, that won't cause problems if it leaks because it is not the Internet's protocol, because all this EH insertion debate and pain is caused by people wanting to use IPv6, but not wanting to pay the IPv6 internetworking protocol overhead. They're trying to have their cake and eat it too.

I think we need to keep an open mind. While I agree that the SR use
case hasn't been well explained why EH insertion is needed, I don't
think we can preclude that there might not be other use cases where it
makes sense.

>
> MPLS framing is an example of something that suits requirement ("MPLS" here is not implying the "MPLS Family" of protocols (RSVP, LDP etc.) that are apparently the actual cause of the problem that SR is trying to solve). There could be other options.
>
> So people need to either accept the IPv6 overhead trade-off to get the commodity benefits of IPv6, or be willing to deploy a lower overhead local network protocol to carry that local information in their network.
>
> EH insertion is a hack and will always be a hack, and anything that tries to work around its issues will also going to be a hack. Decommodified IPv6 due to hacks is not commodity IPv6.

A lot of people thought NAT was a hack too :-) My concern is if we
dismiss protocols becasue we view them as hacks without giving serious
consideration to how they might be made to work reasonably, perhaps in
a limited domain, people will deploy these hacks anyway and in  fact
may end up doing things the are far worse (like the aforemention hacks
where intermediate nodes are mucking with TCP payload).

Tom

---

From: Andrew Alston <[email-masked]>
Date: Tue, 12 May 2020 04:05:54 +0000

I believe how we get around AH issue from a customer endpoint flow is that the customer flow is tunneled, h.encap,  so sits in the payloadend to end customer packet remains unaltered so their is no impact to end to end customer flows if AH is used by any endpoint customer cuz. As far as the outer header H.encap that happens on the SR source or TI-LFA merge point the closer domain intra or inter domain SRv6 comes into play and if the operator tries to use AH instead of ESP the operator that would be broken.  The operator would have to aware to not try to use AH and to use ESP instead.

[AA] Gyan - my problem here is that as you state - the operator would have to be aware - now correct me if I am wrong - but that seems to imply that implementation of this could break existing deployments unless the existing deployments were modified - and I quote from the spring charter

SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments.

Andrew

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 12 May 2020 00:37:25 -0400

On Tue, May 12, 2020 at 12:06 AM Andrew Alston <
[email-masked]> wrote:

> [AA] Gyan - my problem here is that as you state - the operator would have
> to be aware - now correct me if I am wrong - but that seems to imply that
> implementation of this could break existing deployments unless the existing
> deployments were modified - and I quote from the spring charter
>
> SPRING WG should avoid modification to existing data planes that would make
> them incompatible with existing deployments.
>

   Gyan> Very Good point.  Mangling of EH insertion or deletion is
modifying the existing IPv6 data plane and a violation of the SR charter.
Agreed. So this would be brown field existing deployments that was let’s
say LDPv6 a v6 only core that was being converted to SRv6 hypothetical real
world example.  So in this case the LDPv6 data plan would have accommodated
AH, however when upgraded to support SRv6 AH would be broken.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Tue, 12 May 2020 14:45:27 +0000

Robert,

I realize that you are joking, but it might actually be a good idea for SRv6 to move onto another protocol number. This would solve the following problems:

  *   SRv6 could do whatever it wanted, without regard for RFC 4291,  RFC 8200, or anything else that 6man produces
  *   6man could evolve IPv6 as it sees fit, without having to consider the sensitivities of SRv6

It would only mean changing the first four bits of every SRv6 packet. That would probably take much less time than converging the SRv6 and IPv6 architectures.

                                                         Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Monday, May 11, 2020 4:43 PM
To: Brian E Carpenter <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Ron Bonica <[email-masked]>; 6man <[email-masked]>
Subject: Re: Other use cases for header insertion (was Re: Header Insertion and TI-FA)

How about IPv6+ ?

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 12 May 2020 16:55:06 +0200

Hey Ron,

Well it was half joke / half serious suggestion. Your SRv6+ was an
inspiration for IPv6+ - no doubt !

But to your point ...

* Yes it would be much easier to contain any new significant protocol
extension if you apply new ethertype to it

* As sent in the note over weekend I think that this "packets leaking" or
"escaping" fear is a nonsense - packets are not mosquitoes flying where
they want to go - packets are forwarded based on the control plane
directions. If there is more work on controlled leaking IGP to BGP we
should work on that in LSR WG and IDR WG.

* If you force that SRv6 must only be legal in new ethertype then I can no
longer legally send SRv6 packet between my sites over Internet which breaks
completely my #1 application and main interest in/for SRv6.

Cheers,
Robert.

On Tue, May 12, 2020 at 4:45 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> I realize that you are joking, but it might actually be a good idea for
> SRv6 to move onto another protocol number. This would solve the following
> problems:
>
>
>
>    - SRv6 could do whatever it wanted, without regard for RFC 4291,  RFC
>    8200, or anything else that 6man produces
>    - 6man could evolve IPv6 as it sees fit, without having to consider
>    the sensitivities of SRv6
>
>
>
> It would only mean changing the first four bits of every SRv6 packet. That
> would probably take much less time than converging the SRv6 and IPv6
> architectures.
>
>
>
>                                                          Ron
>
>
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Monday, May 11, 2020 4:43 PM
> *To:* Brian E Carpenter <[email-masked]>
> *Cc:* Tom Herbert <[email-masked]>; Ron Bonica <[email-masked]>;
> 6man <[email-masked]>
> *Subject:* Re: Other use cases for header insertion (was Re: Header
> Insertion and TI-FA)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 May 2020 15:56:51 +0100

It would also mean a new Ethertype, and I am sure that as we think about it other issues will come up.

… but I am sure that you are not the only one wondering the same thing.

Stewart

> On 12 May 2020, at 15:45, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Robert,
>  
> SRv6 could do whatever it wanted, without regard for RFC 4291,  RFC 8200, or anything else that 6man produces
> 6man could evolve IPv6 as it sees fit, without having to consider the sensitivities of SRv6
>  
> From: Robert Raszuk <[email-masked] <mailto:[email-masked]>> 
> To: Brian E Carpenter <[email-masked] <mailto:[email-masked]>>
> Cc: Tom Herbert <[email-masked] <mailto:[email-masked]>>; Ron Bonica <[email-masked] <mailto:[email-masked]>>; 6man <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 12 May 2020 15:24:51 +0000

Andrew,

We have already been there.
Please refer to the following email threads:
https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/
https://mailarchive.ietf.org/arch/msg/spring/JdpSLS7ax0VUZLG6SINxnOWJzbY/
https://mailarchive.ietf.org/arch/msg/spring/nbAdEl4HwCeRRzXEWnzxVnBt_YQ/
https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/
https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk/
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
https://mailarchive.ietf.org/arch/msg/spring/QO9qXpv1qlTXfOfFPWrhEw0KJbc/
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek/
https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58/

Regards,
Pablo.

From: Andrew Alston <[email-masked]>
Sent: lunes, 11 de mayo de 2020 21:35
To: Pablo Camarillo (pcamaril) <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: [email-masked]
Subject: Re: Header Insertion and TI-FA

Andrew

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of "Pablo Camarillo (pcamaril)" <pcamaril=[email-masked]<mailto:pcamaril=[email-masked]>>
Date: Monday, 11 May 2020 at 20:13
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Header Insertion and TI-FA

Gyan,

Thanks,
Pablo.

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra
Sent: lunes, 11 de mayo de 2020 18:02
To: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Header Insertion and TI-FA

Krzysztof

All

Thank you

Gyan

Regards,
Krzysztof

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 12 May 2020 15:26:01 +0000

Hi Andrew,

Cisco has demonstrated TILFA with SRH insertion at EANTC-2019. http://www.eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-MPLSSDNNFV2019-WhitePaper-v1.2.pdf

This feature is available to all customers -supported since XR 6.6.1-. Please contact your Cisco account team if you want further details on cisco products or need assistance.

Thank you,
Pablo.

From: Andrew Alston <[email-masked]>
Sent: lunes, 11 de mayo de 2020 22:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: [email-masked]
Subject: Re: Header Insertion and TI-FA

Hi Pablo,

While I fully realize that running code is not mandatory in the IETF - there have been numerous assertions about what is harmful and not harmful etc, and coupled with the deployment draft, I presume there is running code from the perspective of the authors.

Would you be prepared to disclose the release of code where SRH and this functionality is actually implemented - since I'd like to run a series of verification tests against it to test the effects on my network and I'm sure others would be interested in doing the same.  I can also then test against the Juniper implementation as tested at the EANTC and run my own inter-op tests and test the real effects this has on the network in a manner that makes sense.

Obviously however testing against a single vendor code is not ideal - and since the assertions are being made and in light of the deployment draft - I am figuring that you must actually have running code that is in the field? (I know on all code versions I have tested that are GA I have yet to see any SRH on any packet capture that I have done - hence I have been unable to do any verification testing myself against the claims made)

Thanks

Andrew

Gyan,

Thanks,
Pablo.

Krzysztof

All

Thank you

Gyan

Regards,
Krzysztof

---

From: Andrew Alston <[email-masked]>
Date: Tue, 12 May 2020 17:12:06 +0000

Pablo,

Why thank you for the links – I’ve read all of these.  Problem is – its disputed.  Over and over and over again – by many many people.

And while you want to state your views as gospel truth – sadly – that’s just not the way this works.  Right now – I see a total lack of consensus on the very issues these emails refer to, both in SPRING and on this list – by person after person.  So while you may wish that your opinion is the one and only truth – your opinion – does not grant consensus.  In the face of a lack of consensus on an issue relating to a draft – that the authors of said draft have refused to budge on – I fail to see how consensus can exist for that draft.

Please remember – while I realize who you work for – and I realize that you have strong opinions – they are not the only opinions – and they do not form solo consensus

Thanks

Andrew

From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Tuesday, 12 May 2020 18:25
To: Andrew Alston <[email-masked]>
Cc: [email-masked]; Gyan Mishra <[email-masked]>
Subject: RE: Header Insertion and TI-FA

Andrew,

We have already been there.
Please refer to the following email threads:
https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/<https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk>
https://mailarchive.ietf.org/arch/msg/spring/JdpSLS7ax0VUZLG6SINxnOWJzbY/<https://mailarchive.ietf.org/arch/msg/spring/JdpSLS7ax0VUZLG6SINxnOWJzbY>
https://mailarchive.ietf.org/arch/msg/spring/nbAdEl4HwCeRRzXEWnzxVnBt_YQ/<https://mailarchive.ietf.org/arch/msg/spring/nbAdEl4HwCeRRzXEWnzxVnBt_YQ>
https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/<https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw>
https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk/<https://mailarchive.ietf.org/arch/msg/spring/6ZNyPMuZaaP9amVRXQdX9uRMbVk>
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/<https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0>
https://mailarchive.ietf.org/arch/msg/spring/QO9qXpv1qlTXfOfFPWrhEw0KJbc/<https://mailarchive.ietf.org/arch/msg/spring/QO9qXpv1qlTXfOfFPWrhEw0KJbc>
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/<https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso>
https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek/<https://mailarchive.ietf.org/arch/msg/spring/C20J-h835TJYHH2Q4KCHaS_lmek>
https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58/<https://mailarchive.ietf.org/arch/msg/spring/65GgH7fY3_TDEbE7dNXwSz64l58>

Regards,
Pablo.

From: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Sent: lunes, 11 de mayo de 2020 21:35
To: Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Header Insertion and TI-FA

Andrew

Gyan,

Thanks,
Pablo.

Krzysztof

All

Thank you

Gyan

Regards,
Krzysztof

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 12 May 2020 19:48:38 +0200

I would love to hear i am wrong, but i am sure a new IP version number would introduce
more need for HW-upgrades. While i appreciate architectural cleanlyness, i really would love if
we would reserve the need for such fundamental HW changes to more fundamental improvements
to our IPv6 networkinging layer.

For example: IPv6++ could support different adress spaces of different address sizes, one
of which could be Internet/IPv6, another one Internet/IPv4 and many more for various address
sizes for the probably millions of private IP networks on the planet, including the "transport"
layer "network" of most SP networks with likely << 128 bit address sizes or even smaller IoT networks.
Interop between different address spaces/sizes is designed upfront instead of 28+ IPv4/IPv6 transition
solutions.  Addresses would not have to be (ab)used for every path processing function because the
header provides ways to define better alternatives and those are correctly MUST requirements in the
spec, and steering would not be constrained to the concepts of a 40 year old source-routing design.
Oh, and QoS would get more than 8 bits so we would not have to fight over semantic of 1 ECN bit.

To me, that would be evolution goals for which it would be worth to consider mayor HW upgrades and
assigning a new IP version codepoint. Would be nice if more IPv6 supporters would think about
these type of now well feasuble and understood long-term innovation options instead of only
trying to stick to the status quo in the hope of increasing adoption.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 12 May 2020 20:10:42 +0200

Toerless,

No one said here that such change would be bound to contain only two new
relaxed rules related to routing header processing.

Cheers,
R.

On Tue, May 12, 2020 at 7:48 PM Toerless Eckert <[email-masked]> wrote:

> >   *   SRv6 could do whatever it wanted, without regard for RFC 4291,
> RFC 8200, or anything else that 6man produces
> > It would only mean changing the first four bits of every SRv6 packet.
> That would probably take much less time than converging the SRv6 and IPv6
> architectures.
> >
> >                                                          Ron
> >
> >
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2020 08:29:31 +1200

> … but I am sure that you are not the only one wondering the same thing.

Yes, there would be a lot of competition if there was a *serious* proposal
to add a new protocol number. Maybe we should make the first provision of
IPv7 that there should be a sub-version number.

Sigh.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2020 08:39:23 +1200

Pablo,

Yes, the IETF is not the Protocol Police. Interpol will not issue Red Notices for us. Any company can sell products that deviate from IETF standards, and any customer can buy them.

However, many customers do not wish to buy products that will not interoperate with other products. As the histories of SNA, DECnet, Netware, Banyan Vines, and Appletalk show, proprietary networking solutions only last as long as the vendor's monopoly.

We have a mechanism for documenting proprietary protocols, and it is not the IETF Stream of RFCs.

Regards
   Brian Carpenter

On 13-May-20 03:26, Pablo Camarillo (pcamaril) wrote:
> This feature is available to all customers -supported since XR 6.6.1-.. Please contact your Cisco account team if you want further details on cisco products or need assistance.
> 
>  
> 
> Thank you,
> 
> Pablo.
> 
>  
> 
> *From:*Andrew Alston <[email-masked]>
> *Sent:* lunes, 11 de mayo de 2020 22:04
> *To:* Pablo Camarillo (pcamaril) <[email-masked]>; Gyan Mishra <[email-masked]>
> *Cc:* [email-masked]
> While I fully realize that running code is not mandatory in the IETF – there have been numerous assertions about what is harmful and not harmful etc, and coupled with the deployment draft, I presume there is running code from the perspective of the authors..
> 
>  
> 
> *From: *ipv6 <[email-masked] <mailto:[email-masked]>> on behalf of "Pablo Camarillo (pcamaril)" <pcamaril=[email-masked] <mailto:pcamaril=[email-masked]>>
> *To: *Gyan Mishra <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *From:*ipv6 <[email-masked] <mailto:[email-masked]>> *On Behalf Of *Gyan Mishra
> *To:* Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>>
> *Cc:* Ron Bonica <rbonica=[email-masked] <mailto:rbonica=[email-masked]>>; 6man <[email-masked] <mailto:[email-masked]>>
> On Mon, May 11, 2020 at 11:09 AM Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Robert,
> 
>     > On 2020 -May-11, at 16:38, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>     > 
>     > Hi Ron,
>     > 
> Email: [email-masked] <mailto:[email-masked]>
> 
>  
> 
>  
> 
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 May 2020 07:43:34 +1000

Hi Tom,

On Tue, 12 May 2020, 10:27 Tom Herbert, <[email-masked]> wrote:

> >> > As I was painting this weekend, I remembered that the use-case for
> IPv6 Header insertion is TI-LFA. This made the following questions come to
> mind:
> >> >
> >>
> >> Ron,
> >>
> to be useful.

I think that can be accommodated.

The presence of an IOAM header in a packet is the selector of whether IOAM
processing occurs, and whether an IOAM header is present when the packet
leaves the node.

i.e. for packet with IOAM header when it arrives at IOAM node.

1. packet is link-layer decapsulated (including IPv6 virtual-link layer
(tunnel) decap)
2. As packet has IOAM header, IOAM info and packet passed to IOAM function
to process/update IOAM information.
3. Once IOAM processing complete, packet's IP DA is looked up, determining
egress interface and link-layer encapsulation.
4. The packet is link-layer encapsulated (possibly in IPv6 virtual
link-layer/tunnel) with the IOAM header between the link-layer header and
the IP packet, and sent on its way.

for a non-IOAM packet, (standard IP forwarding, just showing for
completeness)

1. packet is link-layer decapsulated.
2. As packet is vanilla IP, packet bypasses the IOAM function.
3. packet's IP DA is looked up, determining egress interface and link-layer
encapsulation.
4. packet is link-layer encapsulated, and sent on its way.

The information produced by IP DA lookups in both cases is the same, so
packets with or without IOAM headers will follow the same path through the
network if they have the same DA.

> <snip>

> > There's a need for a layer 2.5 local networking protocol that has
> smaller headers (and smaller addressing) than IPv6, that won't cause
> problems if it leaks because it is not the Internet's protocol, because all
> this EH insertion debate and pain is caused by people wanting to use IPv6,
> but not wanting to pay the IPv6 internetworking protocol overhead. They're
> trying to have their cake and eat it too.
>

I don't think it will ever make sense to me, and I've thought about the
idea of insertion verses encapsulation since the invention of 802.1Q in
around the early 2000s, verses the Eth-in-Eth tunelling pre-standard
solution Cisco I had deployed.

802.1Q violates the purpose of the FCS, which is a path integrity check
between the frame's original source and its final destination.

> <snip>
>
> A lot of people thought NAT was a hack too :-)

It still is, and I've thought that for nearly 25 years.

Here's my 3 part, 4500 word essay, from an operators point of view, on the
trouble with NAT, based on my AusNOG presentation on that topic in the
previous year.

https://blog.apnic.net/2016/10/25/trouble-nat-part-1/
https://blog.apnic.net/2016/10/26/trouble-nat-part-2/
https://blog.apnic.net/2016/10/27/trouble-nat-part-3/

Slides if that is TL;DR:

https://www.ausnog.net/sites/default/files/ausnog-2016/presentations/1.2_Mark_Smith_AusNOG2016.pdf

Getting rid of NAT is why I've spent so much of my own time on IPv6 here in
the IETF.

My concern is if we
> consideration to how they might be made to work reasonably,

I've given it serious consideration. It's not about whether it can be made
to work, to me it is about how hard it is going to be to fix it when it
breaks.

I consider EH insertion or EH removal so bad that I would much rather
deploy IPv6 with NAT, because at least with NAT, in one of the packet
directions, the NAT device overwrites the packets' source address with its
own. I can troubleshoot broken NAT much easier than I'll be able to
troubleshoot anonymous EH insertion or removal.

perhaps in
> where intermediate nodes are mucking with TCP payload).

I don't think we are obligated to accommodate and facilitate special cases
that comes along, even if there is a level of popularity.

IPv6 is supposed to be the general purpose Internet and internetworking
protocol. Being general purpose means good enough for the majority of
cases, may not be good enough for special cases.

If those special cases can't compromise their requirements to suit IPv6,
then they shouldn't use IPv6. They should come up with something different
that is much more tailored and specialised that better suits their
requirements.

Regards,
Mark.

> Tom
>
> >
> > Regards,
> > Mark.
> >
> >>
> >> Tom
> >> >
> >> >
> >> > How does TI-LFA work when the original packet already contains a
> >> > How does TI-LFA work when the node directly upstream of the link

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 May 2020 07:52:29 +1000

> However, many customers do not wish to buy products that will not interoperate with other products. As the histories of SNA, DECnet, Netware, Banyan Vines, and Appletalk show, proprietary networkin…

I've worked on a networks that were running a number of those
protocols, which was about the time "open systems" and movement to
non-proprietary protocols was occurring. Getting away from being
locked into a single vendor was the motivation.

All this "we want to be able to do what we like in a limited domain"
seems to me that it might be recreating the opportunity for being
locked into a single vendor who has their own proprietary "limited
domain" version of IPv6. You might get fooled because you think you're
buying IPv6 when you're actually not.

Regards,
Mark.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 00:13:01 +0200

> locked into a single vendor

It would be perhaps interesting to see how did you come up with such a
conclusion that discussed support is only available from single vendor ?

I actually see something opposite ... single vendor even though goes out
and does the public demo ... on the lists states some sort of dislike. And
I guess this is all ok.

In IETF we go by rough consensus so documents move fwd even if not everyone
is OK with it.

Thx,
R.

On Tue, May 12, 2020 at 11:53 PM Mark Smith <[email-masked]> wrote:

> > Yes, the IETF is not the Protocol Police. Interpol will not issue Red
> Notices for us. Any company can sell products that deviate from IETF
> standards, and any customer can buy them.
> >
> > However, many customers do not wish to buy products that will not
> interoperate with other products. As the histories of SNA, DECnet, Netware,
> Banyan Vines, and Appletalk show, proprietary networking solutions only
> last as long as the vendor's monopoly.
> >
>
> > > Cisco has demonstrated TILFA with SRH insertion at EANTC-2019.
> http://www.eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-MPLSSDNNFV2019-WhitePaper-v1.2.pdf
> > >
> > >
> > >
> > > This feature is available to all customers -supported since XR
> 6.6.1-.. Please contact your Cisco account team if you want further details
> on cisco products or need assistance.
> > >
> > >
> > >
> > > Thank you,
> > >
> > > Pablo.
> > >
> > >
> > >
> > > While I fully realize that running code is not mandatory in the IETF –
> there have been numerous assertions about what is harmful and not harmful
> etc, and coupled with the deployment draft, I presume there is running code
> from the perspective of the authors..
> > >
> > >
> > >
> > > Would you be prepared to disclose the release of code where SRH and
> this functionality is actually implemented – since I’d like to run a series
> of verification tests against it to test the effects on my network and I’m
> sure others would be interested in doing the same.  I can also then test
> against the Juniper implementation as tested at the EANTC and run my own
> inter-op tests and test the real effects this has on the network in a
> manner that makes sense.
> > >
> > >
> > >
> > > Obviously however testing against a single vendor code is not ideal –
> and since the assertions are being made and in light of the deployment
> draft – I am figuring that you must actually have running code that is in
> the field? (I know on all code versions I have tested that are GA I have
> yet to see any SRH on any packet capture that I have done – hence I have
> been unable to do any verification testing myself against the claims made)
> > >
> > >
> > >
> > > Thanks
> > >
> > >
> > >
> > > Andrew
> > >
> > >
> > >
> > >
> > >
> > > *From: *ipv6 <[email-masked] <mailto:[email-masked]>>
> on behalf of "Pablo Camarillo (pcamaril)" <pcamaril=
> [email-masked] <mailto:pcamaril=[email-masked]>>
> > > *To: *Gyan Mishra <[email-masked] <mailto:[email-masked]
> >>
> > > SRH insertion is NOT part of
> draft-ietf-spring-srv6-network-programming-15.
> > >
> > > *Cc:* Ron Bonica <rbonica=[email-masked] <mailto:rbonica
> =[email-masked]>>; 6man <[email-masked] <mailto:[email-masked]
> >>
> > > If we are all in agreement with the prepend (6in6) encap) workaround
> can we have the PGM draft updated to reflect.
> > >
> > >
> > >
> > > All
> > >
> > >
> > >
> [email-masked] <mailto:[email-masked]>> wrote:
> > >
> > >     Hi Robert,
> > >
> > >     > When an operator is serious about good data plane protection
> with TI-LFA all nodes in the network will be enabled for SR. The less
> overhead required for the protection the better. You may just not have a
> room for adding additional 40 bytes to each packet at each potential PLR
> without fragmentation.
> > >     >
> > >     > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> > >     >
> > >     Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> > >

---

From: S Moonesamy <[email-masked]>
Date: Tue, 12 May 2020 15:16:25 -0700

Hello,
>IPv7 that there should be a sub-version number.

IPv7 was specified in RFC 1475.

Regards,
S. Moonesamy

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 13 May 2020 10:42:47 +0100

> On 12 May 2020, at 21:29, Brian E Carpenter <[email-masked]> wrote:
> 

The big questions for me is the extent to which it should be self describing vis described by reference to context, and the extent to which it should be both the UNI and the network protocol.

Like it or hate it look how powerful MPLS became through the generality that a 20bit pointer to a procedure in the NPU and an arbitrary stack provided.

The self describing nature of IP is both an advantage and a significant limitation to its future extensibility.

So I am not sure if we need a sub-version or not, but we do need to look at building generality in from the beginning.

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 11:48:30 +0200

Stewart,

Don't we already have this indirection with IPv6 today ? And I am not
talking about SRv6 ... just in general least significant bits can encode
any function of the ultimate destination.

Such function can for example be of 20 bits and be used as context demux
for packets.

I am not talking about path engineering ... just flexibility an endpoint
can expose already today with vanilla v6.

Thx,
R.

On Wed, May 13, 2020 at 11:42 AM Stewart Bryant <[email-masked]>
wrote:

> The big questions for me is the extent to which it should be self
> describing vis described by reference to context, and the extent to which
> it should be both the UNI and the network protocol.
>
> Like it or hate it look how powerful MPLS became through the generality
> that a 20bit pointer to a procedure in the NPU and an arbitrary stack
> provided.
>
> So I am not sure if we need a sub-version or not, but we do need to look
> at building generality in from the beginning.
>
> - Stewart
>
>
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 13 May 2020 11:49:50 +0100

I am glad that we accept the NP is not SR!  Although it took a long time to get there, both in terms of the disintertwining and realisation that the concept was needed. It is a long time since I read it, but I am concerned about whether it has the full generality of the opaque instruction that MPLS has. Assuming that it has the next issue and it is one we are discussing here is the overhead of adding a new instruction to a packet in flight.

- Stewart

> On 13 May 2020, at 10:48, Robert Raszuk <[email-masked]> wrote:
> 
> Stewart,
> 
> Don't we already have this indirection with IPv6 today ? And I am not talking about SRv6 ... just in general least significant bits can encode any function of the ultimate destination. 
> 
> Such function can for example be of 20 bits and be used as context demux for packets. 
> 
> I am not talking about path engineering ... just flexibility an endpoint can expose already today with vanilla v6. 
> 
> Thx,
> R.
> 
> On Wed, May 13, 2020 at 11:42 AM Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 12 May 2020, at 21:29, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 May 2020 07:56:20 -0700

On Tue, May 12, 2020 at 2:44 PM Mark Smith <[email-masked]> wrote:
> The presence of an IOAM header in a packet is the selector of whether IOAM processing occurs, and whether an IOAM header is present when the packet leaves the node.
>
> 1. packet is link-layer decapsulated (including IPv6 virtual-link layer (tunnel) decap)
> 2. As packet has IOAM header, IOAM info and packet passed to IOAM function to process/update IOAM information.
> 3. Once IOAM processing complete, packet's IP DA is looked up, determining egress interface and link-layer encapsulation.
> 4. The packet is link-layer encapsulated (possibly in IPv6 virtual link-layer/tunnel) with the IOAM header between the link-layer header and the IP packet, and sent on its way.

Mark,

So that would basically be per link IP-IP encapsulation . That
presumes that every possible node in the path understands and
processes the encapsulation and also there would be considerable
processing overhead at every intermediate node as opposed to just the
ingress and egress points. I think this approach would be a hard sell.

Tom

>
> for a non-IOAM packet, (standard IP forwarding, just showing for completeness)
>
> 3. packet's IP DA is looked up, determining egress interface and link-layer encapsulation.
> The information produced by IP DA lookups in both cases is the same, so packets with or without IOAM headers will follow the same path through the network if they have the same DA.
>
>>
>> <snip>
>
>
>>
> I don't think it will ever make sense to me, and I've thought about the idea of insertion verses encapsulation since the invention of 802.1Q in around the early 2000s, verses the Eth-in-Eth tunelling pre-standard solution Cisco I had deployed.
>
> 802.1Q violates the purpose of the FCS, which is a path integrity check between the frame's original source and its final destination.
>
>>
>> >
>
>
>>
>> <snip>
>>
> Here's my 3 part, 4500 word essay, from an operators point of view, on the trouble with NAT, based on my AusNOG presentation on that topic in the previous year.
>
> Getting rid of NAT is why I've spent so much of my own time on IPv6 here in the IETF.
>
>
>> My concern is if we
> I've given it serious consideration. It's not about whether it can be made to work, to me it is about how hard it is going to be to fix it when it breaks.
>
> I consider EH insertion or EH removal so bad that I would much rather deploy IPv6 with NAT, because at least with NAT, in one of the packet directions, the NAT device overwrites the packets' source address with its own. I can troubleshoot broken NAT much easier than I'll be able to troubleshoot anonymous EH insertion or removal.
>
>
>> perhaps in
> I don't think we are obligated to accommodate and facilitate special cases that comes along, even if there is a level of popularity.
>
> IPv6 is supposed to be the general purpose Internet and internetworking protocol. Being general purpose means good enough for the majority of cases, may not be good enough for special cases.
>
> If those special cases can't compromise their requirements to suit IPv6, then they shouldn't use IPv6. They should come up with something different that is much more tailored and specialised that better suits their requirements.
>
>
> Regards,
> Mark.
>
>>
>> Tom
>>
>> >
>> > Regards,
>> > Mark.
>> >
>> >>
>> >> Tom
>> >> >
>> >> >

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 13 May 2020 08:28:07 -0700

On Wed, May 13, 2020 at 3:50 AM Stewart Bryant <[email-masked]>
wrote:

> I am glad that we accept the NP is not SR!  Although it took a long time
> to get there, both in terms of the disintertwining and realisation that the
> concept was needed. It is a long time since I read it, but I am concerned
> about whether it has the full generality of the opaque instruction that
> MPLS has.
>
I guess, it has.

Assuming that it has the next issue and it is one we are discussing here is
> the overhead of adding a new instruction to a packet in flight.
>

That overhead per 8200 is 40 bytes aka encapsulation (with all good reasons
raised again and again why it has to be like that in L3), where in

L2.5 it is 4 bytes.  Though we may never get to 4 bytes we don't want it to
be 40 bytes, that's the holy grail of insert discussion (push).

The next thing is removal (pop) to me though this is being discussed and in
the document as PSP. The question is not at penultimate node

(regardless of benefit i.e., it is marginal or not) and segment end point
but at any node in the network.

I think at some level we are seeking to  have  these very basic
functionalities needed not only for TI-LFA but other inter-AS scenarios in
a single

domain.  We can all see the difficulties in the underlying  architecture to
get these while taking the goodies it offers (like the UNI and self-

description you mentioned). We need both and unfortunately I don't think
any other RH would get us  there.

--
Uma C.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 13 May 2020 13:31:09 -0300

On 13/5/20 12:28, Uma Chunduri wrote:
> 
> 
>     On Wed, May 13, 2020 at 3:50 AM Stewart Bryant
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         I am glad that we accept the NP is not SR!  Although it took a
>         long time to get there, both in terms of the disintertwining and
>         realisation that the concept was needed. It is a long time since
>         I read it, but I am concerned about whether it has the full
>         generality of the opaque instruction that MPLS has.
> 
> I guess, it has.
> 
>         Assuming that it has the next issue and it is one we are
>         discussing here is the overhead of adding a new instruction to a
>         packet in flight.
> 
> That overhead per 8200 is 40 bytes aka encapsulation (with all good 
> reasons raised again and again why it has to be like that in L3), where in
> 
> L2.5 it is 4 bytes.  Though we may never get to 4 bytes we don't want it 
> to be 40 bytes, that's the holy grail of insert discussion (push).

So you want IPv6, but don't want 40 bytes of overhead. Well, I tell you 
what: those 40 bytes of overhead *are* IPv6.

That should be an indication that you should probably accept it, do 
other smarts to reduce overall overhead, or you might need to look at a 
different protocol.

I find it amusing to use 128-bit labels for what's pretending to be a 
limited domain, and then be concerned about the overhead of the ipv6 header.

As much as I find amusing to have nodes that claim to support IPv6 (and 
hence should be able to ignore a RH that has a SL==0) but they violate 
the spec and fail miserably, so then there's a proposal to violate the 
spec (PSP) to cope with that.

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

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 13 May 2020 12:15:57 -0700

Hi Fernando,

On Wed, May 13, 2020 at 9:31 AM Fernando Gont <[email-masked]> wrote:

>
> So you want IPv6, but don't want 40 bytes of overhead.

Yes - an E2E protocol and I know it is not possible. See below..

> Well, I tell you

I won't disagree.

> That should be an indication that you should probably accept it, do

other smarts to reduce overall overhead,

This is relatively the easier part of the story. And we have already 'n'
(almost) proposal out there.

The one being discussed
https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-15 and various
other proposals

like https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-np-01,
uSIDs, Tom H's proposal, Greg M's proposal and many more I guess.

> or you might need to look at a

different protocol.

This is where I see a problem overall. There is another protocol which is
similar  and we know the IAB

statement https://www.iab.org/2016/11/07/iab-statement-on-ipv6/. So
practically, we have only one protocol i.e., IPv6.

So, I see you are simply saying it's not possible to have both efficiency
and new requirements in a reasonable way (I know the disagreement on

drafted solutions and the dissent rightfully from some folks)  brought-in
here not only from SRv6 pov, but also from IOAM and early multicast/BIER

 discussions. Given the barrier to change internet STD/8200 (even for a
clarification), we are kind of boxed with the current extensibility
constructs

 it has. Even in one operator domain. I am willing to listen and want to
know your thoughts here. Please don't discount everything as few

additional bytes. The domain I am looking into right now, every additional
byte of overhead  on the packet matters. This may not be big issue in

some other places (where IOAM is sought to be deployed originally i.e.,
inside a DC).

I concur with the point raised in this thread
https://mailarchive.ietf.org/arch/msg/ipv6/0k24SD9iFUW3tmi9EsDAaEPqNi0/

Thank you!
--
Uma C.

Fernando Gont

SI6 Networks

---

From: Fernando Gont <[email-masked]>
Date: Wed, 13 May 2020 16:37:26 -0300

Hello, Uma,

On 13/5/20 16:15, Uma Chunduri wrote:
[....]
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-15 and 
> various other proposals

As far as I understand, e.g. this proposal doesn't propose header insertion.

And yes, if I were to do this, and was concerned about header size, I 
would certainly use smaller labels (as opposed to 128-bit labels) as in 
this document.

[..]
> 
> So, I see you are simply saying it's not possible to have both 
> efficiency and new requirements in a reasonable way (I know the 
> disagreement on

No. What I'm saying is that, if your concerned about overhead, avoid 
introducing it (as in the segment-routing header). Introducing overhead 
and then screwing up the architecture to make up for it is a no-go, IMO.

> clarification), we are kind of boxed with the current extensibility 

My take is that, before screwing up the architecture, one should better 
do proper engineering where bits can be more easily saved, leading to a 
clean architecture.

IMO, al the TI-FA/PSP and earlier insertion proposals are horrible hacks 
mean to deal with:

* Boxes that claim to be IPv6-compatible but cannot even handle an IPv6 
header chain

* The overhead introduced with core blocks of the technology, such as 
the segment-routing header.

Thanks,