Subject: [16ng] Interim meeting hasty notes for first day

From: gabriel montenegro <[email-masked]>
Date: Tue, 12 Sep 2006 09:23:15 -0700 (PDT)

In the interest of letting people know what we were up to in the first day of the meeting, here are my hasty notes. These are not the official interim meeting minutes, which will come later, but just an attempt at keeping folks in the loop.

-gabriel

Steigenberger Hotel, Mannheim
   
  AGENDA
   
  Sep 12, Tuesday
   
  1000 - 1030      Coffee break & socializing 1030 - 1230      Opening session Welcome host       and chairs Max provided        welcome and overview of our host (Siemens Communications, to be merged        with other companies like Nokia)18billion         Euro revenue60k         employees160         countriesThanks to        Siemens and MaxAgenda bashing       chairs WG status and       milestone review chairs Some revised        text in the milestones and charterLook at notes        in presentationInformative       reports WiMAX IPv6        activities - Jin Hyeok ChoiLed by Raj,         to run ND (2461/62) over SiMAXSec. 5.11         for stage 3 documentASN and ASN         GW = subnet and routerIn v4: ASN          GW is L2 fwding, in v6 not clear yetNo         mcast/bcast (but MBS might add some stuff here)No direct         comm between MSsR6         (BS-ASNGW) on GRE (per MS at least)Through BSGRE tunnel802.16           transport connectionLink def?All         
 connections a a single link (shared prefix)Needs           relay DADPer -MS          prefix:Like 3gppP2p MS-           ASN GWOn-link           comm & mcast trivial (DAD is easy)Per MS RAASN GW to           aggregate to avoid routing table explosionHow to           handle mobility Link is            conceptual, so even if it moves it could remain on same linkVery            similar to GGSN in 3GPPNo clear         winnerSoliciting         input from service provider (SPWG)To decide in         september16ng input         very valuableMyungki -         why is wimax deciding on any subnet model?Jonne -         seems useful to make behavior predictable for interoperability reasons,         error reporting, etcMax: both         would work if BS/ASNGW is in one boxIf in two          boxes, then should specify what happens at the BS, for exampleNWS only          defines R6, not internal behaviorIETF should          provide feedback on how feasible the shared model is.We know the   
       p-p link model is workable (3GPP)Q from Jin         Hyeok: should we follow wimax model in IETF?Jonne: would         not make sense to ignore them or to try to re-design wimaxGab: the         current milestones reflect a current focus, but we're not limited to         that so we could take on, say, mesh in the futureJari: we do         need to make sure our solutions are general enough for future         applicabilityJH: will         IPv6 CS only follow wimax model?Jari: not         sure, but wimax are the main customer, yes, so it should work with         their modelMax: you're         asking for L3 VPN, L2 is what eth CS with VLANs is doing.Public          access has led to L2 VPN Not          following the Wimax model still leaves us with requirements for a VPN          model for carriers, albeit at L3IPv6       deployment scenario v6ops document review - Myungki Shin Extends        v6ops-bb-deployment-scenarios for broadband802.16 can be        applied in many
 scenarios and architecturesWhy here in        16ng interimSubnet model         discussionLooking for         collaboration/cooperation16ng review         requested statusOfficial          v6ops in March 200601          published in septWG LC end          of the year3 scenariosMobile         access depl scenario3GPP-like         deployment (rfc 3314)Fixed/nomadic         depl scenarioImpacts        identifiedIPv6         infratructure changesAddressingIPv6 control         and data transportroutingEtcMulticast,        mobility, etcMax: comment        on L3 awarenessin wimax         model the BS is becoming L3 unaware cuz classification is done in the         ASN GWBut .16         model the BS is L3 awareJari: what is        DAD optimization? Something new?A: in shared        prefix model, yes, something like relay DADDaniel: yes,        but this is only on nw side, not on host sideMax: your        document mixes models3rd model is         really many models, so should split
 these up into the basic models or         subsetsEach subset         with different optimizationsIn eth CS         case we're trying to address all (single MS, prefix delegation for         hosts behind an MS, etc)Q: is nw        behind an MS in 16ng?Max: not, but        there are implications Brian        Carpenter asked in the light of iab-link-encaps how roaming will work        when moving from one CS to anotherMax: wimax        also needs to solve this problemEvery access         nw provides the basic IP CS (v4 now)802.16 says         nothing about what the MUST implement isLink-encaps         does not apply here as wimax only has one way to do encaps at a given         point in timeIf payload          is eth, use eth csIf payload          is IP, use IP csThere's a         very easy way for ETH deployment to provide IP CSMax to send         this short text outText to be          added to 16ng docsJari: good,        the IETF does need this to be solvedDanielNeed to    
     agree on terminology with DT documentNeed to         avoid duplication of content with DT documentMaxYes we need         common terminologyAlso need         normative description of scenariosJari:But it seems         wrong to describe scenarios that don't reflect real deploymentsScenario         consolidation is a good idea.   
  1230 - 1330      Lunch 1330 - 1530      Technical session I Data       forwarding mechanism within ASN (with service flow and GRE tunnel) - Max       RiegelMust        accommodate IPv4 in which many MS may use the same address spaceTunnels over        the air identified by CID - conn identifierAssigned to a        GRE connection (GRE key) for forwarding over R6 (BS to ASN GW) In 802.16        there are 3 control plane CIDs different from data plane CIDs (above)Primary Secondary -         schedulingMgmt - snmpConv        sublayersClassifications         (11 in 16e)Classification         done using L3 informationWimax         prefers classification to be done in ASN GW to avoid BS complexityMultiple CS        types in a BSMgmt/control         is common and agnostic of CS typeNo CS for         PPP, but PPPoE might be a way:GP CS could          help by removing need for classification at the BSBRAS could          map diffserv to eth service, but no current specification of
 BRAS to          ASN GW interface (for release 1.5)R6: BS to ASN        GW in a routed ASNGRE for both         ETH and IP CSGRE keys          are eitherPer flow           (per CID) - must be done for R4 (inter ASM)Per MS, in           which case the BS must do the final classification if a given MS has           more than one CIDBridged         ASN(R6) is for further studyData plane         encapIP* CS: IP          over GREIP*oETH CS:          IP over ETH over GREETH CS: ETH          over GRELink modelIPv4: GRE         tunnels go into a bridge (switch model) sitting before the ASN GWIPv6: GRE         tunnels go directly into the ASN GW (no bridge)Uses relay          DAD and authoritative address cacheIPv6oETH CSExtend          bridge with relay DAD and authoritative address cacheMax to          document a concern of Jari's about optimizations introducedsynchronicity           of state in the IPv6 caseAre there            any holes? Can the            address cache really
 be authoritative?How to            re-establish state if something is lost?Are we           opening new DoS attacks from the internet (triggering lots of ND           traffic, for example)IPv6 subnet       model design team report - Daniel on behalf of SyamAnalyze        subnet modelsMake a        recommendationNBMA link        model (shared prefix)Relay DADOne prefix         (or more)P-P link        model (unique prefix model)How to         support this?PPP does          not existPerhaps to           be removedPer MS GRE          connection - preferredVLAN tag          802.1q may not be sufficient (only 4K)Not the           right technology for this problem (limiting a VLAN to a single host           is not the expected use of VLANs)Mcast capable        link model (ethernet-like model)Supports         full mcast with bridgingBS filters         multicast to not deliver unwanted packets to MSs not part of a groupShould we         rename it the IEEE 802 segment model?All
 models        support autoconf and DHCPv6DADNbmaRelay DADAddress          cachep-p DAD         required for link local addressesMcast         capableAs per 2462Stds - all        reuse themOn-link mcastNbma via         proxyingp-p only 2         nodesEthernet         fineConsistency        of IP modelPkt        forwardingNbma: bridge         local pkts, route external onesDormant modeEthernet-like:         BS must implement filtering or better, should be handled to reduce the         effectJonne: but         this is an L2 issue, not something 16ng needs to sayMax: but         this trouble is caused by IP behavior by assuming mcast or bcast does         not costJari: fair         enough, but another equally dubious assumption is that these packets         are not needed and one can elide themHost        implementations: no changes we hope (error conditions in the cache may        change this)Router        implementationsNbma - relay         DAD and address cache (may not be
 complete due to pkt loss, etc)p-p: unique         prefix assignment, as usualMcast         capable: bridging is requiredRenumberingp-p more         signaling than nbma?Jonne and          Jari: not soOne RA per          hostSeNDAll models         support thisApplicabilityMobile wimax         and wibro: IP CSFixed and         nomadic: ETH CS  1530 - 1600      Coffee break 1600 - 1800      Technical session II IPv6 solution       discussion - I IPv6 shared        prefix model over IPv6CS - Jin Hyeock ChoiIssue with         no link-scope mcastNo globally         unique link-level addr in .16 frameHost's only         on-link neighbor is its ARExploit         wimax featuresOmniscient          AR - knows all IPv6 addresses in use on a linkISF initial          service flowHost to AR           via BS connectionISF can be           used for RS/RA or NS/NAYes, even            with unspecified src addrSolutionL bit off,          A-bit potentially onOnly the AR          is a neighbor
 to an MSNo direct          MS to MS communicationASN GW is          omniscient ARMAC          transport conn = .16 on + GREISF is          state between MS and ASN GW so RS can elicit the appropriate RA going          to the correct MSGRE key          used as the replacement for a MAC addressNon-standard           extension to 802.16, which does not include a GRE key as one of the           parameters used for classificationAddr resol          and NUD only done between MS and GWSkip in           the future?Jari: not           the conclusion in 3GPP meetings, cuz reachability is a two-way thing,           don't eliminate NUD, but you can use payload packets to elide itDAD is          performed using relay DADRelay DADGW has addr          cache Learns from          DAD NSMS helps to          build cache with NUDMS sends NS          using ISFGW makes a          record and drops it if no matchIf match,          the GW relays NS to addr owner, owner responds, GW forwards to MS,
 MS          processes as usualissuesQ: the           addr cache may grow without limit, no mechanism to reduce or clean           the cache, whereas in per-MN prefix there is no such growing quantityIn per-MS           prefix model, there is a detachment procedure (or timeout) which           cleans the cache of prefixes. Moving an           MS from one BS to another is *NOT* a detachment procedure, as the           link is still activeWhy this         model? A: to save address space, but not neededEach          carrier gets a /32 (today's internet) and can get othersEach user          gets a /48Jonne:          "Each /64 prefix is like an addr in IPv4"This is          being done for 3G, HSDPA, etcJonne:This we          looked into for 3GPP, and back in 2001 we saw issues with address          cache managementPer-MS          Prefix management is much simplerRfc 3314          still holdsAddress          space is not an issueOperators          are fine with per-prefixIPv6
 unique        prefix model over IPv6CS - Jonne Soininen presenting the draft by frank        xia, behcet and rajVirtual link         vs physical linkID, prefix,          CID, etcPrefix         assignmentFast router          discovery via unsolicited RASolicited          RAPeriodic RANDBusiness as          usual for NS/NA/RS/RA, autoconfDAD: use          optiDAD (rfc4429) cuz low possibility of duplicationDormant modeLimited #          of nodesIssuesPrefix mgmt          - dhcp relay           in AR, or simplest,           table in AR with prefixesRoute flip          upon mobilityRoute           aggregation of /64's under a /48 so no issue visible outsideEnough          prefixesAnalysis           in sec 2.3.1 of rfc 3314Ex: about           80,000 prefixes per person on earth todayConclusionsPer-MS          model fits naturally to p-p linksDHCP can be          managed using DHCPEnough          prefixes (no address depletion currently foreseen)No impact          to host
 stacksAll others          (DSL, 3GPP, etc) assigning prefixes, not IP addresses to MSSo why           make Wimax worse?One can          ship now with pre-MS prefix and if there is any issue in the future          with prefix space depletion, then one can always specify shared subnet          model in the futureSome       additional discussion on multiple PDP contexts in 3GPPNo equivalent        in wimaxComplicates        user interface tremendously, a nightmareJari and        Jonne: might have happened because of a misunderstanding on the part of        3GPP about how IP works  1900 - 2200      Social