* 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 —  
Chairs
 


IETF-105 manet minutes

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

Minutes

minutes-105-manet-00 minutes



          5:10
          welcome:
          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
          
          Stu:
          if you put in words may be obsfcated, its semantically its a join/leave
          and leave is a leave all
          
          Lou:
          is on slide
          
          Rick:
          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 ?"
          
          Lou:
          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
          listeners?
          - 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
          
          Stu:
          - assume, dest up/dest update concept clear, not specific
          - multicast address
          
          Lou:
          - that is what is in doc
          - it was assumed, now explicit
          
          Stan:
          - 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
          
          Lou:
          - 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
          protocols
          Stu: one hop listeners
          Alvaro: similar
          - dlep routers, not behind them
          - translate joins
          Lou:
          - pid behavior
          Alvaro:
          - what happens when I get icmp join?
          Lou:
          - you have to go to router
          Alvaro:
          - doing it for dlep subnet
          Stu:
          - can I infer that the dst up/dst update may propgate to different grps
          of listeners based on group we are talking about
          Lou:
          - 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
          Stu:
          - 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
          
          Lou:
          - 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
          
          Stan:
          - as sender how do you cope
          
          Lou:
          - cant see for multicast but can see unicast
          
          Stan:
          - seems like a problem
          - hidden terminal problem
          - propgate foward
          
          Rick:
          - privacy side step
          - single l2 domains
          - not propgating
          
          Lou:
          - 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
                  distrubtion
          
          Stan:
          - 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
          
          Lou:
          - capability of other nodes being shared
          - this becomes PAR, the higher level can inject info into lower level
          and provide dist. and disc. function
          
          Rick:
          - 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
          
          Lou:
          - why not resource param?
          
          Rick:
          - complex meshes building trees
          
          Stan:
          - ask group: getting close on time
          
          Lou:
          - 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
          Lou:
          - key question: exactly what pascal trying to get at
          - with raw and paw activity (bof material / sidemeeting)
          - really wants this
          Rick:
          - really cares
          - this is important
          Ronny:
          - 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
          Question
          - is there interest to do this work?
          - start with problem statement
          - see what is out there
          - write protocol spec
          Rick:
          - straight to standard if we do this
          - enough stuff out there
          - wary of experimental rfcs
          Ron:
          - fine with this
          - but not in charter
          Alvaro:
          - 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
          Ron:
          - should of done on ml sooner
          Rick:
          - non-wg bof thrus morning
          - attempt to combine?
          Lou:
          - 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?
          
          Stan:
          - comments/questions?
          - closing remarks
          
          



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