> PC2: Let me try to give you an analogy. A external packet arrives to an ILA
> network. The original IPv6 DA is translated as per ILA. What is the packet?
> Is it an IP packet or is it an ILA packet? To me this is an ILA packet,
> because if the source and destination UPFs are not ILA capable the
Tom, inline. [PC2]
Thanks,
Pablo.
On 18/07/2018, 18:57, "Tom Herbert" wrote:
>
>In summary if you could address:
>
>
>
>1. Section 5.1 Traditional mode (Tom’s comment on terminology and
>IP-in-IP with no relation to SR?)
>
>
>
On Wed, Jul 18, 2018 at 1:44 PM, Pablo Camarillo (pcamaril)
wrote:
> Uma,
>
>
>
> Inline. [PC1]
>
> (Thanks for the clear list of points to address. It does help.)
>
>
>
> Cheers,
>
> Pablo.
>
>
>
> From: Uma Chunduri
> Date: Wednesday, 18 July 2018 at 12:52
> To: "Pablo Camarillo (pcamaril)" ,
Uma,
Inline. [PC1]
(Thanks for the clear list of points to address. It does help.)
Cheers,
Pablo.
From: Uma Chunduri
Date: Wednesday, 18 July 2018 at 12:52
To: "Pablo Camarillo (pcamaril)" , Arashmid Akhavain
Cc: "dmm@ietf.org" , "Alberto Rodriguez Natal (natal)"
, "spr...@ietf.org"
Hi Uma,
You wrote:
“However, if this is seen as GTP replacement option, by moving TEID of the GTP
header encoded into each SRv6 SID, the unintended consequence is we are making
3GPP functionalities that are associated with TEID specific to one transport
underlay.”
[Arashmid] Let me try a more
On Wed, Jul 18, 2018 at 9:31 AM, Uma Chunduri wrote:
> Hi Arashmid,
>
>
>
>
>
>>>[Uma]: 2 quick and minor corrections for the above first.“we encode the
>>> TEID into a SID” è
>>> https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
>>> says “Note that in this mode the
Hi Pablo,
>As I already clarified in my previous email, the proposal of
>draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.
Great. Thanks.
>As I already said in my previous email, we will clarify this in the next
>revision of the draft.
Sure.
Btw, you responded to
Tom,
In-line [Uma]:
--
Uma C.
-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net]
Sent: Wednesday, July 18, 2018 12:12 PM
To: Uma Chunduri
Cc: Arashmid Akhavain ; Pablo Camarillo
(pcamaril) ; spr...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] Comment on SRv6-mobile
Hi Arashmid,
>>[Uma]: 2 quick and minor corrections for the above first.“we encode the TEID
>>into a SID” ==>
>>https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
>>says “Note that in this mode the TEID is embedded in each SID.”
>>(section 5.1.3 confirms this)
Uma,
As I already clarified in my previous email, the proposal of
draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.
>Only the head nodes know that TEID has been encoded into the SID. Tandem nodes
>treat the traffic as normal SRv6 traffic.
The proposal of the draft
Hi Uma,
Please see my replies inline [Arashmid]
Cheers,
Arashmid
From: Uma Chunduri
Sent: Wednesday, July 18, 2018 11:50 AM
To: Arashmid Akhavain ; Pablo Camarillo
(pcamaril)
Cc: dmm@ietf.org; Alberto Rodriguez Natal (natal) ;
spr...@ietf.org
Subject: RE: Comment on SRv6-mobile-userplane
On Wed, Jul 18, 2018 at 8:56 AM, Uma Chunduri wrote:
> Tom,
>
> >I think the terminology being used in the draft might be making this
> seem complicated than it actually is. AFAICT, SRv6 traditional mode is
> nothing more than IP in IP encapsulation, so the requirement of the underlay
On Wed, Jul 18, 2018 at 8:44 AM, Pablo Camarillo (pcamaril)
wrote:
> Tom,
>
> Isn't the IPv6 flow label designed exactly to avoid that?
Yes, that is supposed to handle ECMP. There are might be other
optimizations of packets for UDP and TCP that could be lost in IP/IP
encapsulation.
> Are you
Tom,
>I think the terminology being used in the draft might be making this
seem complicated than it actually is. AFAICT, SRv6 traditional mode is nothing
more than IP in IP encapsulation, so the requirement of the underlay is that it
>forwards IPv6 and intermediate
Arash,
In-line [Uma]:
--
Uma C.
From: Arashmid Akhavain
Sent: Wednesday, July 18, 2018 9:18 AM
Hi Uma,
I am not sure if I understand your concern. In traditional mode, we encode the
TEID into a SID. This is the mode that draft bogineni refers to as the simplest
form of using SRv6 for the
Tom,
Isn't the IPv6 flow label designed exactly to avoid that? Are you suggesting to
use UDP to avoid using the flow label?
Cheers,
Pablo.
On 18/07/2018, 10:37, "Tom Herbert" wrote:
One caveat to that is that some
intermediate nodes may want to do DPI into transport layer to get
To: Arashmid Akhavain
Cc: Uma Chunduri ; Pablo Camarillo (pcamaril)
; spr...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] Comment on SRv6-mobile-userplane
On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain
wrote:
> Hi Uma,
>
>
>
> I am not sure if I understand your concern. In tradi
On Wed, Jul 18, 2018 at 6:18 AM, Arashmid Akhavain
wrote:
> Hi Uma,
>
>
>
> I am not sure if I understand your concern. In traditional mode, we encode
> the TEID into a SID. This is the mode that draft bogineni refers to as the
> simplest form of using SRv6 for the N9 interface.
>
> Only the head
Hi Uma,
I am not sure if I understand your concern. In traditional mode, we encode the
TEID into a SID. This is the mode that draft bogineni refers to as the simplest
form of using SRv6 for the N9 interface.
Only the head nodes know that TEID has been encoded into the SID. Tandem nodes
treat
[Added Spring too, as one of the chairs, Bruno asked us to discuss]
Hi Pablo,
Please see in in-line [Uma]:
--
Uma C.
From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri
Cc: dmm@ietf.org; Arashmid Akhavain ; Alberto
Rodriguez
20 matches
Mail list logo
