Subject: END SID Without SRH

From: Ron Bonica <[email-masked]>
Date: Fri, 7 Jun 2019 14:26:09 +0000

Darren,

This isn't a blocker. Just a surprising behavior that never struck me before.

Assume that an SRv6 router receives a packet whose destination address is an END SID. The packet does not contain any extension headers at all.

If the next header after the IPv6 header is IPv4 or IPv6, the router removes the outer header and forwards the payload.

If the next header after the IPv6 header is TCP, the router discards the packet and sends an ICMP Parameter Problem message back to the source.

Am I reading the spec correctly?

                                            Ron

Juniper Internal

---

From: Ron Bonica <[email-masked]>
Date: Tue, 11 Jun 2019 13:54:48 +0000

Hi Darren,

I haven't seen a response to this question. Maybe I wasn't clear.

The packet described below has no extension headers at all. This, of course, means that it doesn't have an SRH.

I look forward to your response.

                                                               Ron

Juniper Internal
From: Ron Bonica
Sent: Friday, June 7, 2019 10:26 AM
To: 6man WG <[email-masked]>
Subject: END SID Without SRH

Darren,

                                            Ron

Juniper Internal

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 11 Jun 2019 16:07:24 +0000

Hi Ron, I’ve been traveling and I’m a bit behind on emails to the list (catching up later today).

Yes you read that section correctly.

Darren

On Jun 11, 2019, at 9:54 AM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darren,

I haven’t seen a response to this question. Maybe I wasn’t clear.

The packet described below has no extension headers at all. This, of course, means that it doesn’t have an SRH.

                                                               Ron

Juniper Internal
From: Ron Bonica
Sent: Friday, June 7, 2019 10:26 AM
To: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: END SID Without SRH

Darren,

This isn’t a blocker. Just a surprising behavior that never struck me before.

                                            Ron

Juniper Internal

---

From: Tom Herbert <[email-masked]>
Date: Tue, 11 Jun 2019 12:19:16 -0700

> If the next header after the IPv6 header is TCP, the router discards the packet and sends an ICMP Parameter Problem message back to the source.

Ron,

Extrapolating as to why you think this is surprising behavior (please
correct me if this is wrong), but as I read it, this would be true for
any transport protocol and allows the possibility of hosts that don't
even know what segment routing is to receive the parameter error. For
instance, if someone were just innocently pinging the router's
address, which happens also to be an END SID, the source of the ping
would get the parameter error. In that case, the host might not even
know what segment routing is and much less have any clue why its
getting a parameter problem pointing to the nexthdr field for an
otherwise simple IPv6 packet.

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Tue, 11 Jun 2019 23:52:08 +0000

Tom,

Close, but not exactly.

I am surprised that a document whose title is " IPv6 Segment Routing Header (SRH)" describes behavior changes that occur when the SRH is not present.

Personally, I think that this is an indication that the draft does more than define the SRH, but I am willing to accept that I am in the minority on this point.

                                                    Ron

Juniper Internal

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Tuesday, June 11, 2019 3:19 PM
To: Ron Bonica <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: END SID Without SRH

Ron,

Extrapolating as to why you think this is surprising behavior (please correct me if this is wrong), but as I read it, this would be true for any transport protocol and allows the possibility of hosts that don't even know what segment routing is to receive the parameter error. For instance, if someone were just innocently pinging the router's address, which happens also to be an END SID, the source of the ping would get the parameter error. In that case, the host might not even know what segment routing is and much less have any clue why its getting a parameter problem pointing to the nexthdr field for an otherwise simple IPv6 packet.

Tom

> Administrative Requests: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzo
> CI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=9ASj40JkUp_IP94KYpx
> 2kuAwzMvXveo2lvlaY_frSJU&s=jsc2nf5cRibLHNNp9CDwxadf-QtMl8B1X0Vg-5uBBcc
> &e=

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Jun 2019 10:59:32 +1000

On Sat., 8 Jun. 2019, 00:27 Ron Bonica, <rbonica=
[email-masked]> wrote:

> Assume that an SRv6 router receives a packet whose destination address is
> an END SID. The packet does not contain any extension headers at all.
>
>
>
> If the next header after the IPv6 header is IPv4 or IPv6, the router
> removes the outer header and forwards the payload.
>
>
>
> If the next header after the IPv6 header is TCP, the router discards the
> packet and sends an ICMP Parameter Problem message back to the source.
>

Per RFC 8200's definition of host and router, the packet has arrived at the
destination host, so the TCP segment should be handed up to the TCP layer
for processing, and if there is no matching TCP port, a TCP reset is sent
back to the source.

I don't think any other processing would be compliant with RFC 8200, and
operationally it would be very confusing - the value in the packet's
destination address field isn't being used by a device holding that address
as a destination address.

Regards,
Mark.

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Wed, 12 Jun 2019 05:25:24 +0000

Hi:

But, I think the SRv6 SID function in draft SRH is same as that ENDPOINT defined within 4.1 section of draft "SRv6 networking programming", where the following sentences are from:
A local SID could be bound to a function which authorizes the
   decapsulation of an outer header (e.g.  IPinIP) or the punting of the
   packet to TCP, UDP or any other protocol.  This however needs to be
   explicitly defined in the function bound to the local SID.  By
   default, a local SID bound to the well-known function "End"neither
   allows the decapsulation of an outer header nor the cleanup of an
   SRH.  As a consequence, an End SID cannot be the last SID of an SRH
   and cannot be the DA of a packet without SRH.

According to above, Should the SR source node NOT put END SID as last SID in SRH segment list by default? If we want to implement the function decapsulation of outer IPv6 header, such as IPinIP scenario, DO we need define a new SID for that? Or the SRv6 source node should put normal ipv6@ pointing to tunnel termination router as last member in Segment list? In other words, Can normal IPv6 address (not from SID prefix block) be included as last member in Segment list?
--------------------------------------
Thank you !

WANG Weibin

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 2019年6月12日 7:52
To: Tom Herbert <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: RE: END SID Without SRH

Tom,

Close, but not exactly.

                                                    Ron

Juniper Internal

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Tuesday, June 11, 2019 3:19 PM
To: Ron Bonica <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: END SID Without SRH

Ron,

Tom

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2019 09:29:41 +0200

> Per RFC 8200's definition of host and router, the packet has arrived at the destination host, so the TCP segment should be handed up to the TCP layer for processing, and if there is no matching TCP port, a TCP reset is sent back to the source.
> 
> I don't think any other processing would be compliant with RFC 8200, and operationally it would be very confusing - the value in the packet's destination address field isn't being used by a device holding that address as a destination address.

Traditionally an address identifies an interface (or set of interfaces).
But we use addresses in many different ways. Ranging from NAT64 IPv6 prefixes that represent the IPv4 Internet to IPv6 addresses being used to represent data blocks in a video.
In userland networking one could imagine an IPv6 address representing an individual TCP application.

My understanding (which might be flawed, mind you) is that the SID is an "forwarding instruction" or represents a service. It is not the address of an interface point of attachment.

Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Jun 2019 18:56:37 +1000

On Wed., 12 Jun. 2019, 17:29 Ole Troan, <[email-masked]> wrote:

> > Per RFC 8200's definition of host and router, the packet has arrived at
> the destination host, so the TCP segment should be handed up to the TCP
> layer for processing, and if there is no matching TCP port, a TCP reset is
> sent back to the source.
> >
> But we use addresses in many different ways. Ranging from NAT64 IPv6
> prefixes that represent the IPv4 Internet to IPv6 addresses being used to
> represent data blocks in a video.

Certainly. The way anycast is commonly used is an example. Multicast is too
because groups in many cases represent applications or services rather than
just the destination nodes.

The thing is that in all (compliant) cases, the destination address
identifies the point where forwarding, using the IPv6 fixed header, towards
the DA address stops, and next layer up processing starts.

So in Ron's example (packet with an END SID DA, no extension headers at
all, NH of TCP), if the next header in the packet is a TCP header when it
arrives at the DA that is the END SID, then TCP processing is what happens
to the packet next.

If SR is saying it doesn't, then SR is describing processing rules that
don't comply with RFC 8200, because SR would be ignoring the value in the
packet's Next Header field.

> My understanding (which might be flawed, mind you) is that the SID is an
> "forwarding instruction" or represents a service. It is not the address of
> an interface point of attachment.

I'd generally describe these types of addresses as routeable service or
function addresses.

They're not unicast addresses because it is valid to have multiple devices
in a network have them.

They're not (normally) multicast addresses, because packets aren't intended
to be duplicated at various junctions within the network.

I think they're anycast addresses or very close to anycast addresses.
Identify a service, function or application layer protocol within the
address, valid to exist on one or more nodes in the network, but only to be
delivered to one of them.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Jun 2019 11:07:47 +0200

Mark,

> Certainly. The way anycast is commonly used is an example. Multicast is too because groups in many cases represent applications or services rather than just the destination nodes.
> 
> The thing is that in all (compliant) cases, the destination address identifies the point where forwarding, using the IPv6 fixed header, towards the DA address stops, and next layer up processing starts. 
> 
> So in Ron's example (packet with an END SID DA, no extension headers at all, NH of TCP), if the next header in the packet is a TCP header when it arrives at the DA that is the END SID, then TCP processing is what happens to the packet next.
> 
> If SR is saying it doesn't, then SR is describing processing rules that don't comply with RFC 8200, because SR would be ignoring the value in the packet's Next Header field.

Take my example of user-land networking, where I give my BGP application an IPv6 address.
That packet is forwarded to the application itself (let's assume it has a TCP library implementation). 
It doesn't really make any sense to give that packet to the host's TCP stack. It wouldn't know what to do with it.
I _think_ the same thing applies with SIDs.

Best regards,
Ole

> I'd generally describe these types of addresses as routeable service or function addresses.
> 
> They're not unicast addresses because it is valid to have multiple devices in a network have them.
> 
> They're not (normally) multicast addresses, because packets aren't intended to be duplicated at various junctions within the network.
> 
> I think they're anycast addresses or very close to anycast addresses. Identify a service, function or application layer protocol within the address, valid to exist on one or more nodes in the network, but only to be delivered to one of them.
> 
> Regards,
> Mark.
>  
> 
> Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 Jun 2019 14:15:49 +0000

Hello Wang,

Before we start, it is not entirely clear that the unnamed SID described in draft-ietf-6man-segment-routing-header is the same as any of the SIDs described in the network programming draft. 

But even if the unnamed SID were the same as the END SID, we are not discussing the relative position of the END SID in the SRH. We are discussing whether a document whose title is " IPv6 Segment Routing Header (SRH)" should describe behavior changes that occur when the SRH is not present.

                                                                                           Ron

Juniper Internal

-----Original Message-----
From: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]> 
Sent: Wednesday, June 12, 2019 1:25 AM
To: Ron Bonica <[email-masked]>; Tom Herbert <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: RE: END SID Without SRH

Hi:

WANG Weibin

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: 2019年6月12日 7:52
To: Tom Herbert <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: RE: END SID Without SRH

Tom,

Close, but not exactly.

                                                    Ron

Juniper Internal

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Tuesday, June 11, 2019 3:19 PM
To: Ron Bonica <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: END SID Without SRH

Ron,

Tom

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=TZXeGAVoqh8RRFRx9DbZpp22APN6Ol6LFFZRa-yxBQ4&s=A2EzKSyTFVoYaLMcWD57X2VoDlpHGKCJNDrnqe5QMUY&e= 
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Wed, 12 Jun 2019 08:25:06 -0700

> I _think_ the same thing applies with SIDs.
Ole,

A host can always drop packets it receives and still claim
correctness. The problem here is the new ICMP message that can be sent
in response to a plain IPv6 packet. The ICMP error is segment routing
specific, however it can be sent to hosts that do not support segment
routing. The error is at best confusing to those hosts as well as any
legacy network monitoring that captures ICMP errors.

An alternative is to either just drop the packet without sending the
error, or maybe send an existing error-- possibly Parameter Problem
for Unrecognized Nexthdr, or Destination Unreachable with code 1 or 4.

One nit, a request for a new ICMP Parameter Problem code should be
mentioned in the IANA considerations section.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 Jun 2019 18:54:40 +0000

Ole,

In your example, what is the IPv6 next header value?

                                      Ron

Juniper Internal

-----Original Message-----
From: Ole Troan <[email-masked]> 
Sent: Wednesday, June 12, 2019 5:08 AM
To: Mark Smith <[email-masked]>
Cc: Ron Bonica <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: END SID Without SRH

Mark,

Best regards,
Ole

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 12 Jun 2019 21:52:29 +0000

Hello everyone.

This document defines an SRH and a SID, and how that SID is processed.

I expect anyone "surprised" by this fact should have read this draft at some point:
a - within the past 2 years; since this document has defined a SID and its processing.
b - within the past 13 months; since section 4.3.1 specifically described discarding the packet based on upper layer header being processed.
c - within the past 8 months; since the current version of 4.3.1.2 was updated with the new ICMP error code, published, and the WG was notified via email.

And recall section 3.1 defines a Source SR node as 
   "any node that originates an IPv6 packet with a
   segment (i.e.  SRv6 SID) in the destination address of the IPv6
   header.  The packet leaving the source SR Node may or may not contain
   an SRH."

In other words, there is no surprise.

Darren.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Jun 2019 16:04:27 -0700

Darren,

> On Jun 12, 2019, at 2:52 PM, Darren Dukes (ddukes) <[email-masked]> wrote:
> 
> Hello everyone.
> 

I am trying to sort out this discussion. 

I think the text in the draft this discussion is about is:

>  4.3.1.2.  Upper-layer Header or No Next Header
> 
>    When processing the Upper-layer header of a packet matching a FIB
>    entry locally instantiated as an SRv6 SID defined in this document.
> 
>    IF (Upper-layer Header is IPv4 or IPv6) and
>        local configuration permits {
>      Perform IPv6 decapsulation
>      Resubmit the decapsulated packet to the IPv4 or IPv6 module
>    }
>    ELSE {
>      Send an ICMP parameter problem message to the Source Address and
>      discard the packet.  Error code (TBD by IANA) "SR Upper-layer
>      Header Error", pointer set to the offset of the upper-layer
>      header.
>    }
> 
>    A unique error code allows an SR Source node to recognize an error in
>    SID processing at an endpoint.

If I understand it correctly, the case for the action described in this section  is:

   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 SID defined in this document.

A node receiving this packet that knows it is SRv6 SID (because it was locally instantiated), would follow this procedure.   A node who does not know that it is an SRv6 SID, will process the packet normally as defined in RFC8200/etc/etc.

Essentially, a node will only do this if it is in an SRv6 domain because it has had SRv6 SID information configured manually or via some protocol.

Am I correct?

Bob

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 13 Jun 2019 00:57:17 +0000

Hi Bob. See inline.

On Jun 13, 2019, at 1:04 AM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

On Jun 12, 2019, at 2:52 PM, Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:

Hello everyone.

A node receiving this packet that knows it is SRv6 SID (because it was locally instantiated), would follow this procedure.

Correct.

A node who does not know that it is an SRv6 SID, will process the packet normally as defined in RFC8200/etc/etc.

Yes. This case is covered by section by 4.3.3 specifically, where the destination lpm matches a non-local Route.

4.3.3<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-19#section-4.3.3>.  FIB Entry Is A Non-Local Route

Processing is not changed by this document.

Am I correct?

Yes you are correct.

Thanks.
  Darren

Bob

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Jun 2019 19:26:45 -0700

Darren,

> On Jun 12, 2019, at 5:57 PM, Darren Dukes (ddukes) <[email-masked]> wrote:
> 
> Hi Bob. See inline. 
> 
> On Jun 13, 2019, at 1:04 AM, Bob Hinden <[email-masked]> wrote:
> 
>> Darren,
>> 
> 4.3.3. FIB Entry Is A Non-Local Route
> 

Thanks.   I don’t see any issue here, the document is appropriately scoped.

Bob

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 13 Jun 2019 03:20:59 +0000

I agree Bob.

Darren

On Jun 13, 2019, at 4:26 AM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

<snip>

Bob

---

From: Mark Smith <[email-masked]>
Date: Thu, 13 Jun 2019 14:27:58 +1000

On Thu., 13 Jun. 2019, 07:52 Darren Dukes (ddukes), <[email-masked]>
wrote:

> b - within the past 13 months; since section 4.3.1 specifically described
> discarding the packet based on upper layer header being processed.
> c - within the past 8 months; since the current version of 4.3.1.2 was
> updated with the new ICMP error code, published, and the WG was notified
> via email.
>

So one of the contexts I consider is sitting in front of a packet capture
tool like Wireshark, and trying to troubleshoot a fault by looking at the
packet.

For the packet Ron described, with no SRH header, there is nothing to
distinguish it from a normal IPv6 packet. The fault would be that the
packet contains a TCP header, yet TCP processing is not occurring.

The DA address in the packet might actually be a SID, but if it is coming
from within the existing IPv6 unicast or multicast spaces, there is no
indication of that.

This SR processing is failing the principle of least surprise. That failure
can cause longer than necessary troubleshooting and longer customers'
services impacts. A network's MTTR is negatively impacted.

Mandating that all packets to be SR processed have an SRH would prevent
this problem. It would also be compliant with RFC 8200, because the
processing to occur on the packet when it arrives at the device with the DA
is explicitly encoded in the packet.

Without a formal SID address space, encoding functions to perform on a
packet in addresses is ambiguous, implicit and when troubleshooting,
non-obvious.

Regards,
Mark.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 13 Jun 2019 07:25:31 +0000

Mark.

You remember your SIDs in your SR domain come from a SID block you created, S/s (see section 5.1) and this destination address falls within that space.

You notice the destination sending an ICMP parameter problem error with a code that says “SR Upper-layer Header Error”.

This is how you tell the source is trying to talk to a destination address that doesn’t speak TCP.

Darren

On Jun 13, 2019, at 6:28 AM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Thu., 13 Jun. 2019, 07:52 Darren Dukes (ddukes), <[email-masked]<mailto:[email-masked]>> wrote:
Hello everyone.

So one of the contexts I consider is sitting in front of a packet capture tool like Wireshark, and trying to troubleshoot a fault by looking at the packet.

For the packet Ron described, with no SRH header, there is nothing to distinguish it from a normal IPv6 packet. The fault would be that the packet contains a TCP header, yet TCP processing is not occurring.

The DA address in the packet might actually be a SID, but if it is coming from within the existing IPv6 unicast or multicast spaces, there is no indication of that.

This SR processing is failing the principle of least surprise. That failure can cause longer than necessary troubleshooting and longer customers' services impacts. A network's MTTR is negatively impacted.

Mandating that all packets to be SR processed have an SRH would prevent this problem. It would also be compliant with RFC 8200, because the processing to occur on the packet when it arrives at the device with the DA is explicitly encoded in the packet.

Without a formal SID address space, encoding functions to perform on a packet in addresses is ambiguous, implicit and when troubleshooting, non-obvious.

Regards,
Mark.

Darren.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 13 Jun 2019 07:03:23 -0700

> This is how you tell the source is trying to talk to a destination address that doesn’t speak TCP.
How is that any different than sending an ICMPv6 parameter problem
error with code 1 that says “Unrecognized Next Header type
encountered”?

> Darren
>
> On Jun 13, 2019, at 6:28 AM, Mark Smith <[email-masked]> wrote:
>
>
>
> On Thu., 13 Jun. 2019, 07:52 Darren Dukes (ddukes), <[email-masked]> wrote:
>>
>> Hello everyone.
>>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 13 Jun 2019 16:34:49 +0000

Read the last paragraph of 4.3.1.2. 

Darren

> On Jun 13, 2019, at 4:03 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Jun 2019 11:44:24 -0500

On Wed, Jun 12, 2019 at 9:26 PM Bob Hinden <[email-masked]> wrote:

> >>> b - within the past 13 months; since section 4.3.1 specifically
> described discarding the packet based on upper layer header being processed.
> >> A node receiving this packet that knows it is SRv6 SID (because it was
> locally instantiated), would follow this procedure.
> >
> > Correct.
> >
> >> A node who does not know that it is an SRv6 SID, will process the
> packet normally as defined in RFC8200/etc/etc.
> >>
> >
> > Yes. This case is covered by section by 4.3.3 specifically, where the
> destination lpm matches a non-local Route.
> >
> >
> >> Essentially, a node will only do this if it is in an SRv6 domain
> because it has had SRv6 SID information configured manually or via some
> protocol.
> >>
> >> Am I correct?
> >
> > Yes you are correct.
> >
>

It might be nice if there was a clear simple statement someplace to the
effect, "IPv6 addresses that are used for SIDs SHOULD NOT also be used and
a regular IPv6 destination."

Thanks
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Tom Herbert <[email-masked]>
Date: Thu, 13 Jun 2019 11:06:37 -0700

Darren,

That's:

"A unique error code allows an SR Source node to recognize an error in
SID processing at an endpoint."

You can call nodes that send a plain IP packets to a SID address "SR
Source nodes" if you wish, but you cannot assume that they know
anything about segment routing or participate in the protocol based on
the destination address. To a source host that doesn't understand
segment routing, getting a segment routing specific ICMP error is
nonsensical (as it would be to network monitoring of ICMP errors).
"Unrecognized next header" code makes sense to everyone, and for those
nodes that do understanding segment routing they can do additional
investigation on the destination address in the ICMP error data to see
if they had mistakingly sent to a SID.

Tom

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jun 2019 09:36:02 +1000

> You remember your SIDs in your SR domain come from a SID block you created, S/s (see section 5.1) and this destination address falls within that space.

Humans really aren't all that good at remembering numbers. We even
make errors when

If IPv6 addresses are going to have special meaning and unconventional
RFC 8200 processing, they should come from a special purpose address
space - not one that is from within any of the the existing unicast
address spaces.

That would make it possible for if tools like Wireshark could have
know of a well known SID prefix so that they can identify and mark SR
packets. It reduces the operator's mental load while troubleshooting.
(Having

There are a lot of defined reserved IPv6 and IPv4 prefixes, for uses
that are more obscure than I'd think SR is intended to be e.g.
198.18.0.0/15 for Benchmarking, or 2001::/32 TEREDO.

I still think mandating the SRH in all to be SR processed packets is
better, even with a common well-known IANA assigned SID specific IPv6
prefix. It is explicit, rather than implicit in the packet's IPv6
addresses, and leverages existing mechanisms to deal with received
packet errors (i.e., ICMPv6 Parameter Problem,

> You notice the destination sending an ICMP parameter problem error with a code that says “SR Upper-layer Header Error”.

What if the device receiving the packet isn't SR capable or aware? It
will try to pass the packet to up to the TCP stack and process it. If
it generates a TCP RESET, it'll send the TCP RESET back to the SR
aware node than sent the packet in the first place.

Would that receiving SR node know what to do with a TCP RESET (or a
UDP triggered ICMPv6 Destination Unreachable Port Unreachable?) from
what is supposed to be an SR node?

I don't see any advice to only use ULA address space for SIDs
(assuming an IANA reserved prefix isn't chose), so with SIDs that fall
from within the GUA unicast address space, the likelihood of packets
leaking to non-SR aware nodes increases.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jun 2019 09:59:22 +1000

On Fri, 14 Jun 2019 at 02:45, David Farmer <[email-masked]> wrote:

<snip>

> It might be nice if there was a clear simple statement someplace to the effect, "IPv6 addresses that are used for SIDs SHOULD NOT also be used and a regular IPv6 destination."
>

What's a "regular IPv6 destination"?

It would need to be explicitly defined now, because it has been implicit.

It's one thing to encode function or service destinations in IPv6
addresses. That's is done and supported in IPv6 with anycast and
multicast.

When the packet arrives at that function or service destination
encoded in an anycast or multicast address, it is processed as per the
instructions encoded in the chain of EH and upper layer headers in the
packet. For example, even though the use of TCP with multicast doesn't
make sense, once the multicast packet holding the TCP segment has
arrived at a node with the multicast address, the node is to hand the
TCP segment to the TCP module.

It's quite a different thing to encode packet processing in the
destination address that contradicts or ignores the instructions
encoded in the chain of EH and upper layer headers. I think this might
be a more significant change to the IPv6 packet processing model and
operation than we realise.

RFC 8200 is very clear and explicit on multiple occasions about
following the processing encoded in the EH chain and upper layer
headers when the packet arrives at the destination device that holds
the matching DA:

4.  IPv6 Extension Headers

...

"Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header." (For context for the next two quotes.)

...

"At the destination node, normal demultiplexing on the Next Header
   field of the IPv6 header invokes the module to process the first
   extension header, or the upper-layer header if no extension header is
   present.  The contents and semantics of each extension header
   determine whether or not to proceed to the next header. ***Therefore,
   extension headers must be processed strictly in the order they appear
   in the packet***; a receiver must not, for example, scan through a
   packet looking for a particular kind of extension header and process
   that header prior to processing all preceding ones."

...

4.1.  Extension Header Order

...

  "IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation."

...

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jun 2019 16:25:21 +1000

Oops, not quite complete email.

> Humans really aren't all that good at remembering numbers. We even

copying numbers from a from one place to another, seconds apart. Typos
in IP addresses has been a very common cause of faults in my
experience, and they're fundamentally human memory failures.

We also forget we haven't completed an email when we push 'send' it
the next day!

> packet errors (i.e., ICMPv6 Parameter Problem,

Code 0 - Erroneous header field encountered or more specific Code 2 -
Unrecognized IPv6 option encountered.

<snip>

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Jun 2019 08:52:38 +0200

Mark,

[snip]

> pWhat's a "regular IPv6 destination"?
> 

I think that' a way too literal interpretation of 8200.

Especially in the context of routers.
A remote node cannot expect that any combination of the local nodes's destination address and header chain will be processed.
A router will not process your protocol 89 packet on any DA. In the VPP MAP-E implementation, the BR address is a "service address", and will drop anything that isn't protocol 4 (as well as any packet with extension header).

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jun 2019 20:18:28 +1000

Hi Ole,

<snip>

> I think that' a way too literal interpretation of 8200.

I think it is the "right amount" of literal when you use RFC 8200's
definitions of 'router' and 'host'.

> Especially in the context of routers.

Router as a device, or a router as a function?

RFC 8200 definitions of a router and a host seem to me to be entirely
functional.

 router       a node that forwards IPv6 packets not explicitly
                addressed to itself.

host         any node that is not a router.

A typical router as a device implements the RFC 8200 router function
in its forwarding plane, and the RFC 8200 host function in its control
plane.

> A remote node cannot expect that any combination of the local nodes's destination address and header chain will be processed.

I agree.

I think it is clear what is supposed to happen when a packet is
received that can't be processed according to the EH / transport layer
header chain:

- the packet gets dropped

- a (possibly rate limited) ICMPv6 error message is sent back to the
source stating the drop cause

There isn't supposed to be "the packet is still processed rather than
dropped, and differently to how the packet's sender specified it to be
processed."

> A router will not process your protocol 89 packet on any DA.

Agree.

First thing that needs to match is the DA of the packet against the
router (device (RFC 8200 router & host))'s local addresses or the
device's processes' multicast addresses.

Once that match occurs, then the packet gets handed up the local stack
to the OSPF process, if it exists. If it doesn't, "Parameter Problem,
Unrecognized Next Header type encountered".

This is IPv6 host processing (because of packet arriving at device
holding the matching DA) where the host doesn't support the protocol
in the packet.

>In the VPP MAP-E implementation, the BR address is a "service address", and will drop anything that isn't protocol 4 (as well as any packet with extension header).
>

And that is and would be the expected behaviour. It doesn't understand
it so it drops it and may send an ICMPv6 error message.

The ambiguity and I think non-compliance with RFC 8200 is when
dropping isn't occurring, and how to process the packet is singularly
encoded in the DA address. This is instead of following what is
explicitly encoded in the following EHs and transport layer headers.
This is contrary to IPv6 host processing of DA match -> EH processing
-> Transport layer -> Application Layer packet processing.

(I started down this path a few years ago by thinking about the
scenario of buying a router (device) from a router vendor, and then
running it as a BGP route reflector or server that isn't ever in the
packet forwarding path. Is it still a "router", or is it now a host?
Per RFC 8200, not a router, only a host, even if it still looks like a
router (device) with a router vendor's logo on it).

Best regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Jun 2019 13:06:49 +0200

Mark,

> -> Transport layer -> Application Layer packet processing.

OK, then I don't understand.
Would you mind spoon feeding me. How is SRH processing different?

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jun 2019 22:16:19 +1000

> Would you mind spoon feeding me. How is SRH processing different?

Because in Ron's original example packet, there was not SRH i.e. a
vanilla IPv6 packet, no SRH, no other EH's, and a directly following
TCP header and payload.

So the packet's DA SR semantics encoded a packet processing meaning
that was contradicting what the packet's IPv6's header following TCP
header said to do.

I'm not against the idea of an IPv6 DA encoding some function or
service meaning or semantics.

It is when the DA is encoding processing on a packet that is contrary
to what the rest of the packet says to the do that I think would cause
a lot of problems. (I've had some bad experiences with people placing
semantic meaning on values that they shouldn't have - 0.0.0.0 is still
a valid although deprecated broadcast address, not a "we can switch on
debugging for our layer 2 device IP address" -
http://lists.ausnog.net/pipermail/ausnog/2017-July/039402.html - (if
they wanted to have a magic address for debugging, they should have
chosen a magic layer 2 address within their own address space for
that)).

Best regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 14 Jun 2019 07:39:55 -0700

Mark,

As understand it, a host with SID addresses only recognize IP in IP
encapsulation and no other upper layer protocols, so other protocols
are unrecognized. If such a host drops packets with unrecognized next
header, e.g. TCP, and sends "Parameter Problem, Unrecognized Next
Header type encountered" that is compliant with RFC8200.

Whether this is desirable behavior is arguable. For instance, I'd
expect the first thing that a user might do when they are see packets
with a segment list failing to be delivered is start pinging addresses
in the segment list. Getting an ICMP error instead of just an ICMP
Echo Reply from a destination doesn't seem particularly helpful to me.

Tom

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Jun 2019 19:40:57 +0200

Mark,

> router (device) with a router vendor's logo on it).

To make another analogy.
Let's say I give my BGP application an IPv6 address. Not an interface, not the "host stack", but the application itself.

Cheers,
Ole

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 15 Jun 2019 19:19:08 -0400

This was discussed on the Spring WG regards to SR and the two major flavors
being "MPLS" & "IPv6" of which MPLS = SR-MPLS -IPv4 & IPv6 Prefix & Adj
segments label stacking with use case being "Core PHP UHP" and IPv6 being
SRv6 "Core PSP & USP" as well as the many SRv6 "non core" permutations for
traffic steering use cases that exist.

So the many permutations of SRv6 makes SRv6 that much more powerful next
gen technology and really a driver for all 6MAN stakeholders towards the
near future IPv6 only as there is alot to gain with SRv6!!

Thank you

 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

On Sat, Jun 15, 2019 at 12:57 PM Gyan Mishra <[email-masked]> wrote:

> Catching up on this thread..hopefully not to late for the wrap up..few
> comments..
>
> With SRv6 since there are many applications of SRV6 that go beyond the
> "core"  use case and that SRv6 can be used for any traffic steering use
> case from SOHO edge to DC to Access layers there are so many use cases that
> come up the discussion regarding End SID ends up with so many permutations.
>
> What I wanted to point out was that for the "core" use case both PHP & UHP
> by the time you get to SR end node you either have PSP or USP function for
> implict-null or explicit null scenario respectively that the SRH header has
> been popped on the P 2nd to last hop node for the PSP function and hop
> egress PE node for the USP function.  So in that scenario when you do a
> ping troublehooting lets say the FEC destination loopback egress PE just as
> with mpls will there be an mpls oam type SRv6 ping that is in the data
> plane versus control plane and that might help answer question also with
> the SRv6 OAM type ping draft which I checked Spring and does not exist yet
> if you have the options to set USP explicit null so the SRH stays intact
> till the egress that can also help with data plane ping processing so you
> don't get the ICMP parameter error.  This is out of scope for 6MAN but I
> think should be brought up to the Spring WG. I think if  you did a ping
> within SR domain the ping is in the data plane forwarding so would have SRH
> by default and would be standard SR domain processing for End SID for
> "core" PSP & USP scenario's respectively.
>
> I think the SRv6 "non core" traffic steering use cases will happen as
> customers move towards IPv6 only and that use case is where the End SID
> scenario comes up where we don't have PSP or USP occuring and then SRH is
> still present.  That is described below after the "core" use case.
>
> For the use case of new green field SRv6 core with BEES BGP enabled
> services etc L3 VPN MVPN EVPN etc below is the SRv6 processing behavior
> which is in Spring SR6 network programming draft sections below which I
> think should be included in the SRH section 4.3.1.1. SRH Processing.
>
> **I took some excerpts from this SRv6 preso**
> http://www.segment-routing.net/tutorials/2017-12-05-srv6-introduction/
>
> SR Segment Endpoints
> • SR Endpoints: SR-capable nodes
> whose address is in the IP DA
> • SR Endpoints inspect the SRH and do:
> – IF Segments Left > 0, THEN
> >Decrement Segments Left ( -1 )
> >Update DA with Segment List [ Segments Left ]
> >Forward according to the new IP DA
>
> SR Segment Endpoints
> • SR Endpoints: SR-capable nodes
> whose address is in the IP DA
> • SR Endpoints inspect the SRH and do:
> – IF Segments Left > 0, THEN
> >Decrement Segments Left ( -1 )
> >Update DA with Segment List [ Segments Left ]
> >Forward according to the new IP DA
> – ELSE (Segments Left = 0)
> *>Remove the IP and SR header*
> >Process the payload:
> • Inner IP: Lookup DA and forward
> • TCP / UDP: Send to socket
> •
>
> https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-00.pdf
>
>
> 4.21. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 21
> 4.21.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 21
> 4.21.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 22
> 4.21.3. USD: Ultimate Segment Decapsulation . . . . . . . . 23
>
> *4.21.1. PSP: Penultimate Segment Pop of the SRH*
> After the instruction ’update the IPv6 DA with SRH[SL]’ is executed,
> the following instructions must be added:
> 1. IF updated SL = 0 & PSP is TRUE
> 2. pop the top SRH ;; Ref1
> Ref1: The received SRH had SL=1. When the last SID is written in the
> DA, the End, End.X and End.T functions with the PSP flavour pop the
> first (top-most) SRH. Subsequent stacked SRH’s may be present but
> are not processed as part of the function.
>
> END.PSP – Penultimate Segment Popping
> • Penultimate Segment Popping (PSP) behavior
> – Decrement Segments Left, update DA
> *– If Segments Left = 0, remove SRH*
> – Forward according to new DA
> • Node 5 advertises prefix A5::/64
> • On 5, the Penultimate Segment Popping behavior is associated with ID 1
> • The corresponding SID is A5::1
>
> END.PSP – Penultimate Segment Popping
> • Penultimate Segment Popping (PSP) behavior
> – Decrement Segments Left, update DA
> *– If Segments Left = 0, remove SRH*
> – Forward according to new DA
> • Node 5 advertises prefix A5::/64
> • On 5, the Penultimate Segment Popping behavior is associated with ID 1
> • The corresponding SID is A5::1
>
> 4.21.2. USP: Ultimate Segment Pop of the SRH
> We insert at the beginning of the pseudo-code the following
> instructions:
> 1. IF NH=SRH & SL = 0 & USP=TRUE ;; Ref1
> *2. pop the top SRH*
> 3. restart the function processing on the modified packet ;; Ref2
>
>  END.USP – Ultimate Segment Popping
> • Ultimate Segment Popping (USP) behavior
> – If Segments Left = 0
> *>Pop the top SRH*
> >Restart the END function processing on the modified packet
> • Decrement Segments Left, update DA
> • Forward according to new DA
> • Node 6 advertises prefix A6::/64
> • A6:: is the last segment in the top SRH
>
> *SRv6 traffic steering use case where the SRH is intact and you get the
> parameter error:*
>
> *I think the text in the draft this discussion is about is..*
>
> IF (Upper-layer Header is IPv4 or IPv6) and*==========================>
> SRv6 domain node processing "non core use case" for End SID *
> ELSE {*======================================================> Non SRv6
> domain node use the standard IP spec rfc 8200 processing *
> *RFC 8200 - bottom of section 4.4*
> 4.4. Routing Header
> If, while processing a received packet, a node encounters a Routing
> header with an unrecognized Routing Type value, the required behavior
> of the node depends on the value of the Segments Left field, as
> follows:
> If Segments Left is zero, the node must ignore the Routing header
> and proceed to process the next header in the packet, whose type
> is identified by the Next Header field in the Routing header.
>
>
> *If Segments Left is non-zero, the node must discard the packet andsend an
> ICMP Parameter Problem, Code 0, message to the packet’sSource Address,
> pointing to the unrecognized Routing Type.*
> If, after processing a Routing header of a received packet, an
> intermediate node determines that the packet is to be forwarded onto
> a link whose link MTU is less than the size of the packet, the node
> must discard the packet and send an ICMP Packet Too Big message to
> the packet’s Source Address.
> The currently defined IPv6 Routing Headers and their status can be
> found at [IANA-RH]. Allocation guidelines for IPv6 Routing Headers
> can be found in [RFC5871].
>
>
> https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-00.pdf
>
>
> *I believe this section is referring to the "non core PSP & USP" SRv6
> steering scenario "End SID" decap*
>
> 4.8. End.DX6: Decapsulation and IPv6 cross-connect
>  The "Endpoint with decapsulation and cross-connect to an array of
>  IPv6 adjacencies" function (End.DX6 for short) is a variant of the
>  End.X function.
>  When N receives a packet destined to S and S is a local End.DX6 SID,
>  N does:
>  1. IF NH=SRH and SL > 0
>  2. drop the packet ;; Ref1
>  3. ELSE IF ENH = 41 ;; Ref2
>  4. pop the (outer) IPv6 header and its extension headers
>  5. forward to layer-3 adjacency bound to the SID S ;; Ref3
>  6. ELSE
>
>
>
> * 7. Send an ICMP parameter problem message ;; Ref4====> RFC 8200 standard
> processing non SRv6 domain node 8. drop the packet Ref1: The End.DX6 SID
> must always be the last SID, or it can be the Destination Address of an
> IPv6 packet with no SRH header.*
>
> Ref2: 41 refers to IPv6 encapsulation as defined by IANA allocation
>  for Internet Protocol Numbers
>  Ref3: Selected based on a hash of the packet’s header (at least SA,
>  DA, Flow Label)
>  Ref4: ICMP error is sent to the source address with error code (TBD
>  by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
>  One of the applications of the End.DX6 function is the L3VPNv6 use-
>  case where a FIB lookup in a specific tenant table at the egress PE
>  is not required. This would be equivalent to the per-CE VPN label in
>  MPLS [RFC4364].
>
> 4.9. End.DX4: Decapsulation and IPv4 cross-connect
>  The "Endpoint with decapsulation and cross-connect to an array of
>  IPv4 adjacencies" function (End.DX4 for short) is a variant of the
>  End.X functions.
>  When N receives a packet destined to S and S is a local End.DX4 SID,
>  N does:
>  1. IF NH=SRH and SL > 0
>  2. drop the packet ;; Ref1
>  3. ELSE IF ENH = 4 ;; Ref2
>  4. pop the (outer) IPv6 header and its extension headers
>  5. forward to layer-3 adjacency bound to the SID S ;; Ref3
>  6. ELSE
>  7. *Send an ICMP parameter problem message ;; Ref4* *====> RFC 8200
> standard processing non SRv6 domain nod*
> * 8. drop the packet*
>  Ref1: The End.DX4 SID must always be the last SID, or it can be the
>  Destination Address of an IPv6 packet with no SRH header.
>  Ref2: 4 refers to IPv4 encapsulation as defined by IANA allocation
>  for Internet Protocol Numbers
>  Ref3: Selected based on a hash of the packet’s header (at least SA,
>  DA, Flow Label)
>  Ref4: ICMP error is sent to the source address with error code (TBD
>  by IANA) "SR Upper-layer Header Error" and pointer set to the NH.
>  One of the applications of the End.DX4 function is the L3VPNv4 use-
>  case where a FIB lookup in a specific tenant table at the egress PE
>  is not required. This would be equivalent to the per-CE VPN label in
>  MPLS [RFC4364].
>
>
> The Spring SRv6 network programming draft has all the SR processing
> functions for SID processing so I wonder if we should reference the entire
> section 4 or maybe include that entire section in this draft.
>
>
> https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-00.pdf
>
>
>  Functions associated with a SID . . . . . . . . . . . . . . . 7
>  4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 8
>  4.2. End.X: Layer-3 cross-connect . . . . . . . . . . . . . . 8
>  4.3. End.T: Specific IPv6 table lookup . . . . . . . . . . . . 9
>  4.4. End.DX2: Decapsulation and L2 cross-connect . . . . . . . 10
>  4.5. End.DX2V: Decapsulation and VLAN L2 table lookup . . . . 11
>  4.6. End.DT2U: Decapsulation and unicast MAC L2 table lookup . 11
>  4.7. End.DT2M: Decapsulation and L2 table flooding . . . . . . 12
>  4.8. End.DX6: Decapsulation and IPv6 cross-connect . . . . . . 13
>  4.9. End.DX4: Decapsulation and IPv4 cross-connect . . . . . . 14
>  4.10. End.DT6: Decapsulation and specific IPv6 table lookup . . 15
>  4.11. End.DT4: Decapsulation and specific IPv4 table lookup . . 15
>  4.12. End.DT46: Decapsulation and specific IP table lookup . . 16
>  4.13. End.B6.Insert: Endpoint bound to an SRv6 policy . . . . . 17
>  4.14. End.B6.Insert.Red: [...] with reduced SRH insertion . . . 18
>  4.15. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps 18
>  4.16. End.B6.Encaps.Red: [...] with reduced SRH insertion . . . 19
>  4.17. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 19
>  4.18. End.S: Endpoint in search of a target in table T . . . . 20
>  4.19. SR-aware application . . . . . . . . . . . . . . . . . . 21
>  4.20. Non SR-aware application . . . . . . . . . . . . . . . . 21
>  4.21. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 21
>  4.21.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 21
>  4.21.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 22
>  4.21.3. USD: Ultimate Segment Decapsulation . . . . . . . . 23
>
> See attached SRv6 preso's from Cisco Live
>
> In the SRv6 preso"3123 srv6" page 20-22 insertion vs encapsulation its
> mentioned that on Non SR -- this goes into the End SID scenario for "non
> core PSP & USP" use case where SRH is removed prior to delivery to
> destination which is similar to the "core" USP or PSP pop.
>
> Insertion Vs. Encapsulation
> •Header Insertion at the Source:
> –Source originates the packet with the SRH
> –SRH is kept and used along the path
> –Packet is delivered to destination with the SRH (plain IPv6 operations)
>
> *>Optionally, the SRH may be removed prior to deliver the packet to
> destination–Use case: source is SRv6 capable*
>
> Insertion Vs. Encapsulation
> •Header Insertion at Ingress:
> –Source originates the packet without any SRH
> –SRH is inserted at ingress
>
> *–SRH is removed prior to deliver the packet to the destination–Use case:
> source is not SRv6 capable*
>
> Insertion Vs. Encapsulation
> •Encapsulation at Ingress :
> –Source originates the packet without any SRH
> –Ingress encapsulates the incoming packet into a new outer IPv6 header
> followed by the SRH
> –Packet is decapsulated at egress (both outer IPv6 header and SRH are
> removed)
> –Use Case:
>
> Thank you
>
> 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
>
> On Fri, Jun 14, 2019 at 1:41 PM Ole Troan <[email-masked]> wrote:
>
>> Mark,
>>
>> Let's say I give my BGP application an IPv6 address. Not an interface,
>> not the "host stack", but the application itself.
>>
>> Cheers,
>> Ole
> 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
>
>

-- 

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