[ssm] minutes from ssm ietf-58 in mpls

Hi, folks.  

The minutes were posted in the online proceedings
(http://www.ietf.org/proceedings/03nov/index.html), but I realize now
that I never sent them to the mailing list.  So here you go.  Sorry
for the delayed post.

-Hugh and Supratik.
--------------------------------
Agenda bashing - Hugh 

Presentation - Admin scoping and SSM - Hugh

beau williamson: what we are seeing more and more now is extension of
239/8 down into admin scopes inside the private address space,
multiple limited scopes

hugh: yes, some applies recursively as well.

isidor: scoped range - you don't mean group range, right?

hugh: not , a scoped range is a scoped set of channels, defined by
source mask, destination mask, source and destination simultaneously,
etc.

beau: why would you put a filter on a stub region?

hugh: for example, if an enterprise, not transiting anything, does not
want information to leak out, e.g., CEO giving a speech.

beau: misunderstanding definition of stub - thought that stub is like
a multi-access network with hosts on it.

hugh: no this is more of an AS sense of a stub, a much larger topological stub.

isidor: about blocking joins, I think it would be more in line with
the PIM spec if instead of ignoring joins, you actually store the
joins but actually don't translate them into forwarding state. because
eventually if you change the filter, you may want to use existing
join state that you may have.

hugh: yes.

dino: ssm on 232/8 - is that assuming the type of routing protocol
that will be used for those ranges. so if you are using a dense-mode
protocol you cannot filter joins.

hugh: if you are using dense-mode protocol at the boundary, then that
is a good point, you have to filter the traffic. The draft says that
you have to prevent the traffic from going out - either by filtering
joins or filtering traffic.

dino: so it will be nice for the spec to say that you can do control
plane or data plane filtering.

hugh: yes, out of curiousity, is anybody doing SSM with dense mode?

hugh: some other alternatives not mentioned in the draft - includes
allowing the address range to float in 232/8. a lot of entities need
to know of this range.

isidor: and you still need to the API to request a scoped address.

hugh: yes, so this a property of any proposal. 

hugh: so how do you make this consistent. Another choice is to fix a
range within 232/8. Cannot make it too small to avoid collapsing on a
small set of ethernet addresses.

hugh: comments??

toerless: would like to see the first option (above) to be considered
as an alternative. We are not talking ssm-specific, but
ipv4-specific. there is not much of a problem with allocating 239
range configured properly. that is much of the ssm we are seeing
today. with the proposal, you have to understan how to correctly
configure the filters. the normal approach of allocating an address
range is simpler. would not want ssm to be restricted to 232/8.

hugh: not suggesting not doing ssm outside 232/8, but there are
certain ramifications, would not want the ietf to go down the path.

beau: two things - one is the ability to use 232/8 as SSM or not;
other is the use of filtering other than group-based.

hugh: the draft actually addresses the second point.

beau: it leads to a discussion of the second point. can you explain
the group-based bi-directional boundary approach is inadequate, and we
have to have the uni-directional, more elaborate filtering mechanism?
what problem are you fixing.

isidor: the bi-directional one breaks the transit case.

hugh: the destination-based breaks the transit case; and the
bi-directional breaks the case that you want to listen to a source
outside your domain.

beau: don't see how it is different from an ASM model when you switch
over to a shortest path tree. if you have a domain boundary on a group
address range, you are going to block either the data flow or the
control packet flow from entering or leaving the boundary. This is
already implemented, and it works.

hugh: I decide that I am putting all my company stuff on an internal
source 232.239, and decide to block it. Now there is an external
source transmitting interesting stuff, and I don't want to block it
from coming in.

pekka: don't see a problem in the transit case. don't see why a
transit AS would want to block. other problem - how to do it v6,
because v6 already has scoping, so would this be useful? two issues -
whether we want to do something like this for v6, and do we want to be
able to scope ssm v6 multicast with the source and destination in
global scope.

hugh: if you want to do the latter, then you have to do something like
this p roposal.

dave thaler: about the two proposals. if the first one requires
additional protocol stuff, then hugh's proposal is better. the problem
with the current draft is title - should say ipv4.

hugh: could apply to v6.

dave: don't want it to apply to v6. other thing - there is nothing
that says that it is illegal for the app to use the include mode in
the 239 range.

brian haberman: like this proposal better. gets rid of the
machinery. for v6, we are better off using the scope in the multicast
address. so change the title, no other problem.

john meylor: as long as the app can use include mode in 239 range,
then that is the  most important component brought out in the draft, because
after that you can do pretty much anything in your own admin
domain. key thing to specify that if you are doing anything outside of
239 in a transit networl, then you allow for transit to pass through.

toerless: scope identified by group range is simpler, hugh's option is
doable but complex. it is doable, academically interesting. don't need
it for v6.  this pr

hugh: what do you want?

toerless: don't want anything coming out of this process that is more complex.

hugh: source filtering only in transit case, otherwise always destination.
what would you do?

toerless: a draft should outline all the alternatives for scoping for
v4 multicast, without expressing a preference for any one. would go
for 239/8 sub-ranges that are allocated by local authorities.

dino: if you had group range filtering only, would that make you happy?

toerless: yes.

dino: just say you can optionally do source-based filtering as well.

john meylor: the important point here - whatever range we scope on,
when you arrive on a transit network, you can predict your
behavior. in the scoped domain, as long as you can use include mode in
the application, you can pretty much do what you want. nothing that
the ietf has to dictate about that. nothing that precludes toerless
point other than if you are going to recommend that within the 232
range you have scoped behavior, then you have to make it clear to the
transit provider that if they are going to apply scoped behavior on
the 232 range, they have to allow for transit. and that is what
dictates the uni-directional filter.

hugh: agreed.

pekka: seems like if we do ssm inside 239, we will also have to leave
the option to specify in the protocol stack where we want to do
ssm. would be much better to glue those in when you design the
protocol. an option may be to use 231, will that be better.

hugh: well we could take half of 232.

toerless: for v4, one additional scope for a private enterprise,maybe
that is a simple compromise to give leeway to people that design
protocols and cannot be bothered with the ssm range. not a strong
argument, but if that is what the ietf wants...

hugh: not just the protocols, reduces configuration burden.

toerless: limiting the scope of the application is a primary security
concerns of every scoped definition. so putting effort into that is
considered a part of the securities definition of a network. so there
is not that much of a problem getting work done on that as opposed to
other work on multicast.

beau: we are not gaining anything. the only advantage is that we have
two range - inter-domain 232/8 always transit. the other is a
well-known for ssm but private. don't care where it comes from. still
have the problem of configuring the network.

hugh: reduces the problem of where to configure for ssm behaviour.

beua: no it doesn't because inside an enterprise you will have
different scopes, and those boundaries are going to be arbitrary. so
there is a lot of admin going on in terms of where the boundaries.

hugh: but this avoids configuring other things like RPs, DRs. this is
not necessarily to ease the configuration of boundaries.

beau: so, lock it down into two - inter-domain and intra-domain (carve
up the way you want) and then use group-based boundaries.

unknown (used to be an operator): don't mess with 239, because it will
be nice to sketch out a scenario where a router gets shipped out to an
enterprise which by default would have useful behaviour, e.g., 239 is
admin scoped, etc. i.e., something reasonable out of the box, if the
enterprise wants something more clever, they can do it.

toerless: how about just to be able the same scope boundaries in a
dual mode network simply use the high-order 4 bits of the third byte
to have the same scope levels as an ipv6 so that you can use the same
boundaries when you will be building an enterprise network

hugh: guess you are cutting your address space down.

toerless: how many channels do you need?

hug: there is an ethernet collision issue.

toerless: well, the ietf made a decision about v6. tradeoff between
simplicity and freedom. boundaries not that simple.

dave thaler: half convinced, half not that there is an issue. what do
we expect the apps to do? first, the app has to pick an address G and
there has to be a filter in the router. which happens first?

hugh: filter in the router.

dave : in that case, how does the app pick an address?

hugh: either the user has to know, CLI or on the box or something. Or
you have a protocol mechanism.

dave: don't like either of those. that is why it is good to pick a
sub-range of 232/8 or 239.

hugh: but it is not good as an application user to rely on scoping
simply because the ietf says so.

dave: true. if you use 231/8, you can use the same subnetting scheme,
which is what ipv6 is doing for different types of prefixes. your
breakdown within the /8 could be the same. what is the scoped
divisions for 239 - there is a protocol for that. 50% convinced of
toerless and beau's point. in your proposal, you _have_ to do coordination.

hugh: anyone has a sense how it is difficult to get a /8 for multicast.

toerless: just worried that if it does not say clearly that other
address ranges must be supported to allow for scoping, then this may
fall over. in the end, there may be apps that can only do ssm with
additional protocols in 232. bit paranoid, but has been known to
happen in the past.

hugh: is the concept of a /25 too hard?  can we split the space in
half? would be backward compatible with anyone doing ssm today.

tom: thinking of deployment, if you want to go to admin scoped you
have to configure border routers. already done in 239 range, so let
people do what they want there.

hugh: gotta worry whether things like msnip - would it work in 239 space?

tom: we have the ability to configure additional range of ssm space - then we have to configure all routers.

beau; but you already have a problem like that today. you still have
people building ASM/bidir admin scoped ranges inside the 239 range. so
how do communicate and configure the application so that it uses the
appropriate scoped range address for (1)what the app was designed to
do (2) what the network administrator wants the scope to be for that
particular app.  so...pick some ranges in 239 so that you can do the
same.  you have to configure the routers to let them know which range
within 239, which you have to do at the boundaries. so it is a part of
the configuration.

louis: but the no. of boundaries is smaller than all routers.

toerless: ssm in ip4 with admin scoping must have all the benefits of
global scope, not partial suppirt.

End of presentation - admin scoping and SSM.

Presentation: SSM architecture draft and IPR - Hugh

hugh: possible next steps for ssm - comments??

toerless: go forward. to what degree does the risk factor also apply
to other protocols - e.g., igmpv3. or take PIM - if you get an (S,G)
from IGMP, does it fall under the IPR. and that could be ASM not even
SSM.

hugh: could be interpreted to cover any case where receiver specifies source.

toerless: so include mode in igmpv3.

hugh: yes.

alex: if it is standardized, then licenses will be available. does not
say what if it is not standardized.

tom: if they are not claiming igmpv3 and pim, then why this?

hugh: they are only required to notify if they know specific
technology is IPR-impacted.

tom: by not notifying, they are giving up their rights.

hugh: not true.

pekka: they are not required to give any terms or disclose anything
unless they take par in the deliberations reg. the technology. not
sure if people from apple have been talking about igmp or ssm,
etc. They are probably giving it away for free, they don't have
to. The reason that they are doing this for ssm not igmp is that they
picked something source-specific.  Personal belief: must not go for
proposed standard. try to gather more information. try to get
royalty-free, see later how to proceed.

hugh: approached apple, not very receptive.

bill fenner: what is different from if apple had waited until after
the rfc came out.

pekka: not much of difference. qn here : now that we know about it,
should we do something. depends on how much of backchannel with apple.

dino: claims are very general - e.g. transmitting data with a
computer, joining group. patent was filed in 94, first pim rfc in 97.

bill: options are: investigate validity or force them to license. only
judge can judge validity. it is a judgement call, not for us. so
remove validity from the table. not going to say that this patent is
invalid. on licensing tierms, we have no leverage.

dino: apple lawyers are not stupid - have to go after ciso, microsoft.

bill; they don't have to go after anyone, pick and choose what they
want to enforce. can't see any forward progress with step 2 (checking
validity).

pekka: is there any chance of prior art?

bill: very little, based on the timing.

hugh: maybe we can dig up some emails?

bill: prior art in itself does not do anything. it is the opinion of
the judge taking prior art into account.

brian haberman: only choice seems 1. so go on, and see what they do.

hugh: need two implementations to fo to draft standard. need license
for implementations, at which point the decision will be automatically
made.

john meylor: go forward.

toerless: can the text be changed to be less specific to the IPR.

hugh: not likely to work.

bill: is there anyone who would absolutely not implement it if there
was IPR onit? it is in bsd.

<no response>

pekka: would not put it in linux.

unknown: has anyone licensed?

bill: don't know. apple supports open source.

hugh: incredibly strong licensing statement for W3C.

pekka: regarding w3C, members of w3C have been arm-twisted to provide royalty-free statements, the process here is different.

alex: to move forward, ask the room: who believes that the group is ready to make a decision, and who believes that we need more information and discuss at the next meeting.

john meylor: nothing illegal to move it to proposed standard. what needs to be thought about is whether people would want to implement the draft after that? do people think there is anything wrong with the document? else, go forward.

hugh: who thinks we need more time

2 hands

hugh: who thinks we should go forward

numerous hands

hugh: who thinks we have enough information to decide not to go forward.

none.

hugh: so we will take this discussion to the list.

_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm