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

Hence, most significant issue has to be resolved perhaps would be the first 
item.


BR,
--
Uma C.

From: ila [mailto:[email protected]] On Behalf Of Tom Herbert
Sent: Friday, January 26, 2018 9:14 AM
To: [email protected]; [email protected]
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::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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to