Subject: [Bier] Fwd: New Version Notification for draft-pfister-bier-mld-00.txt

From: Pierre Pfister <[email-masked]>
Date: Fri, 3 Jul 2015 09:32:50 +0200

Hello Bier,

We just submitted a new draft which proposes to use MLDv2 or IGMPv3 (slightly modified)
on top of BIER as the ingress part of a BIER multicast flow overlay layer.
That way, egress routers can share their multicast membership state with ingress routers,
which can in turn use this information to forward multicast packets that enter the network.

Comments are, of course, very welcome. We would also like to request a slot during 
Prague’s session in order to present that new work.

Thanks,

- Pierre

> 
> A new version of I-D, draft-pfister-bier-mld-00.txt
> has been successfully submitted by Pierre Pfister and posted to the
> IETF repository.
> 
> Name:		draft-pfister-bier-mld
> Revision:	00
> Title:		BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols
> Document date:	2015-07-03
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-pfister-bier-mld-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-pfister-bier-mld/
> Htmlized:       https://tools.ietf.org/html/draft-pfister-bier-mld-00
> 
> 
> Abstract:
>   This document specifies the ingress part of a multicast flow overlay
>   for BIER networks.  Using existing multicast listener discovery
>   protocols, it enables multicast membership information sharing from
>   egress routers, acting as listeners, toward ingress routers, acting
>   as queriers.  Ingress routers keep per-egress-router state, used to
>   construct the BIER bit mask associated with IP multicast packets
>   entering the BIER domain.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 14 Jul 2015 15:30:21 -0400

> which can in turn use this information to forward multicast packets that enter the network.

- If two ingress routers receive (from outside the BIER domain) packets 
of the same flow, how is it determined which ingress routers forward the 
packets to which egress routers?  Is there a designated forwarder 
election (or other form of "single forwarder selection") within the BMLD 
instance?  Or does each egress router have some way of selecting the 
ingress router from which it wants to receive a given flow?

- Question about the following from the draft:

    "All Listeners MUST be configured with ... the BFR-ids of all the
    BMLD Queriers.

    All Queriers MUST be configured with ... the BFR-ids of all the
    Queriers and Listeners."

Generally in BIER, each BFR is not configured with the BFR-ids of all 
the other BFRs.  Does the draft really require that any time a new BFR 
is added, all the other BFRs need to be reconfigured?

- BFR-ids are only unique within a sub-domain, but the draft doesn't 
discuss the role played by sub-domains at all.

- Does the draft require every BFIR to maintain a list of all the BFERs 
for all the multicast flows in the entire BIER domain, even those that 
don't pass through the BFIR?  That would seem to be a scaling problem.

- Has any thought been given as to whether/how this would work over a VPN?

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 15 Jul 2015 18:39:11 +0200

Hello Eric,

> Le 14 juil. 2015 à 21:30, Eric C Rosen <[email-masked]> a écrit :
> 
> - If two ingress routers receive (from outside the BIER domain) packets of the same flow, how is it determined which ingress routers forward the packets to which egress routers?  Is there a designated forwarder election (or other form of "single forwarder selection") within the BMLD instance?  Or does each egress router have some way of selecting the ingress router from which it wants to receive a given flow?

Short answer: At this stage of the document, no.
Longer answer: 
Right now, if the same multicast traffic enters the domain at two different BFIRs, it will be forwarded twice. I guess this could be solve with a sort of per-flow election mechanism. A router receiving (S,G) traffic could subscribe to (S,G) within the BIER domain, and therefore detect when some other BFIR forwards the same flow, and trigger some assert-like mechanism.
Do you expect such situation to happen a lot ? Like, having the same flow entering your domain by different entry points, is it something usual ?

> Generally in BIER, each BFR is not configured with the BFR-ids of all the other BFRs.  Does the draft really require that any time a new BFR is added, all the other BFRs need to be reconfigured?

By ‘configured’ here, I am mostly expecting some kind of auto-discovery. BFR-ids and BFR-prefixes will be configured as well, by the mean of the routing protocol, or another protocol (DNCP, from homenet, could do that for instance).
So I think it is reasonable to assume that such ids will be auto-discoverable and therefore dynamically configured.

> 
> - BFR-ids are only unique within a sub-domain, but the draft doesn't discuss the role played by sub-domains at all.

I must admit I did not consider sub-domains yet.
But walking through the architecture draft, I don’t really see the difference between sub-domains and different domains that happen to be next to each other.

I guess for now, the answer would be to consider that different instances are run in each subdomain. But I’ll have to think a bit more about it.

> 
> - Does the draft require every BFIR to maintain a list of all the BFERs for all the multicast flows in the entire BIER domain, even those that don't pass through the BFIR?  That would seem to be a scaling problem.

Yes. This proposal targets implementation simplicity, at the cost of scalability.
I mean, it uses a link-local protocol at a site-local scale, so I don’t expect it to be very scalable.

Of course, proposals to make it more scalable are welcome.

> - Has any thought been given as to whether/how this would work over a VPN?

If the VPN transports BIER encapsulated packets, I guess it would not be a problem.
Do you have a specific concern in mind ?

- Pierre

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 16 Jul 2015 10:36:45 -0400

> [Pierre] Right now, if the same multicast traffic enters the domain at two
> different BFIRs, it will be forwarded twice ... Do you expect such
> situation to happen a lot ? Like, having the same flow entering your
> domain by different entry points, is it something usual ?

There is nothing unusual about that situation; even if it were unusual, 
it would still have to be handled properly.  You don't really have a 
proposal if you don't address the issue of preventing duplicate delivery.

>> [Eric] Has any thought been given as to whether/how this would work
>> over a VPN?

> [Pierre] If the VPN transports BIER encapsulated packets, I guess it would
> not be a problem. Do you have a specific concern in mind ?

Are you assuming that a set of customer sites connected over an L3VPN 
backbone can function as a single BIER domain?  The sites of a VPN 
usually do not participate in a common routing protocol with each other, 
and the BIER layer signaling is piggybacked on routing.  So it's not at 
all obvious how to create a single BIER domain out of mulitlpe customer 
sites.

On the other hand, if you assume that each site is an independent BIER 
domain, it's not obvious how listeners at one site talk to queriers at 
another.

> [Pierre] This proposal targets implementation simplicity, at the cost of scalability.

Well, don't be surprised if someone compares it to 'dense mode' ;-)

> By ‘configured’ here, I am mostly expecting some kind of auto-discovery

That needs to be made clear in the draft.

> [Pierre] I must admit I did not consider sub-domains yet ... I guess for now,
> the answer would be to consider that different instances are run in
> each subdomain.

Then if some listener were in 5 sub-domains, it would get 5 copies of 
each flow?  More likely, there would have to be a sub-domain for running 
BMLD, and a particular flow would have to be sent in a sub-domain that 
contains the flow's source and all its listeners.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 16 Jul 2015 10:50:30 -0400

On 7/15/15 12:39 PM, Pierre Pfister wrote:
>>> We just submitted a new draft which proposes to use MLDv2 or
>>> IGMPv3 (slightly modified) on top of BIER as the ingress part of
>>> a BIER multicast flow overlay layer. That way, egress routers can
>>> share their multicast membership state with ingress routers, 
>> - If two ingress routers receive (from outside the BIER domain)
>> packets of the same flow, how is it determined which ingress
>> routers forward the packets to which egress routers?  Is there a
>> designated forwarder election (or other form of "single forwarder
>> selection") within the BMLD instance?  Or does each egress router
>> have some way of selecting the ingress router from which it wants
>> to receive a given flow?
> 
> Short answer: At this stage of the document, no. Longer answer: Right
> now, if the same multicast traffic enters the domain at two different
> BFIRs, it will be forwarded twice. I guess this could be solve with a
> sort of per-flow election mechanism. A router receiving (S,G) traffic
> could subscribe to (S,G) within the BIER domain, and therefore detect
> when some other BFIR forwards the same flow, and trigger some
> assert-like mechanism. Do you expect such situation to happen a lot ?
> Like, having the same flow entering your domain by different entry
> points, is it something usual ?
> 

The problem with the above is that IGMP/MLD is not designed to make
routing decisions.  It is strictly a signaling protocol that allows
hosts to indicated interest in a multicast group to whatever routers are
listening.

It seems to me that this proposal would require new work at the BIER
level to control the redundant distribution of multicast data across a
domain.

Regards,
Brian

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sun, 19 Jul 2015 12:54:52 +0200

Eric,

> There is nothing unusual about that situation; even if it were unusual, it would still have to be handled properly.  You don't really have a proposal if you don't address the issue of preventing duplicate delivery.

Agreed. There is a similar issue on the egress, where a host may be dually connected to the BIER domain. Some sort of DR/DF election needs to be done in order to prevent duplication. This is a problem that is not specific to this proposal. If we use BGP as the overlay (with BIER end-to-end), you run into similar problems. This is a problem that needs to be resolved independently of the overlay IMO.

We have idea’s how to resolve it, of course ;-) I’ll pull folks aside this week to discuss and plan to submit a draft on this for next IETF.

Thx,

Ice.

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 19 Jul 2015 10:26:16 -0700

As individual contributor: I recommend here (and can cc: folks if desired
on it) the current discussions about EVPN DF which is a very similar
problem that has/is being solved given implementation experience feedback.
The intention is to publish a clean FSM for EVPN DF based on implementation
experience. I already have a writedown that has been looked over if folks
are interested (if may be folded into Satya's draft or not, not clear yet).

thanks

-- tony

On Sun, Jul 19, 2015 at 3:54 AM, IJsbrand Wijnands <[email-masked]> wrote:

> Agreed. There is a similar issue on the egress, where a host may be dually
> connected to the BIER domain. Some sort of DR/DF election needs to be done
> in order to prevent duplication. This is a problem that is not specific to
> this proposal. If we use BGP as the overlay (with BIER end-to-end), you run
> into similar problems. This is a problem that needs to be resolved
> independently of the overlay IMO.
>
> We have idea’s how to resolve it, of course ;-) I’ll pull folks aside this
> week to discuss and plan to submit a draft on this for next IETF.
>
> Thx,
>
> Ice.
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Sun, 19 Jul 2015 17:37:50 +0000

Tony, more then happy to consider any proposal :-). But do keep in mind this should be agnostic to the overlay (no dependency on BGP), and the DR/DF election is interface specific...

Sent from my iPhone

On 19 Jul 2015, at 19:26, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

As individual contributor: I recommend here (and can cc: folks if desired on it) the current discussions about EVPN DF which is a very similar problem that has/is being solved given implementation experience feedback.  The intention is to publish a clean FSM for EVPN DF based on implementation experience. I already have a writedown that has been looked over if folks are interested (if may be folded into Satya's draft or not, not clear yet).

thanks

-- tony

On Sun, Jul 19, 2015 at 3:54 AM, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

Thx,

Ice.

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 19 Jul 2015 10:48:51 -0700

Ice, was not my intention or suggestion, I do not expect this thing to be
generic enough (since the elements elected & election algorithm vary from
problem to problem) but the FSM captures the nature of the problem (albeit
may be too cryptic unless one's familiar with eVPN to a decent degree,
think of ESIs as e.g. MCAST groups). (attached)

Generally, there are really only two choices:

a) distributed election ala DR/DF as you say. Everyone waits a bit and then
elects from all the participant's advertisements assuming e'one ends up
with same set.  In a sense the attached stuff is a variation of DR/BDR and
one could use the DR/BDR as example as well (you have  a version of that in
the auto-BFR-id assignment draft BTW already ;-)   Difference between DF
and DR is that DR implicitly protects via B-DR and DF does not (well,
Satya's draft does now albeit without priorities like OSPF does which may
prove a disadvantage, not clear yet).
b) a full tilt Quorum (Leslie's Paxos). This is normally very expensive
technology to build in terms of complexity and has been pretty much
declined by eVPN (which I agree with). Paxos has the big advantage as far I
remember that misbehaving members can still be tolerated to build a valid
quorum and there are no 'blips' waiting until e'one converged on a result.

thanks

--- tony

On Sun, Jul 19, 2015 at 10:37 AM, IJsbrand Wijnands (iwijnand) <
[email-masked]> wrote:

>  Tony, more then happy to consider any proposal :-). But do keep in mind
> this should be agnostic to the overlay (no dependency on BGP), and the
> DR/DF election is interface specific...
>
> Sent from my iPhone
>
> On 19 Jul 2015, at 19:26, Tony Przygienda <[email-masked]> wrote:
>
>   As individual contributor: I recommend here (and can cc: folks if
> desired on it) the current discussions about EVPN DF which is a very
> similar problem that has/is being solved given implementation experience
> feedback.  The intention is to publish a clean FSM for EVPN DF based on
> implementation experience. I already have a writedown that has been looked
> over if folks are interested (if may be folded into Satya's draft or not,
> not clear yet).
>
>  thanks
>
>  -- tony
>
>> Agreed. There is a similar issue on the egress, where a host may be
>> dually connected to the BIER domain. Some sort of DR/DF election needs to
>> be done in order to prevent duplication. This is a problem that is not
>> specific to this proposal. If we use BGP as the overlay (with BIER
>> end-to-end), you run into similar problems. This is a problem that needs to
>> be resolved independently of the overlay IMO.
>>
>> We have idea’s how to resolve it, of course ;-) I’ll pull folks aside
>> this week to discuss and plan to submit a draft on this for next IETF.
>>
>> Thx,
>>
>> Ice.
>>

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Mon, 20 Jul 2015 11:57:06 +0000

There are ways to solve this problem with or without new standard work especially with BGP signaling as per6513/14 and 6625.

There are implementations that through a local policy can send a join only to a single UMH. Same policy can be applied (or applies) to explicit tracking which would prevent a BFER from receiving traffic from two BFIR for a given c-stream. That solves dual homing of a source and resulting duplication issue.

For dual homed hosts, the issue would only apply to active-active connectivity. But if you have that then host must deal with traffic duplication anyways, so I see no point of solving this.

Andrew

Sent from my iPhone

On Jul 19, 2015, at 7:49 PM, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

Ice, was not my intention or suggestion, I do not expect this thing to be generic enough (since the elements elected & election algorithm vary from problem to problem) but the FSM captures the nature of the problem (albeit may be too cryptic unless one's familiar with eVPN to a decent degree, think of ESIs as e.g. MCAST groups). (attached)

a) distributed election ala DR/DF as you say. Everyone waits a bit and then elects from all the participant's advertisements assuming e'one ends up with same set.  In a sense the attached stuff is a variation of DR/BDR and one could use the DR/BDR as example as well (you have  a version of that in the auto-BFR-id assignment draft BTW already ;-)   Difference between DF and DR is that DR implicitly protects via B-DR and DF does not (well, Satya's draft does now albeit without priorities like OSPF does which may prove a disadvantage, not clear yet).
b) a full tilt Quorum (Leslie's Paxos). This is normally very expensive technology to build in terms of complexity and has been pretty much declined by eVPN (which I agree with). Paxos has the big advantage as far I remember that misbehaving members can still be tolerated to build a valid quorum and there are no 'blips' waiting until e'one converged on a result.

thanks

--- tony

On Sun, Jul 19, 2015 at 10:37 AM, IJsbrand Wijnands (iwijnand) <[email-masked]<mailto:[email-masked]>> wrote:
Tony, more then happy to consider any proposal :-). But do keep in mind this should be agnostic to the overlay (no dependency on BGP), and the DR/DF election is interface specific...

Sent from my iPhone

thanks

-- tony

Thx,

Ice.

<new_df_election_draft_extensions.txt>
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier