[DMM] FPC - Topology
All, I've put together a quick assessment on Topology (proposed for new draft and v09). We'll briefly review it today as time permits. Lyle This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. FPC Working Session - Topology.pptx Description: FPC Working Session - Topology.pptx ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Questions about SRv6 mobile user-plane
Hi Tom and Sri, One of the possible options is perhaps to use something along the line of what public clouds or OTT folks provide/use. A form of DHT (with some wild carding capability) can perhaps fit the bill. We ran some tests with Google and Azure Pub/Sub and got about 120ms response time. These public cloud services though and as such are designed for moving large amount of data around and therefore need to do some buffering to be efficient. A custom version of these types of database and messaging for ID-LOC mapping distribution could perhaps be much faster. Arashmid From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: 29 January 2018 10:26 To: dmm@ietf.org Subject: Re: [DMM] Questions about SRv6 mobile user-plane HI Tom, Thanks for your response. Please see 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. 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. 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? Also, how can we quantify the state that ILA introduces in different parts of the network? Regards Sri From: dmm mailto:dmm-boun...@ietf.org>> on behalf of Tom Herbert mailto:t...@quantonium.net>> Date: Friday, January 26, 2018 at 9:13 AM To: "dmm@ietf.org
Re: [DMM] FPC - Topology
Hello Lyle, I have comments on the slides, and could benefit from larger discussion on the mailing list. On slide 3, the presentation indicates three Indexed Sets -- DPNs, Domains, and Interface Groups. Reference to entities of those three entity types is made available by Keys into the relevant Indexed Set. An Interface, on the other hand, is not shown as referenced by a Key into an Indexed Set. All of the relevant Interface information is directly exhibited as attributes and sub-attributes of a DPN. I think this is a consistent and somewhat understandable way of organizing the entities and attributes in our Information Model. On slide 4, there is the following: Missing – protocol & settings required for selection Should Reside in Group? I think it is more natural for the protocols and settings for an Interface to be shown as attributes for that Interface. The Interface Group enables access to the list of Interfaces on the DPN. So, selection of a DPN might proceed as follows: - For each DPN, look at its Interface Groups = For each Interface Group, look at the protocols and settings that are supported. If this isn't efficient, then we should reorganize the model. Continuing to slide 5, there are three questions, which are relevant to this. * How are Interfaces specifically mapped to a Group (DPN with 2 interfaces but only 1 is part of Group)? Right now the Interface is a part of the DPN definition, and the Interface Group was thought to be a way of collecting the information about what kinds of interfaces are available. That is O.K. as far as having the ability to partition the Interfaces of a DPN into non-overlapping Groups, but there is no reverse structure for getting the Interface details from the Interface Group. If the latter is needed, then we should modify the definition of the Interface Group appropriately. We might put an Interface-Key as an attribute of the Interface-Group, but the Interface Group is in an Indexed Set and the Interface-Key as currently (as an L-Key) defined only makes sense within the context of a DPN. Perhaps we first need to know the structure of the DPN-selection Algorithm to know how best to organize Interfaces in the Information Model. * * What about Interfaces NOT in a group? What do we do with those settings? In the current DPN definition, this is not a problem... right? * * Relation be Roles & Interfaces is unclear For a DPN to serve a particular role, it needs to have certain types of Interfaces. A substantial part of the "type" of an interface is determined by the set of Protocols that the Interface supports. Besides that, the Interfaces will have certain Settings that further define their usefulness. Slide 6 encodes a great deal of information, some of which depends on an understanding of DDDS. Maybe it is appropriate to include within the FPC document an appendix recounting the salient details of DDDS, with some emphasis on the DDDS view of Interface Groups and DPN selection. If you are willing, I might suggest a reorganization of the graph as follows: - Move "Protocols" up vertically quite a bit - Move "Features" to fit between "Protocols" and "Interfaces" Then both instances of the "Features" block could be coalesced, and maintain their pointers to "Selection Relevant" and "Other" Somehow, the idea of a Selection Relevant "Setting" feature is easier to grasp than a Selection Relevant "Protocol" feature. But I understand that many protocols have so many features that one has to be careful to ensure interoperability even between two conformant implementations of the same Protocol. Can't boil the ocean here and so we just have to accept that. Regarding slide 7: - (1) is agreeable to me. Let's try it. - For (2), we could certainly allow a DPN to have more than one role. However, for sanity, I hope we can make it so that the roles are independent. Suppose a DPN could be either a MAG or an LMA. Now let's say that it is chosen to be a MAG. Is it further disqualified from being an LMA at the same time? - (3) - I would be in favor of collapsing Features and Settings. Regards, Charlie P. On 1/30/2018 6:58 AM, Bertz, Lyle T [CTO] wrote: All, I’ve put together a quick assessment on Topology (proposed for new draft and v09). We’ll briefly review it today as time permits. Lyle This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ___ 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/d
Re: [DMM] Questions about SRv6 mobile user-plane
On Tue, Jan 30, 2018 at 8:34 AM, Arashmid Akhavain wrote: > Hi Tom and Sri, > > > > One of the possible options is perhaps to use something along the line of > what public clouds or OTT folks provide/use. > Hi Arashmid, That's a good approach. There's been a lot of innovation over the past few years so that using a key-value store as routing protocol is now feasible. The Open/R project from Facebook applies KV-STORE with modifications to get features of link-state protocols. (https://code.facebook.com/posts/1142111519143652/introducing-open-r-a-new-modular-routing-platform/) > A form of DHT (with some wild carding capability) can perhaps fit the bill. > We ran some tests with Google and Azure Pub/Sub and got about 120ms response > time. These public cloud services though and as such are designed for moving > large amount of data around and therefore need to do some buffering to be > efficient. A custom version of these types of database and messaging for > ID-LOC mapping distribution could perhaps be much faster. > I like DHT for its database lookup properties which would work very well with nodes that are populating mapping caches. One consideration is that for scaling to really large networks we assume that there are both forwarding nodes that maintain a mapping cache (ILA-Ns), and nodes that have a full set of mappings (ILA-Rs). Internet edge routers for a big network would likely want to be ILA-Rs. The mapping database is sharded among ILA-Rs. A shard is identified by some bits in the identifier part of the address. If these are the high order bits of the identifier then routing packets to the right shard is simple prefix routing. So, if a SIR prefix were 2000::/64 and 16 bits are used for a shard index, then a route of 2000:0:0:0:2::/80 routes packets to a node that has the mapping for shard 2. The shard index has no other semantics and this can be DHT where the hash function simply returns the shard index from an address key. Queries by ILA-Ns then are done based on this hash (and hence shard). Tom > > > Arashmid > > > > > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli > (sgundave) > Sent: 29 January 2018 10:26 > To: dmm@ietf.org > Subject: Re: [DMM] Questions about SRv6 mobile user-plane > > > > HI Tom, > > > > Thanks for your response. Please see 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. > > > > > > > > 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. > > > > > > > > > > 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
Re: [DMM] FPC - Topology
Comments inline From: Charlie Perkins [mailto:charles.perk...@earthlink.net] Sent: Tuesday, January 30, 2018 12:20 PM To: Bertz, Lyle T [CTO] ; dmm@ietf.org Subject: Re: [DMM] FPC - Topology Hello Lyle, I have comments on the slides, and could benefit from larger discussion on the mailing list. On slide 3, the presentation indicates three Indexed Sets -- DPNs, Domains, and Interface Groups. Reference to entities of those three entity types is made available by Keys into the relevant Indexed Set. An Interface, on the other hand, is not shown as referenced by a Key into an Indexed Set. All of the relevant Interface information is directly exhibited as attributes and sub-attributes of a DPN. I think this is a consistent and somewhat understandable way of organizing the entities and attributes in our Information Model. On slide 4, there is the following: Missing - protocol & settings required for selection Should Reside in Group? I think it is more natural for the protocols and settings for an Interface to be shown as attributes for that Interface. The Interface Group enables access to the list of Interfaces on the DPN. So, selection of a DPN might proceed as follows: - For each DPN, look at its Interface Groups = For each Interface Group, look at the protocols and settings that are supported. If this isn't efficient, then we should reorganize the model. Continuing to slide 5, there are three questions, which are relevant to this. >> It requires a scan of all DPNs each time. In v09 we put the groups as a >> separate structure (peer of the DPN) so that all DPNs that could meet the >> Roles of a Group were sufficient. However, this did not help all cases. I >> have seen 3 cases: 1. A specific group was named in the selection (this is what DDS does as you need a domain to start the search). 2. A role was needed (this is the academic option as in I see it in specs but not in practice). It does exist as an internal selection mechanism, e.g. load balancing. However, this a special case where we can designate it as a collection of homogenous groups. In our model the driver may be that we are looking for any Role in the tenant. The takeaway is DPN selection starts with a named group in *current* standards and could be role based in customarily invisible methods. * How are Interfaces specifically mapped to a Group (DPN with 2 interfaces but only 1 is part of Group)? Right now the Interface is a part of the DPN definition, and the Interface Group was thought to be a way of collecting the information about what kinds of interfaces are available. That is O.K. as far as having the ability to partition the Interfaces of a DPN into non-overlapping Groups, but there is no reverse structure for getting the Interface details from the Interface Group. If the latter is needed, then we should modify the definition of the Interface Group appropriately. We might put an Interface-Key as an attribute of the Interface-Group, but the Interface Group is in an Indexed Set and the Interface-Key as currently (as an L-Key) defined only makes sense within the context of a DPN. >> An interface can appear in multiple groups. For example, if an operator >> used for peering with partners A & B we would see the same interface in a >> groups set aside for each partner. A reverse structure is needed though as >> this is used for load balancing or just trying to figure out if the group is >> suitable for the request. Perhaps we first need to know the structure of the DPN-selection Algorithm to know how best to organize Interfaces in the Information Model. >> We cannot specify a specific DPN selection model; rather an algorithm that >> selects candidates that can meet the request needs. There will always be >> other considerations such as network state, performance info from say an >> ALTO etc. that will drive the specific DPN selection. * * What about Interfaces NOT in a group? What do we do with those settings? In the current DPN definition, this is not a problem... right? >> It is not a problem for a DPN but it would only be used for internal >> selection. * * Relation be Roles & Interfaces is unclear For a DPN to serve a particular role, it needs to have certain types of Interfaces. A substantial part of the "type" of an interface is determined by the set of Protocols that the Interface supports. Besides that, the Interfaces will have certain Settings that further define their usefulness. Slide 6 encodes a great deal of information, some of which depends on an understanding of DDDS. Maybe it is appropriate to include within the FPC document an appendix recounting the salient details of DDDS, with some emphasis on the DDDS view of Interface Groups and DPN selection. If you are willing, I might suggest a reorganization of the graph as follows: - Move "Protocols" up vertically quite a bit - Move "Features" to fit betwee
