Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
On Wed, Mar 6, 2019 at 3:05 AM Moses, Danny wrote:
>
> Yes, now I see your point. Setsockopt() will trigger the exchange of packets
> between the mobile host and the network to allocate the desired prefix (if
> not already allocated), and connect() will be blocked until the prefix is
> allocated and the TCP handshaking is completed.
>
> Some pros and cons that come to mind are:
> Pros:
> Setsockopt() is still non-blocking.
> Non need to pass the address as a parameter.
> No need for defining a new function.
>
> Conns:
> It is not clear how the connect() should act if the desired address type is
> not allocated by the network. Should it still connect with the address
> available to the host or should it fail?
It should fail with EADDRNOTAVAIL. If the application wants to
fallback to any available address it can do that itself when the error
is returned.
> If it continues to connect, the application is not aware of the type of
> mobility service it will receive from the network.
> If it should not connect, we are changing the definition of the behavior of
> connect(). Furthermore, applications that do not care about mobility service,
> will use connect() without setsockopt(). So now, connect() need to know
> whether or not setsockopt() was invoked for setting the desired mobility
> service type - also a new functionality of connect().
> It will not work for UDP (were connect() is not invoked). However, this is
> not a strong conn, since we can define that as a default address type for UDP
> sockets should be 'non-persistent'.
bind can be called in that case for the same effect.
>
> When the concern regarding the 'blocking' nature of setsockopt() was
> discussed in DMM, we provided several alternatives for resolution, and after
> some discussion, the one defined in the document was chosen.
>
> Your alternative is also viable, but it is not clear to me that it is
> significantly better and is worth reopening the discussion once again in DMM.
> But, our correspondence is on the list and everyone is welcome to post an
> opinion.
Danny,
The problem is that this is API and not protocol being standardized--
it may or may not be adopted by implementations. Adding a new socket
call is a big deal. You'll need to justify that this it is necessary
and that the functionality can't be acheived with existing API. I
would suggest that you post patches for this to Linux netdev to get
feedback from the developer community.
Tom
>
> Regards,
> Danny
>
>
>
> -Original Message-
> From: Tom Herbert [mailto:t...@quantonium.net]
> Sent: Tuesday, March 05, 2019 18:26
> To: Moses, Danny
> Cc: dmm
> Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
>
> On Tue, Mar 5, 2019 at 2:29 AM Moses, Danny wrote:
> >
> > Can you please provide a calling sequence of your proposal?
> >
>
> Something like:
>
> s = socket(AF_INET6, SOCK_STREAM, 0) ;
> setsockopt(s, IPPROTO_IP, PREFERRED_ADDRESS_TYPE,
> IPV6_REQUIRE_SESSION_LASTING_IP)
> if (connect(s, &serverInfo, sizeof(serverInfo)) < 0) {
>if (errno == EADDRNOTAVAIL) {
> // Didn't get address for requested type
> }
> ...
> }
>
> // To get address local address that was selected...
> getsockname(s, &myaddr, &myaddrlen);
>
>
> > Thanks,
> > Danny
> >
> > -Original Message-
> > From: Tom Herbert [mailto:t...@quantonium.net]
> > Sent: Monday, March 04, 2019 17:17
> > To: Moses, Danny
> > Cc: dmm
> > Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
> >
> > On Mon, Mar 4, 2019 at 4:25 AM Moses, Danny wrote:
> > >
> > > Hi Tom,
> > >
> > > Fair question.
> > >
> > > I believe I mentioned that in one of my responses. The original
> > > definition was to use setsockopt() with new flags. However, some people
> > > raised the concern that this new feature changes the behavior of the
> > > function in a way that may confuse programmers and requested to use a new
> > > function (setsc()).
> > >
> > > The issue was due to the time it takes the function to process the
> > > request. In current Socket implementation, setsockopt() is a function
> > > that returns immediately to the caller. On the other hand, this new
> > > feature may trigger an exchange of packets between the IP stack in the
> > > mobile node and the network allocating the IP prefix. This exchange takes
> > > time and the function can return only after the exchange is completed.
> > > They insisted that we maintain the current 'immedia
Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
On Tue, Mar 5, 2019 at 2:29 AM Moses, Danny wrote:
>
> Can you please provide a calling sequence of your proposal?
>
Something like:
s = socket(AF_INET6, SOCK_STREAM, 0) ;
setsockopt(s, IPPROTO_IP, PREFERRED_ADDRESS_TYPE,
IPV6_REQUIRE_SESSION_LASTING_IP)
if (connect(s, &serverInfo, sizeof(serverInfo)) < 0) {
if (errno == EADDRNOTAVAIL) {
// Didn't get address for requested type
}
...
}
// To get address local address that was selected...
getsockname(s, &myaddr, &myaddrlen);
> Thanks,
> Danny
>
> -Original Message-
> From: Tom Herbert [mailto:t...@quantonium.net]
> Sent: Monday, March 04, 2019 17:17
> To: Moses, Danny
> Cc: dmm
> Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
>
> On Mon, Mar 4, 2019 at 4:25 AM Moses, Danny wrote:
> >
> > Hi Tom,
> >
> > Fair question.
> >
> > I believe I mentioned that in one of my responses. The original definition
> > was to use setsockopt() with new flags. However, some people raised the
> > concern that this new feature changes the behavior of the function in a way
> > that may confuse programmers and requested to use a new function (setsc()).
> >
> > The issue was due to the time it takes the function to process the request.
> > In current Socket implementation, setsockopt() is a function that returns
> > immediately to the caller. On the other hand, this new feature may trigger
> > an exchange of packets between the IP stack in the mobile node and the
> > network allocating the IP prefix. This exchange takes time and the function
> > can return only after the exchange is completed. They insisted that we
> > maintain the current 'immediate' return behavior of setsockopt() and
> > introduce a new function that might 'block' the calling thread until it
> > completes.
> >
> Hi Danny,
>
> It is unclear to me why address selection has to be done outside of binding
> the socket. It seems like the required functionality of the draft could be
> achieved by calling setsockopt to express desired address type and then
> calling connect on the socket. Connect will bind an address with the
> requested type and can obviously block if work needs to be done to find an
> appropriate address. This simplifies the API and addresses an ambiguity in
> the draft-- when setsc returns it is unclear if the address was somehow
> reserved for the socket use (e.g.
> this becomes pertinent if we were to add an interface to bind a unique
> address to a socket).
>
> Tom
>
> > Regards,
> > Danny
> >
> >
> >
> >
> > -Original Message-
> > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> > Sent: Friday, February 22, 2019 22:08
> > To: dmm
> > Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
> >
> > Out of curiosity, why is the new API being portrayed as a system call
> > (setsc) instead of a socket option (the bar for adding a socket option is
> > much lower ).
> >
> > Tom
> >
> > On Fri, Feb 22, 2019 at 6:19 AM wrote:
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > This draft is a work item of the Distributed Mobility Management WG of
> > > the IETF.
> > >
> > > Title : On Demand Mobility Management
> > > Authors : Alper Yegin
> > > Danny Moses
> > > Seil Jeon
> > > Filename: draft-ietf-dmm-ondemand-mobility-17.txt
> > > Pages : 18
> > > Date: 2019-02-22
> > >
> > > Abstract:
> > >Applications differ with respect to whether they need session
> > >continuity and/or IP address reachability. The network providing the
> > >same type of service to any mobile host and any application running
> > >on the host yields inefficiencies, as described in [RFC7333]. This
> > >document defines a new concep of enabling applications to influence
> > >the network's mobility services (session continuity and/or IP address
> > >reachability) on a per-Socket basis, and suggests extensions to the
> > >networking stack's API to accomodate this concept.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
> > >
> > >
Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
On Mon, Mar 4, 2019 at 4:25 AM Moses, Danny wrote: > > Hi Tom, > > Fair question. > > I believe I mentioned that in one of my responses. The original definition > was to use setsockopt() with new flags. However, some people raised the > concern that this new feature changes the behavior of the function in a way > that may confuse programmers and requested to use a new function (setsc()). > > The issue was due to the time it takes the function to process the request. > In current Socket implementation, setsockopt() is a function that returns > immediately to the caller. On the other hand, this new feature may trigger an > exchange of packets between the IP stack in the mobile node and the network > allocating the IP prefix. This exchange takes time and the function can > return only after the exchange is completed. They insisted that we maintain > the current 'immediate' return behavior of setsockopt() and introduce a new > function that might 'block' the calling thread until it completes. > Hi Danny, It is unclear to me why address selection has to be done outside of binding the socket. It seems like the required functionality of the draft could be achieved by calling setsockopt to express desired address type and then calling connect on the socket. Connect will bind an address with the requested type and can obviously block if work needs to be done to find an appropriate address. This simplifies the API and addresses an ambiguity in the draft-- when setsc returns it is unclear if the address was somehow reserved for the socket use (e.g. this becomes pertinent if we were to add an interface to bind a unique address to a socket). Tom > Regards, > Danny > > > > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: Friday, February 22, 2019 22:08 > To: dmm > Subject: Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt > > Out of curiosity, why is the new API being portrayed as a system call > (setsc) instead of a socket option (the bar for adding a socket option is > much lower ). > > Tom > > On Fri, Feb 22, 2019 at 6:19 AM wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Distributed Mobility Management WG of the > > IETF. > > > > Title : On Demand Mobility Management > > Authors : Alper Yegin > > Danny Moses > > Seil Jeon > > Filename: draft-ietf-dmm-ondemand-mobility-17.txt > > Pages : 18 > > Date: 2019-02-22 > > > > Abstract: > >Applications differ with respect to whether they need session > >continuity and/or IP address reachability. The network providing the > >same type of service to any mobile host and any application running > >on the host yields inefficiencies, as described in [RFC7333]. This > >document defines a new concep of enabling applications to influence > >the network's mobility services (session continuity and/or IP address > >reachability) on a per-Socket basis, and suggests extensions to the > >networking stack's API to accomodate this concept. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-17 > > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-ondemand-mobility > > -17 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-17 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > ___ > > 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 > - > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt
Out of curiosity, why is the new API being portrayed as a system call (setsc) instead of a socket option (the bar for adding a socket option is much lower ). Tom On Fri, Feb 22, 2019 at 6:19 AM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Distributed Mobility Management WG of the > IETF. > > Title : On Demand Mobility Management > Authors : Alper Yegin > Danny Moses > Seil Jeon > Filename: draft-ietf-dmm-ondemand-mobility-17.txt > Pages : 18 > Date: 2019-02-22 > > Abstract: >Applications differ with respect to whether they need session >continuity and/or IP address reachability. The network providing the >same type of service to any mobile host and any application running >on the host yields inefficiencies, as described in [RFC7333]. This >document defines a new concep of enabling applications to influence >the network's mobility services (session continuity and/or IP address >reachability) on a per-Socket basis, and suggests extensions to the >networking stack's API to accomodate this concept. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-17 > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-ondemand-mobility-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-17 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > 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] [Pidloc] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
On Tue, Jan 29, 2019 at 12:13 PM Templin (US), Fred L
wrote:
>
> Hi Tom,
>
> > -Original Message-----
> > From: Tom Herbert [mailto:t...@quantonium.net]
> > Sent: Tuesday, January 29, 2019 11:25 AM
> > To: Templin (US), Fred L
> > Cc: Vikram Siwach ; pid...@ietf.org; dmm
> > Subject: Re: [Pidloc] [DMM] Fwd: New Version Notification for
> > draft-herbert-intarea-ams-00.txt
> >
> > On Tue, Jan 29, 2019 at 10:25 AM Templin (US), Fred L
> > wrote:
> > >
> > > Hi Tom,
> > >
> > > > -Original Message-
> > > > From: Pidloc [mailto:pidloc-boun...@ietf.org] On Behalf Of Tom Herbert
> > > > Sent: Tuesday, January 29, 2019 9:36 AM
> > > > To: Templin (US), Fred L
> > > > Cc: Vikram Siwach ; pid...@ietf.org; dmm
> > > >
> > > > Subject: Re: [Pidloc] [DMM] Fwd: New Version Notification for
> > > > draft-herbert-intarea-ams-00.txt
> > > >
> > > > On Tue, Jan 29, 2019 at 8:46 AM Templin (US), Fred L
> > > > wrote:
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > Please read 'draft-templin-rtgwg-scalable-bgp' (only 7 pages). It
> > > > > emphasizes
> > > > > the scalability considerations from 'draft-templin-intarea-6706bis'
> > > > > that we
> > > > > omitted from 'draft-ietf-rtgwg-atn-bgp', and also shows that the use
> > > > > cases
> > > > > are not limited to civil aviation. The purpose is to present a
> > > > > condensed
> > > > > version of the AERO routing system that has been around for many
> > > > > years.
> > > > >
> > > > > In 'draft-templin-rtgwg-scalable-bgp', we show that a BGP overlay can
> > > > > be
> > > > > organized to support 1B or more de-aggregated MNP prefixes. So, please
> > > > > have a look at that with the mindset that we are not addressing just
> > > > > the
> > > > > civil aviation use case but are broadly considering other use cases.
> > > > >
> > > > Okay, thanks for the explanation. It might be helpful if you could
> > > > recast draft-ietf-rtgwg-atn-bgp to be more of a general solution.
> > >
> > > Good input, but for that one we really were chartered to focus
> > > specifically
> > > on the aviation use case. Even so, the document says:
> > >
> > >"In this way, each set of c-ASBRs maintains
> > >separate routing and forwarding tables so that scaling is distributed
> > >across multiple c-ASBR sets instead of concentrated in a single
> > >c-ASBR set. For example, a first c-ASBR set could aggregate an MSP
> > >segment A::/32, a second set could aggregate B::/32, a third could
> > >aggregate C::/32, etc. The union of all MSP segments would then
> > >constitute the collective MSP(s) for the entire ATN/IPS."
> > >
> > > The A::/32, B::/32, C::/32 I think correspond to what your document calls
> > > "shards", but there is no implied maximum number in the doc so there
> > > could be thousands. But, in terms of the architecture, all three documents
> > > ('scalable-bgp', 'atn-bgp' and AERO) really say the same thing - scalable
> > > deaggregation.
> > >
> > I see. I think the atn may be nicely describing the sharding referred
> > to in AMS. AMS employs caches to ensure direct path for critical
> > communications.
>
> But, what do you do with arriving packets while there is a cache miss and
> you need to go out and fill the cache? Drop them on the floor? Hold them
> in a queue? With the BGP arrangement, packets are forwarded normally
> even if initial packets end up taking a somewhat longer route.
>
> > From that POV maybe they are complementary.
>
> I think examining the elements that would be at work within the stub AS
> makes sense, and I haven't gone to that level of examination in the *rtgwg*
> docs. But, intra- stub AS candidate solutions already include MIPv6, LISP and
> AERO - so, you may need to look for overlaps with those as well.
>
> > > > I looked at draft-templin-rtgwg-scalable-bgp. There's a lot discussion
> > > > about scalability of c-ASBR but not so much about s-ABSR. I'm
> > > > primarily interested in the latter because that is where the solution
> > > > will be providing the oprimizati
Re: [DMM] [Pidloc] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
On Tue, Jan 29, 2019 at 10:25 AM Templin (US), Fred L
wrote:
>
> Hi Tom,
>
> > -Original Message-
> > From: Pidloc [mailto:pidloc-boun...@ietf.org] On Behalf Of Tom Herbert
> > Sent: Tuesday, January 29, 2019 9:36 AM
> > To: Templin (US), Fred L
> > Cc: Vikram Siwach ; pid...@ietf.org; dmm
> > Subject: Re: [Pidloc] [DMM] Fwd: New Version Notification for
> > draft-herbert-intarea-ams-00.txt
> >
> > On Tue, Jan 29, 2019 at 8:46 AM Templin (US), Fred L
> > wrote:
> > >
> > > Hi Tom,
> > >
> > > Please read 'draft-templin-rtgwg-scalable-bgp' (only 7 pages). It
> > > emphasizes
> > > the scalability considerations from 'draft-templin-intarea-6706bis' that
> > > we
> > > omitted from 'draft-ietf-rtgwg-atn-bgp', and also shows that the use cases
> > > are not limited to civil aviation. The purpose is to present a condensed
> > > version of the AERO routing system that has been around for many years.
> > >
> > > In 'draft-templin-rtgwg-scalable-bgp', we show that a BGP overlay can be
> > > organized to support 1B or more de-aggregated MNP prefixes. So, please
> > > have a look at that with the mindset that we are not addressing just the
> > > civil aviation use case but are broadly considering other use cases.
> > >
> > Okay, thanks for the explanation. It might be helpful if you could
> > recast draft-ietf-rtgwg-atn-bgp to be more of a general solution.
>
> Good input, but for that one we really were chartered to focus specifically
> on the aviation use case. Even so, the document says:
>
>"In this way, each set of c-ASBRs maintains
>separate routing and forwarding tables so that scaling is distributed
>across multiple c-ASBR sets instead of concentrated in a single
>c-ASBR set. For example, a first c-ASBR set could aggregate an MSP
>segment A::/32, a second set could aggregate B::/32, a third could
>aggregate C::/32, etc. The union of all MSP segments would then
>constitute the collective MSP(s) for the entire ATN/IPS."
>
> The A::/32, B::/32, C::/32 I think correspond to what your document calls
> "shards", but there is no implied maximum number in the doc so there
> could be thousands. But, in terms of the architecture, all three documents
> ('scalable-bgp', 'atn-bgp' and AERO) really say the same thing - scalable
> deaggregation.
>
I see. I think the atn may be nicely describing the sharding referred
to in AMS. AMS employs caches to ensure direct path for critical
communications. From that POV maybe they are complementary.
> > I looked at draft-templin-rtgwg-scalable-bgp. There's a lot discussion
> > about scalability of c-ASBR but not so much about s-ABSR. I'm
> > primarily interested in the latter because that is where the solution
> > will be providing the oprimizations we want for low latency. While
> > with c-ASBRs we could expect them to have scaling properties similar
> > core routers, I would expect that s-ASBR devices will exhibit a lot
> > more variety and have a wider range of scalability.
>
> The document is very careful to differentiate scaling considerations of
> s-ASBRs independently of the scaling considerations of the stub AS.
> The s-ASBR is the entity that connects the stub AS to the overlay, but
> there may be many other entities inside the stub AS whose job it is
> to coordinate with the mobile nodes.
>
> > For instance, it's
> > conceivable that we might want the functionality incorporated into a
> > low powered device in the base station of a microcell, or incorporated
> > into MEC servers as I mentioned previously. I assume a BGP solution
> > would require all s-ASBRs to hold all the routes for the sub-MNPs as
> > well as being able to consume the rate of mobile events within the
> > sub-MNP.
>
> Other elements inside the stub AS can do the fine-grained mobility
> signaling with the mobile nodes, while the s-ASBR can be deployed in
> such a fashion that all it ever does is send unidirectional BGP updates
> to c-ASBRs.
>
> > So to me, the obvious question is if such a device were only
> > communicating with, say, a 1000 nodes at any givent time, then does it
> > really make sense to give them all the information about the 1M or so
> > nodes in the sub-MNP, or can we just give them the information that is
> > currently useful to them?
>
> The stub ASes accept mobile node customers up to a certain maximum.
> So, if there are currently only 1K customers then there are currently only
> 1K routes. But, let's a
Re: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
On Tue, Jan 29, 2019 at 8:46 AM Templin (US), Fred L wrote: > > Hi Tom, > > Please read 'draft-templin-rtgwg-scalable-bgp' (only 7 pages). It emphasizes > the scalability considerations from 'draft-templin-intarea-6706bis' that we > omitted from 'draft-ietf-rtgwg-atn-bgp', and also shows that the use cases > are not limited to civil aviation. The purpose is to present a condensed > version of the AERO routing system that has been around for many years. > > In 'draft-templin-rtgwg-scalable-bgp', we show that a BGP overlay can be > organized to support 1B or more de-aggregated MNP prefixes. So, please > have a look at that with the mindset that we are not addressing just the > civil aviation use case but are broadly considering other use cases. > Okay, thanks for the explanation. It might be helpful if you could recast draft-ietf-rtgwg-atn-bgp to be more of a general solution. I looked at draft-templin-rtgwg-scalable-bgp. There's a lot discussion about scalability of c-ASBR but not so much about s-ABSR. I'm primarily interested in the latter because that is where the solution will be providing the oprimizations we want for low latency. While with c-ASBRs we could expect them to have scaling properties similar core routers, I would expect that s-ASBR devices will exhibit a lot more variety and have a wider range of scalability. For instance, it's conceivable that we might want the functionality incorporated into a low powered device in the base station of a microcell, or incorporated into MEC servers as I mentioned previously. I assume a BGP solution would require all s-ASBRs to hold all the routes for the sub-MNPs as well as being able to consume the rate of mobile events within the sub-MNP. So to me, the obvious question is if such a device were only communicating with, say, a 1000 nodes at any givent time, then does it really make sense to give them all the information about the 1M or so nodes in the sub-MNP, or can we just give them the information that is currently useful to them? Do you have any thoughts along these lines? Tom > Thanks - Fred > > > -Original Message- > > From: Tom Herbert [mailto:t...@quantonium.net] > > Sent: Tuesday, January 29, 2019 8:33 AM > > To: Templin (US), Fred L > > Cc: dmm ; pid...@ietf.org; Vikram Siwach > > Subject: Re: [DMM] Fwd: New Version Notification for > > draft-herbert-intarea-ams-00.txt > > > > On Tue, Jan 29, 2019 at 7:35 AM Templin (US), Fred L > > wrote: > > > > > > Hi Tom, > > > > > > I read it, and I do not think it is different from the system described > > > in 'draft-ietf-rtgwg-atn-bgp'. > > > > > Hi Fred, > > > > Thanks for the comment. I have read draft-ietf-rtgwg-atn-bgp also. I > > think that the hub and spoke architecture will end up being similar, > > but I'm not sure that this is exactly the same thing. One difference > > is that draft-ietf-rtgwg-atn-bgp is targeted to particular > > application, whereas draft-herbert-intarea-ams endeavours to be > > general purposes. There are differences especially in scalability. For > > instance, rtgwg-atn-bgp mentions network with millions of routes, and > > in draft-herbert-intarea-ams the target is to support networks with > > billions of active addresses for IoT networks. And if we do get to > > unique address per flow, then the total number of addresses to be > > managed is much more (hence why hidden aggregation becomes > > interesting). > > > > Another consideration is MEC servers providing services to UEs at they > > edge. If they participate in the routing/mapping system (as an ASBR-s > > in draft-ietf-rtgwg-atn-bgp and AMS-F in AMS) then the end device can > > perform overlay routing itself. That is very efficient for lowest > > latency. There may be many MEC servers and each one might only be > > communicating with a small subset of all possible nodes. This seems to > > motivate a working set cache to that limits the number of mappings as > > well as the amount of control plane communications. > > > > Tom > > > > > Fred > > > > > > > -Original Message- > > > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > > > > Sent: Monday, January 28, 2019 3:36 PM > > > > To: dmm ; pid...@ietf.org > > > > Cc: Vikram Siwach > > > > Subject: [DMM] Fwd: New Version Notification for > > > > draft-herbert-intarea-ams-00.txt > > > > > > > > Hello, > > > > > > > > We've posted a first draft of Address Mapping System (AMS). We > > > &g
Re: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
On Tue, Jan 29, 2019 at 7:35 AM Templin (US), Fred L wrote: > > Hi Tom, > > I read it, and I do not think it is different from the system described > in 'draft-ietf-rtgwg-atn-bgp'. > Hi Fred, Thanks for the comment. I have read draft-ietf-rtgwg-atn-bgp also. I think that the hub and spoke architecture will end up being similar, but I'm not sure that this is exactly the same thing. One difference is that draft-ietf-rtgwg-atn-bgp is targeted to particular application, whereas draft-herbert-intarea-ams endeavours to be general purposes. There are differences especially in scalability. For instance, rtgwg-atn-bgp mentions network with millions of routes, and in draft-herbert-intarea-ams the target is to support networks with billions of active addresses for IoT networks. And if we do get to unique address per flow, then the total number of addresses to be managed is much more (hence why hidden aggregation becomes interesting). Another consideration is MEC servers providing services to UEs at they edge. If they participate in the routing/mapping system (as an ASBR-s in draft-ietf-rtgwg-atn-bgp and AMS-F in AMS) then the end device can perform overlay routing itself. That is very efficient for lowest latency. There may be many MEC servers and each one might only be communicating with a small subset of all possible nodes. This seems to motivate a working set cache to that limits the number of mappings as well as the amount of control plane communications. Tom > Fred > > > -Original Message- > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > > Sent: Monday, January 28, 2019 3:36 PM > > To: dmm ; pid...@ietf.org > > Cc: Vikram Siwach > > Subject: [DMM] Fwd: New Version Notification for > > draft-herbert-intarea-ams-00.txt > > > > Hello, > > > > We've posted a first draft of Address Mapping System (AMS). We > > anticipate that this can be applied to mobile networks to provide > > optimized overlay routing. In particular, this design provides for > > anchorless routing (in the form of anchor bypass) and otherwise > > facilitates meeting several requirements for optimizing the mobile > > user plane as described in section 1.0 of > > draft-bogineni-dmm-optimized-mobile-user-plane-01. AMS is agnostic to > > the underlaying overlay protocol and should be compatible with most of > > those being discussed. Another goal of AMS is to not require replacing > > exsiting control planes, but can work in concert with them. For > > example, the draft discusses how AMS might work with 5G. > > > > Tom > > > > -- Forwarded message - > > From: > > Date: Mon, Jan 28, 2019 at 3:15 PM > > Subject: New Version Notification for draft-herbert-intarea-ams-00.txt > > To: Vikram Siwach > > > > > > > > A new version of I-D, draft-herbert-intarea-ams-00.txt > > has been successfully submitted by Tom Herbert and posted to the > > IETF repository. > > > > Name: draft-herbert-intarea-ams > > Revision: 00 > > Title: Address Mapping System > > Document date: 2019-01-28 > > Group: Individual Submission > > Pages: 47 > > URL: > > https://www.ietf.org/internet-drafts/draft-herbert-intarea-ams-00.txt > > Status: https://datatracker.ietf.org/doc/draft-herbert-intarea-ams/ > > Htmlized: https://tools.ietf.org/html/draft-herbert-intarea-ams-00 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ams > > > > > > Abstract: > >This document describes the Address Mapping System that is a generic, > >extensible, and scalable system for mapping network addresses to > >other network addresses. The Address Mapping System is intended to be > >used in conjunction with overlay techniques which facilitate > >transmission of packets across overlay networks. Information returned > >by the Address Mapping System can include the particular network > >overlay method and instructions related to the method. The Address > >Mapping System has a number of potential use cases networking > >including identifier-locator protocols, network virtualization, and > >promotion of privacy. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > ___ > > 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
[DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
Hello, We've posted a first draft of Address Mapping System (AMS). We anticipate that this can be applied to mobile networks to provide optimized overlay routing. In particular, this design provides for anchorless routing (in the form of anchor bypass) and otherwise facilitates meeting several requirements for optimizing the mobile user plane as described in section 1.0 of draft-bogineni-dmm-optimized-mobile-user-plane-01. AMS is agnostic to the underlaying overlay protocol and should be compatible with most of those being discussed. Another goal of AMS is to not require replacing exsiting control planes, but can work in concert with them. For example, the draft discusses how AMS might work with 5G. Tom -- Forwarded message - From: Date: Mon, Jan 28, 2019 at 3:15 PM Subject: New Version Notification for draft-herbert-intarea-ams-00.txt To: Vikram Siwach A new version of I-D, draft-herbert-intarea-ams-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-intarea-ams Revision: 00 Title: Address Mapping System Document date: 2019-01-28 Group: Individual Submission Pages: 47 URL: https://www.ietf.org/internet-drafts/draft-herbert-intarea-ams-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-intarea-ams/ Htmlized: https://tools.ietf.org/html/draft-herbert-intarea-ams-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ams Abstract: This document describes the Address Mapping System that is a generic, extensible, and scalable system for mapping network addresses to other network addresses. The Address Mapping System is intended to be used in conjunction with overlay techniques which facilitate transmission of packets across overlay networks. Information returned by the Address Mapping System can include the particular network overlay method and instructions related to the method. The Address Mapping System has a number of potential use cases networking including identifier-locator protocols, network virtualization, and promotion of privacy. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Mon, Oct 1, 2018 at 4:32 AM, wrote: > Hi Alex, > and sorry for jumping into the discussion... > From my and (AFAIK) 3GPPs understanding your smartphone is a UE - sitting on > the other side of RAN (gNB) - whereas a UPF normally is seen as UP entry (and > exit) of the 5G core (i.e. handling all UP traffic in a true CP/UP split > fashion). > Any other ideas on this? Can someone imagine any scenario where UE implements > UPF? Dirk, I am wondering what a UE that has thousands of downstream nodes and is multi-homed with attachments to several networks is called. It seems like it would be making UPF-like decisions in routing, QoS, and cost as to how forward uplink traffic. I don't think it can be a UPF of any attached network, but it seems like it's maybe acting as a "UPF" for it's own network (I think in IETF terminology we would just call it a glorified router). Tom > Thanks! > Best Regards > Dirk > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Montag, 1. Oktober 2018 13:22 > To: dmm@ietf.org > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > > > > Le 01/10/2018 à 05:50, Shunsuke Homma a écrit : >> Hi all, >> # Sorry for my late response... >> >> Thank you for your lively discussion. It is very helpful for >> understanding points which need supplemental explanation and more >> consideration. >> >> Following the discussion, we're planning to update the I-D for >> covering the points below: >> >> - termination points of GTP-U >>(RANs and UPFs terminate GTP-U in 5GS.) > > What is UPF? > > I understand UPF stands for User-Plane Function. > > Is my smartphone supposed to implement UPF? > > Alex > >> - setting QoS parameter of outer IP header >>(Note that it's not just copy of inner to outer.) >> - problems related to IP connectivity (e.g., MTU in IPv6 networks, >> IPv4 address duplication) >> - summary of network slicing in 5GS >>(E.g., "slice is composed of SMF and UPFs. AMF selects SMF >> depending on NSSAI sent from UE, and SMF indicates to the UE the UPF >> that it is >> allocated.") >> - case studies on UPF selection >>(E.g., parameters used for deciding destination UPF) # Optimizing >> forwarding paths solution might be realized with UPF selection >> mechanism in 3GPP architecture. (ID-LOC may be applied as such >> mechanism.) >> >> >> If you have any request for us on this updating, please let us know. >> >> Best regards, >> >> Shunsuke >> >> On 2018/09/08 3:28, Dino Farinacci wrote: >>>> I understand your point, but there is no guarantee for a precise QoS >>>> without using some sort of encapsulation being it GTP, RSVP, etc. >>>> Even with tunnels, there is no guarantee that all nodes along the >>>> path have the same hardware capability and can provide the same QoS >>>> treatment. >>> >>> There is existing hardware where the encapsulator copies inner QoS to >>> outer QoS. All routers along the path just process the outer QoS, no >>> changes to or new processing requirements for them. >>> >>>> For example, the code points in routers need to be configured to >>>> correctly handle the EXP bits in MPLS labels. But there is no >>>> guarantee that all routers can support all values. The EXP values >>>> get mapped to code points but the mapping is not always one to one. >>>> 3-bit EXPs can map to 4 code points on those routers with less >>>> capable H/W. >>> >>> That is a completely different matter. The discussion is about >>> remarking. And if one remarks to what the path cannot support, well >>> things don’t work as expected. >>> >>>> Slicing is almost the same. It allows user traffic to be mapped to >>>> what the operator provides. >>>> I agree with you that network should not touch/change original >>>> header bits. GTP or any other encapsulation easily allow for this. >>>> The question is whether we can provide for this without using >>>> encapsulation. IPv6 might be the answer. But as Tom pointed out, >>>> flow labels can still change in the middle. Is there any room for >>>> improvement. SIDs might present an opportunity. >>> >>> Not if they are encapsulated and routers don’t touch packets inside. >>> >>> Dino >>> >>>> >>>> >>>> >>>> >>>> &
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Fri, Sep 7, 2018 at 10:46 AM, Arashmid Akhavain wrote: > 100% Agree with you Tom. And these are type of questions we need to answer > when we talk about GTP replacement. The control plane in today's mobile core > sets up the tunnel and ensure the uniformity of QoS in > both forward and backward path. Hi Arashmid, FAST should be orthogonal to the issue of GTP replacement and is agnostic to underlying RAN protocols. It's implemented at the IP layer and the network services it conveys can be supported by a network in an arbitrary fashion. > > Can you elaborate on using FAST? FAST on UPFs? The basic idea of FAST is that hosts (UE) requests tickets from a "ticket agent" in their local network. The request is an abstract description of desired services (like low latency, low jitter for 1080p video chat). The ticket agent sends back a "ticket" that encodes the services the network has granted. The ticket is opaque to the application and anyone else outside of the network provider. The application attaches the ticket to its packets (in IPv6 HBH options) and sends them normally otherwise. At the first hop node in the network, the ticket is decoded by the network. Appropriate services are applied (e.g. set DSCP, set QoS, send into a tunnel or slice, etc.). The packet makes it's way to the destination with the ticket attached. The destination saves the ticket in it's context for communication. When the remote server replies, it attaches saved tickets as a "reflected tickets". When the return packet enters the client's network of the client, a node decodes the ticket and maps it to the right services for transit the provider networks back the UE. There are lot of details: like how to keep overhead low, how to make this secure ans stateless, how to limit scope of sensitive information, how to deal with paths that block HBH options. Please take a look at the FAST draft https://tools.ietf.org/html/draft-herbert-fast and white paper https://github.com/quantonium/papers/blob/master/FAST.pdf Tom > > Arashmid > > >> -Original Message- >> From: Tom Herbert [mailto:t...@quantonium.net] >> Sent: 07 September 2018 11:51 >> To: Arashmid Akhavain >> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp; >> dmm >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >> >> On Fri, Sep 7, 2018 at 8:26 AM, Arashmid Akhavain >> wrote: >> > Correct, flow labels can change along the path. That's why I like the >> > slicing >> concept. >> > UEs can request services with different attributes, operators control how >> service request are mapped into slices. I should look into the air side of >> the >> business and see what happens there. >> >> Arashmid, >> >> Yes, slices are a good model. The key question is how does a user's packets >> get mapped to the right slice. Presumably, this is done at an ingress point >> into the network. There are two ingress points to be considered, one from >> UE into the network and one from Internet into network (return path). If the >> UE sets bits in the packet to get service in the forward path, we somehow >> need to have those bits available on packets in the return path to map >> incoming packets. In lieu or requiring the network to maintain a whole bunch >> of complex flow state, FAST arranges that the remote server reflects the bits >> in response packets. >> >> Tom >> >> > >> > >> > >> >> -Original Message- >> >> From: Tom Herbert [mailto:t...@quantonium.net] >> >> Sent: 07 September 2018 11:13 >> >> To: Arashmid Akhavain >> >> Cc: Dino Farinacci ; >> >> ta-miyas...@kddi-research.jp; dmm >> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >> >> >> >> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain >> >> wrote: >> >> > >> >> > >> >> >> -Original Message- >> >> >> From: Dino Farinacci [mailto:farina...@gmail.com] >> >> >> Sent: 06 September 2018 18:59 >> >> >> To: Arashmid Akhavain >> >> >> Cc: Tom Herbert ; >> >> >> ta-miyas...@kddi-research.jp; dmm >> >> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis- >> 01 >> >> >> >> >> >> > Dino brought up a good point. Here is my two cents worth: >> >> >> >> >> >> Not sure which point. >> >> >> >> >> >> > As it was explained by Sridhar, each UE can have mu
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Fri, Sep 7, 2018 at 8:26 AM, Arashmid Akhavain wrote: > Correct, flow labels can change along the path. That's why I like the slicing > concept. > UEs can request services with different attributes, operators control how > service request are mapped into slices. I should look into the air side of > the business and see what happens there. Arashmid, Yes, slices are a good model. The key question is how does a user's packets get mapped to the right slice. Presumably, this is done at an ingress point into the network. There are two ingress points to be considered, one from UE into the network and one from Internet into network (return path). If the UE sets bits in the packet to get service in the forward path, we somehow need to have those bits available on packets in the return path to map incoming packets. In lieu or requiring the network to maintain a whole bunch of complex flow state, FAST arranges that the remote server reflects the bits in response packets. Tom > > > >> -Original Message- >> From: Tom Herbert [mailto:t...@quantonium.net] >> Sent: 07 September 2018 11:13 >> To: Arashmid Akhavain >> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp; >> dmm >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >> >> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain >> wrote: >> > >> > >> >> -Original Message- >> >> From: Dino Farinacci [mailto:farina...@gmail.com] >> >> Sent: 06 September 2018 18:59 >> >> To: Arashmid Akhavain >> >> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp; >> >> dmm >> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >> >> >> >> > Dino brought up a good point. Here is my two cents worth: >> >> >> >> Not sure which point. >> >> >> >> > As it was explained by Sridhar, each UE can have multiple >> >> > contexts. For >> >> example, today some operators provide Data and VoLTE service to their >> >> customers. These two services are represented by separate GTP tunnels >> >> in the core with each tunnel tied up to a particular QoS. >> >> > >> >> > IPv4 didn't fit the bill when GTP work was under way as it couldn't >> >> > uniquely identify multiple UE >> >> >> >> There is no reason why it shouldn’t. And IPv6, for this use-case >> >> doesn’t add anything new other than a 28 bit traffic-class/flow-label >> >> that can provide more bits for “new functionality”. >> > >> > >> > [Arashmid] And that's what I meant. Having a flow label is handy. We >> > can perhaps use it to identify different UE sessions. >> > >> Careful if you use the flow label to identify flows. It should be considered >> "soft identification" since it might not always be correct (it can be >> changed en >> route, isn't protected by any checksum, anyone can set it however they want, >> etc.). It's useful for things like ECMP that don't require 100% accuracy in >> identifying flow. The flow label was briefly considered for holding VNIs in >> network virtualization, but we talked them out of that. >> >> Tom >> >> >> >> >> > sessions/context/bearer. So, GTP and TEID did the job. But I agree >> >> > with >> >> Dino that IPv6 is much more versatile and is definitely worth looking >> >> at as an alternative. >> >> >> >> That is not what I said. I said “IP could have solved this problem”. And >> >> “IP” >> >> means either IPv4 or IPv6, or both at the same time. >> > >> > >> > [Arashmid] >> > How would we employ IPv4 to distinguish between different UE sessions. >> TOS? >> > Or you mean using encapsulation? >> > >> >> >> >> > A factor worth considering though is that the use of GTP and TEID >> >> > in mobile >> >> core allows operators to deal with QoS on their own terms. The >> >> tunnels with specific operator-controlled QoS are established by the >> >> control plane between eNB, SGW, and PGW. UEs or applications sitting >> >> in the UEs have no say in this. Well at least till the packet exits >> >> operator's >> network. >> >> >> >> The problem with one header, is that if you re-mark (known as PHB >> >> markign in the ole days) you lose the original value. Encapsulation >> >>
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain wrote: > > >> -Original Message- >> From: Dino Farinacci [mailto:farina...@gmail.com] >> Sent: 06 September 2018 18:59 >> To: Arashmid Akhavain >> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp; >> dmm >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >> >> > Dino brought up a good point. Here is my two cents worth: >> >> Not sure which point. >> >> > As it was explained by Sridhar, each UE can have multiple contexts. For >> example, today some operators provide Data and VoLTE service to their >> customers. These two services are represented by separate GTP tunnels in >> the core with each tunnel tied up to a particular QoS. >> > >> > IPv4 didn't fit the bill when GTP work was under way as it couldn't >> > uniquely identify multiple UE >> >> There is no reason why it shouldn’t. And IPv6, for this use-case doesn’t add >> anything new other than a 28 bit traffic-class/flow-label that can provide >> more bits for “new functionality”. > > > [Arashmid] And that's what I meant. Having a flow label is handy. We can > perhaps use it to identify > different UE sessions. > Careful if you use the flow label to identify flows. It should be considered "soft identification" since it might not always be correct (it can be changed en route, isn't protected by any checksum, anyone can set it however they want, etc.). It's useful for things like ECMP that don't require 100% accuracy in identifying flow. The flow label was briefly considered for holding VNIs in network virtualization, but we talked them out of that. Tom >> >> > sessions/context/bearer. So, GTP and TEID did the job. But I agree with >> Dino that IPv6 is much more versatile and is definitely worth looking at as >> an >> alternative. >> >> That is not what I said. I said “IP could have solved this problem”. And “IP” >> means either IPv4 or IPv6, or both at the same time. > > > [Arashmid] > How would we employ IPv4 to distinguish between different UE sessions. TOS? > Or you mean using encapsulation? > >> >> > A factor worth considering though is that the use of GTP and TEID in mobile >> core allows operators to deal with QoS on their own terms. The tunnels with >> specific operator-controlled QoS are established by the control plane >> between eNB, SGW, and PGW. UEs or applications sitting in the UEs have no >> say in this. Well at least till the packet exits operator's network. >> >> The problem with one header, is that if you re-mark (known as PHB markign >> in the ole days) you lose the original value. Encapsulation is useful here >> because you can map the inner to outer and anywhere along the path you >> can PHB remark on the outer header. And then the destination can see the >> orignal source’s ToS/QoS/TC/flow-label whatever. > > > [Arashmid] Yes, I agree. The original value is lost with PHB. Encapsulation > certainly > makes things easier and the inner to outer mapping trick has been widely used > in IP and MPLS(multiple labels like service and transport) > >> >> > Using the information in UE's IP packet header can jeopardise the >> > above tight QoS control. I think going >> >> Not if you encapsulate. But note with SRv6, you can possibly retain the >> original flow-label if the SID can retain those bits before overwriting the >> destination address from the option’s value. > > [Arashmid] Agree. Encapsulation does the trick again. That's why GTP has > worked > well and served the purpos in the mobile back-haul so far. > >> >> Dino >> >> > down this path, operators need proof that they will be still in the >> > driving >> seat and QoS cannot be dictated/tampered by the UE or any application >> running in it. >> > >> > Now, here is an interesting question for the operators. Would any operator >> be interested in allowing QoS to be set by the UE or by applications running >> in the UE and charged for by the network? "Yes" could potentially imply >> impacts on the air interface, UE resource block allocation and can make >> scheduling on the RAN side much more complex. >> > >> > Arashmid >> > >> > >> >> -Original Message- >> >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci >> >> Sent: 06 September 2018 12:45 >> >> To: Tom Herbert >> >> Cc: ta-miyas...@kddi-research.jp; dmm >> >&
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Thu, Sep 6, 2018 at 4:01 PM, Dino Farinacci wrote: > I’d ask the question another way: > > Would users like to set QoS bits that may charge them more for service? Could > they set bits to get cheaper service? > Hey, if I could set some bits and save a few bucks (legally) on my mobile phone bill each month that'd be great! How do I do that? ;-) In lieu of those magic bits, what I'd settle for now as as a user is better, more transparent accounting and pay-per-use for service. I don't have a problem paying more to get better Internet service **if** it's clear I'm getting money's worth. For instance, for the past few months my home Internet provider is currently charging me for going over my data limits each month, but they can't give me any detailed break down of my Internet usage. They can't even tell me _how_ they're doing accounting since they've outsourced it to a third party company. Very irritating! And then, of course, there's the story of firefighters fighting wild fires in California and having their data rate throttled to 1/100th of the nominal rate even though they were on the "unlimited" data plan. Not just irritating, but this put lives at risk! Such problems can be fix with precise accounting and transparency on services and service plans. Tom > Let alone if the operator can deliver the service (in this > net-neutrality-less era). > > Dino > >> On Sep 6, 2018, at 3:15 PM, Tom Herbert wrote: >> >> On Thu, Sep 6, 2018 at 2:49 PM, Arashmid Akhavain >> wrote: >>> Dino brought up a good point. Here is my two cents worth: >>> >>> As it was explained by Sridhar, each UE can have multiple contexts. For >>> example, today some operators provide Data and VoLTE service to their >>> customers. These two services are represented by separate GTP tunnels in >>> the core with each tunnel tied up to a particular QoS. >>> >>> IPv4 didn't fit the bill when GTP work was under way as it couldn't >>> uniquely identify multiple UE sessions/context/bearer. So, GTP and TEID did >>> the job. But I agree with Dino that IPv6 is much more versatile and is >>> definitely worth looking at as an alternative. >>> >>> A factor worth considering though is that the use of GTP and TEID in mobile >>> core allows operators to deal with QoS on their own terms. The tunnels with >>> specific operator-controlled QoS are established by the control plane >>> between eNB, SGW, and PGW. UEs or applications sitting in the UEs have no >>> say in this. Well at least till the packet exits operator's network. >>> >>> Using the information in UE's IP packet header can jeopardise the above >>> tight QoS control. I think going down this path, operators need proof that >>> they will be still in the driving seat and QoS cannot be dictated/tampered >>> by the UE or any application running in it. >>> >>> Now, here is an interesting question for the operators. Would any operator >>> be interested in allowing QoS to be set by the UE or by applications >>> running in the UE and charged for by the network? "Yes" could potentially >>> imply impacts on the air interface, UE resource block allocation and can >>> make scheduling on the RAN side much more complex. >>> >> >> Hi Arashmid, >> >> I might pose the question a bit differently: Do operators want to >> offer a rich set of services, e.g. QoS, and allow applications request >> what services they want applied for their packets? I believe the >> answer to that should be "yes" since it allows operators the chance >> offer and monetize services that can benefit users. That is the easier >> question to ask. The harder one is _how_ to do this in a secure, >> generic, net neutrality compliant, practical, and fair manner that >> doesn't require users to divulge the details of their content to the >> provider or the whole Internet. Firewall and Service Tickets is being >> proposed as one such mechanism to solve this (see >> https://tools.ietf.org/html/draft-herbert-fast). >> >> Tom >> >>> Arashmid >>> >>> >>>> -Original Message- >>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci >>>> Sent: 06 September 2018 12:45 >>>> To: Tom Herbert >>>> Cc: ta-miyas...@kddi-research.jp; dmm >>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >>>> >>>>> Behcet, >>>>> >>>>&
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Thu, Sep 6, 2018 at 2:49 PM, Arashmid Akhavain wrote: > Dino brought up a good point. Here is my two cents worth: > > As it was explained by Sridhar, each UE can have multiple contexts. For > example, today some operators provide Data and VoLTE service to their > customers. These two services are represented by separate GTP tunnels in the > core with each tunnel tied up to a particular QoS. > > IPv4 didn't fit the bill when GTP work was under way as it couldn't uniquely > identify multiple UE sessions/context/bearer. So, GTP and TEID did the job. > But I agree with Dino that IPv6 is much more versatile and is definitely > worth looking at as an alternative. > > A factor worth considering though is that the use of GTP and TEID in mobile > core allows operators to deal with QoS on their own terms. The tunnels with > specific operator-controlled QoS are established by the control plane between > eNB, SGW, and PGW. UEs or applications sitting in the UEs have no say in > this. Well at least till the packet exits operator's network. > > Using the information in UE's IP packet header can jeopardise the above tight > QoS control. I think going down this path, operators need proof that they > will be still in the driving seat and QoS cannot be dictated/tampered by the > UE or any application running in it. > > Now, here is an interesting question for the operators. Would any operator be > interested in allowing QoS to be set by the UE or by applications running in > the UE and charged for by the network? "Yes" could potentially imply impacts > on the air interface, UE resource block allocation and can make scheduling on > the RAN side much more complex. > Hi Arashmid, I might pose the question a bit differently: Do operators want to offer a rich set of services, e.g. QoS, and allow applications request what services they want applied for their packets? I believe the answer to that should be "yes" since it allows operators the chance offer and monetize services that can benefit users. That is the easier question to ask. The harder one is _how_ to do this in a secure, generic, net neutrality compliant, practical, and fair manner that doesn't require users to divulge the details of their content to the provider or the whole Internet. Firewall and Service Tickets is being proposed as one such mechanism to solve this (see https://tools.ietf.org/html/draft-herbert-fast). Tom > Arashmid > > >> -----Original Message- >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci >> Sent: 06 September 2018 12:45 >> To: Tom Herbert >> Cc: ta-miyas...@kddi-research.jp; dmm >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >> >> > Behcet, >> > >> > I was thinking if TEID is need then that can be encoded in a locator >> > easily enough. >> > >> > Tom >> >> Not if a locator is a PGW that is shared by many UEs. >> >> 3GPP wants per bearer awareness so they need a specific ID, that could have >> been the UE’s IP address. And with IPv6 it can be unique and not the issue >> that Sridhar brought up. >> >> If ILA was in use, just use the ILA-ID for this purpose. >> >> Dino >> >> ___ >> 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] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Thu, Sep 6, 2018 at 9:39 AM, Marco Liebsch wrote: > Tom, Behcet, I think TEID may still be needed in some cases, e.g. for mapping > to a radio bearer > or to avoid superfluous packet classification if it has been done on the > packet's path beforehand > already. > > IMO, for non-encapsulation protocols, overloading of id-loc space seems > interesting if the attribute > cannot be carried in extensions. What about encoding QoS class/flow IDs in > that space as well ;-) ? > Marco, Yes, there is a lot of opportunity to encode different things in addresses. The giantic address space of IPv6 almost begs us to do that! :-) The amount of data is limited, so it's unlikely that we can encapsulate all of the GTP-U extension headers. But with some careful planning, we could probably encode the critical information that is most common for fast data path. Address encoding is critical to ILA and is what can eliminate the overhead of encapsulation for a fast, low latency, data path. Tom > marco > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: Donnerstag, 6. September 2018 18:22 > To: Behcet Sarikaya > Cc: ta-miyas...@kddi-research.jp; dmm > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > > On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya > wrote: >> >> >> On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert wrote: >>> >>> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran >>> wrote: >>> > My comments inline marked [SB] >>> > >>> >> > >>> It was never clear to me and no one could ever explain exactly >>> >> > >>> why a >>> >> > >>> TEID is needed. I presumed for accounting reasons. But if there >>> >> > >>> was a >>> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the >>> >> > >>> inner addresses >>> >> > >>> be used for accounting? >>> >> > >>> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a >>> >> > tunnel and hence consequently a bearer. Once the bearer context is >>> >> > identified the QoS and charging policy applicable to the bearer is >>> >> > applied. >>> >> > So the purpose of TEID is not just for accounting. Its for QoS >>> >> > treatment, >>> >> > charging and bearer context identification. >>> >> >>> >> You told me what a TEID is but you didn’t say why you need to use it >>> >> versus using the destination IP address for the tunnel. >>> >> >>> >> >>> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU >>> >> > session whereas the QFI carried in GTPU extension header identifies >>> >> > the >>> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging. >>> >> >>> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses, >>> >> which >>> >> tells us (1) the UE, (2) the destination it is talking to, (3) the >>> >> encapsualting node, and (4) the decapsulating node. >>> >> >>> >> So again, why use more space in the packet, when you have sufficient >>> >> information to identify a user, and therefore their packet policy? >>> >> >>> > [SB] Lets say we only use UE IP address and no TEID. How will you >>> > identify >>> > the bearer context the packet belongs? One UE may use multiple radio >>> > bearers >>> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these >>> > are >>> > IP level markings which could be changed by any on path routers. In >>> > order to >>> > uniquely identify the bearer / qos flow a particular packet for a UE >>> > belongs, GTPU uses TEID. >>> >>> Sridhar, >>> >>> Couldn't the TEID be encoded in the outer IP address of an >>> encpasulation or network overlay in a similar way that VNIs are >>> encoded in IP addresses in virtual networking? >>> >>> Tom >>> >> >> ILA if used would remove any need for tunneling and TEID is for tunneling. >> > Behcet, > > I was thinking if TEID is need then that can be encoded in a locator > easily enough. > > Tom > >> Actually if you read 29.244 it is completely bas
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya wrote: > > > On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert wrote: >> >> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran >> wrote: >> > My comments inline marked [SB] >> > >> >> > >>> It was never clear to me and no one could ever explain exactly >> >> > >>> why a >> >> > >>> TEID is needed. I presumed for accounting reasons. But if there >> >> > >>> was a >> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the >> >> > >>> inner addresses >> >> > >>> be used for accounting? >> >> > >> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a >> >> > tunnel and hence consequently a bearer. Once the bearer context is >> >> > identified the QoS and charging policy applicable to the bearer is >> >> > applied. >> >> > So the purpose of TEID is not just for accounting. Its for QoS >> >> > treatment, >> >> > charging and bearer context identification. >> >> >> >> You told me what a TEID is but you didn’t say why you need to use it >> >> versus using the destination IP address for the tunnel. >> >> >> >> >> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU >> >> > session whereas the QFI carried in GTPU extension header identifies >> >> > the >> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging. >> >> >> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses, >> >> which >> >> tells us (1) the UE, (2) the destination it is talking to, (3) the >> >> encapsualting node, and (4) the decapsulating node. >> >> >> >> So again, why use more space in the packet, when you have sufficient >> >> information to identify a user, and therefore their packet policy? >> >> >> > [SB] Lets say we only use UE IP address and no TEID. How will you >> > identify >> > the bearer context the packet belongs? One UE may use multiple radio >> > bearers >> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these >> > are >> > IP level markings which could be changed by any on path routers. In >> > order to >> > uniquely identify the bearer / qos flow a particular packet for a UE >> > belongs, GTPU uses TEID. >> >> Sridhar, >> >> Couldn't the TEID be encoded in the outer IP address of an >> encpasulation or network overlay in a similar way that VNIs are >> encoded in IP addresses in virtual networking? >> >> Tom >> > > ILA if used would remove any need for tunneling and TEID is for tunneling. > Behcet, I was thinking if TEID is need then that can be encoded in a locator easily enough. Tom > Actually if you read 29.244 it is completely based on legacy protocols with > no IdLoc content at all, as Shunsuke mentioned. > > Behcet >> >> > >> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF >> > are >> > not always unique. The same IP pools can be shared across multiple PDNs >> > / >> > DNs as long as these PDNs / DNs are separate autonomous networks. So >> > just >> > relying on UE IP address alone will result in wrong context >> > identification >> > for the uplink traffic. There is a clear one to one mapping of Radio >> > bearer >> > to the EPS bearer / QoS flow required all the way upto the anchor node >> > for >> > charging and QoS treatment. This comes from the requirements in stage 2 >> > documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for >> > 5G). >> > >> > There are also requirements to support non-IP protocols like Ethernet >> > PDU >> > and Unstructured PDU types in 5G. >> > >> >> >> >> >> > >>> How can packets be sent if the session is not setup. If the >> >> > >>> session >> >> > >>> is not setup, the encapsulator should have no state. And packets >> >> > >>> should be >> >> > >>> dropped locally and not go far to get an error back. This sounds >> >> > >>> architecturally broken. >> >> > >> >> > [Sridhar] The purpose of GTP-U error ind
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran wrote: > My comments inline marked [SB] > >> > >>> It was never clear to me and no one could ever explain exactly why a >> > >>> TEID is needed. I presumed for accounting reasons. But if there was a >> > >>> one-to-one mapping between tunnel and user, why couldn’t the inner >> > >>> addresses >> > >>> be used for accounting? >> > >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a >> > tunnel and hence consequently a bearer. Once the bearer context is >> > identified the QoS and charging policy applicable to the bearer is applied. >> > So the purpose of TEID is not just for accounting. Its for QoS treatment, >> > charging and bearer context identification. >> >> You told me what a TEID is but you didn’t say why you need to use it >> versus using the destination IP address for the tunnel. >> >> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU >> > session whereas the QFI carried in GTPU extension header identifies the >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging. >> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses, which >> tells us (1) the UE, (2) the destination it is talking to, (3) the >> encapsualting node, and (4) the decapsulating node. >> >> So again, why use more space in the packet, when you have sufficient >> information to identify a user, and therefore their packet policy? >> > [SB] Lets say we only use UE IP address and no TEID. How will you identify > the bearer context the packet belongs? One UE may use multiple radio bearers > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are > IP level markings which could be changed by any on path routers. In order to > uniquely identify the bearer / qos flow a particular packet for a UE > belongs, GTPU uses TEID. Sridhar, Couldn't the TEID be encoded in the outer IP address of an encpasulation or network overlay in a similar way that VNIs are encoded in IP addresses in virtual networking? Tom > > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are > not always unique. The same IP pools can be shared across multiple PDNs / > DNs as long as these PDNs / DNs are separate autonomous networks. So just > relying on UE IP address alone will result in wrong context identification > for the uplink traffic. There is a clear one to one mapping of Radio bearer > to the EPS bearer / QoS flow required all the way upto the anchor node for > charging and QoS treatment. This comes from the requirements in stage 2 > documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for > 5G). > > There are also requirements to support non-IP protocols like Ethernet PDU > and Unstructured PDU types in 5G. > >> >> >> > >>> How can packets be sent if the session is not setup. If the session >> > >>> is not setup, the encapsulator should have no state. And packets >> > >>> should be >> > >>> dropped locally and not go far to get an error back. This sounds >> > >>> architecturally broken. >> > >> > [Sridhar] The purpose of GTP-U error indication is to signal in band to >> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is >> > lost >> > for any reason. "No session exist" does not mean Session >> >> What does lost mean? You mean the path from encapsulator to decapsulator >> is not working? And since we are in a packet network, that path can be >> restored quite quickly. > > > [SB] Lost here means - the "context" at the receiving entity is deleted. For > e.g due to administrative reasons, gNB or eNB removes the radio bearers and > correspondingly the GTPU context. If gNB or eNB loses a context for known > reasons, there could be signaling from gNB / eNB to AMF/MME and > corresponding removal of PDU session / EPS bearer at the core network. But > if the context is removed due to administrative reasons or unforeseen local > errors, signaling from gNB / eNB to AMF / MME may not happen. Hence the GTPU > error indication is an inband error detection mechanism. > > Note TEID identifies a context at the receiving side. So all GTPU error > indication tells is that the receiver is not able to identify any context > for the received TEID. > >> >> > is not setup. "No session exist" scenario after a session setup can >> > happen due to local error conditions, bearers released for administrative >> > reasons etc. >> >> So at the encapsulator, do you choose another decapsultor? Note that >> tunnels *usually* stay up since the topology that realizes the tunnel is >> robust and redundant. >> >> >> >> > >>> You should explain in summary form the model the control-plane uses. >> > >>> Does it use TCP for reliability, does it use multicast, is it like a >> > >>> routing >> > >>> protocol, is it like a management protocol. What are the failure >> > >>> modes, the >> > >>> state/bandwidth tradeoffs. >> > >> > [Sridhar] Explaining all these in IETF draft is simply reproducing
Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt
Hi Shunsuke, Thanks for the draft! It does a very good job of describing and framing GTP-U using IETF terminology. This should help significantly to bridge that gap of understanding between IETF and 3GPP. Some comments: General comment: Please look at "Encapsulation Considerations" (https://tools.ietf.org/html/draft-ietf-rtgwg-dt-encap-02). There's a lot of material there that might be relevant to encapsulation aspects of GTP-U. General comment: There are a number of recommendations that could be extracted and made to improve GTP (in section 3 in particular). Does it make sense to these in their own document as a recommendation to 3GPP for a future update of GTP? Section 1: "Another aspects of user plane requirements couldn't be found." - I'm not sure what this means Section 3: "Allocation of UDP source port depends on sender tunnel endpoint node and GTP-U supports dynamic allocation of UDP source port for load balancing objective." - How is this done in practice. In most UDP encapsulation protocols the UDP source is set to value from the hash over a tuple of the encapsulated packet. This way, the outer packet can ECMP router each encapsulated flow for load balancing. If this were done in GTP-U this would probably mean that the source port is not consistent for all packets sent on a tunnel. Would this be consistent with 3GPP specifications? "GTP-U does not support IPv6 flow label for load balancing in case of IPv6 transport." - does the spec say anything about flow label, does it need to be set to zero otherwise? This should be an easy fix since setting flow label isn't a wire protocol change and setting flow label has already commonly implemented in other encapsulations. "UDP zero checksum is not available in case of IPv6 transport." - Setting a UDPv6 zero checksum is a little tricky. RFC6935 and RFC6936 need to be considered, but also the specifics and conditions of the protocol an conditions of deployment. For instance, RFC8086 goes into inordinate detail on requirements to set a zero UDPv6 checksum. "GTP-U does not support to response ICMP PTB for Path MTU Discovery." - I'm not sure what this means. Is this saying that if a GTP-U endpoint receives an ICMP PTB error for a packet sent over tunnel, it doesn't handle that; or is this saying that if a packet from a UE is dropped at a GTP tunnel ingress point because of MTU exceeded then no ICMP PTB is sent? If it's the first case, then that's not much a problem. I doubt PMTU discovery has been implemented for many tunnels. Usually one of the suggestions in RFC4459 is used (that RFC should be referenced in the draft). If it's the second case, then that is more of a bug in the protocol that should be fixed (this is IP layer requirements, should not be specific to GTP-U). "Following list summarizes every extension header which is used for user plane protocol." - Used or defined? It would be good to know which, if any extension headers are commonly used in the data path. This will also be input to the issued raised later on about the efficiency of extension header processing. "DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel endpoint node based on the QFI." - This should be rectified with RFC2983. "In general, multiple GTP-U extension headers are able to contained in one GTP-U packet and the order of those extension headers is not specified by [TS.29.281-3GPP]." - That is the combinatoric nature of TLVs. There has been much discussion on that. A potentially related question would be does GTP-U limit the number or size of extension headers (unlimited TLVs in a packet could be used as a potential denial of service attack. "GTP-U does not support to indicate next protocol type." - A bit unfortunate, IMO an encapsulation should also have a type field. Conceptually, there is a way around this by defining the the first nibble after GTP-U headers to be a type field (similar to GUEv1). 0x4 and 0x6 are IPv4 and IPv6, which is convenient since this coincides with the version number of an overlaid encapsulated IP packet. Other values could be used for different types. "GTP-U supports active OAM as a path management message "Echo Request/Response"" - Does GTP-U support in-situ OAM? Header format "DSCP=0" in inner packet. Is this a requirement? There should be some discussion about how ECN is handled. RFC6040 should probably be referenced. Section 4: "Then, the content information of the PDU may be mapped into UDP port number" - I don't follow this. Does this mean that different destination port numbers are used to determine the protocol of the T-PDU? "For this, the expected evaluation points from this aspect should be whether there is substitutional means to cover other PDU session types. And how much it makes simple the system than deploying original PDU session types." - Is this another way of saying the encapsulation protocols should have type field? :-) "However it increases header size from 20bytes to 40bytes compare to IPv4."
Re: [DMM] Comment on SRv6-mobile-userplane
> PC2: Let me try to give you an analogy. A external packet arrives to an ILA > network. The original IPv6 DA is translated as per ILA. What is the packet? > Is it an IP packet or is it an ILA packet? To me this is an ILA packet, > because if the source and destination UPFs are not ILA capable the overlay > does not work. > Pablo, It is an IPv6 packet that has a destination address that is interpreted with ILA semantics and the destination node. The format of the packet is IPv6, the Ethertype is 0x86dd, and the packet is compliant with the IPv6 protocol standard. Every intermediate device in the path sees a plain IPv6 packet. The property that a packet with an ILA address is indistinguishable on the wire from other IPv6 packet is critical to ILA. > PC2: For this reason, I would not call the above SRv6 example IPinIP. It > needs SRv6 on the UPFs, hence calling it IPinIP does not reflect the > requirement of running SRv6 on the destination UPF -which in my opinion is > considerable to highlight-. It's still not clear to me exactly what the wire format is of SRv6 traditional mode is. 5.5 of draft-filsfils-spring-srv6-network-programming describes the encapsulation operation as: 1. push an IPv6 header with its own SRH (S3, S2; SL=2) 2. set outer IPv6 SA = T and outer IPv6 DA = S1 3. set outer payload length, traffic class and flow label ;; Ref1 4. update the Next-Header value ;; Ref1 5. decrement inner Hop Limit or TTL ;; Ref1 6. forward along the shortest path to S1 Step #4 is ambiguous. It doesn't indicate what the Next-Header value needs to be updated to. Also, it's not really clear which Next-Header field is being updated (there could be an inner value and an outer value). I infer that it is the Next-Header value in the outer IPv6 header and that it is set to either 0x04 or 0x29 if the inner packet is IPv4 or IPv6 respectively. Assuming that all other fields are set normally for IPv6, then the derived packet has the format of a simple IP-in-IPv6 encapsulation and that's that how it will be seen on the wire by intermediate nodes (which similar to case of ILA I think is a good property to have). Is my inference correct? Tom > > > > Tom > > > > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comment on SRv6-mobile-userplane
On Wed, Jul 18, 2018 at 1:44 PM, Pablo Camarillo (pcamaril) wrote: > Uma, > > > > Inline. [PC1] > > (Thanks for the clear list of points to address. It does help.) > > > > Cheers, > > Pablo. > > > > From: Uma Chunduri > Date: Wednesday, 18 July 2018 at 12:52 > To: "Pablo Camarillo (pcamaril)" , Arashmid Akhavain > > Cc: "dmm@ietf.org" , "Alberto Rodriguez Natal (natal)" > , "spr...@ietf.org" > Subject: RE: Comment on SRv6-mobile-userplane > > > > Hi Pablo, > > > >>As I already clarified in my previous email, the proposal of >> draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network. > > Great. Thanks. > >>As I already said in my previous email, we will clarify this in the next >> revision of the draft. > > Sure. > > > > Btw, you responded to Arash’s comments addressing me. > > > > Some parts of the draft already maintained that independence with SRv6 > features in underlay (for example Section 5.3). > > In summary if you could address: > > > > 1. Section 5.1 Traditional mode (Tom’s comment on terminology and > IP-in-IP with no relation to SR?) > > > > PC1: Tom, please read > https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05#section-3 > Pablo, I'm not sure that's relevant to discussion on an encapsulation dataplane. SIDs are 128 bit values that are in the IPv6 address space, and if a SID is place in a destination IPv6 address then it must be routable to a node in the network. Wrt encapsulation, if it's any more complex than that, then I'm missing something fundamental about segment routing. > PC1: It might be IP-in-IP as long as the inner header is not Ethernet or > Unstructured PDUs (3GPP PDU types). > If it's not IP-IP, then what is it? The draft states that in traditional mode: "gNB only adds an outer IPv6 header with IPv6 DA U1::1." This implies that foo over IP can be used if there is a protocol number for it (e.g. IPv[46]/IPv6, GRE/IPv6, MPLS/IPv6, etc.). But what does this mean in the case of unstructured PDUs? How are those encapsulated? Please clarify, or provide the reference to the exact format of encapsulation protocols being used with SR. > PC1: When its IP-in-IP the destination address is an SRv6 SID and is > processed differently at the destination than an interface address. See > 4.8-4.12 of draft-filsfils-srv6-network-programming. > Okay, but I don't see how the protocol is processed changes the fact (at least that I think is a fact) that the solution is using IP-IP, or maybe foo-over-IP in some cases as above, as the encapsulation and that is the on-the-wire protocol in use. Tom > > > 2. Section 5.2 Enhanced mode. Here SR path steering features are used > > > > PC1: The enhanced mode exemplifies the case where a given provider wants to > leverage SR for the overlay (as in Traditional mode but with session > aggregation -see next note-; but also SP wants to leverage SR for underlay > control and service programming. > > PC1: In such example, the gNB can steer incoming traffic into an SR policy > that contains SID for these three things. The benefit of this use-case is > that the provider achieves end-to-end network slicing, spanning N3, N6, N9 > as well as the transport network. > > PC1: Notice that there might be different cases > > 1.- Overlay with session aggregation > > 2.- Overlay with session aggregation and underlay TE > > 3.- Overlay with session aggregation, underlay TE and service programming > > 4.- Overlay with session aggregation and service programming > > > > and not fully described what happens to TEID (as GTP is gone). > > PC1: Enhanced mode uses PDU session aggregation. There is not a single TEID > per PDU Session. Instead, several PDU Sessions are aggregated. The set of > sessions aggregated are still identified by the SID (in 5.2.1 corresponds to > SID U2::1) > > PC1: Each set of aggregated sessions uses a different SRv6 SID. > > PC1: This is the main difference in between traditional mode and enhanced > mode. > > PC1: The aggregation is similar for the other proposals discussed in > draft-bogineni-dmm-optimized-mobile-user-plane > > > > 3. And if TEID after GTP removal is encoded in each SID in the SRH or > this is only specific to some PDU session as you indicated in your first > email. > > > > PC1: In the traditional mode, the TEID for each PDU Session is encoded as an > SRv6 SID. This can be done by two means, either by directly encoding the > TEID in the SRv6 SID, or by using a unique SRv6 SID for each TEID > (one-to-one mapping in between SRv6 SID and TEID). (feedback is welcome on > preferred option) > > PC1: In the enhanced mode, several PDU sessions are aggregated. All the set > of aggregated sessions share the same SRv6 SID. A different set of > aggregated sessions uses a different SRv6 SID. > > > > Thx! > > -- > > Uma C. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comment on SRv6-mobile-userplane
On Wed, Jul 18, 2018 at 9:31 AM, Uma Chunduri wrote: > Hi Arashmid, > > > > > >>>[Uma]: 2 quick and minor corrections for the above first.“we encode the >>> TEID into a SID” è >>> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1 >>> says “Note that in this mode the TEID is embedded in each SID.” > >>>(section 5.1.3 confirms this) > > > > >[Arashmid] Embed vs Encode? Is this issue? > > > > [Uma2:]It’s not embed or encode. It says each SID. > > > > > > > >>[Arashmid] Today each PDU session gets its own set of TEIDs between eNB and >> SGW and between SGW and PGW. For example for a UE with both internet access >> and VoLTE, there are two GTP tunnels between the eNB and the SGW and two >> other GTP tunnels between the SGW and the PGW. > >>We maintain this in traditional mode. > > > > [Uma2]: I am not questioning how each bearer get a different TEID or how > separate tunnels are maintained per PDU session between eNB-SGW or SGW-PGW. > It’s good this being planned to achieve in traditional mode. However, if > this is seen as GTP replacement option, by moving TEID of the GTP header > encoded into each SRv6 SID, is the unintended consequence is we are making > 3GPP > functionalities that are associated with TEID specific to one transport > underlay. Uma, This might another case of nuanced terminology being used in the draft that obscures what is happening and make things seem more complicated than they actually are. In the case of traditional mode, there is no segment routing header in the packet and hence there are not really any SIDs. There is the destination IP address which presumably takes the role of one SID in the segment routing architecture, however to the rest of the world this is just the destination IP address. IP addresses are quite large, so it's convenient to encode things like TEIDs, VNIs in network virtualization, and other context for the overlay in IPv6 addresses. This is a benefit of IP/IP encpasulation (traditional SRV6 mode) over GTP since the overhead GTP and UDP headers are eliminated. ILA takes encoding information in IPv6 addresses one step further to completely eliminate the need and overhead for any encapsulation. It's true that these techniques impose some requirements on the underlay that it's IPv6 and how addresses need to be structured, but I don't see this to be significantly more constraining than using a protocol specfiic UDP encapsulation. Tom > > There are various other modes defined in the document, for example > https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.3 > (called Enhanced mode with unchanged gNB GTP behavior) > > In that case I see separation maintained and with a possibility of multiple > SRv6 features, that can be applied in underlay as needed. > > > > -- > > Uma C. > > > ___ > 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] Comment on SRv6-mobile-userplane
On Wed, Jul 18, 2018 at 8:56 AM, Uma Chunduri wrote: > Tom, > > >I think the terminology being used in the draft might be making this > seem complicated than it actually is. AFAICT, SRv6 traditional mode is > nothing more than IP in IP encapsulation, so the requirement of the underlay > is that it > >forwards IPv6 and intermediate nodes treat the traffic as > "normal IPv6 traffic". There is no segment routing involved, no extension > headers needed, and the only upgrade for the network is to support IPv6. > > I am not sure that is the case. Please re-read Section 5.1 (and 5.1.3) > " This 1-for-1 mapping is >replicated here to replace the GTP encaps with the SRv6 > encaps, while >not changing anything else." > Uma, Right, there is where the terminology of the draft is confusing. SRv6 defines a routing extension header not an encapsulation protocol. "SRv6 encaps" here means IP packets (presumably either IPv4 or IPv6) are encapsulated in IPv6 using standard IP/IP encpasulation. Concurrent with that encapsulation, a segment routing header or other extension headers may be added to the outer IP header (this is consistent with RFC8200 requirement that only source nodes can set extension headers). So there is really no such thing as SRv6 encapsulation, and in the text above replacing SRv6 with IP-in-IP would be much clearer as to how the protocol works. Tom > -- > Uma C. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comment on SRv6-mobile-userplane
On Wed, Jul 18, 2018 at 8:44 AM, Pablo Camarillo (pcamaril) wrote: > Tom, > > Isn't the IPv6 flow label designed exactly to avoid that? Yes, that is supposed to handle ECMP. There are might be other optimizations of packets for UDP and TCP that could be lost in IP/IP encapsulation. > Are you suggesting to use UDP to avoid using the flow label? > No, I would much prefer that flow label is used for ECMP and intermediate nodes stop doing DPI. Problem is that there's been resistence from some operators to enabling the flow label for ECMP since it might not be persistent for a flow, this can wreak havoc in deployments that maintain state in the network of need consistent hashing for load balancing. Discussion on this issue occasionally pops up on 6man list. Tom > Cheers, > Pablo. > > On 18/07/2018, 10:37, "Tom Herbert" wrote: > > One caveat to that is that some > intermediate nodes may want to do DPI into transport layer to get > ports for ECMP or other reasons, if that is desirable it would be easy > enough to alternatively use a UDP encapsulation-- either continue with > GTP or switch to a more generic one like GUE. > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comment on SRv6-mobile-userplane
On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain wrote: > Hi Uma, > > > > I am not sure if I understand your concern. In traditional mode, we encode > the TEID into a SID. This is the mode that draft bogineni refers to as the > simplest form of using SRv6 for the N9 interface. > > Only the head nodes know that TEID has been encoded into the SID. Tandem > nodes treat the traffic as normal SRv6 traffic. Are you saying that the use > of SRv6 in general forces the underlying say MPLS transport to convert to > SRv6? I think the terminology being used in the draft might be making this seem complicated than it actually is. AFAICT, SRv6 traditional mode is nothing more than IP in IP encapsulation, so the requirement of the underlay is that it forwards IPv6 and intermediate nodes treat the traffic as "normal IPv6 traffic". There is no segment routing involved, no extension headers needed, and the only upgrade for the network is to support IPv6. One caveat to that is that some intermediate nodes may want to do DPI into transport layer to get ports for ECMP or other reasons, if that is desirable it would be easy enough to alternatively use a UDP encapsulation-- either continue with GTP or switch to a more generic one like GUE. Tom > > > > Cheers, > > Arash > > > > From: Uma Chunduri > Sent: Tuesday, July 17, 2018 3:10 PM > To: Pablo Camarillo (pcamaril) > Cc: dmm@ietf.org; Arashmid Akhavain ; Alberto > Rodriguez Natal (natal) ; spr...@ietf.org > Subject: RE: Comment on SRv6-mobile-userplane > > > > [Added Spring too, as one of the chairs, Bruno asked us to discuss] > > > > Hi Pablo, > > > > Please see in in-line [Uma]: > > > > -- > > Uma C. > > > > From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com] > Sent: Tuesday, July 17, 2018 11:25 AM > To: Uma Chunduri > Cc: dmm@ietf.org; Arashmid Akhavain ; Alberto > Rodriguez Natal (natal) > Subject: Comment on SRv6-mobile-userplane > > > > Hi Uma, > > > > During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane > you have raised a comment saying that SRv6 mandates an integration in > between the overlay and the underlay transport network. > > > > I would like to clarify that this is NOT true. Please read > https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1 > > The Traditional mode is only offering GTP replacement for specific PDU > sessions with complete independence from the transport network. No matter > whether the transport is MPLS, IPv6 or whatever -without any SR at all-. > > > > > > [Uma]: It is positioned as one of the alternative to replace GTP-U in the > data path. > > > > From Section 5.1 > > “ In the traditional mobile network, an UE session is mapped 1-for-1 > >with a specific GTP tunnel (TEID). This 1-for-1 mapping is > >replicated here to replace the GTP encaps with the SRv6 encaps, while > >not changing anything else. > > > >This mode minimizes the changes required to the entire system and it > >is a good starting point for forming the common basis. Note that in > >this mode the TEID is embedded in each SID.” > > > > I also believe, that way because this is being sent as response to CT4 as a > replacement alternative to GTP-U with SRv6 underlay in traditional mode. > > > > https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01#section-6.1 > > > > “ In its most basic form, SRv6 can be used as a simple drop-in > >alternative for GTP tunnels. The control plane in this approach > >remains the same, and still attempts to establish GTP-U tunnels and > >communicate TEIDs between the tunnel end points. However, at the > >next level, SRv6 capable nodes use SIDs to direct user traffic > >between the UPFs.” > > > > > > If we propose this is a drop-in replacement for GTP-U – this could force > (with the approval of IETF and 3GPP) every operator to use SRv6; as TEID > functionality is basic to any 3GPP procedure (not only for Xn, N2 and > whatever mobility case out there, service request, paging and you name > it..). > > I don’t think you want to exclude SR-MPLS if operator wants (or any TE) it > or transitioning to. > > > > On the other hand if it is only for some PDU sessions then this need to be > specifically mentioned in the draft as well as the “optimized mobile user > plane” response. > > > > > > Hence, if an operator would like to have integration of the overlay and > underlay (for end-to-end network slicing), he can have such integration. If > this is not desired, the dmm-srv6-mobile-uplane proposal can work completely > independently from the transport, as already documented in the draft. > > > > [Uma]: It would be great if we strive to achieve that independence as much > as possible while focusing on the value and feature SRv6 brings it to the > table. > > > > I will check with the rest of co-authors of the draft to see whether we > should clarify in the draft the independence from the transport network. > > > > [Uma]: Sure,
Re: [DMM] [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt
On Tue, Jul 3, 2018 at 8:19 AM, Jon Crowcroft wrote: > beware of sidechannel attacks - eg. a sequence of efficient routes can > determine a sequence of locations just from latency/rtt estimation > (observe outbound data and likely return path ack packets) - you want > privacy, you're gonna pay > Yep, we also know there is a lot of effort being done to extract information from cipher text like apply machine learning to the data. As compute and data acquisition techniques advance, attacks on the Internet only get more sophisticated. Work will always be needed to mitigate new attacks and that will have cost. It's a never ending problem, but it's worth it to continually try to solve IMHO. Tom > On Tue, Jul 3, 2018 at 5:14 PM, Tom Herbert wrote: >> On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft >> wrote: >>> what we need is compact onion routing - maybe we could call it garlic >>> routing. >>> >>> in all seriousness, if people are worried about privacy with regards >>> network operators, or state actors co-ercing network operators, at >>> this level, that is what you want. otherwise forget about efficient >>> mobile routing - the fact is that the signature of the set of >>> locations you visit is enough to re-identify a node pretty quickly - >>> its been done (see wetherall's work on this a few years back on simply >>> looking at sequences of wifi AP associations, without bothing with end >>> system mac addr, to uniquely matc individual (indeed, find their home) >>> - you have to get the threat model appropriately...and proportioately >> >> Jon, >> >> The threat is not limited to coming from network operators, it is >> basically from the whole Internet. IP addresses must be sent as clear >> text, and when they encode personally identifiable information then >> that can be used by third parties to compromise privacy. In mobile >> addresses, the threat is both comprising identity and location of the >> user. Identity can be compromised when the same address (or device >> specific prefix in case of RFC4941 addresses) is reused for different >> flows, location is compromised when an address encodes a locator that >> can be used to determine specific location. There are publicized >> examples of third parties using IP addresses to expose identity and >> location (e.g. >> https://theintercept.com/2018/03/26/facebook-data-ice-immigration/). >> >> In order to provide privacy in addressing, IP addresses need to be >> purged of PII. This likely entails minimizing aggregation and a high >> frequency of address change in a host. On the surface, this does seem >> to be in conflict with "efficient mobile routing" as you mentioned, >> however I don't believe that efficient routing is an acceptable trade >> off for not providing adequate privacy to users. Alternatives that >> achieve both goals should be investigated. >> draft-herbert-ipv6-prefix-address-privacy-00 suggests "hidden >> aggregation" as one possibility. >> >> Tom >> >>> >>> On Mon, Jul 2, 2018 at 11:42 PM, Erik Nordmark wrote: >>>> >>>> This is a rough draft, but hopefully it can stimulate more discussion >>>> around >>>> privacy considerations. >>>> >>>> Forwarded Message >>>> Subject: New Version Notification for draft-nordmark-id-loc-privacy-00.txt >>>> Date: Mon, 02 Jul 2018 15:34:11 -0700 >>>> From: internet-dra...@ietf.org >>>> To: Erik Nordmark >>>> >>>> >>>> A new version of I-D, draft-nordmark-id-loc-privacy-00.txt >>>> has been successfully submitted by Erik Nordmark and posted to the >>>> IETF repository. >>>> >>>> Name: draft-nordmark-id-loc-privacy >>>> Revision: 00 >>>> Title: Privacy issues in ID/locator separation systems >>>> Document date: 2018-07-02 >>>> Group: Individual Submission >>>> Pages: 6 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-nordmark-id-loc-privacy-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-nordmark-id-loc-privacy/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-nordmark-id-loc-privacy-00 >>>> Htmlized: >>>> https://datatracker.ietf.org/doc/html/draft-nordmark-id-loc-privacy >>>> >>>> >>>> Abstract: >>>>There exists several protocols and proposals for identifi
Re: [DMM] [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt
On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft wrote: > what we need is compact onion routing - maybe we could call it garlic routing. > > in all seriousness, if people are worried about privacy with regards > network operators, or state actors co-ercing network operators, at > this level, that is what you want. otherwise forget about efficient > mobile routing - the fact is that the signature of the set of > locations you visit is enough to re-identify a node pretty quickly - > its been done (see wetherall's work on this a few years back on simply > looking at sequences of wifi AP associations, without bothing with end > system mac addr, to uniquely matc individual (indeed, find their home) > - you have to get the threat model appropriately...and proportioately Jon, The threat is not limited to coming from network operators, it is basically from the whole Internet. IP addresses must be sent as clear text, and when they encode personally identifiable information then that can be used by third parties to compromise privacy. In mobile addresses, the threat is both comprising identity and location of the user. Identity can be compromised when the same address (or device specific prefix in case of RFC4941 addresses) is reused for different flows, location is compromised when an address encodes a locator that can be used to determine specific location. There are publicized examples of third parties using IP addresses to expose identity and location (e.g. https://theintercept.com/2018/03/26/facebook-data-ice-immigration/). In order to provide privacy in addressing, IP addresses need to be purged of PII. This likely entails minimizing aggregation and a high frequency of address change in a host. On the surface, this does seem to be in conflict with "efficient mobile routing" as you mentioned, however I don't believe that efficient routing is an acceptable trade off for not providing adequate privacy to users. Alternatives that achieve both goals should be investigated. draft-herbert-ipv6-prefix-address-privacy-00 suggests "hidden aggregation" as one possibility. Tom > > On Mon, Jul 2, 2018 at 11:42 PM, Erik Nordmark wrote: >> >> This is a rough draft, but hopefully it can stimulate more discussion around >> privacy considerations. >> >> Forwarded Message >> Subject: New Version Notification for draft-nordmark-id-loc-privacy-00.txt >> Date: Mon, 02 Jul 2018 15:34:11 -0700 >> From: internet-dra...@ietf.org >> To: Erik Nordmark >> >> >> A new version of I-D, draft-nordmark-id-loc-privacy-00.txt >> has been successfully submitted by Erik Nordmark and posted to the >> IETF repository. >> >> Name: draft-nordmark-id-loc-privacy >> Revision: 00 >> Title: Privacy issues in ID/locator separation systems >> Document date: 2018-07-02 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf.org/internet-drafts/draft-nordmark-id-loc-privacy-00.txt >> Status: https://datatracker.ietf.org/doc/draft-nordmark-id-loc-privacy/ >> Htmlized: https://tools.ietf.org/html/draft-nordmark-id-loc-privacy-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-nordmark-id-loc-privacy >> >> >> Abstract: >>There exists several protocols and proposals for identifier/locator >>split which have some form of control plane by which participating >>nodes can use to share their current id to locator information with >>their peers. This document explores some of the privacy >>considerations for such a system. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> ___ >> 5gangip mailing list >> 5gan...@ietf.org >> https://www.ietf.org/mailman/listinfo/5gangip > > ___ > 5gangip mailing list > 5gan...@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] Fwd: New Version Notification for draft-herbert-idloc-fast-00.txt
Hello, This draft is an alternative proposal for to optimize anchorless mobility in identifier-locator protocols. Similar to the hICN proposal, this espouses the idea of carrying path information in data packets instead of relying on mapping databases or mapping caches in the datapath. Data packets carry a locator in FAST tickets (IPv6 options) to use in the return path to the mobile device. This requires some end host implementation (FAST), however it eliminates the need to do a mapping database lookup or mapping cache lookup in the datapath. Also, this protocol independent of the transport layer so it works with any transport protocol and doesn't require any transport state to be maintained in the network. Tom -- Forwarded message -- From: Date: Tue, Jun 26, 2018 at 10:04 AM Subject: New Version Notification for draft-herbert-idloc-fast-00.txt To: Tom Herbert A new version of I-D, draft-herbert-idloc-fast-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-idloc-fast Revision: 00 Title: Lightweight Identifier-Locator Mapping Using FAST Document date: 2018-06-26 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-herbert-idloc-fast-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-idloc-fast/ Htmlized: https://tools.ietf.org/html/draft-herbert-idloc-fast-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-idloc-fast Abstract: This proposal provides a method to implement identifier to locator mapping in the datapath without the need to access an in-network mapping database or cache. Mappings are encoded in Firewall and Service Tickets (FAST) tickets as locator information. When a packet is sent by a mobile node, a ticket is attached that providers the locator to use in the return path. Peer nodes receive packets with these tickets, cache the tickets in a flow context, and then attach them to packets they send as reflected tickets. When a packet with a reflected ticket enters an identifier-locator domain, the ticket is parsed to extract the locator. That locator is then used to send the packet to the appropriate destination over a network overlay. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Thu, Jun 21, 2018 at 3:29 AM, Luca Muscariello wrote: > There are several points raised here: > 1) Alleged protocol layering violations and the e2e principle. > 2) Relationship between the OS and transport services. > > > 1) Many see the e2e principle as another instance of Occam's razor applied > to communication > protocols function placement, I think it is even written in the first paper > that talks about it (Reed, Clark...). > It's all about design patters for the development of distributed > applications. > Placement of function vertically in a layered architecture and horizontally > in the network path between end-points. > > In this respect, hICN, but I should say CCN and NDN realise that principle > with a new way to look at networking. > Essentially naming data sources with location-independent identifiers. LISP, ILA, SRv6, and ILNP also do this. It's a core concept in identifier locator separation protocols. ILNP requires changes to the transport layer and endhosts to work, however ILA, SRv6, and LISP don't-- these protocols operate strictly at the network layer as does GTP. All of these have the goal to provide anchorless communication (that could also be done in GTP as well given right changes to the control plane). ILA and ILNP have they advantage that they don't have any incur additional packet overhead, although I believe that ILNP does use some extension headers which might be a convolution to use over the Internet. Tom > I am far from going to claim credits to the design principles behind CCN/NDN > as it is Van Jacobson and team > who fundamentally designed that system. hICN is a convenient implementation > of CCN into IPv6 to make that > design available in IPv6 now. > > Other attempts have introduced networking of location-independent > identifiers in the Internet and the most notable > one is LISP even if it is still the host to be identified. > I would avoid to quote in full Brian Carpenter about this topic so I just > report a reference. It's all in there. > > Brian E. Carpenter. 2014. IP addresses considered harmful. SIGCOMM Comput. > Commun. Rev. 44, 2 (April 2014), 65-69. DOI: > http://dx.doi.org/10.1145/2602204.2602215 > > If we look at LISP for instance, the placement of protocol functions > requires to have a mapping system. > It is not exactly an instance of the Occam's razor though. But it is > probably the best solution to a very > specific problem formulation. > > The fact that the network has to support all transport protocols is clearly > false. The Internet is also IP multicast, > among other things, > and the transport protocols being cited (TCP/LEDBAT/QUIC etc) not only will > never work over IP multicast but > have never been meant to at design time. > > hICN mobility for the 5G service based architecture is supposed to run in a > slice for the development of advanced > applications (IoT, AR/VR, MEC etc) but also to rethink current applications > with these new transport services. > This means that alternative solutions for mobility management in 5G, such as > GTP, LISP or derivations of it, are > required to exist. > In the current 5G standardisation effort there might be several mobility > models co-existing and slicing has been > designed in order to enable that. > > 2) This should probably be a whole new email thread and also other mailing > lists might be a better forum. > > It is true that applications make use of a communication API provided by the > OS. But that's quite generic. > Those functions can be place in different parts of the OS. > Our choice is to move communication functions, essentially the entire stack, > out of the kernel > and use a server stack based on VPP https://git.fd.io and install network > functions just like any application in an application store. > The client stack would also de deployed as a portable app. iOS 12 is the > first mobile OS to adopt this kind of philosophy and we continue to adopt > that approach for the time being. > > The fact that MPTCP encounters difficulties to be fully integrated in a > specific OS component is an implementation issue > that belongs to that particular component. The consequence of that might be > that multiple culturally different implementations > and deployment options of network functions should exist in the future. Not > less. > > > > On Wed, Jun 20, 2018 at 7:18 PM Tom Herbert wrote: >> >> On Wed, Jun 20, 2018 at 9:06 AM, Luca Muscariello >> wrote: >> > The adjective minor is used in a comparative way. At least I intended >> > that >> > way. >> > hICN allows to implement ICN features with less changes than using ICN >> > as an >>
Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
ket. > The video player can sequentially switch protocol to retrieve the segment. > Not that it make any sense but it's just > to explain that they live in the same end-host. If the app considers that > one transport service can provide > features that are advantageous it can optionally switch to it. > There is no intent to replace TCP, UDP, LEDBAT, QUIC, SCTP or any other > transport protocol with the consumer/producer > sockets. Okay, but these protocols still need to work in mobile networks, which means in hICN enabled network you still need a mobile infrastructure to handle these "legacy" protocols. That means there are two distinct mobility models needed-- hICN is not simplifying matters in this regard. To me, the hICN story would be a lot more compelling if the transport and network layer are decoupled so there was one solution that provided seamless mobility for everyone in the network regardless of type of transport protocol they use or application that they wish to run. Beyond that, there might be opportunities to improve communications by some coordinated interaction with the network (like we propose in FAST), but these are strictly optimization and not requirements to make basic communications work. Tom > > Luca > > > > On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert wrote: >> >> On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello >> wrote: >> > More on the mobility use case which also makes deployment options easier >> > to >> > digest >> > >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ >> > >> >> From the draft: >> >> "The goal of hICN is to ease ICN insertion in existing IP infrastructure >> by: >> ... >> 3. minor modification to existing IP routers/endpoints;" >> >> Can you elaborate on this "minor modification"? Especially for >> endpoints, which I assume means hosts, what is the scope, the >> necessary modifications, and deployment model. Also, will applications >> have to change or use a new API for hICN? >> >> If the implication of hICN is that all Internet hosts need to change >> to support a new consumer/producer communications model, a new >> transport protocol, and a new application API-- there's nothing minor >> about that! >> >> Tom >> >> > >> > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) >> > wrote: >> >> >> >> This draft is about hICN and discusses various deployment options with >> >> associated pros and cons, without supporting one specifically. Clearly, >> >> depending on application requirements, on network constraints, on >> >> phase of >> >> deployment/transition etc. one option may be preferrable over another >> >> one >> >> (and different ones may coexist). >> >> >> >> >> >> One of the described deployment options also discusses combination of >> >> hICN >> >> and SRv6, without opposing one approach to the other, rather exploiting >> >> in >> >> the combination the advantages of both ones. >> >> >> >> >> >> Giovanna >> >> >> >> >> >> From: Int-area on behalf of Behcet Sarikaya >> >> >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> >> To: Luca Muscariello >> >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> >> management through hICN (hICN-AMM): Deployment options >> >> >> >> >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello >> >> wrote: >> >>> >> >>> I wonder whether this conversation should happen in the intarea wg >> >>> mailing list >> >>> as the main draft was posted there in the first place. I don't know if >> >>> cross posting is welcome >> >>> but I take the risk. >> >>> >> >>> Going back to the question, the transport changes are related to the >> >>> request/reply semantic >> >>> of the architecture. The two distinct forwarding paths described in >> >>> the >> >>> draft take care >> >>> of forwarding requests or replies.This ends up in the transport layer >> >>> as >> >>> a unidirectional >> >>> channel to recv data or snd data. The replies carry data originating >>
Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Wed, Jun 20, 2018 at 7:48 AM, Luca Muscariello wrote: > More on the mobility use case which also makes deployment options easier to > digest > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility/ > >From the draft: "The goal of hICN is to ease ICN insertion in existing IP infrastructure by: 3. minor modification to existing IP routers/endpoints;" Can you elaborate on this "minor modification"? Especially for endpoints, which I assume means hosts, what is the scope, the necessary modifications, and deployment model. Also, will applications have to change or use a new API for hICN? If the implication of hICN is that all Internet hosts need to change to support a new consumer/producer communications model, a new transport protocol, and a new application API-- there's nothing minor about that! Tom > > On Wed, Jun 20, 2018 at 4:33 PM Giovanna Carofiglio (gcarofig) > wrote: >> >> This draft is about hICN and discusses various deployment options with >> associated pros and cons, without supporting one specifically. Clearly, >> depending on application requirements, on network constraints, on phase of >> deployment/transition etc. one option may be preferrable over another one >> (and different ones may coexist). >> >> >> One of the described deployment options also discusses combination of hICN >> and SRv6, without opposing one approach to the other, rather exploiting in >> the combination the advantages of both ones. >> >> >> Giovanna >> >> >> From: Int-area on behalf of Behcet Sarikaya >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> To: Luca Muscariello >> Cc: Internet Area; Luca Muscariello (lumuscar); Tom Herbert; dmm >> Subject: Re: [Int-area] [DMM] New draft posted: Anchorless mobility >> management through hICN (hICN-AMM): Deployment options >> >> >> >> On Tue, Jun 19, 2018 at 6:21 PM, Luca Muscariello >> wrote: >>> >>> I wonder whether this conversation should happen in the intarea wg >>> mailing list >>> as the main draft was posted there in the first place. I don't know if >>> cross posting is welcome >>> but I take the risk. >>> >>> Going back to the question, the transport changes are related to the >>> request/reply semantic >>> of the architecture. The two distinct forwarding paths described in the >>> draft take care >>> of forwarding requests or replies.This ends up in the transport layer as >>> a unidirectional >>> channel to recv data or snd data. The replies carry data originating from >>> a transport end-point (snd buffer) >>> that binds to an identifier which is location independent, an IPv6 number >>> which is not a locator. >>> >>> The forwarding path of the requests is very close to unmodified IPv6 with >>> the DST address carrying the identifier. >>> If you check in the draft an hICN node does one additional lookup in a >>> local cache though. But you can ignore that >>> for now for sake of clarity. What is important is the address rewrite >>> operation made on the SRC address >>> of the request. A copy of the request is stored in the local cache and >>> the locator of the output interface is written in the >>> SRC address before transmission. This is used by an upstream hICN or the >>> final end-point to know the locator that >>> will be used to reply. >>> >>> Replies coming from the snd end-point are label swapped but not like >>> MPLS. >>> The label is the identifier itself that is stored in the SRC address of >>> the reply, >>> whereas the DST address is a locator. In this forwarding path a lookup is >>> made in the local cache to >>> find a request (one or many) and the associated locator (one or many) >>> that matches the identifier. >>> The DST addr field of the replies is rewritten with the locator(s) just >>> obtained from the lookup. >>> This is how the reply is forwarded to the end-points that issued requests >>> for this identifier. >>> >>> For the replies there is no FIB lookup on the identifier (as it is in the >>> SRC addr field). >>> There can be a lookup in the FIB on the locator stored in the DST of the >>> reply to >>> reach back the previous hICN node or eventually the original end-point. >>> >>> >>> >> >> >> Hi, >> >> My humble question is: are you supporting SRv6 or hICN? >> >> Regar
Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Tue, Jun 19, 2018 at 1:50 PM, Luca Muscariello wrote: > The paragraph you reported is from the draft that describes hICN to enable > several use cases. > Mobility is one of those, not the only one. > To clarify, the draft on hICN mobility deployment options focuses on the 5G > service based architecture. > > You may be asking > 1) is it possible to get all the features provided by hICN w/o updates to > the transport layer? > 2) is changing the transport protocol unnecessary difficult to enable all > the use cases mentioned in the draft? > Sorry, but I'm still missing something fundamental here. AFAICT, the idea of hICN is to put routes in the local routing table and use existing forwarding and routing to forward packets to mobile nodes. So if a node changes location, then the routing tables need to be updated. Effectively this is a bunch of host routes that need to be maintained. At least this is what I gather from the draft: "hICN network layer is about using the IPv6 FIB to determine a next hop router to forward requests or using a local packet cache to determine if an incoming request can be satisfied locally." Is this correct? If it is, then I sort of understand how hICN could be used for mobility or virtualization without network overlays, but then I'm completely lost as to why this would require any changes in the transport layer. Tom > IMO, the answers are no for both. > > Luca > > On Tue, Jun 19, 2018 at 9:26 PM Tom Herbert wrote: >> >> On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello >> wrote: >> > Hi all, >> > >> > the draft below has been posted and describes deployments options for >> > anchorless mobility management by using >> > the hicn network architecture that implements icn semantics in IPv6 >> > networks. >> > >> > >> > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options >> > >> > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ >> > >> > A background document has been posted to the internet area WG and >> > reported >> > here for your convenience. >> > The core principle behind hicn and mobility management is that data >> > sources >> > are named using location independent names >> > encoded in IPv6 addresses. The transport service sitting on top of the >> > hicn >> > architecture is not based on usual TCP/UDP sockets >> > but on a novel consumer/producer transport service that will be >> > described in >> > another draft. >> >> From the draft: "The transport end-point offers two kinds of services >> to applications: a producer and a consumer service. The service is >> instantiated in the application by opening communication sockets with >> an API to perform basic transport service operations: allocation, >> initialization, configuration, data transmission and reception." >> >> This seems like a pretty dramatic rethink of the transport layer just >> for the purposes of mobility management. Will there be a way to use >> hICN at the network layer with exsiting and unmodified transport >> protocols (i.e. can this be done without boiling the ocean)? >> >> Thanks, >> Tom >> >> >> >> > The current document and a companion document that will be posted soon >> > describe the different deployment options >> > with special care to the 5G service based architecture. >> > Thanks for the comments already received that helped completing this -00 >> > draft. >> > >> > Luca >> > >> > >> > >> > >> > >> > >> > ___ >> > 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] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options
On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello wrote: > Hi all, > > the draft below has been posted and describes deployments options for > anchorless mobility management by using > the hicn network architecture that implements icn semantics in IPv6 > networks. > > https://datatracker.ietf.org/doc/draft-auge-dmm-hicn-mobility-deployment-options > > https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/ > > A background document has been posted to the internet area WG and reported > here for your convenience. > The core principle behind hicn and mobility management is that data sources > are named using location independent names > encoded in IPv6 addresses. The transport service sitting on top of the hicn > architecture is not based on usual TCP/UDP sockets > but on a novel consumer/producer transport service that will be described in > another draft. >From the draft: "The transport end-point offers two kinds of services to applications: a producer and a consumer service. The service is instantiated in the application by opening communication sockets with an API to perform basic transport service operations: allocation, initialization, configuration, data transmission and reception." This seems like a pretty dramatic rethink of the transport layer just for the purposes of mobility management. Will there be a way to use hICN at the network layer with exsiting and unmodified transport protocols (i.e. can this be done without boiling the ocean)? Thanks, Tom > The current document and a companion document that will be posted soon > describe the different deployment options > with special care to the 5G service based architecture. > Thanks for the comments already received that helped completing this -00 > draft. > > Luca > > > > > > > ___ > 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
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
On Tue, Mar 27, 2018 at 11:47 AM, Arashmid Akhavain 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 > Cc: Satoru Matsushima ; dmm@ietf.org > Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 > > On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain > 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 >> Cc: dmm@ietf.org >> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 >> >> 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 m
Re: [DMM] IETF101 DMM WG Meeting Notes #1
On Tue, Mar 27, 2018 at 11:37 AM, Arashmid Akhavain 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) > 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) > 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF101 DMM WG Meeting Notes #1
On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain 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 > Cc: dmm@ietf.org > Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 > > 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 >>&g
Re: [DMM] IETF101 DMM WG Meeting Notes #1
On Tue, Mar 27, 2018 at 10:27 AM, Uma Chunduri 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) > 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) > 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF101 DMM WG Meeting Notes #1
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] draft-bogineni-dmm-optimized-mobile-user-plane-00
On Tue, Mar 27, 2018 at 7:36 AM, Sri Gundavelli (sgundave) wrote: > Tom: > > I am not against the use of the term “transformation” in ILA function > naming, but honestly I do not understand the difference. I have not seen > any documentation for such interpretation as you explained below. I have > looked at RFC 2663 and other specs, but I did find any such text. > > Lets look at two nodes, one with a NAT function and another with a ILA > function. > > #1 The NAT function intercepts the packets coming on an ingress interface, > look at certain header/payload fields and replaces certain fields with > certain other fields. It creates a temporary state for that mapping, which > we call it as NAT Mapping entry. The modified packet is sent on the egress > interface. > > #2 The ILA function (on ILA-L) intercepts the packet coming on an ingress > interface, looks at certain header fields, and replaces certain bits with > some other bits. For this replacement it looks at its cache, or obtains a > mapping entry which is very similar to NAT entry. The modified packet is > sent on the egress interface. > > > Now, for #2, your argument is that there is an inverse function some where > else in the other side of the network and that makes the original packet > go out to the correspondent node, and that the same does not happen for > #1. I agree with that, but, when you explain the sequence of steps that > these functions execute on a given packet (on a given node), there is very > little difference. Collectively, what ILA-L and ILA-R may achieve may be > different from what NAT realizes, but they are very similar functions when > you see them individually. > The difference is that the endpoints agree on what the addresses are for a flow. In NAT this does not happen so there is a descrepancy, in ILA there is always agreement. In this way ILA transformations are a method to make transparent network overlays. Tom > > Sri > > > > > On 3/23/18, 3:36 AM, "Tom Herbert" wrote: > >>On Tue, Mar 20, 2018 at 4:53 AM, Sri Gundavelli (sgundave) >> wrote: >>> >>> ILA-NAT-GW, or Locator-Rewrite Function ,,,should all work I guess. >>> >>Sri, >> >>I still like the term 'address transformation'. The difference between >>transformation and translation is that no information is lost in >>transformation (pointed out by Mark Smith on ila list) whereas >>translations may be imperfect. A transformation is always reversible >>and must be reversed before delivery to the final destination. >> >>Tom >> >>> Sri >>> >>> >>> >>> >>> On 3/20/18, 4:42 AM, "Marco Liebsch" wrote: >>> >>>>What about naming it nicely locator re-writing? Which is what it does >>>>and >>>>community reacts differently >>>>on certain terms such as NAT.. >>>> >>>>marco >>>> >>>>-Original Message- >>>>From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli >>>>(sgundave) >>>>Sent: Dienstag, 20. März 2018 12:40 >>>>To: Tom Herbert; Lyle Bertz >>>>Cc: dmm >>>>Subject: Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00 >>>> >>>>But, in any case, NAT is not such a bad word, its just that it pushed >>>>IPv6 deployments out by 20 years. >>>> >>>>Sri >>>> >>>>On 3/20/18, 4:37 AM, "dmm on behalf of Sri Gundavelli (sgundave)" >>>> wrote: >>>> >>>>>Tom: >>>>> >>>>>> ILA is not NAT! :-) >>>>> >>>>>As seen from the end point, I agree ILA is not NAT. But, that the >>>>>function that is needed at two places where you do translation of the >>>>>addresses from SIR to LOCATOR, or LOCATOR to SIR is a NAT function, and >>>>>you have a mapping state similar to NAT state. That¹s a NAT :-) >>>>> >>>>> >>>>>Sri >>>>> >>>>>On 3/20/18, 4:29 AM, "dmm on behalf of Tom Herbert" >>>>> wrote: >>>>> >>>>>>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz >>>>>>wrote: >>>>>>> We'll be quite time constrained during this session so I thought I >>>>>>>would ask a couple of simple questions which I hope have already >>>>>>>been addressed in previous e-mails: >>>>>>> >>>>>>> 1. Figures 14 & 15 are described as option
Re: [DMM] IETF101 DMM WG Meeting Notes #1
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: >>>>>&g
Re: [DMM] IETF101 DMM WG Meeting Notes #1
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
Re: [DMM] IETF101 DMM WG Meeting Notes #1
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
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
Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00
On Tue, Mar 20, 2018 at 4:53 AM, Sri Gundavelli (sgundave) wrote: > > ILA-NAT-GW, or Locator-Rewrite Function ,,,should all work I guess. > Sri, I still like the term 'address transformation'. The difference between transformation and translation is that no information is lost in transformation (pointed out by Mark Smith on ila list) whereas translations may be imperfect. A transformation is always reversible and must be reversed before delivery to the final destination. Tom > Sri > > > > > On 3/20/18, 4:42 AM, "Marco Liebsch" wrote: > >>What about naming it nicely locator re-writing? Which is what it does and >>community reacts differently >>on certain terms such as NAT.. >> >>marco >> >>-Original Message- >>From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli >>(sgundave) >>Sent: Dienstag, 20. März 2018 12:40 >>To: Tom Herbert; Lyle Bertz >>Cc: dmm >>Subject: Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00 >> >>But, in any case, NAT is not such a bad word, its just that it pushed >>IPv6 deployments out by 20 years. >> >>Sri >> >>On 3/20/18, 4:37 AM, "dmm on behalf of Sri Gundavelli (sgundave)" >> wrote: >> >>>Tom: >>> >>>> ILA is not NAT! :-) >>> >>>As seen from the end point, I agree ILA is not NAT. But, that the >>>function that is needed at two places where you do translation of the >>>addresses from SIR to LOCATOR, or LOCATOR to SIR is a NAT function, and >>>you have a mapping state similar to NAT state. That¹s a NAT :-) >>> >>> >>>Sri >>> >>>On 3/20/18, 4:29 AM, "dmm on behalf of Tom Herbert" >>> wrote: >>> >>>>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz >>>>wrote: >>>>> We'll be quite time constrained during this session so I thought I >>>>>would ask a couple of simple questions which I hope have already >>>>>been addressed in previous e-mails: >>>>> >>>>> 1. Figures 14 & 15 are described as options and do not include an SMF. >>>>> However, Figures 16 & 17 do. It is a bit confusing. Are 14 & 15 >>>>>incorrect or is an option to skip the SMF? If correct, how does one >>>>>do any policy in those figures? >>>>> >>>>> 2. ILA appears to be super NAT'g (more than 1 NAT) but it is >>>>>unclear how policy works. I am not sure that in its current state >>>>>the proposed ILA design addresses in Section 3. Although it is >>>>>noted that not all functions are supported at a specific UPF it is >>>>>unclear that policy, lawful intercept, etc.. is supported at all. >>>>>Will this be section be updated? >>>>> >>>>Hi Lyle, >>>> >>>>ILA is not NAT! :-) It is an address transformation process that is >>>>always undone before the packet is received so that receiver sees >>>>original packet. In this manner ILA is really just an efficient >>>>mechanism of creating network overlays. In this manner additional >>>>functionality (policy, lawful intercept, etc.) can be higher layers >>>>independent of the actual overlay mechanism. >>>> >>>>Tom >>>> >>>>> 3. Will a feature support comparison be made for each solution with >>>>>the UPF functions to ensure coverage? >>>>> >>>>> 4. Will MFA be proposed as an option ( >>>>> >>>>> draft-gundavelli-dmm-mfa-00 >>>>> >>>>> )? >>>>> >>>>> Thanks! >>>>> >>>>> Lyle >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ___ >>>>> 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 >>> >>>___ >>>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 > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00
On Tue, Mar 20, 2018 at 4:37 AM, Sri Gundavelli (sgundave) wrote: > Tom: > >> ILA is not NAT! :-) > > As seen from the end point, I agree ILA is not NAT. But, that the function > that is needed at two places where you do translation of the addresses > from SIR to LOCATOR, or LOCATOR to SIR is a NAT function, and you have a > mapping state similar to NAT state. That¹s a NAT :-) > I prefer term transformation :-) But in any case, this is definitely not stateful NAT and because the transformations are paired ILA does not have the issues that are typically associated with NAT. Tom > > Sri > > On 3/20/18, 4:29 AM, "dmm on behalf of Tom Herbert" on behalf of t...@quantonium.net> wrote: > >>On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz wrote: >>> We'll be quite time constrained during this session so I thought I >>>would ask >>> a couple of simple questions which I hope have already been addressed in >>> previous e-mails: >>> >>> 1. Figures 14 & 15 are described as options and do not include an SMF. >>> However, Figures 16 & 17 do. It is a bit confusing. Are 14 & 15 >>>incorrect >>> or is an option to skip the SMF? If correct, how does one do any >>>policy in >>> those figures? >>> >>> 2. ILA appears to be super NAT'g (more than 1 NAT) but it is unclear >>>how >>> policy works. I am not sure that in its current state the proposed ILA >>> design addresses in Section 3. Although it is noted that not all >>>functions >>> are supported at a specific UPF it is unclear that policy, lawful >>>intercept, >>> etc.. is supported at all. Will this be section be updated? >>> >>Hi Lyle, >> >>ILA is not NAT! :-) It is an address transformation process that is >>always undone before the packet is received so that receiver sees >>original packet. In this manner ILA is really just an efficient >>mechanism of creating network overlays. In this manner additional >>functionality (policy, lawful intercept, etc.) can be higher layers >>independent of the actual overlay mechanism. >> >>Tom >> >>> 3. Will a feature support comparison be made for each solution with the >>>UPF >>> functions to ensure coverage? >>> >>> 4. Will MFA be proposed as an option ( >>> >>> draft-gundavelli-dmm-mfa-00 >>> >>> )? >>> >>> Thanks! >>> >>> Lyle >>> >>> >>> >>> >>> >>> >>> >>> ___ >>> 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 > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00
On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz wrote: > We'll be quite time constrained during this session so I thought I would ask > a couple of simple questions which I hope have already been addressed in > previous e-mails: > > 1. Figures 14 & 15 are described as options and do not include an SMF. > However, Figures 16 & 17 do. It is a bit confusing. Are 14 & 15 incorrect > or is an option to skip the SMF? If correct, how does one do any policy in > those figures? > > 2. ILA appears to be super NAT'g (more than 1 NAT) but it is unclear how > policy works. I am not sure that in its current state the proposed ILA > design addresses in Section 3. Although it is noted that not all functions > are supported at a specific UPF it is unclear that policy, lawful intercept, > etc.. is supported at all. Will this be section be updated? > Hi Lyle, ILA is not NAT! :-) It is an address transformation process that is always undone before the packet is received so that receiver sees original packet. In this manner ILA is really just an efficient mechanism of creating network overlays. In this manner additional functionality (policy, lawful intercept, etc.) can be higher layers independent of the actual overlay mechanism. Tom > 3. Will a feature support comparison be made for each solution with the UPF > functions to ensure coverage? > > 4. Will MFA be proposed as an option ( > > draft-gundavelli-dmm-mfa-00 > > )? > > Thanks! > > Lyle > > > > > > > > ___ > 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] some test results of different network overlay methods
On Sun, Mar 18, 2018, 1:40 PM Pablo Camarillo (pcamaril) wrote: > Hi Tom, Kalyani, > > > > If the SR processing of the two SIDs is done by the end host, then I > believe the results for SR are obviously not valid. > Pablo, Why isn't this valid? > > > Also in all the hardware-based routing platforms for which we have done > interop > https://tools.ietf.org/html/draft-filsfils-spring-srv6-interop-00#section-2, > we have SRv6 running at linecard rate. > > > > Note that I find this performance testing work interesting, and I’m > willing to help you carry them. However, for next releases I would also > consider leveraging projects like linux foundation fdio CSIT > https://wiki.fd.io/view/CSIT/Description, in order to have a more > methodical and accurate results (ILA has higher throughput than native IPv6 > with a lower TPS). > > > To be clear, this is testing a real TCP stack and host terminating encapsulation (not just router performance). For this purpose the tests are methodical and accurate. The big difference in performance have a lot to do how well NICs deal with different encapsulations and EH in case of SR. The most interesting result, I think, is IPIP (and SR/IPIP) with drop in TPS. This indicates that device (in this case ixgbe) isn't getting 5-tuple hash for RSS. It's not parsing over headers to find ports for hash. Interestingly, it was able to parse into L4 when just SR header is present. Capabilities for things like this will vary between NICs. Tom > Thanks. > > > > Cheers, > > Pablo. > > -- > *De:*Tom Herbert > *Enviado:*viernes, 16 de marzo de 2018 7:58 p. m. > *Para:*Uma Chunduri > *Cc:* dmm > *Asunto:* Re: [DMM] some test results of different network overlay methods > > On Fri, Mar 16, 2018 at 12:40 PM, Uma Chunduri > wrote: > > Great work, Thank you Kalyani & Tom. > > > > 2 quick questions: > > > > 1. I presume SR inline is just SRH with 2 SIDs as mentioned - didn't > see the topology used. Do intermediate nodes handle these SIDs, with > pointer update in SRH? > > Two hosts connected back to back. SR processing done by end host. > > > 2. Also for Geneve - it's IP4 encap and VNI no TLVs? > > > No TLVs. GUE uses RCO extension. Other than that all the variants > should be out of the box with no options set. Encapsulations are > v4/v4, SRv6 and ILA are all IPv6. > > I'll post the all the configuration scripts to github once I have some > time. > > Tom > > > > -- > > Uma C. > > > > > > -Original Message- > > From: dmm [mailto:dmm-boun...@ietf.org ] On > Behalf Of Bogineni, Kalyani > > Sent: Friday, March 16, 2018 11:16 AM > > To: dmm > > Subject: [DMM] some test results of different network overlay methods > > > > > > All: > > > > Here are some raw performance test results based on our understanding of > the different network overlay methods. We welcome discussion and comments.. > > > > Kalyani and 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 > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] some test results of different network overlay methods
On Fri, Mar 16, 2018 at 12:40 PM, Uma Chunduri wrote: > Great work, Thank you Kalyani & Tom. > > 2 quick questions: > > 1. I presume SR inline is just SRH with 2 SIDs as mentioned - didn't see the > topology used. Do intermediate nodes handle these SIDs, with pointer update > in SRH? Two hosts connected back to back. SR processing done by end host. > 2. Also for Geneve - it's IP4 encap and VNI no TLVs? > No TLVs. GUE uses RCO extension. Other than that all the variants should be out of the box with no options set. Encapsulations are v4/v4, SRv6 and ILA are all IPv6. I'll post the all the configuration scripts to github once I have some time. Tom > -- > Uma C. > > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani > Sent: Friday, March 16, 2018 11:16 AM > To: dmm > Subject: [DMM] some test results of different network overlay methods > > > All: > > Here are some raw performance test results based on our understanding of the > different network overlay methods. We welcome discussion and comments. > > Kalyani and 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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
ars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip >> >> LS out from CT4 to RAN3: >> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip >> >> Thanks >> Sridhar >> >> -Original Message- >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima >> Sent: Tuesday, March 13, 2018 6:55 AM >> To: John Kaippallimalil >> Cc: dmm >> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt >> >> John, >> >>> 2018/03/13 7:37、John Kaippallimalil のメール: >>> >>> A few questions for clarification: >>> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push >>> an SRH..." >>> In this case the outer IPv6 address representing a SID would contain a TEID. >>> So for 1000 PDU sessions - would there be as many IPv6 addresses >>> (representing SIDs/TEID in the outer header) >> >> Right. It is not limited but in a typical case given that a /64 per node for >> the SID space which allows each node allocate a SID per session basis. >> >> >>> >>> 2. Section 5.2 (& Figure 3), suppose there were more than 1 UPF on >>> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns >>> - S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to >>> chain functions along the path to UPF1, >>> or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. >>> upto the anchor UPF2. >> >> Please see the section 5.2.1 of packet flow on uplink. >> We assume that there’s no UPF1 along the path in the diagram. >> >> >>> >>> 3. Section 5.2, "The SR policy MAY include SIDs for traffic engineering >>> and service chaining ..." >>> 3GPP service chaining is at N6 interface, but in this case, is the policy >>> for traffic steering implemented at the N3 interface. >>> Would PCF/SMF provision this at gNB. >> >> When it comes to enhanced mode for control-plane side, it may literally be >> enhanced. >> But at this revision of the draft, it is assumed that gNB is capable to >> resolve SR policy from remote endpoint address of tunnel to SIDs list while >> N2 is unchanged and kept as it is. >> >> Cheers, >> --satoru >> >> >>> >>> Thanks, >>> John >>> >>> >>> >>> -Original Message- >>> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] >>> Sent: Mittwoch, 7. März 2018 12:23 >>> To: Marco Liebsch >>> Cc: dmm >>> Subject: Re: [DMM] Fwd: I-D Action: >>> draft-ietf-dmm-srv6-mobile-uplane-01.txt >>> >>> Marco, >>> >>>> 2018/03/07 18:41、Marco Liebsch のメール: >>>> >>>> Satoru, >>>> >>>> since I read this at different places, let me ask one clarifying question >>>> about the stateless motivation: >>>> >>>> I see that for SRv6 you may not need a state at the egress (at least >>>> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need >>>> a state at both edges of the communication since the DL egress serves as >>>> uplink ingress, correct? >>> >>> 2x unidirectional tunnels to form bidirectional paths require 4 states in >>> total at both the ingress and egress. >>> In SR case it requires just 2 states at the ingresses for both directions. >>> >>> Cheers, >>> --satoru >>> >>> >>> >>>> >>>> marco >>>> >>>> >>>> -Original Message- >>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru >>>> Matsushima >>>> Sent: Dienstag, 6. März 2018 17:23 >>>> To: Tom Herbert >>>> Cc: dmm >>>> Subject: Re: [DMM] Fwd: I-D Action: >>>> draft-ietf-dmm-srv6-mobile-uplane-01.txt >>>> >>>> Hello Tom, >>>> >>>>>> A Big progress is that the draft supports interworking with GTP >>>>>> over >>>>>> IPv6 in addition to GTP over IPv4. >>>>>> And we have made change SRv6 function to IPv6 encapsulation with >>>>>> SRH instead of SRH insertion by default. >>>>>> >>>>> >>>>> Hi Satoru, >>>>> >>>>> If there are no intermediate hops od SIDs be
Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
On Wed, Mar 7, 2018 at 10:13 AM, Pablo Camarillo (pcamaril) wrote: > Tom, > > Your understanding is correct: in the traditional mode there is no pushed SRH > • Less MTU overhead than GTP in traditional mode. > • In enhanced mode with underlay TE with SLA bandwidth with stateless > service chaining we use the SRH. > Hi Pablo, I see. So in traditional mode this would just use simple IPIP encapsulation in path towards a mobile node. Conceptually, ILA could be applied int his case to eliminate the encapsulation overhead. That is an interesting possibility, although since SR is not involved in traditional mode the association with SR in the name might be a bit confusing to the reader ;-). I haven't completely thought through possibility of using ILA in enhanced mode, but it conceivable that ILA could be used on segments.For instance, the SIDs themselves might be virtual nodes, and ILA could be used to map them in to real devices at each hop. > Any solution other than SRv6 requires an independent layer for underlay TE(1) > and service chaining(2) > • Do you contemplate combining ILA with RSVP for 1 and NSH for 2 > causing explosion of state in the underlay?? Intent is that ILA can work with NSH, network, slices or other L2 mechanisms. ILA is confined to networks, so it doesn't make any requirements of lower layers, but is hould be able to work with them. The state we are concerned with in ILA is the number of identifier/locator mappings in the network. I believe that is a common problem across most proposals. > • What is the overhead in ILA when supporting IPv4 or Ethernet PDU > sessions? It must be greater, right? > Yes, it is greater. It requires a protocol translation where 20 bytes is expanded to 40 bytes. In itself it might just be as easy to encapsulate, however in the virtualization use case there are cases where protocol translation is quite valuable since it allows us to create a globally routable address for a node in a tenant network that may be using private IPv4 address (e.g. RFC1918). Tom > Thanks, > Pablo. > > On 06/03/2018, 17:23, "dmm on behalf of Satoru Matsushima" > wrote: > > Hello Tom, > > >> A Big progress is that the draft supports interworking with GTP over > IPv6 in > >> addition to GTP over IPv4. > >> And we have made change SRv6 function to IPv6 encapsulation with SRH > instead > >> of SRH insertion by default. > >> > > > > Hi Satoru, > > > > If there are no intermediate hops od SIDs being set when encapsulating > > would a SR header still be needed or could this just be simple IP in > > IP encpasulation? If is no SR header then it's possible that ILA > > might then be used to completely eliminate the encapsulation overhead. > > I think you’re right. You would find that case in the draft as > ‘Traditional Mode’ which is equivalent with traditional GTP-U case. You seem > you say ILA is also equivalent with that mode. In addition, this draft > introduces ‘Enhance Mode’ to cover more advanced cases. > > IMO SR is designed not to maintain path states except at an ingress node. > So the packet need to preserve original DA in the header that keep the egress > node in stateless. It would be great if ILA is designed in the similar > concept as well. > > If it’s not, it looks a kind of tradeoff, between reducing the overhead > and keeping the statelessness. It’s not apple-to-apple comparison. To decide > to choose which one need to be prioritized would depend on each deployment > case in operators IMO. > > Cheers, > --satoru > ___ > 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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
On Tue, Mar 6, 2018 at 11:29 AM, Pablo Camarillo (pcamaril) wrote: > Tom, > > > > Re: your comment on EH insertion. > > > > This point is not applicable; a new version of srv6-mobile-uplane > (https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01) is > > published making SRv6 encapsulation the default. > Yes, thank you for addressing the issue! Tom > > > Thanks, > > Pablo > > > > From: dmm on behalf of Satoru Matsushima > > Date: Tuesday, 6 March 2018 at 01:34 > To: dmm > Subject: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt > > > > Dear folks, > > > > A new revision of SRv6 Mobile User Plane draft has been submitted to IETF. > > > > I’d present brief summary of the updates, but the agenda seems already full > so that it is uncertain I can do that. > > > > So let me share the summary of update on the -01 version here. > > > > A Big progress is that the draft supports interworking with GTP over IPv6 in > addition to GTP over IPv4. > > And we have made change SRv6 function to IPv6 encapsulation with SRH instead > of SRH insertion by default. > > > > Another changes have been made. 5G architecture in 3GPP is shown as a > reference architecture, as the discussion on the list many people ask SRv6 > applicability for 5G. As the result, many terminologies are aligned based on > the reference. > > > > You can see many improvements in terms of readability, especially on packet > flow explanations. I hope that many of us understand how SRv6 works for the > deployment cases described in the draft. > > > > Pablo has contributed those significant part of progresses and improvements. > He's now onboard as a co-author of the draft. > > > > Best regards, > > --satoru > > > > 転送されたメッセージ: > > > > 差出人: internet-dra...@ietf.org > > 件名: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt > > 日付: 2018年3月6日 7:42:01 JST > > 宛先: > > CC: dmm@ietf.org > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Distributed Mobility Management WG of the > IETF. > >Title : Segment Routing IPv6 for Mobile User Plane >Authors : Satoru Matsushima > Clarence Filsfils > Miya Kohno > Pablo Camarillo > Daniel Voyer > Charles E. Perkins > Filename: draft-ietf-dmm-srv6-mobile-uplane-01.txt > Pages : 23 > Date: 2018-03-05 > > Abstract: > This document discusses the applicability of SRv6 (Segment Routing > IPv6) to user-plane of mobile networks. The source routing > capability and the network programming nature of SRv6, accomplish > mobile user-plane functions in a simple manner. The statelessness > and the ability to control underlying layer will be even more > beneficial to the mobile user-plane, in terms of providing > flexibility and SLA control for various applications. It also > simplifies the network architecture by eliminating the necessity of > tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS, > and so on. In addition, Segment Routing provides an enhanced method > for network slicing, which is briefly introduced by this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > 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] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
On Mon, Mar 5, 2018 at 4:34 PM, Satoru Matsushima wrote: > Dear folks, > > A new revision of SRv6 Mobile User Plane draft has been submitted to IETF. > > I’d present brief summary of the updates, but the agenda seems already full > so that it is uncertain I can do that. > > So let me share the summary of update on the -01 version here. > > A Big progress is that the draft supports interworking with GTP over IPv6 in > addition to GTP over IPv4. > And we have made change SRv6 function to IPv6 encapsulation with SRH instead > of SRH insertion by default. > Hi Satoru, If there are no intermediate hops od SIDs being set when encapsulating would a SR header still be needed or could this just be simple IP in IP encpasulation? If is no SR header then it's possible that ILA might then be used to completely eliminate the encapsulation overhead. Tom > Another changes have been made. 5G architecture in 3GPP is shown as a > reference architecture, as the discussion on the list many people ask SRv6 > applicability for 5G. As the result, many terminologies are aligned based on > the reference. > > You can see many improvements in terms of readability, especially on packet > flow explanations. I hope that many of us understand how SRv6 works for the > deployment cases described in the draft. > > Pablo has contributed those significant part of progresses and improvements. > He's now onboard as a co-author of the draft. > > Best regards, > --satoru > > 転送されたメッセージ: > > 差出人: internet-dra...@ietf.org > 件名: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt > 日付: 2018年3月6日 7:42:01 JST > 宛先: > CC: dmm@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Distributed Mobility Management WG of the > IETF. > >Title : Segment Routing IPv6 for Mobile User Plane >Authors : Satoru Matsushima > Clarence Filsfils > Miya Kohno > Pablo Camarillo > Daniel Voyer > Charles E. Perkins > Filename: draft-ietf-dmm-srv6-mobile-uplane-01.txt > Pages : 23 > Date: 2018-03-05 > > Abstract: > This document discusses the applicability of SRv6 (Segment Routing > IPv6) to user-plane of mobile networks. The source routing > capability and the network programming nature of SRv6, accomplish > mobile user-plane functions in a simple manner. The statelessness > and the ability to control underlying layer will be even more > beneficial to the mobile user-plane, in terms of providing > flexibility and SLA control for various applications. It also > simplifies the network architecture by eliminating the necessity of > tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS, > and so on. In addition, Segment Routing provides an enhanced method > for network slicing, which is briefly introduced by this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > 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 > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] SRv6 for Mobile User-Plane
On Tue, Feb 27, 2018 at 10:23 AM, Arashmid Akhavain wrote: > Hi Tom, > I believe you are referring to section 4 of RFC8200 where it states: > > "Extension headers (except for the Hop-by-Hop Options header) are not > processed, inserted, or deleted by any node along a packet’s delivery > path, until the packet reaches the node (or each of the set of nodes, > in the case of multicast) identified in the Destination Address field > of the IPv6 header." > > We copy SID[SL] in to DA as we pass through different segments along the path. > EH manipulation is allowed as long as we do it at nodes identified by the DA > (In SR case this node owns the SID[SL] of course). > Am I missing anything? > Arashmid, When the SR is present in a packet that behavior is correct and complies with RFC8200-- the SR EH is only processed by nodes that are identified in the destination address. The question is how did the SR EH get set in the packet in the first place. If a host sourced a packet with extension headers then it conforms to RFC8200. Also, if an intermediate device performs encapsulation, say IP in IP, and sets the EH in the outer header then that is also conforms to RFC8200 since the device is taking the role of host in sourcing an encapsulated packet. However, if an intermediate device inserts an extension header into an IPv6 packet without encapsulation that is where the problem is. I think Pablo's comment was that this should be allowed in controlled domains. Tom > Arashmid > > > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: 26 February 2018 15:24 > To: Pablo Camarillo (pcamaril) > Cc: satoru.matsush...@g.softbank.co.jp; cf(mailer list) ; > Miya Kohno (mkohno) ; dmm@ietf.org; Voyer, Daniel > > Subject: Re: [DMM] SRv6 for Mobile User-Plane > > On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril) > wrote: >> Hello authors, DMM, >> >> >> >> I have reviewed your I-D on SRv6 for mobile user-plane and I would >> like to make some proposals. I have already discussed and brainstormed >> the details with some of the authors of the draft and they agree to >> this changes, however I would like to get the WG feedback on it. >> >> >> >> Thank you, >> >> Pablo. >> >> >> >> I believe its straightforward to support IPv4 UE traffic by doing SRv6 >> with T.Encaps behavior. Hence, I think this should be documented in the >> draft. >> >> The encapsulation behavior should be the default one, both for IPv4 >> and IPv6 UE traffic. However, a specific provider is allowed to do SRH >> insertion within a controlled domain >> [draft-voyer-6man-extension-header-insertion-02] >> for UE IPv6 traffic. > > Pablo, > > That draft received substantial pushback on 6man list. EH insertion is not > allowed by RFC8200 and a host of points were raised why it shouldn't be > allowed. The authors have not responded to this feedback yet. Also, IMO, the > argument that it's okay to do this within a controlled domain is weak, such > an argument could be used to pretty much justify anything one might do with > protocols. > > Tom > >> >> Also, in order to reduce overhead at the UPFs when using >> encapsulation, I would replace the End.B6 function for a new End.MAP >> function. >> >> For example, if we consider the following topology: >> >> UEgNBUPF1UPF2 >> >> >> >> Then the uplink packet flow for the basic mode would look like this: >> >> UE_out: (A, Z) >> >> gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps >> >> UPF1_out: (gNB, U2::1) (A, Z) -> End.MAP >> >> UPF2_out: (A, Z) -> End.DT >> >> >> >> The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID. >> >> >> >> Notice that using encapsulation, if you compare it with today >> user-plane using IPv6/GTP, the result is that SRv6 is just adding 40B >> of overhead (IPv6 header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP). >> >> >> >> === >> >> >> >> With respect to the aggregation mode, aside from using the >> encapsulation mode as described before, I would also like to add a >> note on the I-D on the fact that we can support the aggregation mode >> without changes in the N2 >> interface: >> >> The current I-D for aggregation mode assumes that the gNB (uplink) has >> knowledge of an SR policy that contains all the SIDs belonging to TE, >> NFV and so on. Even though the I-D does not describe how the gNB is >> retriev
Re: [DMM] SRv6 for Mobile User-Plane
On Mon, Feb 26, 2018 at 5:33 PM, Voyer, Daniel wrote: > Tom, > > In respect of this current draft, and highlighted by Pablo’s comments, is to > propose adding to this draft the use of encapsulation as default behavior for > v4/v6 traffic. > > The use of EH insertion is totally the operator’s discretion, within the > operator domain if the operator chose to. > Right, EH insertion could be at an operators discretion. But then so is deploying proprietary IP protocols, overloading standard protocol fields with proprietary info, rearranging IP headers, using IPv10, etc. Doing these sort of things are possible and actually common in closed networks, but they are not interoperable standards. I'd also point out that the issues raised in the 6man discussion were material and raised fundamental questions if header insertion is robust even in a controlled domain. Even if the argument is that EH insertion will only ever be done in a controlled domain, these issues still need to be addressed I think. Tom > I think Pablo’s proposition make sense. Thoughts ? > > dan > > > On 2018-02-26, 3:24 PM, "Tom Herbert" wrote: > > On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril) > wrote: > > Hello authors, DMM, > > > > > > > > I have reviewed your I-D on SRv6 for mobile user-plane and I would like > to > > make some proposals. I have already discussed and brainstormed the > details > > with some of the authors of the draft and they agree to this changes, > > however I would like to get the WG feedback on it. > > > > > > > > Thank you, > > > > Pablo. > > > > > > > > I believe its straightforward to support IPv4 UE traffic by doing SRv6 > with > > T.Encaps behavior. Hence, I think this should be documented in the > draft. > > > > The encapsulation behavior should be the default one, both for IPv4 and > IPv6 > > UE traffic. However, a specific provider is allowed to do SRH insertion > > within a controlled domain > [draft-voyer-6man-extension-header-insertion-02] > > for UE IPv6 traffic. > > Pablo, > > That draft received substantial pushback on 6man list. EH insertion is > not allowed by RFC8200 and a host of points were raised why it > shouldn't be allowed. The authors have not responded to this feedback > yet. Also, IMO, the argument that it's okay to do this within a > controlled domain is weak, such an argument could be used to pretty > much justify anything one might do with protocols. > > Tom > > > > > Also, in order to reduce overhead at the UPFs when using encapsulation, > I > > would replace the End.B6 function for a new End.MAP function. > > > > For example, if we consider the following topology: > > > > UEgNBUPF1UPF2 > > > > > > > > Then the uplink packet flow for the basic mode would look like this: > > > > UE_out: (A, Z) > > > > gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps > > > > UPF1_out: (gNB, U2::1) (A, Z) -> End.MAP > > > > UPF2_out: (A, Z) -> End.DT > > > > > > > > The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID. > > > > > > > > Notice that using encapsulation, if you compare it with today user-plane > > using IPv6/GTP, the result is that SRv6 is just adding 40B of overhead > (IPv6 > > header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP). > > > > > > > > === > > > > > > > > With respect to the aggregation mode, aside from using the encapsulation > > mode as described before, I would also like to add a note on the I-D on > the > > fact that we can support the aggregation mode without changes in the N2 > > interface: > > > > The current I-D for aggregation mode assumes that the gNB (uplink) has > > knowledge of an SR policy that contains all the SIDs belonging to TE, > NFV > > and so on. Even though the I-D does not describe how the gNB is > retrieving > > this information, I would like to make a statement on the fact that > there > > are two alternatives: > > > > A. The N2 interface is modified in order to signal a SID list to the > gNB. > > > > B. The N2 interface is not mod
Re: [DMM] SRv6 for Mobile User-Plane
On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril) wrote: > Hello authors, DMM, > > > > I have reviewed your I-D on SRv6 for mobile user-plane and I would like to > make some proposals. I have already discussed and brainstormed the details > with some of the authors of the draft and they agree to this changes, > however I would like to get the WG feedback on it. > > > > Thank you, > > Pablo. > > > > I believe its straightforward to support IPv4 UE traffic by doing SRv6 with > T.Encaps behavior. Hence, I think this should be documented in the draft. > > The encapsulation behavior should be the default one, both for IPv4 and IPv6 > UE traffic. However, a specific provider is allowed to do SRH insertion > within a controlled domain [draft-voyer-6man-extension-header-insertion-02] > for UE IPv6 traffic. Pablo, That draft received substantial pushback on 6man list. EH insertion is not allowed by RFC8200 and a host of points were raised why it shouldn't be allowed. The authors have not responded to this feedback yet. Also, IMO, the argument that it's okay to do this within a controlled domain is weak, such an argument could be used to pretty much justify anything one might do with protocols. Tom > > Also, in order to reduce overhead at the UPFs when using encapsulation, I > would replace the End.B6 function for a new End.MAP function. > > For example, if we consider the following topology: > > UEgNBUPF1UPF2 > > > > Then the uplink packet flow for the basic mode would look like this: > > UE_out: (A, Z) > > gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps > > UPF1_out: (gNB, U2::1) (A, Z) -> End.MAP > > UPF2_out: (A, Z) -> End.DT > > > > The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID. > > > > Notice that using encapsulation, if you compare it with today user-plane > using IPv6/GTP, the result is that SRv6 is just adding 40B of overhead (IPv6 > header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP). > > > > === > > > > With respect to the aggregation mode, aside from using the encapsulation > mode as described before, I would also like to add a note on the I-D on the > fact that we can support the aggregation mode without changes in the N2 > interface: > > The current I-D for aggregation mode assumes that the gNB (uplink) has > knowledge of an SR policy that contains all the SIDs belonging to TE, NFV > and so on. Even though the I-D does not describe how the gNB is retrieving > this information, I would like to make a statement on the fact that there > are two alternatives: > > A. The N2 interface is modified in order to signal a SID list to the gNB. > > B. The N2 interface is not modified. In this case, we signal through the N2 > interface an SRv6 BindingSID, that the gNB is going to resolve into a SID > list via an SDN controller either using PCEP, reverse DNS lookup or LISP. > > > > I’m aware that the I-D focuses on the user-plane, however I believe it’s > important to state this alternatives since it simplifies the adoption and > reduces impact in the existing mobile architectures (without going into the > details on the mechanisms for each one of the alternatives of LISP, PCEP, > reverse DNS-lookup). > > > > === > > > > On the other hand, the current I-D proposes a mechanism for stateless > interworking with legacy access networks that doesn’t support SRv6 (SGW > and/or eNB). This mechanism presented in the I-D is limited to IPv4/GTP > legacy networks. I would like to propose a mechanism to support interworking > with legacy gNBs that does not support SRv6 but do support IPv6/GTP. > > The main benefit comes from the fact that we can leverage an SRv6 BindingSID > to have remote classification and steering of the UE traffic over an SR > policy [draft-filsfils-spring-segment-routing-policy]. > > > > In this scenario, I propose that we add the notion of an SR GW -as the > current stateless interworking node in the I-D-. This SR GW can be either a > software based platform -e.g. VPP- or any existing router -the mechanism is > simple and can be supported in existing HW-. This SR GW receives through the > control plane the SR policies and installs the required Binding SIDs. > > > > Then, for any UE connecting to a gNB, the N2 interface is going to signal an > IPv6 address and a TEID. However, the difference is that with this new > mechanism the IPv6 address that we are going to signal is going to be an > SRv6 BindingSID instantiated at the SR GW. > > > > The overall workflow is the following: > > > > Uplink > > Note: S1, S2 represent service functions and C1 represents a node for TE > purposes > > UE sends its packet (A, Z) on a specific wireless bearer to its gNB > > gNB’s CP associates the session from the UE (A) with IPv6 address B and TEID > T (N2 interface unchanged) > > gNB_out: (gNB, B) (GTP: TEID T) (A, Z) ;; Interface N3 > is unchanged > > SR_GW_out: (SRGW, S1) (U2::1, C1; SL=2)(A, Z) ;; new End.GTP.UP > > S1_out: (SRGW, C
Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
On Fri, Feb 9, 2018 at 12:09 AM, Alexandre Petrescu < alexandre.petre...@gmail.com> wrote: > > > Le 07/02/2018 à 18:29, Tom Herbert a écrit : > >> >> >> On Wed, Feb 7, 2018 at 8:49 AM, Alexandre Petrescu < >> alexandre.petre...@gmail.com <mailto:alexandre.petre...@gmail.com>> >> wrote: >> >> >> >> Le 06/02/2018 à 05:52, Lorenzo Colitti a écrit : >> >> On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert > t...@quantonium.net> <mailto:t...@quantonium.net >> <mailto:t...@quantonium.net>>> >> wrote: >> >> We like like to request that the dmm WG consider ILA as a candidate >> protocol for the 3GPP "Study on User Plane Protocol in 5GC". >> >> >> Echoing Tom's earlier comment about this: I think the address assignment >> sections (6.3 and 8.3) should be reworded to clarify that >> for general purpose hosts, best practice is not to use singleton >> addresses, but always to provide a /64 prefix. >> >> >> I would say a prefix yes, but prefer a /63 and shorter. >> >> Alex, >> >> I'm curious as to why you'd need even shorter prefixes. >> > > This is an optional accessory. > A /63 prefix is beneficial for a Mobile Router, or 'IoT Router', for > local area tethering, or for in-vehicle networks. It gets a /63 from > the ISP and makes two /64s out of it. One for its WiFi interface and > one for its Ethernet interface. > > Alex, Why not just get a /64 for WIFI and one for Ethernet? That would be the common case any way if they are attached to two different providers. > If it only gets a /64 then it cant make other /64s out of it and it > can't route. > I'm a bit amused by the phrase "only gets a /64". Assigning a /64 to a device is the equivalent of assigning four billion IPv4 address spaces after all! Why not just carve up a /64 into bunch of /96s or something like that for down stream allocation? Tom ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
On Wed, Feb 7, 2018 at 8:49 AM, Alexandre Petrescu < alexandre.petre...@gmail.com> wrote: > > > Le 06/02/2018 à 05:52, Lorenzo Colitti a écrit : > >> On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert > t...@quantonium.net>> wrote: >> >> We like like to request that the dmm WG consider ILA as a candidate >> protocol for the 3GPP "Study on User Plane Protocol in 5GC". >> >> >> Echoing Tom's earlier comment about this: I think the address assignment >> sections (6.3 and 8.3) should be reworded to clarify that for general >> purpose hosts, best practice is not to use singleton addresses, but always >> to provide a /64 prefix. >> > > I would say a prefix yes, but prefer a /63 and shorter. > > Alex, I'm curious as to why you'd need even shorter prefixes. If a subnet is so huge that it needs more than a /64, why not just give it a static prefix allocation. ILA can be used independently within the subnet if desired. Tom ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
HI Sri, On Mon, Feb 5, 2018 at 10:25 PM, Sri Gundavelli (sgundave) < sgund...@cisco.com> wrote: > Tom: > > Thanks! That sounds like some interesting trick. But, let me make sure I > understood this correctly. So, the > identifier space for the MN is encoded in the upper 64-bits. Now, the UE > can use those bits to generate any Identifier from that space, and use it > with the SIR prefix to form the 128 bit address. Bear with me, let me use > an example > > MN1 is assigned a prefix *2001:ABCD:CAFÉ*: / 48 > MN2 is assigned a prefix *2001:ABCD:FOOD*: /48 > > The SIR Prefix for that ILA domain is 2001:DB8::/64 > > So, the SIR Addresses can be formed using the 16-bit identifier space > left from the /48 prefix assignment? UE can form any identifier from bit > space? > > No, we want allow a full /64 assignment since that is being already deployed. > I can’t figure out the scheme from this below text in 6.3.2. I think I am > missing the context here. May be you guys discussed this before. > > > >To support /64 prefix assignment with ILA, the ILA identifier can be >encoded in the the upper sixty-four bits of an address and the lower > >sixty-four bits are ignored by ILA. Since only a subset of bits are >available, a level of indirection can be used so that ILA transforms >the upper sixty four bits to contain both a locator and an index into >a locator (ILA-N) specific table. The entry in the table provides the >original sixty-four bit prefix so that ILA to SIR address >transformation can be done. > > - > > The SIR prefix and identifier are encoded in the upper 64 bits. Assuming the network has a /24, and address for /64 assignment might have this format. NetworkSIR/identifier IID 24 bits 40 bits 64 bits |--|--| The IID part is arbitrarily assigned by the device, so that is ignored by ILA. All routing, lookups, and transformations (excepting checksum neutral mapping) are based in upper sixty-four bits. For SIR->ILA transformation, a lookup is done on the upper sixty four bits. That returns a locator that would have format something like: Network Locator Locator_index 24 bits 20 bits 20 bits |---|--| The packet is forwarded and routed to the ILA addressed by locator (/44 route). ILA, the locator index is used as a key to an ILA-N specific table that returns the 40 bit SIR/identifier. This value is then written in the packet do ILA->SIR transformation thereby restoring the original address. The locator index is not globally unique, it is specific to each ILA-N. When a node attaches to an ILA-N, an index is chosen so that the table is populated at the ILA-N and the ILA mapping includes the locator and index. When a node detaches from on ILA, it's entry in the table is removed and the index can be reused after a holddown period to purge stale mappings. Tom > From: Tom Herbert > Date: Monday, February 5, 2018 at 9:13 PM > To: Sri Gundavelli > Cc: Lorenzo Colitti , "i...@ietf.org" , > dmm > Subject: Re: [DMM] Fwd: New Version Notification for > draft-herbert-ila-mobile-00.txt > > > > On Mon, Feb 5, 2018 at 9:07 PM, Sri Gundavelli (sgundave) < > sgund...@cisco.com> wrote: > >> > best practice is not to use singleton addresses, but always to provide >> a /64 prefix. >> >> But, how does that work with ILA's approach of identifier management? >> With the previously IETF recommended approaches in RFC5213 and even in 3GPP >> architecture, per RFC3315, the network assigned a set of unique prefixes >> for each MN, allowed the MN to generate the identifiers. Even CGA >> addressing worked with the per-MN prefix model. >> >> But, with ILA there is no concept of prefix assignment. Will ILA network >> now generate a identifier block for each MN? Is DHCPv6 the only approach? >> >> Sri, see section 6.3.2. That describes encoding the identifier in the > upper sixty-four bits and using an indirection table to accommodate network > prefixes. > > Tom > > If that block is not summarizable, will it not result in mapping table >> size getting multiple many times? >> >> >> Sri >> >> >> >> >> >> From: dmm on behalf of Lorenzo Colitti < >> lore...@google.com> >> Date: Monday, February 5, 2018 at 8:52 PM >> To: Tom Herbert >> Cc: "i...@ietf.org" , dmm >> Subject:
Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
On Mon, Feb 5, 2018 at 10:16 PM, Lorenzo Colitti wrote: > On Tue, Feb 6, 2018 at 3:02 PM, Tom Herbert wrote: > >> On Tue, Feb 6, 2018 at 2:17 PM, Tom Herbert wrote: >>> >>>> Section 8.3 provides the argument that singleton addresses are needed >>>> for privacy-sensitive communications. For practicality and probably scaling >>>> /64 is needed, however for strong privacy singleton addresses would be >>>> needed (to avoid resorting to NAT). >>>> >>> >>> You don't need singletons for privacy. You can just assign /64s that >>> change over time. >>> >> >> Yes, that seems to be the recommendation of RFC4914. However, neither >> that RFC nor anyone else that I can tell has been able to quantitatively >> describe the relationship between frequency of changing prefix and privacy. >> Any statements about this are qualitative in nature. By intuition, it might >> be believable that higher frequency should mean better privacy, but nobody >> can quantify that. So for a user where privacy is paramount, my example is >> a political dissident that is anonymously criticizing their government, >> there is no definitive answer to give then when they ask what frequency >> they need to ensure their privacy. Besides that, I believe that any >> frequency could be defeated with the postulated exploit below (if you see a >> flaw in this logic please let me know). >> > > In general, any scheme that relies in changing singletons can be > implemented by changing /64 prefixes in the same way. > > Lorenzo, The number of unique /64 prefixes a network could assign for this purpose is much less than 2^64 due to network prefix and a prefix needed for internal routing. > Your example of a dissident that is criticizing the government is not a > relevant one in the likely case that the > Consider that the dissident might be exiled in a country that is sympathetic to their cause, and the government being criticized has no control over the local provider. There are several famous individuals for which this is true, protecting their anonymity and location may be a matter life and death. > government has the power to compel the network operator to log all the > singletons that the network assigns. > > Then the government should have the power to compel an operator to log NAT mappings, but apparently that hasn't happened or isn't sufficient for what law enforcement thinks they need. I suspect that the primary reason that LI wants trackable addresses in the Internet is to perform mass passive surveillance on transit networks in their jurisdiction to deduce criminal networks and intent. > Actually, there is one frequency where the privacy effects can be >> qualified: that is to use a different address per connection. This is >> effectively what stateful NAT provides and why law enforcement doesn't like >> it. With a large enough pool of users behind a NAT, flows sourced form the >> same device cannot be correlated by a third party in external network. This >> is strong privacy privacy in addressing (properties listed in 8.3). In lieu >> of telling the political dissident to find a provider using NAT, assigning >> addresses for singe use can provide it. Assigning a /64 to every flow won't >> scale, but singleton addresses could. >> > > Saying that assigning unaggregatable singleton addresses to each flow > would scale is an extremely bold statement. Back-of-the-envelope says that > with 100M devices and an average of 10 flows per device that last 5 minutes > on average you've got 1B entries and 3.3 milion flow updates per second. > That amount of state must be available within a reasonable time (line rate, > or, say, 1 RTT) to any border router that could conceivably receive a > packet for any one of those flows. I don't know what sort of hardware you'd > be able to run that on, nor who would want to make such a colossal > infrastructure investment even if it could be done. > Here are some mitigating factors for scaling issue: 1) Not all communications require strong privacy, so they all don't need singleton addresses. 2) The amount of state is equal, or at least proportional, to that in a network using NAT today. Scaling single use addresses then scales as much as NAT scales. 3) As pointed out in section 8.3 it is conceivable that crypto-graphic addresses might be used that would allow a method of address aggregation that a provider network knows about but is hidden to the rest of the world. I think this possibility is worth investigation. Tom ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
On Mon, Feb 5, 2018 at 9:22 PM, Lorenzo Colitti wrote: > On Tue, Feb 6, 2018 at 2:17 PM, Tom Herbert wrote: > >> Section 8.3 provides the argument that singleton addresses are needed for >> privacy-sensitive communications. For practicality and probably scaling /64 >> is needed, however for strong privacy singleton addresses would be needed >> (to avoid resorting to NAT). >> > > You don't need singletons for privacy. You can just assign /64s that > change over time. > Yes, that seems to be the recommendation of RFC4914. However, neither that RFC nor anyone else that I can tell has been able to quantitatively describe the relationship between frequency of changing prefix and privacy. Any statements about this are qualitative in nature. By intuition, it might be believable that higher frequency should mean better privacy, but nobody can quantify that. So for a user where privacy is paramount, my example is a political dissident that is anonymously criticizing their government, there is no definitive answer to give then when they ask what frequency they need to ensure their privacy. Besides that, I believe that any frequency could be defeated with the postulated exploit below (if you see a flaw in this logic please let me know). Actually, there is one frequency where the privacy effects can be qualified: that is to use a different address per connection. This is effectively what stateful NAT provides and why law enforcement doesn't like it. With a large enough pool of users behind a NAT, flows sourced form the same device cannot be correlated by a third party in external network. This is strong privacy privacy in addressing (properties listed in 8.3). In lieu of telling the political dissident to find a provider using NAT, assigning addresses for singe use can provide it. Assigning a /64 to every flow won't scale, but singleton addresses could. The following exploit is proposed to defeat the privacy goal of periodic address rotation: - The attacker creates an “always connected” app that provides some seemingly benign service and users download the app. - The app includes some sort of persistent identity. For instance, this could be a login to account. - The backend server for the app logs the user identity and IP address they are using each time they connect. - When an address change happens, existing connections on the user device are disconnected. The app will receive a notification and immediately attempt to reconnect using the new source address. - The backend server will see the new connection and log the new IP address as being used by the user. - Thus, the server has a real-time record of users and the IP address they are using. - The attacker gains access to packet traces taken at some point in the Internet. The addresses in the captured packets can be time correlated with the server database to deduce the identity of the source of packets for flows communications unrelated to the app. Tom ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
On Mon, Feb 5, 2018 at 8:52 PM, Lorenzo Colitti wrote: > On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert wrote: > >> We like like to request that the dmm WG consider ILA as a candidate >> protocol for the 3GPP "Study on User Plane Protocol in 5GC". >> > > Echoing Tom's earlier comment about this: I think the address assignment > sections (6.3 and 8.3) should be reworded to clarify that for general > purpose hosts, best practice is not to use singleton addresses, but always > to provide a /64 prefix. > Lorenzo, Section 8.3 provides the argument that singleton addresses are needed for privacy-sensitive communications. For practicality and probably scaling /64 is needed, however for strong privacy singleton addresses would be needed (to avoid resorting to NAT). I'm not sure a best practice can be defined here since it may depend on the application context. Tom ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
On Mon, Feb 5, 2018 at 9:07 PM, Sri Gundavelli (sgundave) < sgund...@cisco.com> wrote: > > best practice is not to use singleton addresses, but always to provide a > /64 prefix. > > But, how does that work with ILA's approach of identifier management? > With the previously IETF recommended approaches in RFC5213 and even in 3GPP > architecture, per RFC3315, the network assigned a set of unique prefixes > for each MN, allowed the MN to generate the identifiers. Even CGA > addressing worked with the per-MN prefix model. > > But, with ILA there is no concept of prefix assignment. Will ILA network > now generate a identifier block for each MN? Is DHCPv6 the only approach? > > Sri, see section 6.3.2. That describes encoding the identifier in the upper sixty-four bits and using an indirection table to accommodate network prefixes. Tom If that block is not summarizable, will it not result in mapping table size > getting multiple many times? > > > Sri > > > > > > From: dmm on behalf of Lorenzo Colitti < > lore...@google.com> > Date: Monday, February 5, 2018 at 8:52 PM > To: Tom Herbert > Cc: "i...@ietf.org" , dmm > Subject: Re: [DMM] Fwd: New Version Notification for > draft-herbert-ila-mobile-00.txt > > On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert wrote: > >> We like like to request that the dmm WG consider ILA as a candidate >> protocol for the 3GPP "Study on User Plane Protocol in 5GC". >> > > Echoing Tom's earlier comment about this: I think the address assignment > sections (6.3 and 8.3) should be reworded to clarify that for general > purpose hosts, best practice is not to use singleton addresses, but always > to provide a /64 prefix. > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] [Ila] Questions about SRv6 mobile user-plane
Hi Uma, > [Uma]: SRH in the proposal not only put a sort of mobility solution (encoded > in the SID) but also use to guide the packet through non shortest path from > the source as needed and as listed in the SRH. > It would be nice to have a concrete example of how this would be used and how SR uniquely solves the problem. >One of the assumption, I saw the discussion here, ILA and > 5GIP seems to assume delivering the packet to the shortest path but this may > not be necessary the case for lot of 5G slices and also tunneling in couple > of cases is unavoidable (if you ought to overlay IPSec in few cases). > I believe you could get the same effect for either ILA or encapsulation by doing hop-by-hop routing over a network overlay. As I mentioned, the operation in slide "Basic Mode User-Plane Flows (Uplink)" where A3::1 is written into the destination seems to be doing just that. Tom ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
On Thu, Feb 1, 2018 at 4:38 PM, Sri Gundavelli (sgundave) wrote: >> One thing to add. LISP has a more mature control-plane mapping system. >>ILA has a recent proposal for its control-plane. > > Mobility architectures started with a unified CP/UP approach, then the > industry thought its a great idea to move the Control-plane out, and > reduce the state in the User-plane, and eliminate tunnels. Now, we want to > eliminate the tunnels, but we need a new control protocol to manage the > binding tables, and manage the complex cache states. Wondering, what¹s > wrong with this picture? What de we name this new CUPS architecture? > Sri, Bear in mind that "industry" has different meanings depending on the context. For ILA, and probably for LISP, the intent is to build a generic protocol that can be used across variety of use cases in the networking industry which hasn't uniformly adopted CUPS. It's pretty obvious that we'd want to leverage a single data plane control plane for these (isn't that the point of generic protocols :-) ). The CUPS actually architecture helps a lot here by creating a clean well abstracted interface that should make it straightforward to adapt an ILA control plane. I think our architecture where we define ILA as an NF reflects that. Tom > > Sri > > > (with no chair hat) > > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt
Hello, We posted this draft that describe using ILA for the mobile network use case, and some specifics about using ILA in 5G. We like like to request that the dmm WG consider ILA as a candidate protocol for the 3GPP "Study on User Plane Protocol in 5GC". Comments are appreciated! Thank you, Tom -- Forwarded message -- From: Date: Thu, Feb 1, 2018 at 10:09 AM Subject: New Version Notification for draft-herbert-ila-mobile-00.txt To: Tom Herbert , Kalyani Bogineni A new version of I-D, draft-herbert-ila-mobile-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-ila-mobile Revision: 00 Title: Identifier Locator Addressing for Mobile User-Plane Document date: 2018-02-01 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-herbert-ila-mobile-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-ila-mobile/ Htmlized: https://tools.ietf.org/html/draft-herbert-ila-mobile-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-ila-mobile-00 Abstract: This document discusses the applicability of Identifier Locator Addressing (ILA) to the user-plane of mobile networks. ILA allows a means to implement network overlays without the overhead, complexities, or anchor points associated with encapsulation. This solution facilitates highly efficient packet forwarding and provides low latency and scalability in mobile networks. ILA can be used in conjunction with techniques such as network slices and Network Function Virtualization to achieve optimal service based forwarding. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Questions about SRv6 mobile user-plane
a locator in some special cases? > > > > Yes, the SIR prefix is routable to forward to an ILA router. This is > necessary for the redirect mechanism I describe above. I suppose this could > be contorted to make the SIR address be a home address like in MobileIP and > locators are COAs (if my use of MobileIP terminology is correct). There also > might be nodes in the network, as well as external nodes that don't do go > through a cache to their packets need to hit an ILA router to get forwarded > to the location of mobile nodes. An upshot of that is that edge routers > might need to perform transformations (SIR to ILA) at high rates so the > mechanism needs to be very efficient and amenable to HW implementation. > > > > > > [Sri] This is precisely what I was thinking. > > > > I get that SIR prefix takes the packet awards the ILA domain and some ILA > router in the path can apply the mapping. I was thinking there may not be a > good reason to have more than one or two SIR prefixes for each ILA domain. > As long as the SIR prefix can take the packet from a non-ILA domain > (internet) to ILA domain, then the edge router can apply the mapping. But, > that also implies the edge routers will have to have too much of mapping > state. Now, if we have many SIR prefixes and associate a SIR prefix for each > PGW/UPF, that state can be distributed and keep the edge routers stateless, > but it also brings anchoring back into the picture. In one simplest mode, as > you say, HNP (home network prefix) can be a SIR and the PGW/SGW or > (LMA/MAG) can do the translation of SIR - ILA, without the need for > tunneling. > > > > So, in your mind how many SIR prefixes will be used in a typical T1 operator > domain? Also, how can we quantify the state that ILA introduces in different > parts of the network? > > > > > > Regards > > Sri > > > > > > > > > > > > > > > > From: dmm on behalf of Tom Herbert > > Date: Friday, January 26, 2018 at 9:13 AM > To: "dmm@ietf.org" , "i...@ietf.org" > Subject: [DMM] Questions about SRv6 mobile user-plane > > > > Hello, > > > > I am working on a comparison between ILA and SRv6 for the mobile user-plane. > I have some questions/comments about SRv6 and particularly on the example > use cases that were depicted in the slides that were presented in IETF100: > > > > https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/ > > > > - It's clear from the depicted use cases that extension header insertion is > being done by intermediate nodes, but extension header insertion is > currently prohibited by RFC8200. There was an I-D posted on 6man to allow > this for SR, but that was met with pushback. Is there going to be followup > to resolve this? > > > > - For the uplink use cases, this seems to be more like using SR to source > route to an egress router. In other words, it's not strictly related to > mobility. Is there some connection to mobility that I'm missing? > > > > - The size or number of SR headers in the uplink cases seems to be larger > than necessary (IMO minimizing these is important since each additional sid > is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and > DA=A2::1-- this seems to be redundant information. Also this depicts a > second SR being inserted, but the first one should no longer be relevant. > Why not just discard the first one and save the overhead? In the second > scenario, DA is changing from A2::1 to A3::1, but AFAICT that was not done > per the SR processing. What is the operation that happened here? (it's > actaully looks like an ILA transfomation). > > > > - Considering the points above, could this have been done in the following > manner to minimize overhead? A1 creates one SRH with one sid and makes > DA=A2. A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet > address, and EH is removed. > > > > - For downlink this does see to be relevant to mobility. But I have the same > question, wouldn't it be less overhead to only use one SRH and one sid? i.e. > A3 creates an SRH with just one sid that is the S:: (identifier in > identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 > restores original packet for delivery. > > > > - One possible typo. In the last use case slide SA=S:: and DA=D::, I believe > these should be swapped? > > > > Thanks, > > 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] Questions about SRv6 mobile user-plane
Hi Sri, My comments are inline. > https://tools.ietf.org/html/draft-herbert-ila-motivation-00 provides some > comparisons between ILA and ILNP, encapsulations, SR, and transport layer > mechanisms that can achieve some effects in mobility. > > The choice of mapping system is critical. The mapping of identifier, or > equivalently virtual to physical address mapping, seems to be a common > problem in mobility and networking virtualization. As you mentioned, LISP > defines a query method to populate a mapping cache. I assume this problem > needs to be tackled in SR for mobile user-plane but I'm not sure what > solution is preferred after reading the draft. > > [Sri] There are multiple approaches on how we manage this mapping state. > Obviously, ILA is one approach, but there are few other approaches as well > that we need to review. It's a good discussion to have. > ILA partitions the problem into a two level hierarchy: ILA routers and IL > forwarding nodes. This is somewhat analogous to core IP routers and nodes > running neighbor discovery. ILA routers contain all the (possibly sharded) > mappings. They are authoritative. Forwarding nodes are located close to user > devices and maintain a working set cache of entries driven by user activity. > If a packet doesn't hit the cache it's forwarded to a router that will do the > ILA transformation. If the cache is hit, the packet can be transformed at the > forwarding node to eliminate triangular routing. Caches can be populated by > pull or push models. ILAMP (the ILA mapping protocol) supports both of these, > but my current preference for scalability and mitigating DOS attacks on the > cache is to use secure redirects sent by ILA routers (analogous to ICMP > redirects). > > > [Sri] When I last reviewed the ILA I-D, I do not seem to remember reading > about the cache state, ILMP. or about how the mapping gets to the ILA > routers. Looks like the spec is evolving as we speak. With ILAMP type control > protocol for cache management, I see more similarities to LISP. > > We separate data plane from the control plane. The ILA draft describes the data plane, other drafts (ILAMP, BGP/ILA, ILA in the datacenter) describe control plane aspects. We'll post a draft shortly with details specific to the mobile user plane. There are similarities to LISP, but also differences. > > > >> On a different note, just curious if SID prefix can ever have topological >> relevance and can be used for routing. In other words, can you ever route a >> packet without translating the SIR prefix of the destination address with >> the locator? Can SID prefix be used as a locator in some special cases? > > > Yes, the SIR prefix is routable to forward to an ILA router. This is > necessary for the redirect mechanism I describe above. I suppose this could > be contorted to make the SIR address be a home address like in MobileIP and > locators are COAs (if my use of MobileIP terminology is correct). There also > might be nodes in the network, as well as external nodes that don't do go > through a cache to their packets need to hit an ILA router to get forwarded > to the location of mobile nodes. An upshot of that is that edge routers might > need to perform transformations (SIR to ILA) at high rates so the mechanism > needs to be very efficient and amenable to HW implementation. > > > [Sri] This is precisely what I was thinking. > > I get that SIR prefix takes the packet awards the ILA domain and some ILA > router in the path can apply the mapping. I was thinking there may not be a > good reason to have more than one or two SIR prefixes for each ILA domain. As > long as the SIR prefix can take the packet from a non-ILA domain (internet) > to ILA domain, then the edge router can apply the mapping. But, that also > implies the edge routers will have to have too much of mapping state. Now, if > we have many SIR prefixes and associate a SIR prefix for each PGW/UPF, that > state can be distributed and keep the edge routers stateless, but it also > brings anchoring back into the picture. In one simplest mode, as you say, HNP > (home network prefix) can be a SIR and the PGW/SGW or (LMA/MAG) can do the > translation of SIR - ILA, without the need for tunneling. > > So, in your mind how many SIR prefixes will be used in a typical T1 operator > domain? One SIR prefix is the simplest way. This allows 64 bit identifier lookups instead of 128 bit. Also, there's no ambiguity in ILA to SIR address translation since all locators may back to the same SIR. However, there's nothing in the architecture that prevents multiple SIR addresses as long as the mapping from ILA to SIR address is unambiguous. Non local address identifiers do this. > Also, how can we quantify the state that ILA introduces in different parts of > the network? Please look at topology of section 2 in https://tools.ietf.org/html/draft-herbert-ila-ilamp-00. ILA routers collectively contain t
Re: [DMM] Questions about SRv6 mobile user-plane
On Sun, Jan 28, 2018 at 10:29 PM, Satoru Matsushima wrote: > Hello Tom, > > To make the overhead discussion quantitative and realistic, I’ve made a > spreadsheet of user-plane total overhead comparison by deployment scenarios. > > https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qR > S5ok2IO1i0VZbmwzZJNVh0g/edit?usp=sharing > > This includes not only for mobility, but also range of possible cases of > real deployment in operators to fulfill isolation, quality and reliability > requirements for mobile networks. Some of them seem most likely cases, but > others sound extreme. But I’d like to share all those scenarios to make us > aware of them when it comes to packet overhead in real deployments. > > The total overhead length of the scenarios which exceed 2x SIDs (58) and > 4x SIDs (90) cases are highlighted with red color to the number and the > cell respectively in the sheet. Please take a look at it. The sheet looks a > bit busy but you may find some interesting points, or errors. Any comments > and corrections from all of you are really welcome. > Hi Satoru, Thank you for the spreadsheet. A few points: - I don't understand why there aren't use cases list for SR/IPv6 over MPLS or L3VPN. Could you explain that? It seems to me that SR doesn't replace that those, and they might be complementary. - I'm missing something on how the overhead is being calculated. For instance, in deployment scenario #1 headers are 14 (ethhdr) + 40 (IPv6) + 4 (EH hdr) + 4 (SRH) + 2 * 16 (2 sids) = 94. I think you might not be including the original IPv6 header, so this shouldn't this be 54 bytes? Similarly, it seems like ILA over Ethernet should be 14 bytes. - You may want include scenarios for SR that include the overhead of encapsulation that would be needed to avoid extension header insertion. I assume this would just be IP/IP encapsulation, but as I said previously the inner destination address can serve as the final segment so that might eliminate one sid. - Not all overhead is equal cost. The effects on protocol and processing should be considered. For instance, unlike L3 encapsulations layer 2 encaspulations shouldn't affect MTU at L3. It's a bit difficult to quantify processing overhead, but generally the number of table lookups and number of calculations over packet data (like a checksum) are a good measure. Simple push/pop of headers isn't usually too bad if the headers are constant. Tom Best regards, > --satoru > > > > 2018/01/27 2:13、Tom Herbert のメール: > > > > Hello, > > > > I am working on a comparison between ILA and SRv6 for the mobile > user-plane. I have some questions/comments about SRv6 and particularly on > the example use cases that were depicted in the slides that were presented > in IETF100: > > > > https://datatracker.ietf.org/meeting/100/materials/slides-10 > 0-dmm-srv6-for-mobile-user-plane/ > > > > - It's clear from the depicted use cases that extension header insertion > is being done by intermediate nodes, but extension header insertion is > currently prohibited by RFC8200. There was an I-D posted on 6man to allow > this for SR, but that was met with pushback. Is there going to be followup > to resolve this? > > > > - For the uplink use cases, this seems to be more like using SR to > source route to an egress router. In other words, it's not strictly related > to mobility. Is there some connection to mobility that I'm missing? > > > > - The size or number of SR headers in the uplink cases seems to be > larger than necessary (IMO minimizing these is important since each > additional sid is ~1% overhead of standard MTU). In this first scenario > sid[1]=A2::1 and DA=A2::1-- this seems to be redundant information. Also > this depicts a second SR being inserted, but the first one should no longer > be relevant. Why not just discard the first one and save the overhead? In > the second scenario, DA is changing from A2::1 to A3::1, but AFAICT that > was not done per the SR processing. What is the operation that happened > here? (it's actaully looks like an ILA transfomation). > > > > - Considering the points above, could this have been done in the > following manner to minimize overhead? A1 creates one SRH with one sid and > makes DA=A2. A2 makes DA=A3. At A3 SR is processed, DA is restored to > Internet address, and EH is removed. > > > > - For downlink this does see to be relevant to mobility. But I have the > same question, wouldn't it be less overhead to only use one SRH and one > sid? i.e. A3 creates an SRH with just one sid that is the S:: (identifier > in identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, > A1 restores origin
Re: [DMM] Questions about SRv6 mobile user-plane
On Fri, Jan 26, 2018 at 5:35 PM, Sri Gundavelli (sgundave) < sgund...@cisco.com> wrote: > Hi Tom, > > > I am working on a comparison between ILA and SRv6 for the mobile > user-plane. > > This is a good effort. I was wondering, about the key parameters that you > will use for this comparison between ILA/ILNP/LISP/HICN etc. For example, > ILA router the entries at the ILA router ( ID – L OC - SIR Prefix), vs at > the LISP mapping system. How do you compare the two, a cache/MAP query > cost, vs a translation cost + local memory state for keeping that entry. > > Sri, https://tools.ietf.org/html/draft-herbert-ila-motivation-00 provides some comparisons between ILA and ILNP, encapsulations, SR, and transport layer mechanisms that can achieve some effects in mobility. The choice of mapping system is critical. The mapping of identifier, or equivalently virtual to physical address mapping, seems to be a common problem in mobility and networking virtualization. As you mentioned, LISP defines a query method to populate a mapping cache. I assume this problem needs to be tackled in SR for mobile user-plane but I'm not sure what solution is preferred after reading the draft. ILA partitions the problem into a two level hierarchy: ILA routers and IL forwarding nodes. This is somewhat analogous to core IP routers and nodes running neighbor discovery. ILA routers contain all the (possibly sharded) mappings. They are authoritative. Forwarding nodes are located close to user devices and maintain a working set cache of entries driven by user activity. If a packet doesn't hit the cache it's forwarded to a router that will do the ILA transformation. If the cache is hit, the packet can be transformed at the forwarding node to eliminate triangular routing. Caches can be populated by pull or push models. ILAMP (the ILA mapping protocol) supports both of these, but my current preference for scalability and mitigating DOS attacks on the cache is to use secure redirects sent by ILA routers (analogous to ICMP redirects). > On a different note, just curious if SID prefix can ever have topological > relevance and can be used for routing. In other words, can you ever route a > packet without translating the SIR prefix of the destination address with > the locator? Can SID prefix be used as a locator in some special cases? > Yes, the SIR prefix is routable to forward to an ILA router. This is necessary for the redirect mechanism I describe above. I suppose this could be contorted to make the SIR address be a home address like in MobileIP and locators are COAs (if my use of MobileIP terminology is correct). There also might be nodes in the network, as well as external nodes that don't do go through a cache to their packets need to hit an ILA router to get forwarded to the location of mobile nodes. An upshot of that is that edge routers might need to perform transformations (SIR to ILA) at high rates so the mechanism needs to be very efficient and amenable to HW implementation. Tom > Sri > > > > > > From: dmm on behalf of Tom Herbert < > t...@quantonium.net> > Date: Friday, January 26, 2018 at 9:13 AM > To: "dmm@ietf.org" , "i...@ietf.org" > Subject: [DMM] Questions about SRv6 mobile user-plane > > Hello, > > I am working on a comparison between ILA and SRv6 for the mobile > user-plane. I have some questions/comments about SRv6 and particularly on > the example use cases that were depicted in the slides that were presented > in IETF100: > > https://datatracker.ietf.org/meeting/100/materials/slides- > 100-dmm-srv6-for-mobile-user-plane/ > > - It's clear from the depicted use cases that extension header insertion > is being done by intermediate nodes, but extension header insertion is > currently prohibited by RFC8200. There was an I-D posted on 6man to allow > this for SR, but that was met with pushback. Is there going to be followup > to resolve this? > > - For the uplink use cases, this seems to be more like using SR to source > route to an egress router. In other words, it's not strictly related to > mobility. Is there some connection to mobility that I'm missing? > > - The size or number of SR headers in the uplink cases seems to be larger > than necessary (IMO minimizing these is important since each additional sid > is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and > DA=A2::1-- this seems to be redundant information. Also this depicts a > second SR being inserted, but the first one should no longer be relevant. > Why not just discard the first one and save the overhead? In the second > scenario, DA is changing from A2::1 to A3::1 > <https://maps.google.com/?q=A3::1&entry=gmail&source=g>, but AFAICT that > was not done per the SR processing
Re: [DMM] [Ila] Questions about SRv6 mobile user-plane
On Fri, Jan 26, 2018 at 11:59 AM, Uma Chunduri wrote: > Comments are spot-on. > > > > Can somebody tell 8200 update would be a possibility in future (w.r.t 6man > consensus) i.e., EH insertion in the middle without re-encapsulating the > SRH again. > > I presume the technical aspect for the 8200 mandate is the ability to > fragment if needed at the insertion point. Anything else? Please > enlighten.. > > > Uma, There were several issues raised. I don't think fragmentation actually came up as one of them, but that is good point. Intermediate nodes cannot fragment packets in IPv6. Interestingly, the subject of fragmentation came up yesterday on the 5gangIP list. There are providers that see fragmentation happening because of GTP. Not all networks have converted to us jumbo frames to preserve a 1500 MTU to end nodes and do encapsulation-- increasing packet size in intermediate nodes is still a problem. Here is a summary of issues that were raised on 6man: - The proposal attempted to carve out an exception to RFC8200 for just SR and limited use to controlled domains. That entails many caveats an assumptions that would need to be MUSTs. - Encapsulation is recommended to allow EH insertion and several people asked why not use it. It will work inasmuch as encapsulation within the network already works. - If a host is already using extension headers and the network tries to add more, there is an ambiguity about which ones the.network is responsible for. When packet leaves the domain, the EH that the network added needs to be removed and it needs to be unambiguous which ones are to be removed. - ICMP is a problem. If a host gets an ICMP error that contains extension headers that it did not possibly send then that will be confused. Presumably, ICMP errors will need to be stripped of EH before forwarding to a source node. - PTB is interesting. For instance, EH insertion could force PMTU to drop below 576 minimum. - If the added extension headers are causing packet drops this is a major problem. The intermediate node that is inserting the EHs will never get feedback that its actions are doing harm. An end host might detect packet loss at the transport layer or might get an ICMP error (maybe something like draft-herbert-6man-icmp-limits-02 <https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-02>), But, even if it knows that inserted EHs are causing drops, there's is no action a host can take to stop it. At least with encapsulation the tunnel ingress might get and ICMP error about what it's doing. I suppose the primary argument against encapsulation is that it's too much overhead. But, I would point out that in the examples if only one sid is required for mobility (address of destination) in an IP/IP encapsulation this would be the destination of the inner packet and SRH wouldn't be needed. So encapsulation overhead = 40 bytes, SRH overhead = 20 bytes. I'm not sure that difference justifies the complexity of EH insertion. Tom Hence, most significant issue has to be resolved perhaps would be the first > item. > > > > > > BR, > > -- > > Uma C. > > > > *From:* ila [mailto:ila-boun...@ietf.org] *On Behalf Of *Tom Herbert > *Sent:* Friday, January 26, 2018 9:14 AM > *To:* dmm@ietf.org; i...@ietf.org > *Subject:* [Ila] Questions about SRv6 mobile user-plane > > > > Hello, > > > > I am working on a comparison between ILA and SRv6 for the mobile > user-plane. I have some questions/comments about SRv6 and particularly on > the example use cases that were depicted in the slides that were presented > in IETF100: > > > > https://datatracker.ietf.org/meeting/100/materials/slides- > 100-dmm-srv6-for-mobile-user-plane/ > > > > - It's clear from the depicted use cases that extension header insertion > is being done by intermediate nodes, but extension header insertion is > currently prohibited by RFC8200. There was an I-D posted on 6man to allow > this for SR, but that was met with pushback. Is there going to be followup > to resolve this? > > > > - For the uplink use cases, this seems to be more like using SR to source > route to an egress router. In other words, it's not strictly related to > mobility. Is there some connection to mobility that I'm missing? > > > > - The size or number of SR headers in the uplink cases seems to be larger > than necessary (IMO minimizing these is important since each additional sid > is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and > DA=A2::1-- this seems to be redundant information. Also this depicts a > second SR being inserted, but the first one should no longer be relevant. > Why not just discard the first one and save the overhead? In the second > scenario, DA is changing from A2::
[DMM] Questions about SRv6 mobile user-plane
Hello, I am working on a comparison between ILA and SRv6 for the mobile user-plane. I have some questions/comments about SRv6 and particularly on the example use cases that were depicted in the slides that were presented in IETF100: https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/ - It's clear from the depicted use cases that extension header insertion is being done by intermediate nodes, but extension header insertion is currently prohibited by RFC8200. There was an I-D posted on 6man to allow this for SR, but that was met with pushback. Is there going to be followup to resolve this? - For the uplink use cases, this seems to be more like using SR to source route to an egress router. In other words, it's not strictly related to mobility. Is there some connection to mobility that I'm missing? - The size or number of SR headers in the uplink cases seems to be larger than necessary (IMO minimizing these is important since each additional sid is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and DA=A2::1-- this seems to be redundant information. Also this depicts a second SR being inserted, but the first one should no longer be relevant. Why not just discard the first one and save the overhead? In the second scenario, DA is changing from A2::1 to A3::1, but AFAICT that was not done per the SR processing. What is the operation that happened here? (it's actaully looks like an ILA transfomation). - Considering the points above, could this have been done in the following manner to minimize overhead? A1 creates one SRH with one sid and makes DA=A2. A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet address, and EH is removed. - For downlink this does see to be relevant to mobility. But I have the same question, wouldn't it be less overhead to only use one SRH and one sid? i.e. A3 creates an SRH with just one sid that is the S:: (identifier in identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 restores original packet for delivery. - One possible typo. In the last use case slide SA=S:: and DA=D::, I believe these should be swapped? Thanks, Tom ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] Fwd: New Version Notification for draft-herbert-fast-00.txt
Hello, This might be of interest to DMM group. The basic idea of FAST (Firewall and Service Tickets) is to allow applications to signal to the network the services they want for their flows. The granted services are expressed in "tickets" that an application sets in packet of of a flow (destination or nexthop options EH). Tickets are interpreted by the ingress node of the network and services are applied (QoS, diffserv, map to network slice, encapsulation, etc.). Tickets are reflected by peers to get services applied in the reverse direction. They are also stateless and in fact a goal of FAST is to reduce flow state in the network. Tom -- Forwarded message -- From: Date: Thu, Jan 11, 2018 at 11:46 AM Subject: New Version Notification for draft-herbert-fast-00.txt To: Tom Herbert A new version of I-D, draft-herbert-fast-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-fast Revision: 00 Title: Firewall and Service Tickets Document date: 2018-01-11 Group: Individual Submission Pages: 21 URL:https://www.ietf.org/internet-drafts/draft-herbert-fast-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-fast/ Htmlized: https://tools.ietf.org/html/draft-herbert-fast-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-fast-00 Abstract: This document describes the Firewalls and Service Tickets protocol. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network service to be applied. Applications request tickets from a local agent in the network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to a packets. A single ticket may provide both firewall and service ticket information. Tickets are sent in either IPv6 Destination options or Hop-by-Hop options. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] Fwd: New Non-WG Mailing List: ILA- Identifier Locator Addressing
Hello, We'll be discussing ILA on this list and its use cases in mobility, datacenter virtualization, and networking virtualization. ILA might be relevant in DMM as a mobility protocol that doesn't rely on encapsulation. Please join the list if you're interested! Tom -- Forwarded message -- From: IETF Secretariat Date: Wed, Jan 17, 2018 at 2:57 PM Subject: New Non-WG Mailing List: ILA- Identifier Locator Addressing To: IETF Announcement List Cc: kalyani.bogin...@verizonwireless.com, t...@quantonium.net, sur...@kaloom.com, i...@ietf.org A new IETF non-working group email list has been created. List address: i...@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=ila To subscribe: https://www.ietf.org/mailman/listinfo/ila Purpose: This mailing list is for discussion about Identifier Locator Addressing (ILA) and the possibility of forming a working group around this topic. For additional information, please contact the list administrators. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
