Subject: What is necessity for SRH, and other EH, insertion/removal?

From: Tom Herbert <[email-masked]>
Date: Sat, 7 Dec 2019 09:17:15 -0800

Pulling this out into a separate thread. Pertinent questions are:

Why is extension header insertion and removal at necessary?

Why isn't the proposed alternative of IPIP encapsulation sufficient?
(where the encapsulating headers contain the extension headers that
would otherwise be inserted)

Please note, I'm asking for the technical justification of the
protocol design, saying that it's necessary because it's already being
deployed isn't useful in this regard.

Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Dec 2019 17:44:12 -0000

Hi Tom,

Thanks for breaking the thread and focussing us back on technical questions.

I can see some small value in PSP just as there is in MPLS PHP. This arises
in the combination of two circumstances:
- The destination node is not SRH-capable
- The source node and/or the node that determines the SR path is not aware
that the destination is not SRH-capable
In that case, the penultimate segment end point can know that its segment
neighbour end point is not SRH-capable and can perform PSP.

Whether this is ever the case with a central controller is unclear.

I'm not sure that this is a big use case, although MPLS PHP has proven to
have use cases as a form of "pop and go" especially when the next hop needs
to process the payload as "native".

There may be other use cases, and I'd be keen to learn about them.

The principle of keep things simple yet extensible would suggest that if
there are no substantial reasons to include a function it should be shelved
until there is a use case, but that this should be done in a way that allows
additions if necessary.

Cheers,
Adrian

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: 07 December 2019 17:17
To: 6man <[email-masked]>
Subject: What is necessity for SRH, and other EH, insertion/removal?

Tom

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Dec 2019 17:49:03 -0000

Oh, I should have said...
PSP, like PHP in MPLS, has an OAM cost associated with it.
Adrian

-----Original Message-----
From: Adrian Farrel <[email-masked]> 
Sent: 07 December 2019 17:44
To: 'Tom Herbert' <[email-masked]>; '6man' <[email-masked]>
Subject: RE: What is necessity for SRH, and other EH, insertion/removal?

Hi Tom,

Cheers,
Adrian

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: 07 December 2019 17:17
To: 6man <[email-masked]>
Subject: What is necessity for SRH, and other EH, insertion/removal?

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Dec 2019 09:24:18 +1300

> - The destination node is not SRH-capable

In that case, how can the "destination" node be considered to be part of
the SR domain in any way? It won't even know that the outer header
is an outer header. As far as I can see, the "penultimate" node
is the exit node from the SR domain. So why is the "destination" node
even a thing? It's only meaningful in terms of the encapsulated
packet, not the encapsulating packet that includes the SRH.

Regards
   Brian Carpenter

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Dec 2019 15:40:48 -0500

Tom

Since we are drawing similarities between MPLS and SR both have the domain
concept.

The big difference between SR and MPLS is that each MPLS router maintains
state in the P and PE nodes where with SR each PE or P along the source
routed path does not maintain state.

That is where with SR the source routing function on the ingress PE node of
the SR domain created the source routed SR label stacking path with SR-MPLS
topmost label.  In IPv6 forwarding plane case with SRv6 is accomplished
with the SRH routing header type 4 which has the Segment list. So with SRv6
the one hop prior to egress node of the SRv6 domain being the PSP node end
“egress P”in MPLS terms and the last  hop node in the USP scenario is the
“egress PE” last node in the SRv6 domain.

PHP in MPLS came about historically as with older MPLS routers instead of
putting the burden on the last node to pop all labels “ultimate” hopping
with explicit null the default behavior has always been for all vendors to
do the PHP function.

There are use cases primarily for QOS and maintaining EXP scheduling in the
last hop from PE to P the concept of “pipe node” came about which is the
explicit null option which allows the topmost label to be maintained on the
last hop to the egress PE.

I agree that that with SRv6 we are dealing with the IPv6 data plane and not
MPLS data plane so its truly like apple and oranges.

However from a functional scenario in reality SPs can now deploy SRv6 core
replacement of the legacy MPLS LDP label switching.

>From an SP core L3 VPN perspective the BGP AFI vpnv4 vpnv6 ipv4 IPv6 all
AFI/SAFI can now sit right on top of this new IPv6 data plane model with
SRv6.

I believe from the BESS working group it has been mentioned that China SPs
has 7+ deployments of SRV6.

So as you enter a domain you perform MPLS imposition or now SRH eh
 insertion and when you exit the domain you do PHP/UHP for MPLS or PSP/USP
for SRv6.

Hope this helps clarify in bridging the gap between WGs 6man, Spring, BESS,
LSR, RTG, MPLS.

Cheers,

Gyan

-- 

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/networking-technologies-consultant

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Dec 2019 16:00:48 -0500

Not to confuse the subject but this is an email  I had sent to
Spring/6man/BESS WGs related to comment on inter AS considerations “inter
domain” and that we should be able to apply the same Inter-AS L3 vpn
 features since its truly a bgp service construct overlay on top of the
SRv6 domain.

To that end with TEAS WG as well we with traffic engineering IP TE we are
looking at taking the RSVP
feature and benefits and applying then to SRv6 as well as SR-MPLS to both
SR-TR and Ti-LFA.

That is reason I think why the concepts of PSP was being applied to the
SRv6 specification.

Post below:

Here are some details related to existing Inter domain MPLS which has come
a long ways since inception decades ago.

Inter AS options A, B, C & CSC
https://tools.ietf.org/html/rfc4364#section-10

Inter AS option AB
https://datatracker.ietf.org/doc/draft-mapathak-interas-ab/

Inter AS Option A:  Back to back VRF native IP.  Subinterface VRF per
customer VPN. LSP terminates on each ASBR PE router.  No BGP-LU (labeled
switched unicast) which requires importing of loopback FEC of all PEs
between each AS.  Simple and works if isolation is required between
providers.  Does not scale. Multicast Is simple as MVPN profiles do not
need to match as PIM over the NNI inter AS link glues the two MVPN domains
together.

Inter AS Option B: Segmented LSP with single VPNV4 BGP session over inter
AS link.  Highly scalable.  RT filtering is enabled by default on all PEs
so has to be disabled on ASBR PE. Retain RT policy applied can filter and
RTs and don’t have to accept all RTs. Multicast MVPN profiles must match
between SPs as recursive-FEC and this the LMDT(labeled multicast
distribution tree) is end to end and not a segmented LSP as is with
unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for
LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.  No
BGP-LU (labeled switched unicast) which requires importing of loopback FEC
of all PEs between each AS.

Inter AS Option C: End to End LSP with BGP-LU (label switched unicast)
enabled on inter AS link data plane path.  All SP PE loopback FEC
destinations  must be exchanged imported between SPs and iBGP-LU PE to RR
for SP loops exchanged to have label binding when advertised over eBGP LU
inter AS. VPNV4 peering next-hop-unchanged for control plane update so end
to end LSP can build between any to any PE between SPs. Multicast MVPN
profiles must match between SPs as recursive-FEC and this the LMDT(labeled
multicast distribution tree) is end to end and not a segmented LSP as is
with unicast.  Option C offloads the ASBR PE having to maintain the L3 VPN
FIB.

Inter AS Option AB Hybrid of Option A and B with single control plane VPNV4
peer as is with Option B and VRF data plane isolation sub interfaces per
customer VRF.  Scales well as control plane is provided via single BGP
peer. AB provides additional security with VRF isolation feature.  No
importing of PE FEC loopback as this is a segmented LSP with 3
segments. Multicast
MVPN profiles must match between SPs as recursive-FEC and this the
LMDT(labeled multicast distribution tree) is end to end and not a segmented
LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer
to come up for LDP router-id label binding.ASBR PE must maintain all the L3
VPN FIBs.

Of the 4 inter AS options available today with MPLS Option A very simple
and seamless and works well if you have a minimal number of VRFs.  Option B
and AB both are highly scalable and AB works well if security is a
concern.  Option C is a good option for enterprises as well as service
providers that have a close trust relationship.

In your introduction section can you provide some details I have mentioned
of the existing MPLS inter domain options.  As you mentioned the importing
of millions of prefixes that would only be with Option C and it would only
be a million if each provider had a million PE loopback to import.

As far as SR-MPLS since it’s reusing the MPLS IPv4 dataplane to provide BGP
IPV4 IPV6 VPNV4 VPNV6 services for inter AS would that still have to use
the traditional mpls inter as options.

As for SRv6 since it uses the IPv6 data plane as far as inter domain that
can be stitched with SRv6 using Option B style but IPv6 dataplane in place
of the MPLS topmost label. Then all BGP services IPV4 IPV6 VPNV4 VPNV6
would ride on top.  I guess you could do Option C style and advertise the
PE FEC loopbacks between domains for an end to end SID list similar to an
end to end LSP do the PSP PHP would not happen until you hit the last or
next to last node in the chain of domains.

My guess is with both SRv6 and SR-MPLS you could literally take all for
inter AS options and use them as the bottom service BGP label would be the
same it’s just that you are swapping out the MPLS topmost label MPLS IPv4
data plane with SRv6 IPv6 data plane.

Thank you

Gyan

On Sat, Dec 7, 2019 at 3:40 PM Gyan Mishra <[email-masked]> wrote:

> That is where with SR the source routing function on the ingress PE node
> of the SR domain created the source routed SR label stacking path with
> SR-MPLS topmost label.  In IPv6 forwarding plane case with SRv6 is
> accomplished with the SRH routing header type 4 which has the Segment list.
> So with SRv6 the one hop prior to egress node of the SRv6 domain being the
> PSP node end “egress P”in MPLS terms and the last  hop node in the USP
> scenario is the “egress PE” last node in the SRv6 domain.
>
> There are use cases primarily for QOS and maintaining EXP scheduling in
> the last hop from PE to P the concept of “pipe node” came about which is
> the explicit null option which allows the topmost label to be maintained on
> the last hop to the egress PE.
>
> I agree that that with SRv6 we are dealing with the IPv6 data plane and
> not MPLS data plane so its truly like apple and oranges.
>
> Hope this helps clarify in bridging the gap between WGs 6man, Spring,
> BESS, LSR, RTG, MPLS.
>
> Cheers,
>
> Gyan
>

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Dec 2019 16:15:37 -0500

Because SRv6 is touted to be the Swiss Army knife so to speak for any use
case requiring traffic engineering that’s where it gets much more
complicated with EH insertion and violation of RFC 8200.

Cheers,

Gyan

On Sat, Dec 7, 2019 at 4:00 PM Gyan Mishra <[email-masked]> wrote:

> Inter AS Option AB Hybrid of Option A and B with single control plane
> VPNV4 peer as is with Option B and VRF data plane isolation sub interfaces
> per customer VRF.  Scales well as control plane is provided via single BGP
> importing of PE FEC loopback as this is a segmented LSP with 3 segments. Multicast
> As far as SR-MPLS since it’s reusing the MPLS IPv4 dataplane to provide
> BGP IPV4 IPV6 VPNV4 VPNV6 services for inter AS would that still have to
> use the traditional mpls inter as options.
>
>> Since we are drawing similarities between MPLS and SR both have the
>> domain concept.
>>
>> However from a functional scenario in reality SPs can now deploy SRv6
>> core replacement of the legacy MPLS LDP label switching.
>>
>> I believe from the BESS working group it has been mentioned that China
>> SPs has 7+ deployments of SRV6.
>>

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Dec 2019 21:36:48 -0000

[For the avoidance of doubt: I am not speaking as an advocate, merely a seeker after truth]

> the SR domain in any way?

By the definition of SR domain in 8402, I think you are right.
But it is clearly targeted through SR.
The same question applies to the end point of an MPLS LSP where PHP is used. Is that node part of the MPLS domain? It is not MPLS-capable, but it is the end point of the LSP (meaning that a packet encapsulated in an MPLS header and given a label will end up at that node through only MPLS forwarding).

> It won't even know that the outer header is an outer header.

Well, it will see the outer header as an IP-in-IP header. Or, more precisely and depending on encapsulation at the SR source, it will see the outer header as an IP header for a packet delivered to one of its addresses and will process the payload accordingly. Business as usual.

> As far as I can see, the "penultimate" node is the exit node from
> the SR domain. So why is the "destination" node

I am finding the term "destination node" to be problematic in most of the threads running around this topic ☹
There is "the ultimate destination of the packet" and there is "the node at which the outer header will be stripped" and there is "tunnel end point" and there is "current value of the DA field".

Ciao,
Adrian

---

From: Tom Herbert <[email-masked]>
Date: Sat, 7 Dec 2019 13:38:14 -0800

Gyan,

Traffic engineering is not a new concept, and tunneling across a transit
domain has long been an effective method. So the question remains: why
can't that be used in segment routing use case?

So far, no one has said why it won't work. I'm really hoping someone will
stand up and clearly articulate why that or any other alternative doesn't
work such EH insertion is necessary. At that point, we might be able have a
productive discussion about how to move forward.

Tom

On Sat, Dec 7, 2019, 1:15 PM Gyan Mishra <[email-masked]> wrote:

>> Here are some details related to existing Inter domain MPLS which has
>> come a long ways since inception decades ago.
>>
>> In your introduction section can you provide some details I have
>> mentioned of the existing MPLS inter domain options.  As you mentioned the
>> importing of millions of prefixes that would only be with Option C and it
>> would only be a million if each provider had a million PE loopback to
>> import.
>>
>>> The big difference between SR and MPLS is that each MPLS router
>>> maintains state in the P and PE nodes where with SR each PE or P along the
>>> source routed path does not maintain state.
>>>
>>> PHP in MPLS came about historically as with older MPLS routers instead
>>> of putting the burden on the last node to pop all labels “ultimate” hopping

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Dec 2019 18:48:13 -0500

Tom

Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

The initial proposal for SRv6 was EH insertion of SRH routing type 4 header in flight which is a violation of RFC 8200 which we 6man gave tremendous push back.

Spring came back with Encapsulation at the ingress PE of the SR domain and removal at the PSP or USP node upon leaving the SR domain. 

What was added to that was in order for the hop by hop traffic engineering of the flow to happen the EH insertion still has to happen with the SRH routing header type 4 that has the instruction set PSSI function of explicit hop by hop Routing the flow through the SR domain.

Hope that explains the technical reason for the SRH routing type 4 header that has to be inserted and removed along with the encapsulation.  

With tunneling to your comment that is not technically traffic engineering.  Traffic engineering is hop by hop explicit pathing of a flow which done via MPLS TE or SR via SR-TE or Ti-LFA.

Cheers,

Gyan

Sent from my iPhone

> On Dec 7, 2019, at 4:38 PM, Tom Herbert <[email-masked]> wrote:
> 
> 
> Gyan,
> 
> Traffic engineering is not a new concept, and tunneling across a transit domain has long been an effective method. So the question remains: why can't that be used in segment routing use case?
> 
> So far, no one has said why it won't work. I'm really hoping someone will stand up and clearly articulate why that or any other alternative doesn't work such EH insertion is necessary. At that point, we might be able have a productive discussion about how to move forward.
> 
> Tom
> 
> 
>> Because SRv6 is touted to be the Swiss Army knife so to speak for any use case requiring traffic engineering that’s where it gets much more complicated with EH insertion and violation of RFC 8200.
>> 
>> Cheers,
>> 
>> Gyan
>> 
>>> Not to confuse the subject but this is an email  I had sent to Spring/6man/BESS WGs related to comment on inter AS considerations “inter domain” and that we should be able to apply the same Inter-AS L3 vpn  features since its truly a bgp service construct overlay on top of the SRv6 domain.
>>> 
>>> To that end with TEAS WG as well we with traffic engineering IP TE we are looking at taking the RSVP 
>>> feature and benefits and applying then to SRv6 as well as SR-MPLS to both SR-TR and Ti-LFA.
>>> 
>>> That is reason I think why the concepts of PSP was being applied to the SRv6 specification.
>>> 
>>> Post below:
>>> 
>>> Here are some details related to existing Inter domain MPLS which has come a long ways since inception decades ago.  
>>> 
>>> Inter AS Option A:  Back to back VRF native IP.  Subinterface VRF per customer VPN. LSP terminates on each ASBR PE router.  No BGP-LU (labeled switched unicast) which requires importing of loopback FEC of all PEs between each AS.  Simple and works if isolation is required between providers.  Does not scale. Multicast Is simple as MVPN profiles do not need to match as PIM over the NNI inter AS link glues the two MVPN domains together.
>>> 
>>> Inter AS Option B: Segmented LSP with single VPNV4 BGP session over inter AS link.  Highly scalable.  RT filtering is enabled by default on all PEs so has to be disabled on ASBR PE. Retain RT policy applied can filter and RTs and don’t have to accept all RTs. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.  No BGP-LU (labeled switched unicast) which requires importing of loopback FEC of all PEs between each AS. 
>>> 
>>> Inter AS Option C: End to End LSP with BGP-LU (label switched unicast) enabled on inter AS link data plane path.  All SP PE loopback FEC destinations  must be exchanged imported between SPs and iBGP-LU PE to RR for SP loops exchanged to have label binding when advertised over eBGP LU inter AS. VPNV4 peering next-hop-unchanged for control plane update so end to end LSP can build between any to any PE between SPs. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  Option C offloads the ASBR PE having to maintain the L3 VPN FIB.
>>> 
>>> Inter AS Option AB Hybrid of Option A and B with single control plane VPNV4 peer as is with Option B and VRF data plane isolation sub interfaces per customer VRF.  Scales well as control plane is provided via single BGP peer. AB provides additional security with VRF isolation feature.  No importing of PE FEC loopback as this is a segmented LSP with 3 segments. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.  
>>> 
>>> Of the 4 inter AS options available today with MPLS Option A very simple and seamless and works well if you have a minimal number of VRFs.  Option B and AB both are highly scalable and AB works well if security is a concern.  Option C is a good option for enterprises as well as service providers that have a close trust relationship.
>>> 
>>> In your introduction section can you provide some details I have mentioned of the existing MPLS inter domain options.  As you mentioned the importing of millions of prefixes that would only be with Option C and it would only be a million if each provider had a million PE loopback to import. 
>>> 
>>> As far as SR-MPLS since it’s reusing the MPLS IPv4 dataplane to provide BGP IPV4 IPV6 VPNV4 VPNV6 services for inter AS would that still have to use the traditional mpls inter as options.
>>> 
>>> As for SRv6 since it uses the IPv6 data plane as far as inter domain that can be stitched with SRv6 using Option B style but IPv6 dataplane in place of the MPLS topmost label. Then all BGP services IPV4 IPV6 VPNV4 VPNV6 would ride on top.  I guess you could do Option C style and advertise the PE FEC loopbacks between domains for an end to end SID list similar to an end to end LSP do the PSP PHP would not happen until you hit the last or next to last node in the chain of domains.
>>> 
>>> My guess is with both SRv6 and SR-MPLS you could literally take all for inter AS options and use them as the bottom service BGP label would be the same it’s just that you are swapping out the MPLS topmost label MPLS IPv4 data plane with SRv6 IPv6 data plane.
>>> 
>>> Thank you 
>>> 
>>> Gyan
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Since we are drawing similarities between MPLS and SR both have the domain concept.
>>>> 
>>>> The big difference between SR and MPLS is that each MPLS router maintains state in the P and PE nodes where with SR each PE or P along the source routed path does not maintain state.
>>>> 
>>>> That is where with SR the source routing function on the ingress PE node of the SR domain created the source routed SR label stacking path with SR-MPLS topmost label.  In IPv6 forwarding plane case with SRv6 is accomplished with the SRH routing header type 4 which has the Segment list. So with SRv6 the one hop prior to egress node of the SRv6 domain being the PSP node end “egress P”in MPLS terms and the last  hop node in the USP scenario is the “egress PE” last node in the SRv6 domain.  
>>>> 
>>>> PHP in MPLS came about historically as with older MPLS routers instead of putting the burden on the last node to pop all labels “ultimate” hopping with explicit null the default behavior has always been for all vendors to do the PHP function. 
>>>> 
>>>> 
>>>> There are use cases primarily for QOS and maintaining EXP scheduling in the last hop from PE to P the concept of “pipe node” came about which is the explicit null option which allows the topmost label to be maintained on the last hop to the egress PE.
>>>> 
>>>> I agree that that with SRv6 we are dealing with the IPv6 data plane and not MPLS data plane so its truly like apple and oranges.
>>>> 
>>>> However from a functional scenario in reality SPs can now deploy SRv6 core replacement of the legacy MPLS LDP label switching.  
>>>> 
>>>> From an SP core L3 VPN perspective the BGP AFI vpnv4 vpnv6 ipv4 IPv6 all AFI/SAFI can now sit right on top of this new IPv6 data plane model with SRv6.
>>>> 
>>>> I believe from the BESS working group it has been mentioned that China SPs has 7+ deployments of SRV6.
>>>> 
>>>> So as you enter a domain you perform MPLS imposition or now SRH eh  insertion and when you exit the domain you do PHP/UHP for MPLS or PSP/USP for SRv6.
>>>> 
>>>> Hope this helps clarify in bridging the gap between WGs 6man, Spring, BESS, LSR, RTG, MPLS.
>>>> 
>>>> Cheers,
>>>> 
>>>> Gyan
>>>>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 7 Dec 2019 16:30:44 -0800

> What was added to that was in order for the hop by hop traffic engineering of the flow to happen the EH insertion still has to happen with the SRH routing header type 4 that has the instruction set…

Why does it need to happen? As you mention, there was pushback
inserting extension headers at ingress, but that same pushback is
applicable for inserting extension headers at any intermediate nodes.
So if encapsulation is acceptable to solve the problem at ingress to
the domain, why isn't acceptable for that same technique to be used at
nodes internal to the domain or other intermediate nodes?

Tom

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Dec 2019 22:04:23 -0300

Hello, Adrian,

> Thanks for breaking the thread and focussing us back on technical questions.

One would assume that if 6man (and ipv6 wg) got to consensus about
forbidding EH insertion/removal, is because of technical considerations.

Some of them have been spelled out in
draft-smith-6man-in-flight-eh-insertion-harmful.

Of course, that doesn't mean that the spec cannot be changed. However,
since it's indeed a change to what has been specified in RFC8200, the
document proposing eh-insertion processing should, at the bare minimum,
include a discussion of the problem they want to solve, why they think
they can't solve it with encapsulation, and how they would mitigate the
issues described in draft-smith-6man-in-flight-eh-insertion-harmful.

At least myself, I'm open to change my mind as a result of the above
analsys. OTOH, I'm not that keen about being slamped a spec with an
undercover update to RFC8200, and a lot of bizarre analysis of our specs.

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Dec 2019 22:37:35 -0500

On Sat, Dec 7, 2019 at 7:30 PM Tom Herbert <[email-masked]> wrote:

> > Re: New Version Notification for
> draft-voyer-6man-extension-header-insertion-08.txt
> >
> > The initial proposal for SRv6 was EH insertion of SRH routing type 4
> header in flight which is a violation of RFC 8200 which we 6man gave
> tremendous push back.
> >
> > Spring came back with Encapsulation at the ingress PE of the SR domain
> and removal at the PSP or USP node upon leaving the SR domain.
> >
> > What was added to that was in order for the hop by hop traffic
> engineering of the flow to happen the EH insertion still has to happen with
> the SRH routing header type 4 that has the instruction set PSSI function of
> explicit hop by hop Routing the flow through the SR domain.
>

     I believe the 6in6 encapsulation with SRH eh insertion at the ingress
or any intermediate node within the SR domain is a solid technical
workaround that would allow SRv6 to function and provide the hop by hop
traffic engineered path.  Every time an EH insertion is required an
encapsulation would occur with the SRH eh added each time.  Like pealing an
onion the encapsulation wrappers would be removed at each egress point
until you reach the 2nd to last PSP node or last USP node at which point
all encapsulations and EHs would be removed that were inserted and the IPv6
packet would now be forwarded leaving the SR domain as it entered.

The reason for the intermediate node EH insertion encapsulation workaround
technically from an SRv6 perspective is for Ti-LFA node and path protection
NNH path PLR (point of local repair) to egress PQ node where the
encapsulation is then removed that was added at the PLR intermediate node.
There maybe cases with SRv6 tunnel stitching that may require more then 2
encapsulations that could possibly occur.  I would say in most use cases in
general you would have 2 encapsulations.

Gyan

>
> Tom
>
> >
> > Hope that explains the technical reason for the SRH routing type 4
> header that has to be inserted and removed along with the encapsulation.
> >
> > With tunneling to your comment that is not technically traffic
> engineering.  Traffic engineering is hop by hop explicit pathing of a flow
> which done via MPLS TE or SR via SR-TE or Ti-LFA.
> >
> > Cheers,
> >
> >
> > Gyan
> >
> > Sent from my iPhone
> >
> > So far, no one has said why it won't work. I'm really hoping someone
> will stand up and clearly articulate why that or any other alternative
> doesn't work such EH insertion is necessary. At that point, we might be
> able have a productive discussion about how to move forward.
> >
> > Tom
> >
> >
> >> Because SRv6 is touted to be the Swiss Army knife so to speak for any
> use case requiring traffic engineering that’s where it gets much more
> features since its truly a bgp service construct overlay on top of the SRv6
> domain.
> >>>
> >>> Inter AS Option B: Segmented LSP with single VPNV4 BGP session over
> inter AS link.  Highly scalable.  RT filtering is enabled by default on all
> PEs so has to be disabled on ASBR PE. Retain RT policy applied can filter
> and RTs and don’t have to accept all RTs. Multicast MVPN profiles must
> match between SPs as recursive-FEC and this the LMDT(labeled multicast
> importing of PE FEC loopback as this is a segmented LSP with 3 segments.
> Multicast MVPN profiles must match between SPs as recursive-FEC and this
> the LMDT(labeled multicast distribution tree) is end to end and not a
> segmented LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for
> mLDP peer to come up for LDP router-id label binding.ASBR PE must maintain
> all the L3 VPN FIBs.
> >>>
> >>> Of the 4 inter AS options available today with MPLS Option A very
> simple and seamless and works well if you have a minimal number of VRFs.
> Option B and AB both are highly scalable and AB works well if security is a
> >>> As far as SR-MPLS since it’s reusing the MPLS IPv4 dataplane to
> provide BGP IPV4 IPV6 VPNV4 VPNV6 services for inter AS would that still
> have to use the traditional mpls inter as options.
> >>>
> >>> As for SRv6 since it uses the IPv6 data plane as far as inter domain
> that can be stitched with SRv6 using Option B style but IPv6 dataplane in
> place of the MPLS topmost label. Then all BGP services IPV4 IPV6 VPNV4
> VPNV6 would ride on top.  I guess you could do Option C style and advertise
> the PE FEC loopbacks between domains for an end to end SID list similar to
> an end to end LSP do the PSP PHP would not happen until you hit the last or
> >>> My guess is with both SRv6 and SR-MPLS you could literally take all
> for inter AS options and use them as the bottom service BGP label would be
> the same it’s just that you are swapping out the MPLS topmost label MPLS
> IPv4 data plane with SRv6 IPv6 data plane.
> >>>
> >>> Thank you
> >>>
> >>> Gyan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> That is where with SR the source routing function on the ingress PE
> node of the SR domain created the source routed SR label stacking path with
> >>>> PHP in MPLS came about historically as with older MPLS routers
> instead of putting the burden on the last node to pop all labels “ultimate”
> hopping with explicit null the default behavior has always been for all
> vendors to do the PHP function.
> >>>>
> >>>>
> >>>> There are use cases primarily for QOS and maintaining EXP scheduling
> in the last hop from PE to P the concept of “pipe node” came about which is
> >>>> I agree that that with SRv6 we are dealing with the IPv6 data plane
> and not MPLS data plane so its truly like apple and oranges.
> >>>>
> >>>> From an SP core L3 VPN perspective the BGP AFI vpnv4 vpnv6 ipv4 IPv6
> all AFI/SAFI can now sit right on top of this new IPv6 data plane model
> with SRv6.
> >>>>
> >>> Verizon Communications Inc.
> <https://www.google.com/maps/search/ommunications+Inc.+?entry=gmail&source=g>
> (VZ)
> >>>
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 02:26:42 +0000

Hi Adrian,

If the destination node can process Routing headers on the fast path, but does not recognize the SRH, it SHOULD:
	- skip over the SRH, because Segments Left is equal to zero (as per RFC 8200)
	- forward the packet at line speed

If the destination node cannot process Routing headers on the fast path, it will:
	- punt the packet to the slow path
	- skip over the SRH, because Segments Left is equal to zero (as per RFC 8200)
	- forward the packet, albeit slowly

                                                                                         Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Adrian Farrel
Sent: Saturday, December 7, 2019 12:44 PM
To: 'Tom Herbert' <[email-masked]>; '6man' <[email-masked]>
Subject: RE: What is necessity for SRH, and other EH, insertion/removal?

Hi Tom,

I can see some small value in PSP just as there is in MPLS PHP. This arises in the combination of two circumstances:
- The destination node is not SRH-capable
- The source node and/or the node that determines the SR path is not aware that the destination is not SRH-capable In that case, the penultimate segment end point can know that its segment neighbour end point is not SRH-capable and can perform PSP.

I'm not sure that this is a big use case, although MPLS PHP has proven to have use cases as a form of "pop and go" especially when the next hop needs to process the payload as "native".

The principle of keep things simple yet extensible would suggest that if there are no substantial reasons to include a function it should be shelved until there is a use case, but that this should be done in a way that allows additions if necessary.

Cheers,
Adrian

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: 07 December 2019 17:17
To: 6man <[email-masked]>
Subject: What is necessity for SRH, and other EH, insertion/removal?

Why isn't the proposed alternative of IPIP encapsulation sufficient?
(where the encapsulating headers contain the extension headers that would otherwise be inserted)

Please note, I'm asking for the technical justification of the protocol design, saying that it's necessary because it's already being deployed isn't useful in this regard.

Tom

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WzZKN3lbJ3IPeRv55moUERJbxW2t8ERi7n1WUHmRTQTT1SP56_ODQLQ5_06G_k7T$
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WzZKN3lbJ3IPeRv55moUERJbxW2t8ERi7n1WUHmRTQTT1SP56_ODQLQ5_06G_k7T$
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Dec 2019 07:45:44 -0800

On Sat, Dec 7, 2019 at 7:37 PM Gyan Mishra <[email-masked]> wrote:
>      I believe the 6in6 encapsulation with SRH eh insertion at the ingress or any intermediate node within the SR domain is a solid technical workaround that would allow SRv6 to function and provide the hop by hop traffic engineered path.  Every time an EH insertion is required an encapsulation would occur with the SRH eh added each time.  Like pealing an onion the encapsulation wrappers would be removed at each egress point until you reach the 2nd to last PSP node or last USP node at which point all encapsulations and EHs would be removed that were inserted and the IPv6 packet would now be forwarded leaving the SR domain as it entered.
>
> The reason for the intermediate node EH insertion encapsulation workaround technically from an SRv6 perspective is for Ti-LFA node and path protection NNH path PLR (point of local repair) to egress PQ node where the encapsulation is then removed that was added at the PLR intermediate node.  There maybe cases with SRv6 tunnel stitching that may require more then 2 encapsulations that could possibly occur.  I would say in most use cases in general you would have 2 encapsulations.
>

Gyan,

I see two possibilities for showing necessity of a protocol:

1) The protocol uniquely solves a problem for which there is no other
feasible means to solve the problem.
2) The protocol solves a problem in a better way than any of the alternatives.

For EH insertion, encapsulation with the EH that would otherwise be
inserted has been proposed as an alternative several times. In fact
this was required in early versions of draft-ietf-6man-rfc2460bis:

"Extension headers must never be inserted by any node other than the
source of the packet.  IP Encapsulation must be used to meet any
requirement for inserting headers, for example, as defined in
[RFC2473]."

Is there agreement that proper use of IP encapsulation with EH is
functionally equivalent to EH insertion?

If there is agreement that EH insertion doesn't satisfy #1, then
necessity of EH insertion would be a matter of showing that the
benefits of it outweigh the disadvantages relative to IP encapsulation
with EH.

Tom

---

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Dec 2019 11:13:37 -0500

>         - forward the packet, albeit slowly

Wait, what?

The slow path is not "slow" in the sense of it takes its time figuring
out what to do with the packets, it is "slow" in the sense that it is
a much lower bandwidth. My slow path is already sufficiently busy
doing things like BFD, ICMP, TTL expired, and, depending which slow
path you are meaning, things like routing updates and SSH and
management and things like that.

I suspect what actually happens is:
If the destination node cannot process Routing headers on the fast
path, it will:
         - punt the packet to the slow path
         - hit the control plane policer
         - throw away the packet

Expecting the slow path (PFE or RE or ...) to touch transit traffic
simply won't work at any kind of scale.

W
[0]: it also takes longer to figure out what to do with the packets,
but that is a secondary concern

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 19:00:37 +0000

Good point. Worse than slow. Low bandwidth.

                                   Ron

-----Original Message-----
From: Warren Kumari <[email-masked]> 
Sent: Monday, December 9, 2019 11:14 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; Tom Herbert <[email-masked]>; 6man <[email-masked]>
Subject: Re: What is necessity for SRH, and other EH, insertion/removal?

Wait, what?

The slow path is not "slow" in the sense of it takes its time figuring out what to do with the packets, it is "slow" in the sense that it is a much lower bandwidth. My slow path is already sufficiently busy doing things like BFD, ICMP, TTL expired, and, depending which slow path you are meaning, things like routing updates and SSH and management and things like that.

Expecting the slow path (PFE or RE or ...) to touch transit traffic simply won't work at any kind of scale.

W
[0]: it also takes longer to figure out what to do with the packets, but that is a secondary concern

> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!WzZKN3lbJ3IPeRv55moUERJbxW2t8ERi7n1WUHmRTQTT1SP56_ODQ
> LQ5_06G_k7T$
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!WzZKN3lbJ3IPeRv55moUERJbxW2t8ERi7n1WUHmRTQTT1SP56_ODQ
> LQ5_06G_k7T$
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!T9-gMf5yF_eHZ_kaa7MQrUDQvc9H0DBQ-LLbs9_TZO5xex3T0taI5
> WEiT-oTITeA$

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 9 Dec 2019 19:15:58 +0000

> Good point. Worse than slow. Low bandwidth.

The term "slow path" gives the misleading impression that it's a viable 
way of pushing packets through a router.  Maybe we should rename this 
the "hilarity path", to give a more realistic impression of how it 
performs in real life?

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Dec 2019 08:14:33 +0100

Le 09/12/2019 à 16:45, Tom Herbert a écrit :
[...]
> functionally equivalent to EH insertion?

I do agree.

In programming terms, IP encapsulation means to insert an IP header, 
which is a C struct like any other EH.

Conceptually, sending a packet from A to C through B can be

Enc:       src=A|dst=B[src=A|dst=C|payload]
or
EH removal: src=A|dst=B|EH|payload, and then src=A|dst=C|payload

It's the same thing.

Alex

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Dec 2019 14:07:52 -0800

> would otherwise be inserted)
I believe that inband network telemetry (INT and IOAM ) might provide
the best motivation for extension header insertion. One of the goals
is to allow network operators to perform telemetry on packets as they
traverse their network. A telemetry header, INT or IOAM, is put into
packets on ingress to the domain and removed at egress, and
intermediate nodes modify the packet with measurement data.

Key requirements are that not all packets for a flow need to be
measured, and measured packets need to follow the same path as those
not measured  in order for the measurements to reflect what is
happening for the flow. IPIP encapsulation would change the hash that
ECMP uses so encapsulated packets might traverse a different path--
therefore it's not sufficient in this case. Extension header insertion
would maintain the routing in ECMP (although the fact that extension
headers aren't supported in IPv4 creates another problem).

Some of the inband telemetry implementations are already addressing
this by inserting the inband telemetry headers directly into the UDP
or TCP payload of existing packets and removing the inserted payload
bytes at the egress point. Since only transport payload is being
modified, the packets will be routed the same way as other modified
packets for a flow. The obvious problem with this approach is that
payload is being changed by intermediate nodes such that if the end
host were to ever receive the modified packet this could result in
silent data corruption of users' data. So this protocol mechanism is
fundamentally not robust and probably dangerous. I think this actually
makes extension header insertion, where the worst case scenario is
probably unexplained packet loss, look palatable!

Tom

---

From: [email-masked]
Date: Wed, 18 Dec 2019 19:26:32 -0800

> probably unexplained packet loss, look palatable!

Explained that way, it evoked this thought: Put telemetry in a
trailer [cf. RFC893]. If conforming IPv6 implementations expect
there's no information after the nominally final octet of a
packet, then they'll neglect to forward (the trailer) onward?
QED! No escape to the "open" Internet, no munged ECMP hash, no
header insertion. Obvs, processing trailers on the fast path is
... problematic.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Dec 2019 19:52:39 -0800

> header insertion. Obvs, processing trailers on the fast path is

Do you mean trailers in L2 frame or L3 packet? Using UDP options for
this sort of thing has already been mentioned, although that wouldn't
help TCP or other transport protocols. In any case, it's unlikely
trailers are ever going to fly for doing anything in fast path.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Dec 2019 14:05:28 +0100

Le 18/12/2019 à 23:07, Tom Herbert a écrit :
>> Why isn't the proposed alternative of IPIP encapsulation
>> sufficient? (where the encapsulating headers contain the extension
>> headers that would otherwise be inserted)
>> 
> I believe that inband network telemetry (INT and IOAM ) might
> provide the best motivation for extension header insertion. One of
> the goals is to allow network operators to perform telemetry on
> packets as they traverse their network. A telemetry header, INT or
> IOAM, is put into packets on ingress to the domain and removed at
> egress, and intermediate nodes modify the packet with measurement
> data.
> 
> happening for the flow. IPIP encapsulation would change the hash
> that ECMP uses so encapsulated packets might traverse a different
> path-- therefore it's not sufficient in this case.

Why would ECMP (Equal-cost multi-path routing) be influenced by an
addition of an IP header (IPIP encapsulation) but not influenced by the
insertion of an extension header?

> Extension header insertion would maintain the routing in ECMP
> (although the fact that extension headers aren't supported in IPv4
> creates another problem).

ECMP distinguishes between IP headers being extension headers vs base
headers?  IF yes, it should be modified to work with base headers
addition as well (encapsulation IPIP).

> fundamentally not robust and probably dangerous. I think this
> actually makes extension header insertion, where the worst case
> scenario is probably unexplained packet loss, look palatable!

Inserting data in the packets and then measuring them - isn't it an
interference with the phenomenon to be measured?

Alex

>> protocol design, saying that it's necessary because it's already
>> being deployed isn't useful in this regard.
>> 
>> Tom
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 Dec 2019 10:55:51 -0800

> insertion of an extension header?
Alexandre,

When IP encapsulation is performed, unless the outer destination
happens to be the same as the inner destination, the destination
address will be different and hence packet can be routed over a
different path even with just simple destination based routing. The
outer source address will also presumably be different, so even if the
destination address were the same, the ECMP hash computed as routers
would still be different so packets could take a different path.

With extension header insertion, the IP addresses are not changed.
Neither is the flow label, nor any transport ports. So the network
still routes to the same destination address, and if ECMP is in use
the same hash is always produced since the inputs to the hash remain
the same after the header insertion.

> addition as well (encapsulation IPIP).

Some implementations might do that, but not all. In IPv6 this is
unnecessary since the flow label contains per flow information so
routers don't need to parse beyond the IPv6 header to do EMCP. Also,
packets must be routed based on (outer) destination address, ECMP is
only used to pick amongst possible paths to a destination. Even if the
EMCP hash computation is the same, the packets might still follow
different paths when destination address is different.

> interference with the phenomenon to be measured?
Yes, there certainly is some uncertainty principle effects, however I
imagine  not measuring the "actual" path for a flow would probably be
considered as invalid results.

Tom

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Dec 2019 14:11:48 +1100

> intermediate nodes modify the packet with measurement data.

So I assume that within an IOAM domain, the design would be that all
IP routers the packet passes through, from domain ingress to domain
egress, are IOAM capable.

Therefore, IOAM could be implemented as a layer 2 shim between the
link-layer header and the IPv6 original packet. The additional
overhead would only be the IOAM shim itself.

This is of course how MPLS works to add the label stack to existing IP packets.

Similar to MPLS, a FEC at ingress could be used to select which
packets have IOAM added or not.

> probably unexplained packet loss, look palatable!

The reason I have such strong opinions on this is that I first thought
about insertion verses encapsulation starting about 20 years ago.

I deployed Cisco's pre-standard version of "VLAN tagging",
Inter-Switch Link (ISL)*, which used Ethernet-in-Ethernet
encapsulation to add information to existing PDUs, back in the late
1990s. Then came along the IEEE 802.1Q spec in 1998, which specified
VLAN tagging using insertion into the frame, after the Ethernet header
and before the payload.

Thinking about the pros-and-cons at the time, I realised the Cisco
method was better, despite the E-in-E overhead, because the original
frame was preserved without modification. Although probably not by
design, the protection of the inner frame frame is strengthened while
being "VLAN trunked", because there is now the outer Eth FCS covering
the whole of the inner frame as well as the inner frame's own FCS
protecting its payload.

VLAN tagging via insertion corrupts the purpose and integrity of the
tagged frame's checksum / FCS, because it is recalculated and replaced
each time the VLAN tag is inserted and removed. It is now not a
reliable check that the frame received by the SA is the same frame
that was sent by the DA. VLAN tagging reduces the strength and purpose
of the FCS.

The only thing the checksum/FCS validates, in the presence of VLAN tag
insertion, is the last hop between the last switch/brige that removed
the VLAN tag and the device with the DA. The checksum/FCS is not
end-to-end anymore, and is failing to achieve its original purpose.
Frame corruption can occur within any of the VLAN tagging devices and
it won't be possible to detect, because the FCS is being recalculated
on the way out of the device after the VLAN tag has been added.

People might say this corruption hasn't ever happened because they
haven't heard of it happening. The trouble is that absence of evidence
is not evidence of absence.

So why insertion was used for VLAN tagging?

Radia Perlman explained it in her "Interconnections" book (2nd
edition). It was to accommodate existing Ethernet hardware at the time
that couldn't support frames large enough to use encapsulation. It's a
work around, not an ideal. Cisco could use Eth-in-Eth tunnelling
because they knew all of their hardware could support frames big
enough for that.

Regards,
Mark.

* "Inter-Switch Link and IEEE 802.1Q Frame Format",
https://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 Dec 2019 20:23:56 -0800

> egress, are IOAM capable.

Mark,

That's an awfully big assumption/requirement to make. I'm doubtful
that would be feasible for deployment in a large network. Note that
RFC2460 also required all nodes in the path to support HBH options and
look what happened!

> because they knew all of their hardware could support frames big
All good points, but I'm not sure that punting problems because their
hard to L2 is the answer. I could just as easily ask if MPLS was so
good, then why was segment routing even invented? Clearly there's
incentive to standardize on IP protocols for carrying end-to-end
information. Besides that, things are pretty far down the path for
sending IOAM over IPv6 and in fact there might even be consensus that
HBH options are the correct way to do that as opposed to a lot of
other hacks that have been suggested.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 Dec 2019 16:00:38 +0100

> the same after the header insertion.

But in that case (dont change src and dst addresses, just insert 
headers) then the packet would not pass through other enforced 
intermediary destinations before reaching the final destination.

In such a case, there could be headers inserted but the contents in 
these headers would not be IP addresses of intermediaries, but some 
other applicatioin-layer data.

If so, why would not be these data added as a payload, and not as an IP 
extension header?  I.e... encapsulate?

> considered as invalid results.

I agree.  It depends what is measured, and how the routing is realized.

Some routing might put bigger packets on a different path, just because 
of their size.  This mechanism would be fooled by someone inserting 
headers because it created bigger packets.

Other routing might work hand-in-hand with the header insertion 
mechanism (in same computer the process deciding a path be same process 
inserting headers).

To my mind it comes down again to the concept of a limited domain: if in 
a limited domain the routing and header inserters are bound closely, and 
ends of the comm are both there, then it migh work.

It might be that measurement mechanisms you mentioned, and ECMP 
(multi-path routing), and header insertion, might be appropriate in a 
limited domain.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 Dec 2019 16:07:45 +0100

[...]
> information.

I think an improved mechanism of using IPv6 (and potentially its 
extension headers) to achieve same goals as MPLS achieves would be 
better than currently MPLS-for-IPv4.

Fine engineering trade-offs could be found between too many 
encapsulation headers, packet modification en-route, and limited domains.

One easy thing to do would also for proponents to accept to get rid of IPv4.

There are many other easy things to do.

Alex

  Besides that, things are pretty far down the path for

---

From: Tom Herbert <[email-masked]>
Date: Fri, 20 Dec 2019 08:08:28 -0800

Alexandre,

I think there's two questions that need to be answered: Is extension
header insertion needed? If it is needed, how can we make work as
robustly as possible?

For the first question, so far it seems like there's three
possibilities why header insertion is better than encapsulation:
1) The alternate routing path problem (talking about here)
2) The right address of the domain egress to set as the destination
address of encapsulation might not be known to the ingress node (i.e.,
not all networks are going to be doing source routing)
3) Header insertion might be less overhead

For segment routing I don't believe #1 or #2 apply, and the overhead
savings of #3 don't seem like a big win relative to overhead of SRH
itself which can be substantial; also the potential overhead savings
for SRH insertion is probably more like twenty-four bytes or less
since encapsulation destination address should save one address one
address routing list. Nevertheless, it's plausible there are use cases
that show a valid need for header insertion (IOAM as one example).

For the second question, IMO, if extension header insertion is needed
then it's essential that the attribution problem is addressed. It must
be clearly indicated in a packet which extension headers have been
inserted and by whom. draft-herbert-6man-eh-attrib-00 proposes an the
Attribution Option for this purpose. Please take a look.

Tom

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 20 Dec 2019 10:47:52 -0800

+1 Warren

TTL meltdown, remember?

Cheers,
Jeff