Skip to main content

Minutes IETF105: manet
minutes-105-manet-00

Meeting Minutes Mobile Ad-hoc Networks (manet) WG
Title Minutes IETF105: manet
State Active
Other versions plain text
Last updated 2019-07-29

minutes-105-manet-00

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