On Wed, Mar 7, 2018 at 10:13 AM, Pablo Camarillo (pcamaril)
<pcama...@cisco.com> 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" 
> <dmm-boun...@ietf.org on behalf of satoru.matsush...@gmail.com> 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

Reply via email to