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

--===============6134256694651964867==
Content-Type: multipart/alternative; boundary="089e0820ed84eb54c70563b4358a"

--089e0820ed84eb54c70563b4358a
Content-Type: text/plain; charset="UTF-8"

On Fri, Jan 26, 2018 at 11:59 AM, Uma Chunduri <[email protected]>
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:[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
> <https://maps.google.com/?q=A3::1&entry=gmail&source=g>, 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
>
>
>
>
>
>
>
>
>

--089e0820ed84eb54c70563b4358a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jan 26, 2018 at 11:59 AM, Uma Chunduri <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email protected]" target=3D"_blank">uma.chunduri@hua=
wei.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">





<div lang=3D"EN-US">
<div class=3D"gmail-m_-8182187660000647781WordSection1">
<p class=3D"MsoNormal"><a name=3D"m_-8182187660000647781__MailEndCompose"><=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">Comments are spot-on.
<u></u><u></u></span></a></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)">Can somebody tell 8200 update would be a pos=
sibility in future (w.r.t 6man consensus) i.e., EH insertion in the middle =
without re-encapsulating the SRH again.
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)">I presume the technical aspect for the 8200 =
mandate is the ability to fragment if needed at the insertion point. Anythi=
ng else?=C2=A0 Please enlighten..<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)"><u></u>=C2=A0</span></p></div></div></blockq=
uote><div>Uma,</div><div><br></div><div>There were several issues raised. I=
 don&#39;t think fragmentation actually came up as one of them, but that is=
 good point. Intermediate nodes cannot fragment packets in IPv6. Interestin=
gly, the subject of fragmentation came up yesterday on the 5gangIP list. Th=
ere 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 no=
des and do encapsulation-- increasing packet size in intermediate nodes is =
still a problem.</div><div><br></div><div>Here is a summary of issues that =
were raised on 6man:</div><div><br></div><div>- The proposal attempted to c=
arve 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 MUS=
Ts.</div><div><br></div><div>- Encapsulation is recommended to allow EH ins=
ertion and several people asked why not use it. It will work inasmuch as en=
capsulation within the network already works.</div><div><br></div><div>- If=
 a host is already using extension headers and the network tries to add mor=
e, there is an ambiguity about which ones the.network is responsible for. W=
hen packet leaves the domain, the EH that the network added needs to be rem=
oved and it needs to be unambiguous which ones are to be removed.</div><div=
><br></div><div>- ICMP is a problem. If a host gets an ICMP error that cont=
ains extension headers that it did not possibly send then that will be conf=
used. Presumably, ICMP errors will need to be stripped of EH before forward=
ing to a source node.</div><div><br></div><div>- PTB is interesting. For in=
stance, EH insertion could force PMTU to drop below 576 minimum.</div><div>=
<br></div><div>- If the added extension headers are causing packet drops th=
is 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 dete=
ct packet loss at the transport layer or might get an ICMP error (maybe som=
ething like=C2=A0<span style=3D"color:rgb(0,0,0);font-size:13.3333px"> </sp=
an><a href=3D"https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-02=
" style=3D"font-size:13.3333px">draft-herbert-6man-icmp-limits-02</a>), But=
, even if it knows that inserted EHs are causing drops, there&#39;s is no a=
ction a host can take to stop it. At least with encapsulation the tunnel in=
gress might get and ICMP error about what it&#39;s doing.</div><div><br></d=
iv><div>I suppose the primary argument against encapsulation is that it&#39=
;s too much overhead. But, I would point out that in the examples if only o=
ne sid is required for mobility (address of destination)=C2=A0 in an IP/IP =
encapsulation this would be the destination of the inner packet and SRH wou=
ldn&#39;t be needed. So encapsulation overhead =3D 40 bytes, SRH overhead =
=3D 20 bytes. I&#39;m not sure that difference justifies the complexity of =
EH insertion.</div><div><br></div><div>Tom</div><div><br></div><div><br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div la=
ng=3D"EN-US"><div class=3D"gmail-m_-8182187660000647781WordSection1"><p cla=
ss=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sans-ser=
if;color:rgb(31,73,125)"><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)">Hence, most significant issue has to be reso=
lved perhaps would be the first item.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)">BR,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)">--</span><span style=3D"font-size:11pt;font-=
family:&quot;Freestyle Script&quot;;color:rgb(31,73,125)"><u></u><u></u></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)">Uma C.</span><span style=3D"font-size:11pt;f=
ont-family:&quot;Brush Script MT&quot;;color:rgb(31,73,125)"><u></u><u></u>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt;font-family:Calibri,sa=
ns-serif;color:rgb(31,73,125)"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11pt;font-family:Calibri=
,sans-serif">From:</span></b><span style=3D"font-size:11pt;font-family:Cali=
bri,sans-serif"> ila [mailto:<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>]
<b>On Behalf Of </b>Tom Herbert<br>
<b>Sent:</b> Friday, January 26, 2018 9:14 AM<br>
<b>To:</b> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</=
a>; <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br>
<b>Subject:</b> [Ila] Questions about SRv6 mobile user-plane<u></u><u></u><=
/span></p><div><div class=3D"gmail-h5">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<div>
<p class=3D"MsoNormal">Hello,<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">I am working on a comparison between ILA and SRv6 fo=
r the mobile user-plane. I have some questions/comments about SRv6 and part=
icularly on the example use cases that were depicted in the slides that wer=
e presented in IETF100:<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<p class=3D"MsoNormal"><a href=3D"https://datatracker.ietf.org/meeting/100/=
materials/slides-100-dmm-srv6-for-mobile-user-plane/" target=3D"_blank">htt=
ps://datatracker.ietf.org/<wbr>meeting/100/materials/slides-<wbr>100-dmm-sr=
v6-for-mobile-user-<wbr>plane/</a><u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">- It&#39;s clear from the depicted use cases that ex=
tension header insertion is being done by intermediate nodes, but extension=
 header insertion is currently prohibited by RFC8200. There was an I-D post=
ed on 6man to allow this for SR, but that
 was met with pushback. Is there going to be followup to resolve this?<u></=
u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">- For the uplink use cases, this seems to be more li=
ke using SR to source route to an egress router. In other words, it&#39;s n=
ot strictly related to mobility. Is there some connection to mobility that =
I&#39;m missing?<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">- The size or number of SR headers in the uplink cas=
es seems to be larger than necessary (IMO minimizing these is important sin=
ce each additional sid is ~1% overhead of standard MTU). In this first scen=
ario sid[1]=3DA2::1 and DA=3DA2::1-- this
 seems to be redundant information. Also this depicts a second SR being ins=
erted, 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 changin=
g from A2::1 to <a href=3D"https://maps.google.com/?q=3DA3::1&amp;entry=3Dg=
mail&amp;source=3Dg">A3::1</a>, but AFAICT
 that was not done per the SR processing. What is the operation that happen=
ed here? (it&#39;s actaully looks like an ILA transfomation).<u></u><u></u>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">- 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=3DA2. A2 makes DA=3DA3. At A3 SR is processed, DA is =
restored to Internet address, and EH is
 removed.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">- For downlink this does see to be relevant to mobil=
ity. But I have the same question, wouldn&#39;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 p=
acket for delivery.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">- One possible typo. In the last use case slide SA=
=3DS:: and DA=3DD::, I believe these should be swapped?<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Tom<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">=C2=A0<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br></div></div>

--089e0820ed84eb54c70563b4358a--


--===============6134256694651964867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

--===============6134256694651964867==--