* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Manet Status Pages

Mobile Ad-hoc Networks (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 1997-Jun-12 —  

IETF-105 manet minutes

Session 2019-07-23 1710-1810: Notre Dame - manet chatroom


minutes-105-manet-00 minutes

          Stan Ratliff - chair
          Justin Dean  - co chair not here
          apology no agenda slide or notewell
          No Agenda items at all until a couple of days ago
          Start with discussion concerning multicast DLEP support
          Ronald in 't Velt also has slides
          proceed w/o ad
          Document status:
          multihop forwarding ext - published as RFC 8629
          - congrats
          Remaining documents mostly in last call
          - DLEP LID extension - updated id needed
          - pause ext - in RFC editor queue
          DLEP flow control, diff, traffic class
          - been in last call for sometime, should close out
          - adv toward pub on mailing list
          - one more round potentional comments
          Rick Taylor:
          - credit ext stuff, debate on authorship, dnap, resolved?
          Stan Ratliff:
          - it has been resolved
          - others nod in agreement
          notewell ietf in effect
          mass confusion on finding materials ???
          AD (Alvaro Retana) now present
          DLEP multicast discussion: Lou Berger
          - based on discussion w/ start with dave wiggins
          - open source on github implementation
          - came up with answer
          - rfc8175 authors opinion was wanted, didnt wait bias
          - same answers!
          - Dave point: strict reading of doc, doesnt support everything that is
          being presented
          - intent is there, for first two
          - last is not clear and beyond doc, but doesnt take change in proto to
          do it
          - might as well do in small doc
          Rick Taylor:
          DLEP (RFC 8175) needs an errata: points out incconsistency, two sections
          condtradict eachother
          Lou Berger:
          If we give doc clarification then we might as well do in one
          excerpts from 8175: interesting
          - behaviors clearly defined
          - some things need interpretation
          - where do you carry multicast address? just say logical dst, and can
          be treated as such
          - ip addresses carried in ip packets
          Rick Taylor:
          - DLEP lisp exists, dst is defined by its mac address
          - multicast mac
          - specific
          Lou Berger: expected that real multicast address is going to be carried?
          - intent can be read, but better to be explicit
          - qualifies as errata
          Alvaro Retana: errata out of order/misspelled things
          Lou Berger: end results
          - c is not errata, d IS
          - we do small doc that clarifies all these points and updatres 8175
          - not an Rfc 8175 bis document.
          Stan Ratliff: cant do it with word but with a sentence
          Lou Berger: we will end up here, might as well put it all in there for
          clarification and acts as update
          point 2:
          - modem needs/expects multicast address in DLEP Destination Up message
          - Dest Up *NOT* Dest Announce
          - in info text, but need to infer
          Rick Taylor: historical
          - Dest Announce came into the 8175 specification late
          - renamed and got missed in search and replace
          Stan's answer from email
          some offline dicussion
          - how does reciever id itself?
          - same conclusion:
                  - join dest announce
                  - leave dest down
          Rick Taylor may have pull req. to fix
          everyone agrees on dest announce
          do believe we need multicast address list
          when you update list
          - list that is complete list of all groups
          - like old soft state protos
          - will send complete understanding modem infer delta
          if you put in words may be obsfcated, its semantically its a join/leave
          and leave is a leave all
          is on slide
          dont know: if you send announce with small mac/ip and then mac/diff ip,
          does the modem
          - how do you retract?
          - add remove indicator on address already
          - not explicitly called out
          Lou: send one message that add/drop
          "I'm a listener, you request info with announce with ip address, sometime
          later with different ip that collides
          not clear that you can just send incremental ?"
          something we need to describe and need definition
          Since only mac in leave (Destination Down message), you do it on final
          leave when you have no more listeners
          how does a sender know there is multicast group out there with any
          - what are service params
          - spec is clear
          - talks about logic dest
          - dest up has dest address which is logical - in our case mulitcast mac
          - associated ip addresses
          - dest update for add/drop case
                  - right with flag (Rick)
          - dest down
                  - only when final listener leaves on far side
          - we think this was intent
          - questioned authors and it is indeed the intent
          - dest may be a broadcast address
          how do you know what endpoints are mutual?
          - want to know
          - on an rf channel that they move and cant get the packet
          - cant assume its a lan
          - just cant assume when someone joins they can hear you
          - ip addreess list unqualified
                  - add that it was multicast
                  - no reason that it can be first multi, then unicastr
                  - feels hacky
                  - changed for unintented semantic change
                  - stan: unelegant, not hack
                  - win for not changing encodings, but change in code
                  - most significant
          - assume, dest up/dest update concept clear, not specific
          - multicast address
          - that is what is in doc
          - it was assumed, now explicit
          - if we do that, need to be careful of dest up. Inclusion of list(s)
          of IP addresses for MCAST listeners could introduce ordering issues that
          we want to stay away from
          - Other alternative is to restrict to a single MCAST address per Dest
          Up/Dest Update
          - does not see
          - if we can id multi from uni
          - doesnt matter order
          - now if group has different sets of listeners is an issue
          - intentionally does not want to imply that you didnt get that info
          - which listeners were listening to which ip multicast address
          - persepective wrong?
          Rick: what?
          Lou: do you want to understand if this is a list of listeners for a
          specific MCAST address or who is the union of multicast
          Rick: former, needs clarifying
          Roman: may be very confused, never knows.
          Lou: on subnet level routers know who the listeners are in many routing
          Stu: one hop listeners
          Alvaro: similar
          - dlep routers, not behind them
          - translate joins
          - pid behavior
          - what happens when I get icmp join?
          - you have to go to router
          - doing it for dlep subnet
          - can I infer that the dst up/dst update may propgate to different grps
          of listeners based on group we are talking about
          - back 2 slides
          - trace on subnet
          - listeners: hey im listeners, magic happens to notify that there are
          listeners, that info propogates
          - goes to other radios/modems
          - they want to tell attached routers that there is a possible mac dst
          they can send to
          - that is this mechanism
          - when ip addres and mac address are avalible
          - does not send endpoints
          - everyone on network subbed
                  - how does a sender router knows someone is too far away to get
                  to everyone who is
          - focusing on multicast group and time
          - need to know arg both scale and privacy
          - number of nodes need to know
          - they dont need to know all multicast grps I am listening on
          - operating in single routing/op domain
          - privacy nothing different
          - scale - has different than on traditional lan
          - but you are not on traditional lan so protocols are making assumptions
          - need to accomodate
          - as sender how do you cope
          - cant see for multicast but can see unicast
          - seems like a problem
          - hidden terminal problem
          - propgate foward
          - privacy side step
          - single l2 domains
          - not propgating
          - side step inside single admin domain
          Ricks comment slide
          - Lou's takeaway
                  - when we say multicast we must include broadcast
          toying with extra tlv
          - Lou: not sure he cares
                  - there are uses
                  - not a fan of rps that are unaware of subnet level power
          - sat systems
          - network controller mode
                  - l2 super important box
          - vague notion trying to comm that from l2 that modem is special
                  - it has cap that arent on network
                  - for net control is obvious
                  - you are guarnteed connectivity downstream
          - capability of other nodes being shared
          - this becomes PAR, the higher level can inject info into lower level
          and provide dist. and disc. function
          - wasn't where we were going
          - leader in protocol
                  - pick node with lowest id
                  - problem: mesh radio, the guy with lowest might be in tunnel
                  - way to let radio know this is bad idea in this case
          - the root being suggestion modem that they can be leader
          - l3-l1 interactions
          - why not resource param?
          - complex meshes building trees
          - ask group: getting close on time
          - wants to hear other guy
          - we need to work on 4 topics
          - Rick/Stan wants to
          - Stan volenteers
          Ronald in 't Velt: inter-manet routing
          - DLEP, straying away from what wg was about
          - wants to work on connecting manets together
          - how to connect multi-manets?
          - internally can be using 1 more types of radios
          - form collation/federation of manets
          - exchange routing info
          - large scale disaster recovery
          - key question: exactly what pascal trying to get at
          - with raw and paw activity (bof material / sidemeeting)
          - really wants this
          - really cares
          - this is important
          - also agree
          - things move
          - gateway nodes
          - can run two or more manet rt protocols
          - flat
          - overlay
          - egp for manet
          - typically bgp, but not suit for this
          - need something new
          - literature has been explored but no implementations
          - most are sketchy on how to do it
          - is there interest to do this work?
          - start with problem statement
          - see what is out there
          - write protocol spec
          - straight to standard if we do this
          - enough stuff out there
          - wary of experimental rfcs
          - fine with this
          - but not in charter
          - I love your work BUT
          - you can tweak to do anything you want
          - before we start a new routing proto, lets see what we have
          - yes we need to recharter
          - incredibley happy
          - biggest attendance last 2 years
          - need to energy in room
          - like to see discussion in group in this direction
          - then as we get closer recharter
          - dont want to recharter before we see thrust
          - should of done on ml sooner
          - non-wg bof thrus morning
          - attempt to combine?
          - sidemeeting
          - think ideas are interesting
          - focused on ??? usecase
          - not general, service based
          - role for dlep and all these things togther
          - show up and listen, try to help
          - big question: where does that work end up?
          - new wg energy cool, but maybe hijack?
          - bof in singapor
          - listen and align to their interests?
          - comments/questions?
          - closing remarks

Generated from PyHt script /wg/manet/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -