Re: [6gip] IP Address Mobility Project

[Alexandre Petrescu <[e-mail]>]

David,

There are many points in your message that are worth important
consideration.

LEt me try to point to a few things:

Le 23/02/2023 à 11:54, David Lake a écrit :
[...]

> <DL> No it shouldn’t.   The network is a service you buy.

It is a good point of view in many contexts.  E.g. we dont want pure
academic work but something grounded in the reality of markets which
senses what users want, and rely on business plans, where people
exchange money to improve each other's situation.

Yet, from a certain perspective, sometimes, one would not consider
Internet as a service to buy.  It's more than a 'network', it is the
Internet.  It is like the air we breath - we dont contract that to a
provider.  A public good.

Other times, some business plan exists where the most in need are
_given_ cheap smartphones with twitter(?) on it for almost nothing, and
the funds can be found to compensate.

As an example from outside the world of Internet, some cities pay for
transportation of all, the ticket is for free.  The mobility is so
important that funding for it can be found at different than usual layers.

> It is delivered against an SLA and that SLA is built from the 
> capabilities of the infrastructure, the cost of provision and the 
> sales margin.
> 
> You enter into a contract to deliver with the carrier and it is
> their job to deliver against that contract.

YEs, I agree, there are many cases like that, but they are not the only
ones.

> Yes, for the most part the Internet contract just says ‘best efforts’
> but that has never been the case with PTT voice and increasingly
> customers want to buy differentiated services across the network. And
> we as an industry want to sell them that because that is where the
> money is, money we need to invest in new infrastructure.
> 
> What SHOULD happen is the same as when you book a parcel to be 
> collected from home – you are given a choice of (in my case) five 
> courier companies including the legacy post office and within each
> of those various grades of service with all kinds of options.
> Against each of those is a price which I pay and then I expect the
> service to deliver against that outcome.  If that fails, I am
> recompensed. Just as with the Internet, there are multiple (often
> over-lapping) transport elements involved and each are rewarded for
> their part in the overall SLA. </DL>

Sure - contract-based networking.

It is not the only kind of Internet.

>> It is not just network capabilities but also the RF numerology. 
>> VoLTE, for example, travels over a more robust numerology than the
>>  numerology on the default bearer.  This is why voice over LTE is 
>> much better in terms of jitter and loss than voice over WhatsApp 
>> (for example).
>> 
>> Personally, I would like to see the ability to carry out such 
>> mapping across the wider Internet - I worked on proposals for
>> H.325 to do just that many years ago - not just in the
>> operator/cellular domain but as application needs <<<<< available
>> bandwidth (and bandwidth has been relatively cheap) we haven't
>> really had to deal with this problem.
>> 
>> We absolutely do in cellular because SLAs are based on it.
> 
> Carrying out mappings across the wider Internet is a great idea and I
> support it.
> 
> I understand a little bit VoLTE, yet I dont see precisely why would 
> it be better than a WhatsApp voice calls, a whatsapp that I 
> understand even less.
> 
> <DL> Because VoLTE packets flow over the Dedicated Bearer whereas 
> everything else flows over the Default Bearer.

Thanks, now I understand.

Can I try it now?

Other operators do this voip-on-dedicated bearer concept, under a
different than VoLTE name?  Maybe I can try that instead.

[...]
> I would like to know whether both VoLTE and WhatsApp work ok on IPv6 
> or not.  The latter <(whatsapp) I can check myself right now, but the
> former no - VoLTE is a concept bound to a particular operator, if I
> understand correctly.  I am not at that operator.
> 
> <DL> You cannot see the VoLTE packets as an end user.  Whether they 
> use IPv4, IPv6 or any other protocol is really irrelevant. </DL>

One might find that IPv4 IPv6 distinction irrelevant, or 'orthogonal' to
our discussion of QoS, yet I need to know.

For example, hopefully IP in 6G will mean IPv6 natively, and mostly
IPv6.  Hopefully translation mechanisms such as 464XLAT and CLAT will no
longer be needed in the IP of 6G.

Additionally, the QoS mechanisms in IPv4 and IPv6 are very different.
There is flow label in IPv6.

> 
> 
> 
> That means that I can try right away a handover of an ongoing 
> whatsapp call between wifi and 4G.  I can show right away whether it 
> breaks or not.  If it breaks, I can formulate right away a 
> requirement for it not to break.  If it keeps up, but there are some 
> audio glitches, then I can formulate a requirement for these glitches
> to go away.
> 
> <DL> “… I can formulate a requirement for these glitches” No you 
> can’t. You have NO control as an end-user over the direction of flow 
> of the packets associated with the media stream over the air 
> interface.

> Of course WhatsApp will work as you switch from 802.11 to LTE and 
> back but just as the default bearer in LTE has no QoS, current
> 802.11 (other than WiFi6) has no concept of RF capabilities.

Will it work?  Is one sure?  I have strong doubts that my whatsapp phone
call will not break if I turn off the WiFi access point and handover to
a 4G network.

The discussion of glitches - is in addition to that first point.

If we agree that the whatsapp phone call breaks when moving from WiFi to
4G, then we can see about the glitches too.

By 'break' I mean 'hanged' (like when the person at the other end of the
phone line has hanged the phone and I need to dial up again).

If we dont agree about that breakage, then the discussion about glitches
is different.

Alex
PS: I read the text below, I will see later.


> 
> And even with WiFi6, who determines which packets travel on the 
> robust modulation items?  You’d just end up with everything being 
> marked ‘high-priority’ and there would be much less bandwidth to 
> share – self-defeating.
> 
> And be VERY careful what you mean by ‘break.’  This is down to the 
> use case – if I’m accompanying a singer/soloist over an LTE service 
> (which I often do), then what is important for me is utter stability 
> – jitter, lost packets or changes of codec are an utter nightmare 
> because my brain is already very busy reading music, playing the 
> piano.  I really don’t have many more cycles left to second-guess 
> that lost note or slight change in tempo introduced by a bit of 
> packet buffering.  In that case, actually VoLTE is very, very good.
> 
> But if I’m talking to someone where 30% of speech is silence and the 
> brain is excellent at in-filling words then the occasional glitch on 
> VoIP services such as WhatsApp is probably acceptable (although for 
> me, very annoying!) </DL>
> 
> 
> 
> For VoLTE I cant do any of these immediately obvious steps.
> 
> But I can agree with you, based on trust, that probably VoLTE is a 
> great performing tool.
> 
> <DL> It is and I think we would be churlish to think it is anything 
> but. What I think we need in future 6G networks is a 
> domain-independent way of extending the concept of SLAs that is 
> implied by IMS across the whole of the Internet so that we offer 
> differentiated services both for technical and commercial reasons. 
> But we need to do that in an inter-operable and open manner, not the 
> closed-world of 3GPP, IMvHO. </DL>
> 
> 
> Alex
> 
>> 
>> David
>> 
>> Sent from Outlook for iOS 
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukef&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HoBefsDYohturBHlD2kNuqh05DMNMON0GvxfntMYRMk%3D&reserved=0
>>
>>
>>
>>
>>
>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukef&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HoBefsDYohturBHlD2kNuqh05DMNMON0GvxfntMYRMk%3D&reserved=0>>
>> 
>> 
------------------------------------------------------------------------
>> 
>> 
> *From:* Alexandre Petrescu <[e-mail]>
>> *Sent:* Thursday, February 23, 2023 9:12:36 AM *To:* Sridhar 
>> Bhaskaran <[e-mail]> *Cc:* Hesham ElBakoury 
>> <[e-mail]>; Lake, David (PG/R - Comp Sci & Elec Eng) 
>> <[e-mail]>; Giles Heron 
>> <giles=[e-mail]>; Toerless Eckert 
>> <[e-mail]>; [e-mail] <[e-mail]> *Subject:* Re: 
>> [6gip] IP Address Mobility Project For the traffic class 
>> mutability: the routers in an xGPP (3GPP) network are all under
>> the same authority. This means that that authority can easily
>> configure all intermediary routers to not touch on the traffic
>> class.
>> 
>> Alex
>> 
>> Le 23/02/2023 à 05:00, Sridhar Bhaskaran a écrit :
>>>> Are there proposals to replace GTP?
>>> 
>>> <SB> See 3GPP TR 29.892 - 
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xuwvK9L67cZ8kRB2wC6XOTItsSxI73%2F8HofT%2BGscKuU%3D&reserved=0
>>>
>>>
>>>
>>>
>>>
>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xuwvK9L67cZ8kRB2wC6XOTItsSxI73%2F8HofT%2BGscKuU%3D&reserved=0>
>>> 
>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xuwvK9L67cZ8kRB2wC6XOTItsSxI73%2F8HofT%2BGscKuU%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xuwvK9L67cZ8kRB2wC6XOTItsSxI73%2F8HofT%2BGscKuU%3D&reserved=0>>
>>> 
>>> 
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xuwvK9L67cZ8kRB2wC6XOTItsSxI73%2F8HofT%2BGscKuU%3D&reserved=0
>
>
>
>
>
>
> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xuwvK9L67cZ8kRB2wC6XOTItsSxI73%2F8HofT%2BGscKuU%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2Farchive%2F29_series%2F29.892%2F29892-g00.zip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xuwvK9L67cZ8kRB2wC6XOTItsSxI73%2F8HofT%2BGscKuU%3D&reserved=0>>>
>>> SRv6 was proposed and the outcome of the study is in this TR. 
>>> After this IETF DMM worked on this draft independently - 
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pWTB3U4xzcQq7AFsMcsjdG4B5dOw%2F0ITH77XHq4psDI%3D&reserved=0
>>>
>>>
>>>
>>>
>>>
>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pWTB3U4xzcQq7AFsMcsjdG4B5dOw%2F0ITH77XHq4psDI%3D&reserved=0>
>>> 
>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pWTB3U4xzcQq7AFsMcsjdG4B5dOw%2F0ITH77XHq4psDI%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pWTB3U4xzcQq7AFsMcsjdG4B5dOw%2F0ITH77XHq4psDI%3D&reserved=0>>
>>> 
>>> 
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pWTB3U4xzcQq7AFsMcsjdG4B5dOw%2F0ITH77XHq4psDI%3D&reserved=0
>
>
>
>
>
>
> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pWTB3U4xzcQq7AFsMcsjdG4B5dOw%2F0ITH77XHq4psDI%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-srv6-mobile-uplane&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972013624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pWTB3U4xzcQq7AFsMcsjdG4B5dOw%2F0ITH77XHq4psDI%3D&reserved=0>>>
>>> 
>>> 
>>>> I can say that QoS can also be done with flow labels and 
>>>> traffic
>>>> 
>>> classes
>>>> in IPv6 headers, without GTP.
>>> <SB> Flow labels and traffic classes can be changed by on path
>>> IP devices (routers etc). 3GPP endpoints require an unmodified
>>> flow identifier. That is why they keep the flow identifier in 
>>> additional layer of encapsulation (i.e in GTP header). The flow 
>>> identifier marked by the first 3GPP entrypoint gateway (UPF) is 
>>> kept all the way upto radio network in the downlink direction so 
>>> that, radio network can directly use that as index to look up the
>>> resource allocation scheme / scheduler and RRM details. For 
>>> certain services like voice media (which is marked by QOS flow 
>>> identifier corresponding to QCI/5QI 1), mission critical
>>> services (QFI --> 5QI --> 69) etc, strict SLAs are there. Network
>>> cant afford to let on path routers meddle with QoS flow markers.
>>> 
>>> Regards Sridhar On Thu, Feb 23, 2023 at 1:16 AM Alexandre 
>>> Petrescu <[e-mail] 
>>> <mailto:[e-mail]
>>> 
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>> wrote:
>>> 
>>> 
>>> 
>>> Le 22/02/2023 à 19:43, Hesham ElBakoury a écrit :
>>> 
>>> I can try to find that out.  I remember some relatively recent 
>>> presentations at IETF about replacing GTP, or reducing the number
>>> of headers.  It might have been in the (precursor?) of the DMM
>>> WG. (distributed mobility mgmt).
>>> 
>>> A related question, IMHO, would be too whether there is an RFC 
>>> for GTP in a first place...
>>> 
>>> I can remember an Internet Draft of year 2000 about GTP - named 
>>> simply draft-casati-gtp - but it was not pursued at IETF.
>>> 
>>> If there were a GTP RFC, then we could think about improving it, 
>>> replacing it, etc.
>>> 
>>> When there is no GTP RFC, one can think about what should an 
>>> ideal xGPP (3GPP) network use instead.
>>> 
>>> Or maybe another way...
>>> 
>>> Alex
>>> 
>>>> Hesham
>>>> 
>>>> On Wed, Feb 22, 2023, 10:39 AM Alexandre Petrescu 
>>>> <[e-mail]
>>> <mailto:[e-mail] 
>>> <mailto:[e-mail] 
>>> <mailto:[e-mail]>>> 
>>> <mailto:[e-mail] 
>>> <mailto:[e-mail]
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>>> wrote:
>>>> 
>>>> David, Giles,
>>>> 
>>>> Le 22/02/2023 à 14:35, David Lake a écrit :
>>>>> This:
>>>>> 
>>>>> “…the 5G UPF terminates the GTP tunnel but also does QoS,
>>> charging,
>>>>> lawful intercept etc. ”
>>>>> 
>>>>> … is a VERY important point.  GTP enables a number of very
>>> low-level
>>>>> RF features which MNOs need to control their allocation of
>>> spectrum
>>>>> and more importantly the numerology associated with an
>>> application.
>>>>> It is also used in shared solutions such a CoMP.
>>>> 
>>>> I can agree with the importance of the point above.  I can
>>> agree about
>>>> improvements there might be necessary.
>>>> 
>>>> I can say that QoS can also be done with flow labels and
>>> traffic classes
>>>> in IPv6 headers, without GTP.
>>>> 
>>> 
>>>> But I agree with the importance of the topic.
>>>> 
>>>>> If we are to replace GTP (and I think there is a reason to
>>> do that)
>>>>> we have to provide the interactions to the layer 1 that
>>> MNOs need.
>>>> 
>>>> I agree.
>>>> 
>>>> [...] Giles said:
>>>>> I’m not sure that your electricity analysis is correct.
>>>>> 
>>>>> Doing e.g. an MPLS exact match lookup across a FIB with a
>>>>> few thousand labels rather than an IPv6 longest-match lookup
>>> across a FIB
>>>>> with a few million prefixes, for example, may well more
>>> than offset
>>>>> the extra electricity consumption caused by the extra 4
>>> bytes of
>>>>> header.
>>>>> 
>>>>> And then of course there’s all the electricity consumed by 
>>>>> the control plane updates hitting the router CPUs.
>>>> 
>>>> I can agree.  But I do not take that as an invitation to
>>>> ignore electricity consumption.  Rather, all points you
>>>> mention
>>> (exact match
>>>> lookup consumption, ctl plane) should be measured and told
>>> who consumes
>>>> more, and then decide what to reduce.
>>>> 
>>>> I do not take your remark as giving up electricity savings in
>>> front of
>>>> too much complexity of understanding what's happening.
>>>> 
>>>> I do not take your remark as freedom to add more headers when
>>> it becomes
>>>> necessary to add more functionality.
>>>> 
>>>> [...]
>>>> 
>>>>>> More details about this performance degradation can be
>>> provided if
>>>>>> absolutely necessary, but some times trust might also
>>> help for a
>>>>>> quicker understanding towards realizing a common goal. (the
>>>>>> development of trust is another matter that we can discuss
>>>>>> separately :-)
>>>>> 
>>>>> Trust takes time to earn, and I’d tend to suggest that
>>> arguing that
>>>>> it makes sense to inject a host route for a UE into OSPF
>>> may not be
>>>>> the best way to earn it.
>>>> 
>>>> Given this apparent disparate understanding about routing -
>>> you seem to
>>>> be more people to be saying the contrary of what I say - I
>>> give up this
>>>> topic discussion on host based routes.  Maybe for later for
>>> another G,
>>>> maybe never.
>>>> 
>>>> Alex
>>>> 
>>>> -- 6gip mailing list [e-mail] <mailto:[e-mail] 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>> 
>>>> <mailto:[e-mail]
>>> <mailto:[e-mail] <mailto:[e-mail] 
>>> <mailto:[e-mail]>>>>
>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0>
>>>> 
>>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0>>
>>> 
>>>> 
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0
>
>
>
>
>
>
> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0>>>
>>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0
>
>
>
>
>
>
> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0>>>>
>>>> 
>>> 
>>> -- 6gip mailing list [e-mail] <mailto:[e-mail] 
>>> <mailto:[e-mail] <mailto:[e-mail]>>> 
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0
>>>
>>>
>>>
>>>
>>>
>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0>
>>> 
>>> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0>>
>>> 
>>> 
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0
>
>
>
>
>
>
> 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0 
<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&data=05%7C01%7Cd.lake%40surrey.ac.uk%7C2fd12d6c763c49615b9108db1584b5fa%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C638127431972169852%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lSGg8LIU9jtDRaQweXR3%2FSlRD5EKKM6X7PhJgr1Tk50%3D&reserved=0>>>
>>> 
>>> 
>>> 
>>> -- o__ _>  /__ (_) \(_)... Burn fat not fuel - Bike along to a 
>>> healthier life and cleaner world! :)
>>> 
>>> Sridhar Bhaskaran
>>> 
>