Re: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt
Jouni <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
On Jul 13, 2013, at 8:20 PM, Satoru Matsushima wrote: > Hi Pete, > > Thanks for your comments. > > On 2013/07/14, at 0:49, Peter McCann <[email protected]> wrote: > >> Hi, Ryuji, Satoru, >> >> If I understand your draft correctly, you are encoding the PGW ID and the >> TEID into the prefix portion of an IPv6 address. You seem to allocate >> 16 bits for the TEID. I thought that TEIDs in 3GPP were 32 bits. Do you >> have enough space? Could you instead encode the TEID in the Interface >> Identifier part of the IPv6 address? > > Oops. Yes, you are correct. I'll update it soon. > Using TEID is one of the candidates of generating unique MN's prefix as described in stateless-pd draft. > (http://tools.ietf.org/html/draft-savolainen-stateless-pd-01) > > Full of 32bits space is not necessary because embedded ID could be shortened by taking a part 16 bits or more longer from an TEID as long as its uniqueness is kept. We assume that the RAN side TEID assigned by SGW are encoded to MN's prefix. TEIDs do not have structure, thus I would be careful starting to take shorter subsets out of it. There is quite a bit of vendor specific information already encoded into TEIDs so the text need to be clear it does not assume anything about TEID or then state each deployment & prefix "structure" is deployment/vendor specific. - Jouni >> Perhaps I have misunderstood how the routing update is supposed to work, >> but why do you need to encode the UE's prefix or address at all in the >> Next-Hop IPv6 address? You have the UE's prefix as the Destination, and >> the Next-Hop can just point to the tunnel, correct? > > UE's prefix is not encoded in the next-hop. The next-hop indicates tunnel endpoint in the way of BGP remote next-hop draft. Please see "http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-03" > > cheers, > --satoru > >> >> -Pete >> >> Ryuji Wakikawa wrote: >>> Hi >>> >>> We submit a new document. Your comments are appreciated! >>> >>> thanks, >>> ryuji >>> >>> >>> Begin forwarded message: >>> >>>> From: [email protected] >>>> Subject: New Version Notification for >>>> draft-matsushima-stateless-uplane-vepc-00.txt >>>> Date: July 10, 2013 9:09:44 AM PDT >>>> To: Ryuji Wakikawa <[email protected]>, Satoru Matsushima >>>> <[email protected]> >>>> >>>> >>>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt has >>>> been successfully submitted by Satoru Matsushima and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-matsushima-stateless-uplane-vepc Revision: 00 >>>> Title: Stateless user-plane architecture for virtualized EPC (vEPC) >>>> Creation date: 2013-07-10 Group: Individual Submission Number of >>>> pages: 19 URL: http://www.ietf.org/internet-drafts/draft- >>>> matsushima-stateless-uplane-vepc-00.txt Status: >>>> http://datatracker.ietf.org/doc/draft-matsushima- stateless-uplane-vepc >>>> Htmlized: http://tools.ietf.org/html/draft-matsushima- >>>> stateless-uplane-vepc-00 >>>> >>>> >>>> Abstract: >>>> We envision a new mobile architecture for the future Evolved Packet >>>> Core (EPC). The new architecture is designed to support the >>>> virtualization scheme called NFV (Network Function Virtualization). >>>> In our architecture, the user plane of EPC is decoupled from the >>>> control-plane and uses routing information to forward packets of >>>> mobile nodes. Although the EPC control plane will run on hypervisor, >>>> our proposal does not modify the signaling of the EPC control plane. >>>> The benefits of our architecture are 1) scalability, 2) flexibility >>>> and 3) Manageability. How to run the EPC control plane on NFV is out >>>> of our focus in this document. >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmm >> >> >> >> _______________________________________________ >> dmm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm