Re: [DMM] Questions about SRv6 mobile user-plane

[Tom Herbert]

On Tue, Jan 30, 2018 at 8:34 AM, Arashmid Akhavain
<arashmid.akhav...@huawei.com> 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 prefi

Re: [DMM] Questions about SRv6 mobile user-plane

[Arashmid Akhavain]

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 <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of Tom 
Herbert <t...@quantonium.net<mailto:t...@quantonium.net>>

Re: [DMM] Questions about SRv6 mobile user-plane

[Tom Herbert]

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 

Re: [DMM] Questions about SRv6 mobile user-plane

[Tom Herbert]

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 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
>
>

Re: [DMM] Questions about SRv6 mobile user-plane

[Sri Gundavelli (sgundave)]

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 <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of Tom 
Herbert <t...@quantonium.net<mailto:t...@quantonium.net>>
Date: Friday, January 26, 2018 at 9:13 AM
To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto: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 heade

Re: [DMM] Questions about SRv6 mobile user-plane

[Satoru Matsushima]

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-qRS5ok2IO1i0VZbmwzZJNVh0g/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.

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-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

[Miya Kohno]

Hi Tom,

Thank you, first of all, for your interest!

Yes, SID list can be reduced in some cases. I agree it should be restricted
to the minimum necessary.

I think ILA and SRv6 share a common view, while SRv6 allows more flexible
functions.

Regarding RFC8200, attacks can be and should be prevented in another way.
If under agreement, header insertion, which could make network more
efficient, should be allowed.

I hope ILA and SRv6 converge.

Miya@a co-author of SRv6 mobile data plane

On Sat, Jan 27, 2018 at 2:13 AM, Tom Herbert  wrote:

> 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

[Tom Herbert]

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 <dmm-boun...@ietf.org> on behalf of Tom Herbert <
> t...@quantonium.net>
> Date: Friday, January 26, 2018 at 9:13 AM
> To: "dmm@ietf.org" <dmm@ietf.org>, "i...@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=gmail=g>, but AFAICT that
> was not done per the SR 

Re: [DMM] Questions about SRv6 mobile user-plane

[Sri Gundavelli (sgundave)]

Typo's ... SID -> SIR


From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of Sri 
Gundavelli <sgund...@cisco.com<mailto:sgund...@cisco.com>>
Date: Friday, January 26, 2018 at 5:35 PM
To: Tom Herbert <t...@quantonium.net<mailto:t...@quantonium.net>>, 
"dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>
Subject: Re: [DMM] Questions about SRv6 mobile user-plane

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.

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?

Sri





From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of Tom 
Herbert <t...@quantonium.net<mailto:t...@quantonium.net>>
Date: Friday, January 26, 2018 at 9:13 AM
To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto: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

Re: [DMM] Questions about SRv6 mobile user-plane

[Sri Gundavelli (sgundave)]

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.

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?

Sri





From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of Tom 
Herbert <t...@quantonium.net<mailto:t...@quantonium.net>>
Date: Friday, January 26, 2018 at 9:13 AM
To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto: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

Re: [DMM] Questions about SRv6 mobile user-plane

[Sri Gundavelli (sgundave)]

Hi Tom:

Marco and myself are planning to publish another proposal on anchor-less 
mobility (leveraging SRv6). That may be of interest to you from ILA point of 
view. We will post the draft in one or two weeks.


Regards
Sri






From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of Tom 
Herbert <t...@quantonium.net<mailto:t...@quantonium.net>>
Date: Friday, January 26, 2018 at 9:13 AM
To: "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto: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] Questions about SRv6 mobile user-plane

[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-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