Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

s necessary and that the functionality can't be acheived with existing API. I would suggest that you post patches for this to Linux netdev to get feedback from the developer community. Tom > > Regards, > Danny > > > > -Original Message- > From: Tom Herbert [mailto:t...@qua

Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

nfo)) < 0) { if (errno == EADDRNOTAVAIL) { // Didn't get address for requested type } ... } // To get address local address that was selected... getsockname(s, , ); > Thanks, > Danny > > -Original Message- > From: Tom Herbert [mailto:t...@quantonium.ne

Re: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-17.txt

Out of curiosity, why is the new API being portrayed as a system call (setsc) instead of a socket option (the bar for adding a socket option is much lower ). Tom On Fri, Feb 22, 2019 at 6:19 AM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >

Re: [DMM] [Pidloc] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt

On Tue, Jan 29, 2019 at 12:13 PM Templin (US), Fred L wrote: > > Hi Tom, > > > -Original Message----- > > From: Tom Herbert [mailto:t...@quantonium.net] > > Sent: Tuesday, January 29, 2019 11:25 AM > > To: Templin (US), Fred L > > Cc: Vikram Siwach

Re: [DMM] [Pidloc] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt

On Tue, Jan 29, 2019 at 10:25 AM Templin (US), Fred L wrote: > > Hi Tom, > > > -Original Message- > > From: Pidloc [mailto:pidloc-boun...@ietf.org] On Behalf Of Tom Herbert > > Sent: Tuesday, January 29, 2019 9:36 AM > > To: Templin (US), Fred L > &

Re: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt

s along these lines? Tom > Thanks - Fred > > > -Original Message- > > From: Tom Herbert [mailto:t...@quantonium.net] > > Sent: Tuesday, January 29, 2019 8:33 AM > > To: Templin (US), Fred L > > Cc: dmm ; pid...@ietf.org; Vikram Siwach > > Subjec

Re: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt

ions. Tom > Fred > > > -Original Message- > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > > Sent: Monday, January 28, 2019 3:36 PM > > To: dmm ; pid...@ietf.org > > Cc: Vikram Siwach > > Subject: [DMM] Fwd: New Version Notifica

[DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt

version of I-D, draft-herbert-intarea-ams-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-intarea-ams Revision: 00 Title: Address Mapping System Document date: 2019-01-28 Group: Individual Submission

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

same. It allows user traffic to be mapped to >>>> what the operator provides. >>>> I agree with you that network should not touch/change original >>>> header bits. GTP or any other encapsulation easily allow for this. >>>> The question is whether we can provide for

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

ke this secure ans stateless, how to limit scope of sensitive information, how to deal with paths that block HBH options. Please take a look at the FAST draft https://tools.ietf.org/html/draft-herbert-fast and white paper https://github.com/quantonium/papers/blob/master/FAST.pdf Tom > > Arashmid

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

unch of complex flow state, FAST arranges that the remote server reflects the bits in response packets. Tom > > > >> -Original Message- >> From: Tom Herbert [mailto:t...@quantonium.net] >> Sent: 07 September 2018 11:13 >> To: Arashmid Akhavain >> Cc:

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain wrote: > > >> -Original Message- >> From: Dino Farinacci [mailto:farina...@gmail.com] >> Sent: 06 September 2018 18:59 >> To: Arashmid Akhavain >> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp; &g

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

t risk! Such problems can be fix with precise accounting and transparency on services and service plans. Tom > Let alone if the operator can deliver the service (in this > net-neutrality-less era). > > Dino > >> On Sep 6, 2018, at 3:15 PM, Tom Herbert wrote: >>

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

ewall and Service Tickets is being proposed as one such mechanism to solve this (see https://tools.ietf.org/html/draft-herbert-fast). Tom > Arashmid > > >> -Original Message- >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci >> Sent: 06 Septem

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

dress encoding is critical to ILA and is what can eliminate the overhead of encapsulation for a fast, low latency, data path. Tom > marco > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: Donnerstag, 6. September 2018 18

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya wrote: > > > On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert wrote: >> >> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran >> wrote: >> > My comments inline marked [SB] >> > >> >> > >&g

Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran wrote: > My comments inline marked [SB] > >> > >>> It was never clear to me and no one could ever explain exactly why a >> > >>> TEID is needed. I presumed for accounting reasons. But if there was a >> > >>> one-to-one mapping between tunnel and

Re: [DMM] Fwd: New Version Notification for draft-hmm-dmm-5g-uplane-analysis-01.txt

Hi Shunsuke, Thanks for the draft! It does a very good job of describing and framing GTP-U using IETF terminology. This should help significantly to bridge that gap of understanding between IETF and 3GPP. Some comments: General comment: Please look at "Encapsulation Considerations"

Re: [DMM] Comment on SRv6-mobile-userplane

> 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

Re: [DMM] Comment on SRv6-mobile-userplane

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)" ,

Re: [DMM] Comment on SRv6-mobile-userplane

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

Re: [DMM] 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

Re: [DMM] Comment on SRv6-mobile-userplane

flow, this can wreak havoc in deployments that maintain state in the network of need consistent hashing for load balancing. Discussion on this issue occasionally pops up on 6man list. Tom > Cheers, > Pablo. > > On 18/07/2018, 10:37, "Tom Herbert" wrote: > > One cav

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

Re: [DMM] [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt

ate new attacks and that will have cost. It's a never ending problem, but it's worth it to continually try to solve IMHO. Tom > On Tue, Jul 3, 2018 at 5:14 PM, Tom Herbert wrote: >> On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft >> wrote: >>> what we need is compact onion

Re: [DMM] [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt

On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft wrote: > what we need is compact onion routing - maybe we could call it garlic routing. > > in all seriousness, if people are worried about privacy with regards > network operators, or state actors co-ercing network operators, at > this level, that

[DMM] Fwd: New Version Notification for draft-herbert-idloc-fast-00.txt

of the transport layer so it works with any transport protocol and doesn't require any transport state to be maintained in the network. Tom -- Forwarded message -- From: Date: Tue, Jun 26, 2018 at 10:04 AM Subject: New Version Notification for draft-herbert-idloc-fast-00.txt To: Tom Herbert

Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

being. > > The fact that MPTCP encounters difficulties to be fully integrated in a > specific OS component is an implementation issue > that belongs to that particular component. The consequence of that might be > that multiple culturally different implementations > and deployment o

Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

might be opportunities to improve communications by some coordinated interaction with the network (like we propose in FAST), but these are strictly optimization and not requirements to make basic communications work. Tom > > Luca > > > > On Wed, Jun 20, 2018 at 5:13 PM Tom Herbert

Re: [DMM] [Int-area] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

proach to the other, rather exploiting in >> the combination the advantages of both ones. >> >> >> Giovanna >> >> >> From: Int-area on behalf of Behcet Sarikaya >> >> Sent: Wednesday, June 20, 2018 4:18 PM >> To: Lu

Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

rrect? If it is, then I sort of understand how hICN could be used for mobility or virtualization without network overlays, but then I'm completely lost as to why this would require any changes in the transport layer. Tom > IMO, the answers are no for both. > > Luca > > On Tue, Jun

Re: [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

On Tue, Jun 19, 2018 at 2:46 AM, Luca Muscariello wrote: > Hi all, > > the draft below has been posted and describes deployments options for > anchorless mobility management by using > the hicn network architecture that implements icn semantics in IPv6 > networks. > >

Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 7:30 PM, Sri Gundavelli (sgundave) wrote: > Hi Tom, > > I realize there have been some discussions, but I think its time to reopen > those discussion in 6MAN or wherever and find a way-forward. There is a > strong use-case now for such capability. I am

Re: [DMM] IETF101 DMM WG Meeting Notes #1

ing extension headers when encapsulating is okay since the encapsulator is the source of the outer packet. The problems with EH insertion were enumerated in the discussion on 6man list. Tom > Arashmid > > > > > > -Original Message- > From: dmm [mailto:dmm-boun...@

Re: [DMM] IETF101 DMM WG Meeting Notes #1

> > Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming > device, what protocol are they going to use? > > > > > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: 27 March 2018 10:03 > To:

Re: [DMM] IETF101 DMM WG Meeting Notes #1

day one even in closed systems. Tom > > But the best course still would be to have this documented clearly and if > possible do an update to RFC8200 @ 6man as pointed below by Tom. > > -- > Uma C. > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Be

Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) <sgund...@cisco.com> wrote: > > > On 3/26/18, 5:16 PM, "Tom Herbert" <t...@quantonium.net> wrote: > >>> With regards to SR encapsulation: "this is using IP-in-IP as default. >>> Wh

Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00

> The difference is that the endpoints agree on what the addresses are for a flow. In NAT this does not happen so there is a descrepancy, in ILA there is always agreement. In this way ILA transformations are a method to make transparent network overlays. Tom > > Sri > > > > > On

Re: [DMM] IETF101 DMM WG Meeting Notes #1

lticast and those should be the part of criteria. >> IMO as you suggested, overhead size, performance, TE, extensibility and >> encryption would be good idea for the criteria in addition to the above >> fundamental ones. >> >> Best regards, >> --satoru >> >

Re: [DMM] IETF101 DMM WG Meeting Notes #1

cryption would be good idea for the criteria in addition to the above > fundamental ones. > > Best regards, > --satoru > > > >> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール: >> >> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima >> <s

Re: [DMM] IETF101 DMM WG Meeting Notes #1

nnel) then I believe GUE is a good alternative for that case to provide necessary functionality and extensibility. Tom >> 2018/03/27 9:16、Tom Herbert <t...@quantonium.net>のメール: >> >> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave) >> <sgund...@cisco.com

Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave) wrote: > FYI. This is the notes that Carlos captured. Thank you Carlos!! > > We are also waiting for Lyle to share his notes. Please review and > comment, if you see any mistakes. > With regards to SR encapsulation:

Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00

dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli >>(sgundave) >>Sent: Dienstag, 20. März 2018 12:40 >>To: Tom Herbert; Lyle Bertz >>Cc: dmm >>Subject: Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00 >> >>But, in any case, NAT is not such a bad w

Re: [DMM] draft-bogineni-dmm-optimized-mobile-user-plane-00

On Tue, Mar 20, 2018 at 3:57 AM, Lyle Bertz wrote: > We'll be quite time constrained during this session so I thought I would ask > a couple of simple questions which I hope have already been addressed in > previous e-mails: > > 1. Figures 14 & 15 are described as options

Re: [DMM] some test results of different network overlay methods

en just SR header is present. Capabilities for things like this will vary between NICs. Tom > Thanks. > > > > Cheers, > > Pablo. > > -- > *De:*Tom Herbert <t...@quantonium.net> > *Enviado:*viernes, 16 de marzo de 2018 7:58 p. m. &

Re: [DMM] some test results of different network overlay methods

On Fri, Mar 16, 2018 at 12:40 PM, Uma Chunduri wrote: > Great work, Thank you Kalyani & Tom. > > 2 quick questions: > > 1. I presume SR inline is just SRH with 2 SIDs as mentioned - didn't see the > topology used. Do intermediate nodes handle these SIDs, with pointer

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

al Message- >>> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] >>> Sent: Mittwoch, 7. März 2018 12:23 >>> To: Marco Liebsch >>> Cc: dmm >>> Subject: Re: [DMM] Fwd: I-D Action: >>> draft-ietf-dmm-srv6-mobile-uplane-01.txt >>&

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

On Wed, Mar 7, 2018 at 10:13 AM, Pablo Camarillo (pcamaril) 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

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

On Tue, Mar 6, 2018 at 11:29 AM, Pablo Camarillo (pcamaril) wrote: > Tom, > > > > Re: your comment on EH insertion. > > > > This point is not applicable; a new version of srv6-mobile-uplane > (https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-01) is > > published

Re: [DMM] SRv6 for Mobile User-Plane

lo's comment was that this should be allowed in controlled domains. Tom > Arashmid > > > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: 26 February 2018 15:24 > To: Pablo Camarillo (pcamaril) <pcama...@cisco.com> &

Re: [DMM] SRv6 for Mobile User-Plane

even in a controlled domain. Even if the argument is that EH insertion will only ever be done in a controlled domain, these issues still need to be addressed I think. Tom > I think Pablo’s proposition make sense. Thoughts ? > > dan > > > On 2018-02-26, 3:24 PM, "Tom Herbert&qu

Re: [DMM] SRv6 for Mobile User-Plane

On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril) wrote: > Hello authors, DMM, > > > > I have reviewed your I-D on SRv6 for mobile user-plane and I would like to > make some proposals. I have already discussed and brainstormed the details > with some of the authors

Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

On Fri, Feb 9, 2018 at 12:09 AM, Alexandre Petrescu < alexandre.petre...@gmail.com> wrote: > > > Le 07/02/2018 à 18:29, Tom Herbert a écrit : > >> >> >> On Wed, Feb 7, 2018 at 8:49 AM, Alexandre Petrescu < >> alexandre.petre...@gmail.com &l

Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

On Wed, Feb 7, 2018 at 8:49 AM, Alexandre Petrescu < alexandre.petre...@gmail.com> wrote: > > > Le 06/02/2018 à 05:52, Lorenzo Colitti a écrit : > >> On Fri, Feb 2, 2018 at 6:27 AM, Tom Herbert <t...@quantonium.net > t...@quantonium.net>> wrote: >> >

Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

to each ILA-N. When a node attaches to an ILA-N, an index is chosen so that the table is populated at the ILA-N and the ILA mapping includes the locator and index. When a node detaches from on ILA, it's entry in the table is removed and the index can be reused after a holddown period to purge stale m

Re: [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

On Mon, Feb 5, 2018 at 10:16 PM, Lorenzo Colitti <lore...@google.com> wrote: > On Tue, Feb 6, 2018 at 3:02 PM, Tom Herbert <t...@quantonium.net> wrote: > >> On Tue, Feb 6, 2018 at 2:17 PM, Tom Herbert <t...@quantonium.net> wrote: >>> >>>> Section

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

Hi Uma, > [Uma]: SRH in the proposal not only put a sort of mobility solution (encoded > in the SID) but also use to guide the packet through non shortest path from > the source as needed and as listed in the SRH. > It would be nice to have a concrete example of how this would be used and how SR

Re: [DMM] [Ila] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

On Thu, Feb 1, 2018 at 4:38 PM, Sri Gundavelli (sgundave) wrote: >> One thing to add. LISP has a more mature control-plane mapping system. >>ILA has a recent proposal for its control-plane. > > Mobility architectures started with a unified CP/UP approach, then the > industry

[DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

Thank you, Tom -- Forwarded message -- From: <internet-dra...@ietf.org> Date: Thu, Feb 1, 2018 at 10:09 AM Subject: New Version Notification for draft-herbert-ila-mobile-00.txt To: Tom Herbert <t...@quantonium.net>, Kalyani Bogineni <kalyani.bogin...@verizon.com>

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

ome 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

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

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

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

ecksum) 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 <t...@quantonium.net>のメール: > > > > Hello, > > > > I am working on a comparison bet

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

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

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

ot 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:ila-boun...@ietf.org] *On Be

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

[DMM] Fwd: New Version Notification for draft-herbert-fast-00.txt

act a goal of FAST is to reduce flow state in the network. Tom -- Forwarded message -- From: <internet-dra...@ietf.org> Date: Thu, Jan 11, 2018 at 11:46 AM Subject: New Version Notification for draft-herbert-fast-00.txt To: Tom Herbert <t...@quantonium.net> A new

[DMM] Fwd: New Non-WG Mailing List: ILA- Identifier Locator Addressing

Hello, We'll be discussing ILA on this list and its use cases in mobility, datacenter virtualization, and networking virtualization. ILA might be relevant in DMM as a mobility protocol that doesn't rely on encapsulation. Please join the list if you're interested! Tom -- Forwarded