Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

I agree on your comment about more use cases. We should consider all those 
scenarios and see what fits the bill.

Arashmid 

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: 27 March 2018 15:59
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 11:47 AM, Arashmid Akhavain 
<arashmid.akhav...@huawei.com> wrote:
> ID-LOC (SRV6, ILA, LISP, ILNP) would cover these use cases easily 
> since UE ID remains the same no matter what access technology we use.

Right, but I haven't seen anyone suggest GTP-U or CAPWAP for that list. There 
are more use cases now that seem to demand a more general and common 
encapsulation technique.

Tom

> Without ID-LOC, there is always going to be a need for all sort of 
> complicated control plane hand over procedures.
> Also, we end up with n2 interworking issue as we add more access technologies 
> to the mix.
>
> Arashmid
>
> -Original Message-
> From: Tom Herbert [mailto:t...@quantonium.net]
> Sent: 27 March 2018 14:25
> To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
> Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain 
> <arashmid.akhav...@huawei.com> wrote:
>> Tom,
>> Are you referring to a use case where the UE moves between different access 
>> technologies?
>>
> I think it's possible and should be a consideration. Countless devices are 
> already regularly multihomed between WiFi and mobile.
>
> Tom
>
>
>> Arashmid
>>
>>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>>> protocol which is also a foo-over-UDP variation.
>>>
>> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
>> device, what protocol are they going to use?
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
>> Sent: 27 March 2018 10:03
>> To: Satoru Matsushima <satoru.matsush...@gmail.com>
>> Cc: dmm@ietf.org
>> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>>
>> On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
>> <satoru.matsush...@gmail.com> wrote:
>>> Thank you Tom,
>>>
>>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U.
>>> (No offensive, please don’t get me wrong.)
>>>
>>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
>>> type encapsulation in IETF.
>>
>> It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
>> draft-ietf-intarea-gue-extensions.
>>
>>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>>> protocol which is also a foo-over-UDP variation.
>>>
>> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
>> device, what protocol are they going to use?
>>
>>> Nevertheless I think that that aspect would be a criteria for user plane 
>>> protocols comparison provided to 3GPP. But I don’t think it is good idea 
>>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in 
>>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP 
>>> protocol to be compared with GTP-U supported functionalities.
>>>
>> GUE is the generic foo-over-UDP protocol for that purpose.
>>
>>> Basic functionalities of GTP-U is that sequence number option, 
>>> extension-headers, and multicast and those should be the part of criteria. 
>>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>>> encryption would be good idea for the criteria in addition to the above 
>>> fundamental ones.
>>>
>>> Best regards,
>>> --satoru
>>>
>>>
>>>
>>>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>>>>
>>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima 
>>>> <satoru.matsush...@gmail.com> wrote:
>>>>> Thank you Tom for your suggestion.
>>>>>
>>>>> Do you think that GUE has some advantages against GTP-U?
>>>>
>>>> I believe so. GUE is designed to be a general pu

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

Hi Tom,
I totally understand your point.  But RFC8200 doesn't single out the source as 
the only node that can do this type of manipulation. "Any node along a packet's 
delivery path" is rather open to interpretation.

Arashmid

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: 27 March 2018 15:50
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com>; dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 11:37 AM, Arashmid Akhavain 
<arashmid.akhav...@huawei.com> wrote:
> Although segment end points are nodes along packets' delivery path, they are 
> terminating a segment.
> So why is it considered a RFC8200 violation if SRH manipulation is restricted 
> to those nodes.
>
Hi Arashmid,

Because only the source of a packet is allowed to create extension headers. The 
source is identified by the source address, and we know that intermediate nodes 
in segment routing are not the source since they don't change to the source 
address to be their own. Creating extension headers when encapsulating is okay 
since the encapsulator is the source of the outer packet. The problems with EH 
insertion were enumerated in the discussion on 6man list.

Tom

> Arashmid
>
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: 27 March 2018 11:05
> To: Sri Gundavelli (sgundave) <sgund...@cisco.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) 
> <sgund...@cisco.com> wrote:
>>
>>
>> On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote:
>>
>>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>>> Why not using UDP encapsulation?"
>>>
>>
>> I am really hoping we will be able to apply SRH insertion without the 
>> need for IP encapsulation. At least for mobile environments within a 
>> closed administrative domains, there should be exceptions for 
>> allowing insertion of SRH by a on-path node. I realize there are 
>> issues with ICMP error messages hitting the source etc, but we should 
>> be able to document those issues and specify work arounds. I 
>> understand there have been discussions on this topic before, but I 
>> hope authors will find some agreements for the same.
>>
> Sri,
>
> There's been quite a bit of discussion on this on 6man list with reference to 
> draft-voyer-6man-extension-header-insertion. The problem is that extension 
> header insertion would violate RFC8200: "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".
>
> In addition to the the protocol ramifications of doing this (dealing with 
> MTU, ICMP error, etc.) there were questions as to whether the benefit is 
> significant enough to justify the cost, as well as what does it mean to 
> define Internet protocols that only work in a "controlled domain".
>
> I believe 6man is the right place for further discussions on this.
>
> Tom
>
>
>
>
>>
>> Sri
>> 
>>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Tue, Mar 27, 2018 at 7:30 PM, Sri Gundavelli (sgundave)
 wrote:
> Hi Tom,
>
> I realize there have been some discussions, but I think its time to reopen
> those discussion in 6MAN or wherever and find a way-forward. There is a
> strong use-case now for such capability. I am not convinced that we cannot
> find a work around. May be its about documentation on the potential issues
> and with an IESG note on the considerations before enabling such mode. It
> will be unfortunate, if we loose this basic capability of SRH insertion by
> an on-path node.
>
Sri,

Personally, I don't think the justification was all that strong.
AFAICT the only reason to do this is to save bytes of header. But the
savings aren't all that impressive. As pointed out previously, if you
use encapsulation for SR then the destination address eliminates the
need for one sid so the savings is at most 24 bytes. But in the case
there is only one sid (I belives that's 'traditional mode') the need
for the EH overhead is eliminated with encapsulation, so the savings
is only 16 bytes. Given that SR is pretty verbose to begin with (each
sid is 16 bytes), it's not clear to me at least that saving a some
bytes of encapsulation header is worth the effort of changing a
protocol that's now a full Internet standard.

Perhaps there's some other reason why header insertion is critically needed?

Tom

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Sri Gundavelli (sgundave)]

For untrusted access (Ex: 3GPP access over untrusted Wi-Fi), protocols
like IKEv2-IPsec/MIPv6-UDP (client based solutions) are possible
candidates; I agree with Charlie on that.  I realize there is work in
progress in 5G specs on these interfaces, but I do not see many new
options there. 



Sri




On 3/27/18, 12:02 PM, "dmm on behalf of Charlie Perkins"
 wrote:

>Hello Arashmid,
>
>> if a WiFi network needs to talk to 3GPP network for a roaming device,
>>what protocol are they going to use?
>
>They could use Mobile IPv6, which was designed for exactly this purpose.
>
>Do you think that would work?
>
>Regards,
>Charlie P.
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Sri Gundavelli (sgundave)]

Hi Tom,

I realize there have been some discussions, but I think its time to reopen
those discussion in 6MAN or wherever and find a way-forward. There is a
strong use-case now for such capability. I am not convinced that we cannot
find a work around. May be its about documentation on the potential issues
and with an IESG note on the considerations before enabling such mode. It
will be unfortunate, if we loose this basic capability of SRH insertion by
an on-path node.


Sri




On 3/27/18, 11:22 AM, "Tom Herbert" <t...@quantonium.net> wrote:

>On Tue, Mar 27, 2018 at 10:27 AM, Uma Chunduri <uma.chund...@huawei.com>
>wrote:
>> Hi Sri,
>>
>> >
>> > I am really hoping we will be able to apply SRH insertion
>>without the
>> > need for IP encapsulation. At least for mobile environments
>>within a
>> > closed administrative domains, there should be exceptions for
>>allowing
>> > insertion of SRH by a on-path node.
>>
>> While I see you intention to see a way to reduce the RFC8200 encap
>>overhead;
>> for mobile/cellular environments  I see its paramount to have a
>>standardized solutions because
>> it's mostly multi-vendor equipment from most of the operators
>>deployments. Regardless if it's a closed administrative domain or not.
>>
>>
>> However, it might be fine if it is an inside a DC (for example DC
>>underlay) kind of  environment and  this exception could be made;
>> as the diversity of different vendor equipment can be less.
>>
>That story line has played out many times before. In a closed system
>like a DC there is always seems to be some motivation to deploy
>proprietary solutions. Often this is done for convenience and because
>something is viewed as something critically needed today. In the long
>run, this is self defeating. It is a lot of effort to maintain
>proprietary protocols, and even worse can force the network into
>vendor lock-in. It's almost always better to stick with open standards
>from day one even in closed systems.
>
>Tom
>
>>
>> But the best course still would be to have this documented clearly and
>>if possible do an update to RFC8200 @ 6man as pointed below by Tom.
>>
>> --
>> Uma C.
>>
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
>> Sent: Tuesday, March 27, 2018 8:05 AM
>> To: Sri Gundavelli (sgundave) <sgund...@cisco.com>
>> Cc: dmm@ietf.org
>> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>>
>> On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave)
>><sgund...@cisco.com> wrote:
>>>
>>>
>>> On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote:
>>>
>>>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>>>> Why not using UDP encapsulation?"
>>>>
>>>
>>> I am really hoping we will be able to apply SRH insertion without the
>>> need for IP encapsulation. At least for mobile environments within a
>>> closed administrative domains, there should be exceptions for allowing
>>> insertion of SRH by a on-path node. I realize there are issues with
>>> ICMP error messages hitting the source etc, but we should be able to
>>> document those issues and specify work arounds. I understand there
>>> have been discussions on this topic before, but I hope authors will
>>> find some agreements for the same.
>>>
>> Sri,
>>
>> There's been quite a bit of discussion on this on 6man list with
>>reference to draft-voyer-6man-extension-header-insertion. The problem is
>>that extension header insertion would violate RFC8200: "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".
>>
>> In addition to the the protocol ramifications of doing this (dealing
>>with MTU, ICMP error, etc.) there were questions as to whether the
>>benefit is significant enough to justify the cost, as well as what does
>>it mean to define Internet protocols that only work in a "controlled
>>domain".
>>
>> I believe 6man is the right place for further discussions on this.
>>
>> Tom
>>
>>
>>
>>
>>>
>>> Sri
>>> 
>>>
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Tue, Mar 27, 2018 at 11:37 AM, Arashmid Akhavain
<arashmid.akhav...@huawei.com> wrote:
> Although segment end points are nodes along packets' delivery path, they are 
> terminating a segment.
> So why is it considered a RFC8200 violation if SRH manipulation is restricted 
> to those nodes.
>
Hi Arashmid,

Because only the source of a packet is allowed to create extension
headers. The source is identified by the source address, and we know
that intermediate nodes in segment routing are not the source since
they don't change to the source address to be their own. Creating
extension headers when encapsulating is okay since the encapsulator is
the source of the outer packet. The problems with EH insertion were
enumerated in the discussion on 6man list.

Tom

> Arashmid
>
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: 27 March 2018 11:05
> To: Sri Gundavelli (sgundave) <sgund...@cisco.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) 
> <sgund...@cisco.com> wrote:
>>
>>
>> On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote:
>>
>>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>>> Why not using UDP encapsulation?"
>>>
>>
>> I am really hoping we will be able to apply SRH insertion without the
>> need for IP encapsulation. At least for mobile environments within a
>> closed administrative domains, there should be exceptions for allowing
>> insertion of SRH by a on-path node. I realize there are issues with
>> ICMP error messages hitting the source etc, but we should be able to
>> document those issues and specify work arounds. I understand there
>> have been discussions on this topic before, but I hope authors will
>> find some agreements for the same.
>>
> Sri,
>
> There's been quite a bit of discussion on this on 6man list with reference to 
> draft-voyer-6man-extension-header-insertion. The problem is that extension 
> header insertion would violate RFC8200: "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".
>
> In addition to the the protocol ramifications of doing this (dealing with 
> MTU, ICMP error, etc.) there were questions as to whether the benefit is 
> significant enough to justify the cost, as well as what does it mean to 
> define Internet protocols that only work in a "controlled domain".
>
> I believe 6man is the right place for further discussions on this.
>
> Tom
>
>
>
>
>>
>> Sri
>> 
>>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

Hi Charlie,

Mobile IPV6 can be among the alternatives. But mobility is just one the 
important features in 3GPP.
There are several aspects such as impact on CP, support for service chaining, 
traffic engineering, QoS and BW reservation, etc. that perhaps require further 
investigation.

Best regards,
Arashmid




-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net] 
Sent: 27 March 2018 15:02
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

Hello Arashmid,

> if a WiFi network needs to talk to 3GPP network for a roaming device, what 
> protocol are they going to use?

They could use Mobile IPv6, which was designed for exactly this purpose.

Do you think that would work?

Regards,
Charlie P.



On 3/27/2018 11:08 AM, Arashmid Akhavain wrote:
> Tom,
> Are you referring to a use case where the UE moves between different access 
> technologies?
>
> Arashmid
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: 27 March 2018 10:03
> To: Satoru Matsushima <satoru.matsush...@gmail.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
> <satoru.matsush...@gmail.com> wrote:
>> Thank you Tom,
>>
>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U.
>> (No offensive, please don’t get me wrong.)
>>
>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
>> type encapsulation in IETF.
> It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
> draft-ietf-intarea-gue-extensions.
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>> Nevertheless I think that that aspect would be a criteria for user plane 
>> protocols comparison provided to 3GPP. But I don’t think it is good idea 
>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in 
>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP protocol 
>> to be compared with GTP-U supported functionalities.
>>
> GUE is the generic foo-over-UDP protocol for that purpose.
>
>> Basic functionalities of GTP-U is that sequence number option, 
>> extension-headers, and multicast and those should be the part of criteria. 
>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>> encryption would be good idea for the criteria in addition to the above 
>> fundamental ones.
>>
>> Best regards,
>> --satoru
>>
>>
>>
>>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>>>
>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima 
>>> <satoru.matsush...@gmail.com> wrote:
>>>> Thank you Tom for your suggestion.
>>>>
>>>> Do you think that GUE has some advantages against GTP-U?
>>> I believe so. GUE is designed to be a general purposed multi use 
>>> case encapsulation. The defined GUE extensions deal with problems 
>>> and provide features of encapsulation (header security, 
>>> fragmentation, payload security, checksum handling etc.). This is 
>>> done without resorting to expensive TLV processing. GUE also allows 
>>> "private data"
>>> that could be used for use case specific info-- so TLVs or GTP 
>>> extensions could be encoded so in that sense it's a superset of GTP 
>>> functionality. As I mentioned, GUE has a mode for encapsulating IP 
>>> in UDP with minimal overhead (direct IP over UDP).
>>>
>>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>>> beyond GTP-U?
>>>>
>>> I think so. Perhaps the biggest advantage is the GUE can be used 
>>> accross different use cases and technologies. It's generic protocol 
>>> so it could be used for multiple use cases in a mobile network. For 
>>> instance, a UE might talk to a a

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

ID-LOC (SRV6, ILA, LISP, ILNP) would cover these use cases easily since UE ID 
remains the same no matter what access 
technology we use.
Without ID-LOC, there is always going to be a need for all sort of complicated 
control plane hand over procedures.
Also, we end up with n2 interworking issue as we add more access technologies 
to the mix.

Arashmid

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: 27 March 2018 14:25
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain 
<arashmid.akhav...@huawei.com> wrote:
> Tom,
> Are you referring to a use case where the UE moves between different access 
> technologies?
>
I think it's possible and should be a consideration. Countless devices are 
already regularly multihomed between WiFi and mobile.

Tom


> Arashmid
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: 27 March 2018 10:03
> To: Satoru Matsushima <satoru.matsush...@gmail.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
> <satoru.matsush...@gmail.com> wrote:
>> Thank you Tom,
>>
>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U.
>> (No offensive, please don’t get me wrong.)
>>
>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
>> type encapsulation in IETF.
>
> It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
> draft-ietf-intarea-gue-extensions.
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>> Nevertheless I think that that aspect would be a criteria for user plane 
>> protocols comparison provided to 3GPP. But I don’t think it is good idea 
>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in 
>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP protocol 
>> to be compared with GTP-U supported functionalities.
>>
> GUE is the generic foo-over-UDP protocol for that purpose.
>
>> Basic functionalities of GTP-U is that sequence number option, 
>> extension-headers, and multicast and those should be the part of criteria. 
>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>> encryption would be good idea for the criteria in addition to the above 
>> fundamental ones.
>>
>> Best regards,
>> --satoru
>>
>>
>>
>>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>>>
>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima 
>>> <satoru.matsush...@gmail.com> wrote:
>>>> Thank you Tom for your suggestion.
>>>>
>>>> Do you think that GUE has some advantages against GTP-U?
>>>
>>> I believe so. GUE is designed to be a general purposed multi use 
>>> case encapsulation. The defined GUE extensions deal with problems 
>>> and provide features of encapsulation (header security, 
>>> fragmentation, payload security, checksum handling etc.). This is 
>>> done without resorting to expensive TLV processing. GUE also allows 
>>> "private data"
>>> that could be used for use case specific info-- so TLVs or GTP 
>>> extensions could be encoded so in that sense it's a superset of GTP 
>>> functionality. As I mentioned, GUE has a mode for encapsulating IP 
>>> in UDP with minimal overhead (direct IP over UDP).
>>>
>>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>>> beyond GTP-U?
>>>>
>>> I think so. Perhaps the biggest advantage is the GUE can be used 
>>> accross different use cases and technologies. It's generic protocol 
>>> so it could be used for multiple use cases in a mobile network. For 
>>> instance, a UE

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

Although segment end points are nodes along packets' delivery path, they are 
terminating a segment.
So why is it considered a RFC8200 violation if SRH manipulation is restricted 
to those nodes.

Arashmid





-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: 27 March 2018 11:05
To: Sri Gundavelli (sgundave) <sgund...@cisco.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) <sgund...@cisco.com> 
wrote:
>
>
> On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote:
>
>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>> Why not using UDP encapsulation?"
>>
>
> I am really hoping we will be able to apply SRH insertion without the 
> need for IP encapsulation. At least for mobile environments within a 
> closed administrative domains, there should be exceptions for allowing 
> insertion of SRH by a on-path node. I realize there are issues with 
> ICMP error messages hitting the source etc, but we should be able to 
> document those issues and specify work arounds. I understand there 
> have been discussions on this topic before, but I hope authors will 
> find some agreements for the same.
>
Sri,

There's been quite a bit of discussion on this on 6man list with reference to 
draft-voyer-6man-extension-header-insertion. The problem is that extension 
header insertion would violate RFC8200: "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".

In addition to the the protocol ramifications of doing this (dealing with MTU, 
ICMP error, etc.) there were questions as to whether the benefit is significant 
enough to justify the cost, as well as what does it mean to define Internet 
protocols that only work in a "controlled domain".

I believe 6man is the right place for further discussions on this.

Tom




>
> Sri
> 
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Uma Chunduri]

In-line..
--
Uma C.

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net]
Sent: Tuesday, March 27, 2018 11:23 AM
To: Uma Chunduri <uma.chund...@huawei.com>
Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com>; dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 10:27 AM, Uma Chunduri 
<uma.chund...@huawei.com<mailto:uma.chund...@huawei.com>> wrote:
> Hi Sri,
>
> >
> > I am really hoping we will be able to apply SRH insertion without 
> the
> > need for IP encapsulation. At least for mobile environments within a
> > closed administrative domains, there should be exceptions for 
> allowing
> > insertion of SRH by a on-path node.
>
> While I see you intention to see a way to reduce the RFC8200 encap
> overhead; for mobile/cellular environments  I see its paramount to
> have a  standardized solutions because it's mostly multi-vendor equipment 
> from most of the operators deployments. Regardless if it's a closed 
> administrative domain or not.
>
>
> However, it might be fine if it is an inside a DC (for example DC
> underlay) kind of  environment and  this exception could be made; as the 
> diversity of different vendor equipment can be less.
>
That story line has played out many times before. In a closed system like a DC 
there is always seems to be some motivation to deploy proprietary solutions. 
Often this is done for convenience and because something is viewed as something 
critically needed today. In the long run, this is self defeating. It is a lot 
of effort to maintain proprietary protocols, and even worse can force the 
network into vendor lock-in. It's almost always better to stick with open 
standards from day one even in closed systems.

[Uma]:  Tom, I am all for open standards (regardless of which SDO). I was just 
comparing the realities of two different environments and both in MSDC or 
medium sized DCs today we have *both* proprietary protocols and single vendor 
equipment is prevalent.
   I was just saying this is not the case in other case (cellular). 
Otherwise I agree with your observation.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain
<arashmid.akhav...@huawei.com> wrote:
> Tom,
> Are you referring to a use case where the UE moves between different access 
> technologies?
>
I think it's possible and should be a consideration. Countless devices
are already regularly multihomed between WiFi and mobile.

Tom


> Arashmid
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>
>
>
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: 27 March 2018 10:03
> To: Satoru Matsushima <satoru.matsush...@gmail.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
> <satoru.matsush...@gmail.com> wrote:
>> Thank you Tom,
>>
>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U.
>> (No offensive, please don’t get me wrong.)
>>
>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
>> type encapsulation in IETF.
>
> It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
> draft-ietf-intarea-gue-extensions.
>
>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming 
> device, what protocol are they going to use?
>
>> Nevertheless I think that that aspect would be a criteria for user plane 
>> protocols comparison provided to 3GPP. But I don’t think it is good idea 
>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in 
>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP protocol 
>> to be compared with GTP-U supported functionalities.
>>
> GUE is the generic foo-over-UDP protocol for that purpose.
>
>> Basic functionalities of GTP-U is that sequence number option, 
>> extension-headers, and multicast and those should be the part of criteria. 
>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>> encryption would be good idea for the criteria in addition to the above 
>> fundamental ones.
>>
>> Best regards,
>> --satoru
>>
>>
>>
>>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>>>
>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima
>>> <satoru.matsush...@gmail.com> wrote:
>>>> Thank you Tom for your suggestion.
>>>>
>>>> Do you think that GUE has some advantages against GTP-U?
>>>
>>> I believe so. GUE is designed to be a general purposed multi use case
>>> encapsulation. The defined GUE extensions deal with problems and
>>> provide features of encapsulation (header security, fragmentation,
>>> payload security, checksum handling etc.). This is done without
>>> resorting to expensive TLV processing. GUE also allows "private data"
>>> that could be used for use case specific info-- so TLVs or GTP
>>> extensions could be encoded so in that sense it's a superset of GTP
>>> functionality. As I mentioned, GUE has a mode for encapsulating IP in
>>> UDP with minimal overhead (direct IP over UDP).
>>>
>>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>>> beyond GTP-U?
>>>>
>>> I think so. Perhaps the biggest advantage is the GUE can be used
>>> accross different use cases and technologies. It's generic protocol
>>> so it could be used for multiple use cases in a mobile network. For
>>> instance, a UE might talk to a a low latency service application via
>>> GUE. To the server this looks much more like simple virtualization or
>>> encapsulation and GUE includes potential optimizations. Similarly,
>>> GUE also could be use to connect across different access technologies
>>> that might not be 3GPP (like roaming between WIFI and a mobile network).
>>> Conceptually, other IETF defined encapsulations could also be used
>>> for this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically
>>> designed to be multi use case, low overhead, but still extensible.
>>>
>>&g

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Tue, Mar 27, 2018 at 10:27 AM, Uma Chunduri <uma.chund...@huawei.com> wrote:
> Hi Sri,
>
> >
> > I am really hoping we will be able to apply SRH insertion without 
> the
> > need for IP encapsulation. At least for mobile environments within a
> > closed administrative domains, there should be exceptions for 
> allowing
> > insertion of SRH by a on-path node.
>
> While I see you intention to see a way to reduce the RFC8200 encap overhead;
> for mobile/cellular environments  I see its paramount to have a  standardized 
> solutions because
> it's mostly multi-vendor equipment from most of the operators deployments. 
> Regardless if it's a closed administrative domain or not.
>
>
> However, it might be fine if it is an inside a DC (for example DC underlay) 
> kind of  environment and  this exception could be made;
> as the diversity of different vendor equipment can be less.
>
That story line has played out many times before. In a closed system
like a DC there is always seems to be some motivation to deploy
proprietary solutions. Often this is done for convenience and because
something is viewed as something critically needed today. In the long
run, this is self defeating. It is a lot of effort to maintain
proprietary protocols, and even worse can force the network into
vendor lock-in. It's almost always better to stick with open standards
from day one even in closed systems.

Tom

>
> But the best course still would be to have this documented clearly and if 
> possible do an update to RFC8200 @ 6man as pointed below by Tom.
>
> --
> Uma C.
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: Tuesday, March 27, 2018 8:05 AM
> To: Sri Gundavelli (sgundave) <sgund...@cisco.com>
> Cc: dmm@ietf.org
> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
>
> On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) 
> <sgund...@cisco.com> wrote:
>>
>>
>> On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote:
>>
>>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>>> Why not using UDP encapsulation?"
>>>
>>
>> I am really hoping we will be able to apply SRH insertion without the
>> need for IP encapsulation. At least for mobile environments within a
>> closed administrative domains, there should be exceptions for allowing
>> insertion of SRH by a on-path node. I realize there are issues with
>> ICMP error messages hitting the source etc, but we should be able to
>> document those issues and specify work arounds. I understand there
>> have been discussions on this topic before, but I hope authors will
>> find some agreements for the same.
>>
> Sri,
>
> There's been quite a bit of discussion on this on 6man list with reference to 
> draft-voyer-6man-extension-header-insertion. The problem is that extension 
> header insertion would violate RFC8200: "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".
>
> In addition to the the protocol ramifications of doing this (dealing with 
> MTU, ICMP error, etc.) there were questions as to whether the benefit is 
> significant enough to justify the cost, as well as what does it mean to 
> define Internet protocols that only work in a "controlled domain".
>
> I believe 6man is the right place for further discussions on this.
>
> Tom
>
>
>
>
>>
>> Sri
>> 
>>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Arashmid Akhavain]

Tom,
Are you referring to a use case where the UE moves between different access 
technologies?

Arashmid

> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
> protocol which is also a foo-over-UDP variation.
>
Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming device, 
what protocol are they going to use?





-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: 27 March 2018 10:03
To: Satoru Matsushima <satoru.matsush...@gmail.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
<satoru.matsush...@gmail.com> wrote:
> Thank you Tom,
>
> Unfortunately I couldn’t find clear advantage of GUE against GTP-U. 
> (No offensive, please don’t get me wrong.)
>
> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
> type encapsulation in IETF.

It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
draft-ietf-intarea-gue-extensions.

> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
> protocol which is also a foo-over-UDP variation.
>
Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming device, 
what protocol are they going to use?

> Nevertheless I think that that aspect would be a criteria for user plane 
> protocols comparison provided to 3GPP. But I don’t think it is good idea that 
> we provides 3GPP all kind of foo-over-UDP encapsulation protocols in IETF. It 
> would be better to pick SRv6 and some generic foo-over-UDP protocol to be 
> compared with GTP-U supported functionalities.
>
GUE is the generic foo-over-UDP protocol for that purpose.

> Basic functionalities of GTP-U is that sequence number option, 
> extension-headers, and multicast and those should be the part of criteria. 
> IMO as you suggested, overhead size, performance, TE, extensibility and 
> encryption would be good idea for the criteria in addition to the above 
> fundamental ones.
>
> Best regards,
> --satoru
>
>
>
>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール:
>>
>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima 
>> <satoru.matsush...@gmail.com> wrote:
>>> Thank you Tom for your suggestion.
>>>
>>> Do you think that GUE has some advantages against GTP-U?
>>
>> I believe so. GUE is designed to be a general purposed multi use case 
>> encapsulation. The defined GUE extensions deal with problems and 
>> provide features of encapsulation (header security, fragmentation, 
>> payload security, checksum handling etc.). This is done without 
>> resorting to expensive TLV processing. GUE also allows "private data"
>> that could be used for use case specific info-- so TLVs or GTP 
>> extensions could be encoded so in that sense it's a superset of GTP 
>> functionality. As I mentioned, GUE has a mode for encapsulating IP in 
>> UDP with minimal overhead (direct IP over UDP).
>>
>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>> beyond GTP-U?
>>>
>> I think so. Perhaps the biggest advantage is the GUE can be used 
>> accross different use cases and technologies. It's generic protocol 
>> so it could be used for multiple use cases in a mobile network. For 
>> instance, a UE might talk to a a low latency service application via 
>> GUE. To the server this looks much more like simple virtualization or 
>> encapsulation and GUE includes potential optimizations. Similarly, 
>> GUE also could be use to connect across different access technologies 
>> that might not be 3GPP (like roaming between WIFI and a mobile network).
>> Conceptually, other IETF defined encapsulations could also be used 
>> for this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically 
>> designed to be multi use case, low overhead, but still extensible.
>>
>> We intend to use ILA in a similar multi-use case fashion, however 
>> when encapsulation is required (like SR TE is needed, or we need an 
>> encrypted tunnel) then I believe GUE is a good alternative for that 
>> case to provide necessary functionality and extensibility.
>>
>> Tom
>>
>>>> 2018/03/27 9:16、Tom Herbert <t...@quantonium.net>のメール:
>>>>
>>>> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave) 
>>>> <sgund...@cisco.com> wrote:
>>>>> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>>

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Uma Chunduri]

Hi Sri,

>
> I am really hoping we will be able to apply SRH insertion without the 
> need for IP encapsulation. At least for mobile environments within a 
> closed administrative domains, there should be exceptions for 
allowing 
> insertion of SRH by a on-path node.

While I see you intention to see a way to reduce the RFC8200 encap overhead; 
for mobile/cellular environments  I see its paramount to have a  standardized 
solutions because 
it's mostly multi-vendor equipment from most of the operators deployments. 
Regardless if it's a closed administrative domain or not.


However, it might be fine if it is an inside a DC (for example DC underlay) 
kind of  environment and  this exception could be made;
as the diversity of different vendor equipment can be less.


But the best course still would be to have this documented clearly and if 
possible do an update to RFC8200 @ 6man as pointed below by Tom.

--
Uma C.

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Tuesday, March 27, 2018 8:05 AM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com>
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) <sgund...@cisco.com> 
wrote:
>
>
> On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote:
>
>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>> Why not using UDP encapsulation?"
>>
>
> I am really hoping we will be able to apply SRH insertion without the 
> need for IP encapsulation. At least for mobile environments within a 
> closed administrative domains, there should be exceptions for allowing 
> insertion of SRH by a on-path node. I realize there are issues with 
> ICMP error messages hitting the source etc, but we should be able to 
> document those issues and specify work arounds. I understand there 
> have been discussions on this topic before, but I hope authors will 
> find some agreements for the same.
>
Sri,

There's been quite a bit of discussion on this on 6man list with reference to 
draft-voyer-6man-extension-header-insertion. The problem is that extension 
header insertion would violate RFC8200: "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".

In addition to the the protocol ramifications of doing this (dealing with MTU, 
ICMP error, etc.) there were questions as to whether the benefit is significant 
enough to justify the cost, as well as what does it mean to define Internet 
protocols that only work in a "controlled domain".

I believe 6man is the right place for further discussions on this.

Tom




>
> Sri
> 
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave)
 wrote:
>
>
> On 3/26/18, 5:16 PM, "Tom Herbert"  wrote:
>
>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>> Why not using UDP encapsulation?"
>>
>
> I am really hoping we will be able to apply SRH insertion without the need
> for IP encapsulation. At least for mobile environments within a closed
> administrative domains, there should be exceptions for allowing insertion
> of SRH by a on-path node. I realize there are issues with ICMP error
> messages hitting the source etc, but we should be able to document those
> issues and specify work arounds. I understand there have been discussions
> on this topic before, but I hope authors will find some agreements for the
> same.
>
Sri,

There's been quite a bit of discussion on this on 6man list with
reference to draft-voyer-6man-extension-header-insertion. The problem
is that extension header insertion would violate RFC8200: "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".

In addition to the the protocol ramifications of doing this (dealing
with MTU, ICMP error, etc.) there were questions as to whether the
benefit is significant enough to justify the cost, as well as what
does it mean to define Internet protocols that only work in a
"controlled domain".

I believe 6man is the right place for further discussions on this.

Tom




>
> Sri
> 
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Sri Gundavelli (sgundave)]

On 3/26/18, 5:16 PM, "Tom Herbert"  wrote:

>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>> Why not using UDP encapsulation?"
>

I am really hoping we will be able to apply SRH insertion without the need
for IP encapsulation. At least for mobile environments within a closed
administrative domains, there should be exceptions for allowing insertion
of SRH by a on-path node. I realize there are issues with ICMP error
messages hitting the source etc, but we should be able to document those
issues and specify work arounds. I understand there have been discussions
on this topic before, but I hope authors will find some agreements for the
same.


Sri


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Tue, Mar 27, 2018 at 12:52 AM, Satoru Matsushima
 wrote:
> One thing I want to follow my comment.
>
>> Basic functionalities of GTP-U is that sequence number option, 
>> extension-headers, and multicast and those should be the part of criteria. 
>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>> encryption would be good idea for the criteria in addition to the above 
>> fundamental ones.
>
>
> I think that we have to have OAM functionality in addition to that criteria.
>
OAM is supported in GUE. There are two types of messages in GUE:
control and data. Control could be used for sending OAM messages.
Additionally, OAM flags and fields can be used with control message.
It's likely we'll define two flag bits to handle proposed inline
performance measurement that has been defined.

Tom

> Best regards,
> --satoru
>
>
>
>> 2018/03/27 15:57、Satoru Matsushima のメール:
>>
>> Thank you Tom,
>>
>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U. (No 
>> offensive, please don’t get me wrong.)
>>
>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
>> type encapsulation in IETF.
>> IMO Unified concept in that encapsulation doesn’t seem to work in that 
>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
>> protocol which is also a foo-over-UDP variation.
>>
>> Nevertheless I think that that aspect would be a criteria for user plane 
>> protocols comparison provided to 3GPP. But I don’t think it is good idea 
>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in 
>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP protocol 
>> to be compared with GTP-U supported functionalities.
>>
>> Basic functionalities of GTP-U is that sequence number option, 
>> extension-headers, and multicast and those should be the part of criteria. 
>> IMO as you suggested, overhead size, performance, TE, extensibility and 
>> encryption would be good idea for the criteria in addition to the above 
>> fundamental ones.
>>
>> Best regards,
>> --satoru
>>
>>
>>
>>> 2018/03/27 11:51、Tom Herbert のメール:
>>>
>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima
>>>  wrote:
 Thank you Tom for your suggestion.

 Do you think that GUE has some advantages against GTP-U?
>>>
>>> I believe so. GUE is designed to be a general purposed multi use case
>>> encapsulation. The defined GUE extensions deal with problems and
>>> provide features of encapsulation (header security, fragmentation,
>>> payload security, checksum handling etc.). This is done without
>>> resorting to expensive TLV processing. GUE also allows "private data"
>>> that could be used for use case specific info-- so TLVs or GTP
>>> extensions could be encoded so in that sense it's a superset of GTP
>>> functionality. As I mentioned, GUE has a mode for encapsulating IP in
>>> UDP with minimal overhead (direct IP over UDP).
>>>
 When it comes to foo over UDP capsulation, does GUE benefit user plane 
 beyond GTP-U?

>>> I think so. Perhaps the biggest advantage is the GUE can be used
>>> accross different use cases and technologies. It's generic protocol so
>>> it could be used for multiple use cases in a mobile network. For
>>> instance, a UE might talk to a a low latency service application via
>>> GUE. To the server this looks much more like simple virtualization or
>>> encapsulation and GUE includes potential optimizations. Similarly, GUE
>>> also could be use to connect across different access technologies that
>>> might not be 3GPP (like roaming between WIFI and a mobile network).
>>> Conceptually, other IETF defined encapsulations could also be used for
>>> this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically designed
>>> to be multi use case, low overhead, but still extensible.
>>>
>>> We intend to use ILA in a similar multi-use case fashion, however when
>>> encapsulation is required (like SR TE is needed, or we need an
>>> encrypted tunnel) then I believe GUE is a good alternative for that
>>> case to provide necessary functionality and extensibility.
>>>
>>> Tom
>>>
> 2018/03/27 9:16、Tom Herbert のメール:
>
> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
>  wrote:
>> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>>
>> We are also waiting for Lyle to share his notes. Please review and
>> comment, if you see any mistakes.
>>
>
> With regards to SR encapsulation: "this is using IP-in-IP as default.
> Why not using UDP encapsulation?"
>
> There is some rationale for UDP encapsulation here to maximize
> compatibility with the network and potentially intermediate nodes like
> firewalls. For example, in the performance numbers that Kalyani
> posted, the TPS for SR over IPIP 

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima
 wrote:
> Thank you Tom,
>
> Unfortunately I couldn’t find clear advantage of GUE against GTP-U. (No 
> offensive, please don’t get me wrong.)
>
> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
> type encapsulation in IETF.

It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue
and draft-ietf-intarea-gue-extensions.

> IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
> protocol which is also a foo-over-UDP variation.
>
Rigtht so if a WiFi network needs to talk to 3GPP network for a
roaming device, what protocol are they going to use?

> Nevertheless I think that that aspect would be a criteria for user plane 
> protocols comparison provided to 3GPP. But I don’t think it is good idea that 
> we provides 3GPP all kind of foo-over-UDP encapsulation protocols in IETF. It 
> would be better to pick SRv6 and some generic foo-over-UDP protocol to be 
> compared with GTP-U supported functionalities.
>
GUE is the generic foo-over-UDP protocol for that purpose.

> Basic functionalities of GTP-U is that sequence number option, 
> extension-headers, and multicast and those should be the part of criteria. 
> IMO as you suggested, overhead size, performance, TE, extensibility and 
> encryption would be good idea for the criteria in addition to the above 
> fundamental ones.
>
> Best regards,
> --satoru
>
>
>
>> 2018/03/27 11:51、Tom Herbert のメール:
>>
>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima
>>  wrote:
>>> Thank you Tom for your suggestion.
>>>
>>> Do you think that GUE has some advantages against GTP-U?
>>
>> I believe so. GUE is designed to be a general purposed multi use case
>> encapsulation. The defined GUE extensions deal with problems and
>> provide features of encapsulation (header security, fragmentation,
>> payload security, checksum handling etc.). This is done without
>> resorting to expensive TLV processing. GUE also allows "private data"
>> that could be used for use case specific info-- so TLVs or GTP
>> extensions could be encoded so in that sense it's a superset of GTP
>> functionality. As I mentioned, GUE has a mode for encapsulating IP in
>> UDP with minimal overhead (direct IP over UDP).
>>
>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>> beyond GTP-U?
>>>
>> I think so. Perhaps the biggest advantage is the GUE can be used
>> accross different use cases and technologies. It's generic protocol so
>> it could be used for multiple use cases in a mobile network. For
>> instance, a UE might talk to a a low latency service application via
>> GUE. To the server this looks much more like simple virtualization or
>> encapsulation and GUE includes potential optimizations. Similarly, GUE
>> also could be use to connect across different access technologies that
>> might not be 3GPP (like roaming between WIFI and a mobile network).
>> Conceptually, other IETF defined encapsulations could also be used for
>> this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically designed
>> to be multi use case, low overhead, but still extensible.
>>
>> We intend to use ILA in a similar multi-use case fashion, however when
>> encapsulation is required (like SR TE is needed, or we need an
>> encrypted tunnel) then I believe GUE is a good alternative for that
>> case to provide necessary functionality and extensibility.
>>
>> Tom
>>
 2018/03/27 9:16、Tom Herbert のメール:

 On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
  wrote:
> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>
> We are also waiting for Lyle to share his notes. Please review and
> comment, if you see any mistakes.
>

 With regards to SR encapsulation: "this is using IP-in-IP as default.
 Why not using UDP encapsulation?"

 There is some rationale for UDP encapsulation here to maximize
 compatibility with the network and potentially intermediate nodes like
 firewalls. For example, in the performance numbers that Kalyani
 posted, the TPS for SR over IPIP routing was lower than other
 encapsulations. The reason for this is that the particular NIC (ixgbe)
 is not parsing over IPIP or using flow label to get a good hash for
 RSS. This is symptomatic of network devices that don't provide as good
 support for protocols outside of TCP and UDP. There are likely routers
 that would not be able to provide flow specific ECMP for similar
 reasons. There was a comment in dmm meeting that ECMP for IPIP was
 expected to by solved by using flow label in the hash. This is a great
 idea, but unfortunately there is significant resistance to using flow
 label for this purpose since it is not 

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Satoru Matsushima]

One thing I want to follow my comment.

> Basic functionalities of GTP-U is that sequence number option, 
> extension-headers, and multicast and those should be the part of criteria. 
> IMO as you suggested, overhead size, performance, TE, extensibility and 
> encryption would be good idea for the criteria in addition to the above 
> fundamental ones.


I think that we have to have OAM functionality in addition to that criteria.

Best regards,
--satoru



> 2018/03/27 15:57、Satoru Matsushima のメール:
> 
> Thank you Tom,
> 
> Unfortunately I couldn’t find clear advantage of GUE against GTP-U. (No 
> offensive, please don’t get me wrong.)
> 
> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
> type encapsulation in IETF.
> IMO Unified concept in that encapsulation doesn’t seem to work in that 
> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
> protocol which is also a foo-over-UDP variation.
> 
> Nevertheless I think that that aspect would be a criteria for user plane 
> protocols comparison provided to 3GPP. But I don’t think it is good idea that 
> we provides 3GPP all kind of foo-over-UDP encapsulation protocols in IETF. It 
> would be better to pick SRv6 and some generic foo-over-UDP protocol to be 
> compared with GTP-U supported functionalities.
> 
> Basic functionalities of GTP-U is that sequence number option, 
> extension-headers, and multicast and those should be the part of criteria. 
> IMO as you suggested, overhead size, performance, TE, extensibility and 
> encryption would be good idea for the criteria in addition to the above 
> fundamental ones.
> 
> Best regards,
> --satoru
> 
> 
> 
>> 2018/03/27 11:51、Tom Herbert のメール:
>> 
>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima
>>  wrote:
>>> Thank you Tom for your suggestion.
>>> 
>>> Do you think that GUE has some advantages against GTP-U?
>> 
>> I believe so. GUE is designed to be a general purposed multi use case
>> encapsulation. The defined GUE extensions deal with problems and
>> provide features of encapsulation (header security, fragmentation,
>> payload security, checksum handling etc.). This is done without
>> resorting to expensive TLV processing. GUE also allows "private data"
>> that could be used for use case specific info-- so TLVs or GTP
>> extensions could be encoded so in that sense it's a superset of GTP
>> functionality. As I mentioned, GUE has a mode for encapsulating IP in
>> UDP with minimal overhead (direct IP over UDP).
>> 
>>> When it comes to foo over UDP capsulation, does GUE benefit user plane 
>>> beyond GTP-U?
>>> 
>> I think so. Perhaps the biggest advantage is the GUE can be used
>> accross different use cases and technologies. It's generic protocol so
>> it could be used for multiple use cases in a mobile network. For
>> instance, a UE might talk to a a low latency service application via
>> GUE. To the server this looks much more like simple virtualization or
>> encapsulation and GUE includes potential optimizations. Similarly, GUE
>> also could be use to connect across different access technologies that
>> might not be 3GPP (like roaming between WIFI and a mobile network).
>> Conceptually, other IETF defined encapsulations could also be used for
>> this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically designed
>> to be multi use case, low overhead, but still extensible.
>> 
>> We intend to use ILA in a similar multi-use case fashion, however when
>> encapsulation is required (like SR TE is needed, or we need an
>> encrypted tunnel) then I believe GUE is a good alternative for that
>> case to provide necessary functionality and extensibility.
>> 
>> Tom
>> 
 2018/03/27 9:16、Tom Herbert のメール:
 
 On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
  wrote:
> FYI. This is the notes that Carlos captured. Thank you Carlos!!
> 
> We are also waiting for Lyle to share his notes. Please review and
> comment, if you see any mistakes.
> 
 
 With regards to SR encapsulation: "this is using IP-in-IP as default.
 Why not using UDP encapsulation?"
 
 There is some rationale for UDP encapsulation here to maximize
 compatibility with the network and potentially intermediate nodes like
 firewalls. For example, in the performance numbers that Kalyani
 posted, the TPS for SR over IPIP routing was lower than other
 encapsulations. The reason for this is that the particular NIC (ixgbe)
 is not parsing over IPIP or using flow label to get a good hash for
 RSS. This is symptomatic of network devices that don't provide as good
 support for protocols outside of TCP and UDP. There are likely routers
 that would not be able to provide flow specific ECMP for similar
 reasons. There was a comment in dmm meeting that ECMP for IPIP was
 expected to by 

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima
 wrote:
> Thank you Tom for your suggestion.
>
> Do you think that GUE has some advantages against GTP-U?

I believe so. GUE is designed to be a general purposed multi use case
encapsulation. The defined GUE extensions deal with problems and
provide features of encapsulation (header security, fragmentation,
payload security, checksum handling etc.). This is done without
resorting to expensive TLV processing. GUE also allows "private data"
that could be used for use case specific info-- so TLVs or GTP
extensions could be encoded so in that sense it's a superset of GTP
functionality. As I mentioned, GUE has a mode for encapsulating IP in
UDP with minimal overhead (direct IP over UDP).

> When it comes to foo over UDP capsulation, does GUE benefit user plane beyond 
> GTP-U?
>
I think so. Perhaps the biggest advantage is the GUE can be used
accross different use cases and technologies. It's generic protocol so
it could be used for multiple use cases in a mobile network. For
instance, a UE might talk to a a low latency service application via
GUE. To the server this looks much more like simple virtualization or
encapsulation and GUE includes potential optimizations. Similarly, GUE
also could be use to connect across different access technologies that
might not be 3GPP (like roaming between WIFI and a mobile network).
Conceptually, other IETF defined encapsulations could also be used for
this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically designed
to be multi use case, low overhead, but still extensible.

We intend to use ILA in a similar multi-use case fashion, however when
encapsulation is required (like SR TE is needed, or we need an
encrypted tunnel) then I believe GUE is a good alternative for that
case to provide necessary functionality and extensibility.

Tom

>> 2018/03/27 9:16、Tom Herbert のメール:
>>
>> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
>>  wrote:
>>> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>>>
>>> We are also waiting for Lyle to share his notes. Please review and
>>> comment, if you see any mistakes.
>>>
>>
>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>> Why not using UDP encapsulation?"
>>
>> There is some rationale for UDP encapsulation here to maximize
>> compatibility with the network and potentially intermediate nodes like
>> firewalls. For example, in the performance numbers that Kalyani
>> posted, the TPS for SR over IPIP routing was lower than other
>> encapsulations. The reason for this is that the particular NIC (ixgbe)
>> is not parsing over IPIP or using flow label to get a good hash for
>> RSS. This is symptomatic of network devices that don't provide as good
>> support for protocols outside of TCP and UDP. There are likely routers
>> that would not be able to provide flow specific ECMP for similar
>> reasons. There was a comment in dmm meeting that ECMP for IPIP was
>> expected to by solved by using flow label in the hash. This is a great
>> idea, but unfortunately there is significant resistance to using flow
>> label for this purpose since it is not guaranteed to be persistent for
>> a flow and that can cause problems for stateful devices like
>> firewalls.
>>
>> UDP encapsulation is the typical answer to network protocol
>> compatibility. Several UDP encapsulation techniques have been defined
>> as well as some foo over UDP to run existing encapsulations over UDP
>> (e.g. MPLS/UDP, GRE/UDP). draft-ietf-rtgwg-dt-encap gives a nice
>> overview of considerations for UDP encap protocols.
>>
>> If a UDP encapsulation is considered for use with SR, I would suggest
>> GUE is an option. GUE has some unique features:
>>
>> - It's extensible (both common extensions are defined and allows
>> custom extensions per use case)
>> - It's generic (can encapsulate any IP protocol)
>> - It allows directly encapsulating IPv4 and IPv6 in UDP (to minimize
>> encapsulation overhead)
>> - It allows encapsulation of extension headers
>>
>> The last point may be of particular interest to SR. SR over IPIP might
>> be more precarious compared to other encapsulations since it
>> introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE could
>> be used to normalize SR packets to look like UDP to the network. This
>> might look something like:
>>
>> IP|UDP|GUE|Routing_hdr|IP|payload
>>
>> The UDP and GUE header are effectively treated as routing shim at each
>> segment hop so SR is processed as without regard to the encapsulation.
>> To intermediate nodes these packets looks like any other UDP packet so
>> there's no compatibility issue.
>>
>> Tom
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Satoru Matsushima]

Thank you Tom for your suggestion.

Do you think that GUE has some advantages against GTP-U?
When it comes to foo over UDP capsulation, does GUE benefit user plane beyond 
GTP-U?

Best regards,
--satoru



> 2018/03/27 9:16、Tom Herbert のメール:
> 
> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
>  wrote:
>> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>> 
>> We are also waiting for Lyle to share his notes. Please review and
>> comment, if you see any mistakes.
>> 
> 
> With regards to SR encapsulation: "this is using IP-in-IP as default.
> Why not using UDP encapsulation?"
> 
> There is some rationale for UDP encapsulation here to maximize
> compatibility with the network and potentially intermediate nodes like
> firewalls. For example, in the performance numbers that Kalyani
> posted, the TPS for SR over IPIP routing was lower than other
> encapsulations. The reason for this is that the particular NIC (ixgbe)
> is not parsing over IPIP or using flow label to get a good hash for
> RSS. This is symptomatic of network devices that don't provide as good
> support for protocols outside of TCP and UDP. There are likely routers
> that would not be able to provide flow specific ECMP for similar
> reasons. There was a comment in dmm meeting that ECMP for IPIP was
> expected to by solved by using flow label in the hash. This is a great
> idea, but unfortunately there is significant resistance to using flow
> label for this purpose since it is not guaranteed to be persistent for
> a flow and that can cause problems for stateful devices like
> firewalls.
> 
> UDP encapsulation is the typical answer to network protocol
> compatibility. Several UDP encapsulation techniques have been defined
> as well as some foo over UDP to run existing encapsulations over UDP
> (e.g. MPLS/UDP, GRE/UDP). draft-ietf-rtgwg-dt-encap gives a nice
> overview of considerations for UDP encap protocols.
> 
> If a UDP encapsulation is considered for use with SR, I would suggest
> GUE is an option. GUE has some unique features:
> 
> - It's extensible (both common extensions are defined and allows
> custom extensions per use case)
> - It's generic (can encapsulate any IP protocol)
> - It allows directly encapsulating IPv4 and IPv6 in UDP (to minimize
> encapsulation overhead)
> - It allows encapsulation of extension headers
> 
> The last point may be of particular interest to SR. SR over IPIP might
> be more precarious compared to other encapsulations since it
> introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE could
> be used to normalize SR packets to look like UDP to the network. This
> might look something like:
> 
> IP|UDP|GUE|Routing_hdr|IP|payload
> 
> The UDP and GUE header are effectively treated as routing shim at each
> segment hop so SR is processed as without regard to the encapsulation.
> To intermediate nodes these packets looks like any other UDP packet so
> there's no compatibility issue.
> 
> Tom
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Tom Herbert]

On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
 wrote:
> FYI. This is the notes that Carlos captured. Thank you Carlos!!
>
> We are also waiting for Lyle to share his notes. Please review and
> comment, if you see any mistakes.
>

With regards to SR encapsulation: "this is using IP-in-IP as default.
Why not using UDP encapsulation?"

There is some rationale for UDP encapsulation here to maximize
compatibility with the network and potentially intermediate nodes like
firewalls. For example, in the performance numbers that Kalyani
posted, the TPS for SR over IPIP routing was lower than other
encapsulations. The reason for this is that the particular NIC (ixgbe)
is not parsing over IPIP or using flow label to get a good hash for
RSS. This is symptomatic of network devices that don't provide as good
support for protocols outside of TCP and UDP. There are likely routers
that would not be able to provide flow specific ECMP for similar
reasons. There was a comment in dmm meeting that ECMP for IPIP was
expected to by solved by using flow label in the hash. This is a great
idea, but unfortunately there is significant resistance to using flow
label for this purpose since it is not guaranteed to be persistent for
a flow and that can cause problems for stateful devices like
firewalls.

UDP encapsulation is the typical answer to network protocol
compatibility. Several UDP encapsulation techniques have been defined
as well as some foo over UDP to run existing encapsulations over UDP
(e.g. MPLS/UDP, GRE/UDP). draft-ietf-rtgwg-dt-encap gives a nice
overview of considerations for UDP encap protocols.

If a UDP encapsulation is considered for use with SR, I would suggest
GUE is an option. GUE has some unique features:

- It's extensible (both common extensions are defined and allows
custom extensions per use case)
- It's generic (can encapsulate any IP protocol)
- It allows directly encapsulating IPv4 and IPv6 in UDP (to minimize
encapsulation overhead)
- It allows encapsulation of extension headers

The last point may be of particular interest to SR. SR over IPIP might
be more precarious compared to other encapsulations since it
introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE could
be used to normalize SR packets to look like UDP to the network. This
might look something like:

IP|UDP|GUE|Routing_hdr|IP|payload

The UDP and GUE header are effectively treated as routing shim at each
segment hop so SR is processed as without regard to the encapsulation.
To intermediate nodes these packets looks like any other UDP packet so
there's no compatibility issue.

Tom

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm