Subject: [bess] comment on draft-ietf-bess-ir

From: Lucy yong <[email-masked]>
Date: Tue, 1 Sep 2015 17:34:56 +0000

Hi Authors,

The draft is well written. Some simper implementation maybe considered.

The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS number is used as the tree root ID and RT is used for Parent identifier. The implementation requires each parent to track all its children and each child selects one parent.

Section 6.2 describes the rules for intermediate node as a child to allocate a single label for two received Leaf A-D routes from its downstream.

Section 9 describes that the solution is able to support dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in section 6.2 becomes a near impossible condition because the Leaf A-D route at downstream may change for the time being.

Section 9 further describes "the make before break" implementation and requires some cooperation between patent and its child who is changing to a new parent;  that is: the patent detects the change from RT value changes and update its state (not as parent for the child), but continually send the packet in data plane until receiving the withdraw Leaf A-D route from the child; the child sends the leaf A-D with the new parent identified by IP address-specific RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from new patent.

Since the essential rule in this mechanism is for each child to select one and only one patent, the child node can implement "make before break" without parent assistant. Thus, patent does not need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Leaf A-D route. Let the child to manage it. If two nodes send the same packet to a child, the child only accepts the packet from its parent and discards a packet from non parent now as the essential rule. When a child changes parents, it just needs to continually accept the packet from old parent for a while, after accepting the packet from the new UMH, it sends the withdraw lead A-D and stop accepting the packet from old parent.

The essential rule can relax the #2 rule in section 6.2, i.e. no need to restrict N's forwarding state for K1 and K2 are exactly same, i.e. the same set of downstream neighbors. This will be more practical.

We just need to state rules for a node to discard the received packet, 1)  the packet is from non-patent node; 2) the node never advertises for the corresponding Leaf A-D route.

To balance avoiding packet discard at a downstream node and sharing a label in upstream path, an intermediate node can have a proper algorithm for label allocation.

Does this make a sense? Comment?

Thanks.
Lucy

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 1 Sep 2015 19:26:39 +0000

Hi Lucy,

Please see zzh> below.

From: BESS [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: [bess] comment on draft-ietf-bess-ir

Hi Authors,

Zzh> While in a separate thread you and I talked about AS number identifying the tree root for an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel, whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (e.g. an S-PMSI).

Zzh> More accurately, a single label for the upstream segment of two different tunnels. Suppose there are two tunnels, both have the same forwarding state for the downstream segment, then the upstream can share the same label.

Zzh> Section 6.2 already points out the following:

   Of course, N MAY always specify distinct non-zero labels in each of
   the Leaf A-D routes that it originates.

I.e., you can always advertise different labels for different tunnels. The more complicated label allocation scheme in the section allows for different tunnel segments to share the same forwarding state, and is an optimization. The implementation of that is not infeasible.

Zzh> When a child changes the RT value because it picks a new parent, the old parent will get a withdraw - not that it gets the updated route (with the new RT) first and then a withdraw later.

Zzh> Perhaps this can be done by the child to include the RT for the new parent and the RT for the old parent for a while, and then remove the RT for the old parent later. The drawback is that an additional route update is needed.

Zzh> Section 6.2 and section 9 are independent?

Jeffrey

Thanks.
Lucy

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 1 Sep 2015 19:44:43 +0000

Two corrections - thanks for Eric to point out:

> When a child changes the RT value because it picks a new parent, the old parent will get a withdraw - not that it gets the updated route (with the new RT) first and then a withdraw later.

More accurately, it's that the old parent will get the updated route (with the new RT) which serves as an implicit withdraw (because the old RT that caused the importation is no longer present). If RTC is used, then the old parent does get a withdraw (and you can't control the time it is done).

> Perhaps this can be done by the child to include the RT for the new parent and the RT for the old parent for a while, and then remove the RT for the old parent later

That is actually not feasible. The updated route has the label allocated for the new parent and should not be imported by the old parent.

Jeffrey

From: Jeffrey (Zhaohui) Zhang
Sent: Tuesday, September 01, 2015 3:27 PM
To: 'Lucy yong' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Hi Lucy,

Please see zzh> below.

From: BESS [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [bess] comment on draft-ietf-bess-ir

Hi Authors,

Jeffrey

Thanks.
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 1 Sep 2015 19:48:26 +0000

Hi Jeffery,

Thank you for your quick reply. To clarify, the first part of my previous email is to state what are specified in the draft. Starting "Since the essential rule" is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Section 6.2 and 9.

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Hi Lucy,

Please see zzh> below.

Hi Authors,

Zzh> More accurately, a single label for the upstream segment of two different tunnels. Suppose there are two tunnels, both have the same forwarding state for the downstream segment, then the upstream can share the same label.
[Lucy] Please clarify: both have the same forwarding state for the downstream segment at a time or forever? Section 9 states that many reason may cause to change the parents for a leaf A-D.

I.e., you can always advertise different labels for different tunnels. The more complicated label allocation scheme in the section allows for different tunnel segments to share the same forwarding state, and is an optimization. The implementation of that is not infeasible.
[Lucy] This is always valid to do. My point is when it is proper to have a shared label.

Zzh> When a child changes the RT value because it picks a new parent, the old parent will get a withdraw - not that it gets the updated route (with the new RT) first and then a withdraw later.
[Lucy] why can't the child send the Leaf A-D for new patent first to the new parent and send withdraw Leaf A-D to old Patent the later when it stops accepting the packet from old-parent?  In fact, this is what I propose below.

Thanks,
Lucy

Jeffrey

Thanks.
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 1 Sep 2015 19:53:14 +0000

Please see inline.

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 2:45 PM
To: Lucy yong; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

More accurately, it's that the old parent will get the updated route (with the new RT) which serves as an implicit withdraw (because the old RT that caused the importation is no longer present). If RTC is used, then the old parent does get a withdraw (and you can't control the time it is done).
[Lucy] IMO:  This is the part that can be improved.

That is actually not feasible. The updated route has the label allocated for the new parent and should not be imported by the old parent.
[Lucy] agree. However, a child can use one leaf A-D with the new parent with a new label and later send withdraw leaf A-D to the old parent when stop accepting the packet from ole parent that removes the old label too.

Lucy

Jeffrey

To: 'Lucy yong' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Lucy,

Please see zzh> below.

Hi Authors,

Jeffrey

Thanks.
Lucy

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 1 Sep 2015 20:00:31 +0000

Lucy,

Please see zzh2> below.

From: Lucy yong [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 3:48 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Hi Jeffery,

To: Lucy yong; [email-masked]<mailto:[email-masked]>

Hi Lucy,

Please see zzh> below.

Hi Authors,

Zzh2> As long as they still share the same downstream forwarding state. The motivation for this optimization is to reduce the forwarding state on this and upstream routers when possible.

I.e., you can always advertise different labels for different tunnels. The more complicated label allocation scheme in the section allows for different tunnel segments to share the same forwarding state, and is an optimization. The implementation of that is not infeasible.
[Lucy] This is always valid to do. My point is when it is proper to have a shared label.
Zzh2> It's valid to share label as long as your downstream forwarding state are the same for the two tunnels.

Zzh2> For a particular PMSI route, you can only have one instance of the Leaf A-D route. If it contains only the RT for the new parent, then the old parent will get an implicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to the new parent and that's not good.

Jeffrey

Thanks,
Lucy

Jeffrey

Thanks.
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 1 Sep 2015 20:07:34 +0000

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 3:01 PM
To: Lucy yong; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Lucy,

Please see zzh2> below.

To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Jeffery,

Hi Lucy,

Please see zzh> below.

Hi Authors,

Zzh2> As long as they still share the same downstream forwarding state. The motivation for this optimization is to reduce the forwarding state on this and upstream routers when possible.
[Lucy] I understand this benefit. The relaxed rule make easier to qualify the condition.

I.e., you can always advertise different labels for different tunnels. The more complicated label allocation scheme in the section allows for different tunnel segments to share the same forwarding state, and is an optimization. The implementation of that is not infeasible.
[Lucy] This is always valid to do. My point is when it is proper to have a shared label.
Zzh2> It's valid to share label as long as your downstream forwarding state are the same for the two tunnels.
[Lucy] IMO: this is not necessary. Without the same downstream forwarding state, two tunnels can share the label too as long as we state the downstream operation properly.

Thanks,
Lucy

Jeffrey

Thanks,
Lucy

Jeffrey

Thanks.
Lucy

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 1 Sep 2015 16:15:21 -0400

> However, a child can use one leaf A-D with the new
> parent with a new label and later send withdraw leaf A-D to the old
> parent

Lucy,

Note that "both" of Leaf A-D routes you mention above have the same NLRI 
and the same next hop.  Thus to BGP, these are really the same route.

What you are suggesting is:

- Send a route with a particular set of attributes to one neighbor;

- Send the same route with a different set of attributes to another 
neighbor;

- Then withdraw the route from the first neighbor without withdrawing it 
from the second.

This sort of functionality is not really supported by the BGP 
distribution mechanisms.   The MVPN mechanisms generally assume the 
typical BGP distribution mechanisms, where BGP chooses the bestpath for 
a particular NLRI, and then distributes it.

Eric

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 1 Sep 2015 20:15:47 +0000

Lucy,

> The relaxed rule make easier to qualify the condition.

Section 6.2 and section 9 are independent. Section 6.2 is about sharing label (for the same parent) among two different tunnels; section 9 is about the child picking a new parent for the same tunnel.

I had thought your "relaxed rule" is about section 9 - let the child manage the make-before-break w/o involving parent.

Now it seems that you're referring to section 6.2, and it's not clear what the relaxed rule is.

Jeffrey

From: Lucy yong [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 4:08 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Lucy,

Please see zzh2> below.

Hi Jeffery,

Hi Lucy,

Please see zzh> below.

Hi Authors,

Thanks,
Lucy

Jeffrey

Thanks,
Lucy

Jeffrey

Thanks.
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 2 Sep 2015 13:47:16 +0000

Hi Jeffery,

Let me clarify, I suggest to relax the second rule in Section 6.2, i.e. no need to require N to have exact same set of downstream neighbors in two tunnels. For example, if K1 has downstream neighbors n1~n10 and K2 has downstream neighbors n2-n10. N node can assign a single label for the upstream for both tunnels. As a result, the packet with this label from upstream node will be sent to downstream neighbors n1-n10; n1 accepts the packets that associate with K1 and discard the packets that associate with K2. N2-N10 will accept the packets that associate with either K1 or K2.

The reason I point out the section 9 is that at one time, K1 and K2 may have the same set of downstream neighbors, at another time, another downstream neighbors may advertise leaf A-D route for K1 but not K2, now N will have different set of downstream neighbors, N has to allocate different label for K1. Since leaf A-D route can by dynamically advertised by downstream neighbor for join, withdraw, parent change; rule #2 in section 6.2 makes sharing label or merge tunnel a hard condition to satisfy. If rule #2 is not satisfied, the node allocates different label for each tunnel, which results a large table; and changing the label on fly makes more complex for the parent, parent of patent, as so on.

Regards,
Lucy

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, September 01, 2015 3:16 PM
To: Lucy yong; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Lucy,

Jeffrey

Lucy,

Please see zzh2> below.

Hi Jeffery,

Hi Lucy,

Please see zzh> below.

Hi Authors,

Thanks,
Lucy

Jeffrey

Thanks,
Lucy

Jeffrey

Thanks.
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 2 Sep 2015 14:02:11 +0000

Hi Eric,

Please see below.

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Tuesday, September 01, 2015 3:15 PM
To: Lucy yong; Jeffrey (Zhaohui) Zhang; [email-masked]
Cc: [email-masked]
Subject: Re: [bess] comment on draft-ietf-bess-ir

> However, a child can use one leaf A-D with the new parent with a new 
> label and later send withdraw leaf A-D to the old parent

Lucy,

Note that "both" of Leaf A-D routes you mention above have the same NLRI and the same next hop.  Thus to BGP, these are really the same route.

- Send the same route with a different set of attributes to another neighbor;

- Then withdraw the route from the first neighbor without withdrawing it from the second.

This sort of functionality is not really supported by the BGP 
distribution mechanisms.   The MVPN mechanisms generally assume the 
typical BGP distribution mechanisms, where BGP chooses the bestpath for a particular NLRI, and then distributes it.
[Lucy] What you say is that, in BGP distribution mechanism, BGP (child here) chooses the bestpath (i.e. parent here) for a particular NLRI, then distributes the NLRI to all BGP peers (including the parent node). 

Since the NLRI is only stored by the parent node and may be removed by old parent node, such distribution mechanism has no advance for such purpose and causes a scaling issue. To reduce the distribution symptom, it should explicitly require that, if a node receiving a leaf A-D route is not the parent node including old parent node, the node should not redistribute the leaf A-D route; in other words, only the parent node is allowed to readvertise the leaf A-D route. In fact, for this purpose, use REFRESH msg may be better than UPDATE. This is about mcast membership announcement.

One question, if one ASBR or ABR node that is the parent for a set of downstream neighbors fails, what is the procedure for the downstream neighbors to select a new parent? If a child fails, the parent should update multicast state as if the child is withdrawn. 

Thanks,
Lucy

Eric

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 2 Sep 2015 14:10:24 +0000

Hi Lucy,

If downstream neighbor n1 relies on IP forwarding, it can discard the packet associated with k2 after an IP lookup. But if it does not (e.g., it uses label switching - because it is a segmentation point and has its own downstream segment), then it won't be able to discard traffic and will continue to forward traffic downstream.

Besides, w/o requiring the set of matching neighbors (and the matching encapsulation for each neighbor), it becomes hard for N to decide if it can advertise the same label for k1 and k2. It is true that the hard requirements causes more updates when downstream come and go, but that dynamic does not increase the complexity of the logic that allocates the label, and there are ways (e.g. dampening) to mitigate the thrashing. One may argue that the dampening will cause the same issue I mentioned in the previous paragraph, but I think it's better to have precise/hard rules on label allocation.

Jeffrey

From: Lucy yong [mailto:[email-masked]]
Sent: Wednesday, September 02, 2015 9:47 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Hi Jeffery,

Regards,
Lucy

Lucy,

Jeffrey

Lucy,

Please see zzh2> below.

Hi Jeffery,

Hi Lucy,

Please see zzh> below.

Hi Authors,

Thanks,
Lucy

Jeffrey

Thanks,
Lucy

Jeffrey

Thanks.
Lucy

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 2 Sep 2015 10:55:44 -0400

On 9/2/2015 9:47 AM, Lucy yong wrote:
> Let me clarify, I suggest to relax the second rule in Section 6.2, i.e.
> no need to require N to have exact same set of downstream neighbors in
> two tunnels. For example, if K1 has downstream neighbors n1~n10 and K2
> has downstream neighbors n2-n10. N node can assign a single label for
> the upstream for both tunnels. As a result, the packet with this label
> from upstream node will be sent to downstream neighbors n1-n10; n1
> accepts the packets that associate with K1 and discard the packets that
> associate with K2. N2-N10 will accept the packets that associate with
> either K1 or K2.

Lucy,

The ingress replication procedures are designed so that the forwarding 
is entirely MPLS-based, and the intermediate nodes are not required to 
examine the payload or to maintain any VPN-specific flow states.

In the scenario you describe above, the K1 packets from N and the K2 
packets from N will arrive at N1 with the same top label.  Hence N1 will 
forward the K1 packets just as if they were K2 packets, causing an 
unintended merging of the two tunnels.

Eric

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 2 Sep 2015 10:58:30 -0400

Hi Lucy,

It is certainly true that the BGP route distribution mechanism is not 
optimal for multicast signaling.  The advantages and disadvantages of 
using BGP for multicast signaling were discussed extensively in the WG 
when RFCs 6513 and 6514 were being written.  But the entire mechanism is 
built around the standard BGP route distribution procedures, and one has 
to be very cautious about making changes.

 > [Lucy] What you say is that, in BGP distribution mechanism, BGP
 > (child here) chooses the bestpath (i.e. parent here) for a particular
 > NLRI, then distributes the NLRI to all BGP peers (including the
 > parent node).

Right.  But ...

One thing you have to remember is that the child might not have a BGP 
session directly with the parent.  For instance, one can have a 
deployment where ingress replication is used in a non-segmented manner, 
such that the ingress PE makes a copy for each egress PE.  In this case, 
when an egress PE originates a Leaf A-D route, the RT will identify the 
ingress PE.  But ingress and egress PEs generally don't have BGP 
sessions to each other.  In many deployments, the ingress and egress PEs 
are clients of a route reflector; the egress PE sends the Leaf A-D route 
to the RR, and the RR redistributes it to the ingress PE.  In other 
deployments, the Leaf A-D route from a given egress PE may have to 
travel over several BGP sessions before it reaches the ingress PE.

 > Since the NLRI is only stored by the parent node and may be removed
 > by old parent node, such distribution mechanism has no advance for
 > such purpose and causes a scaling issue. To reduce the distribution
 > symptom, it should explicitly require that, if a node receiving a
 > leaf A-D route is not the parent node including old parent node, the
 > node should not redistribute the leaf A-D route; in other words, only
 > the parent node is allowed to readvertise the leaf A-D route.

This would break the deployment scenarios described above.

 > One question, if one ASBR or ABR node that is the parent for a set of
 > downstream neighbors fails, what is the procedure for the downstream
 > neighbors to select a new parent?

If a node fails, its BGP sessions go down, and the routes it originated 
are considered to have been withdrawn.  If parent and child are 
separated by a RR, failure of the parent will cause its session to the 
RR to go down.  The RR will then send withdraws to the child for all of 
the routes that were originated by the parent and redistributed to the 
child.

If there are two potential parents for a given flow, each will have 
originated an S-PMSI A-D route with an NLRI identifying the flow.  One 
of these S-PMSI A-D routes is the bestpath for that NLRI, and the next 
hop (or P2MP Inter-Area Segmented Next Hop Extended Community) of that 
route determines the parent that is chosen by a given child.  If that 
parent fails, the route from the other potential parent becomes the best 
path, and the child will then rehome itself by changing the RT on the 
Leaf A-D route.

 > If a child fails, the parent should
 > update multicast state as if the child is withdrawn.

If a child fails, its Leaf A-D route appears to the parent to have been 
withdrawn, and this causes the change in multicast state.

Note that the procedures for dealing with withdrawn S-PMSI or Leaf A-D 
routes are not specific to Ingress Replication.

Eric

---

From: Lucy yong <[email-masked]>
Date: Wed, 2 Sep 2015 16:00:06 +0000

Hi Eric,

Please see inline below with [Lucy1] and green text.

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]]
Sent: Wednesday, September 02, 2015 9:59 AM
To: Lucy yong; Jeffrey (Zhaohui) Zhang; [email-masked]
Cc: [email-masked]
Subject: Re: [bess] comment on draft-ietf-bess-ir

Hi Lucy,

It is certainly true that the BGP route distribution mechanism is not optimal for multicast signaling.  The advantages and disadvantages of using BGP for multicast signaling were discussed extensively in the WG when RFCs 6513 and 6514 were being written.  But the entire mechanism is built around the standard BGP route distribution procedures, and one has to be very cautious about making changes.

[Lucy1] I did not work on the subject by then and am not aware of these discussions. With these already published RFC, changes need to be cautious. But if there is an issue when using it, the enhancement is necessary.

> [Lucy] What you say is that, in BGP distribution mechanism, BGP  > (child here) chooses the bestpath (i.e. parent here) for a particular  > NLRI, then distributes the NLRI to all BGP peers (including the  > parent node).

Right.  But ...

One thing you have to remember is that the child might not have a BGP session directly with the parent.  For instance, one can have a deployment where ingress replication is used in a non-segmented manner, such that the ingress PE makes a copy for each egress PE.  In this case, when an egress PE originates a Leaf A-D route, the RT will identify the ingress PE.  But ingress and egress PEs generally don't have BGP sessions to each other.  In many deployments, the ingress and egress PEs are clients of a route reflector; the egress PE sends the Leaf A-D route to the RR, and the RR redistributes it to the ingress PE.  In other deployments, the Leaf A-D route from a given egress PE may have to travel over several BGP sessions before it reaches the ingress PE.

[Lucy1] For the RR case, RR will redistribute it to all PEs including the ingress PE, right? RR can be exception, i.e. RR always redistributes Leaf A-D. For other deployment, it seems the case that the IR applies, i.e. there is a distribution tree built by IR.

> Since the NLRI is only stored by the parent node and may be removed  > by old parent node, such distribution mechanism has no advance for  > such purpose and causes a scaling issue. To reduce the distribution  > symptom, it should explicitly require that, if a node receiving a  > leaf A-D route is not the parent node including old parent node, the  > node should not redistribute the leaf A-D route; in other words, only  > the parent node is allowed to readvertise the leaf A-D route.

[Lucy1] This mechanism raises a big scaling concern. If we have a separate rule for RR, my suggestion above may still work. RR has different roles.

BTW: I still think that REFRESH is better than UPDATE for this purpose.

> One question, if one ASBR or ABR node that is the parent for a set of  > downstream neighbors fails, what is the procedure for the downstream  > neighbors to select a new parent?

If a node fails, its BGP sessions go down, and the routes it originated are considered to have been withdrawn.  If parent and child are separated by a RR, failure of the parent will cause its session to the RR to go down.  The RR will then send withdraws to the child for all of the routes that were originated by the parent and redistributed to the child.

If there are two potential parents for a given flow, each will have originated an S-PMSI A-D route with an NLRI identifying the flow.  One of these S-PMSI A-D routes is the bestpath for that NLRI, and the next hop (or P2MP Inter-Area Segmented Next Hop Extended Community) of that route determines the parent that is chosen by a given child.  If that parent fails, the route from the other potential parent becomes the best path, and the child will then rehome itself by changing the RT on the Leaf A-D route.

[Lucy1] This means that each child node maintain all potential parents' information for a given flow although it only selects one patent. This is a resource scaling concern.

> update multicast state as if the child is withdrawn.

If a child fails, its Leaf A-D route appears to the parent to have been withdrawn, and this causes the change in multicast state.

Note that the procedures for dealing with withdrawn S-PMSI or Leaf A-D routes are not specific to Ingress Replication.

[Lucy1] Yes, this one is obvious.

Thanks,

Lucy

Eric

---

From: Lucy yong <[email-masked]>
Date: Wed, 2 Sep 2015 16:17:44 +0000

Hi Jeffery,

Please see inline below.

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Wednesday, September 02, 2015 9:10 AM
To: Lucy yong; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Hi Lucy,

If downstream neighbor n1 relies on IP forwarding, it can discard the packet associated with k2 after an IP lookup. But if it does not (e.g., it uses label switching - because it is a segmentation point and has its own downstream segment), then it won't be able to discard traffic and will continue to forward traffic downstream.
[Lucy] the rule in 6.2 does not require downstream neighbor to assign the same label for K1 and K2.  If it is, it follows its parent behavior described in the draft. Agree if all parent for both to meet the rules specified in Section 6.2, two tunnels share the same labels on the upstream path until two tunnels have different parent again.

Besides, w/o requiring the set of matching neighbors (and the matching encapsulation for each neighbor), it becomes hard for N to decide if it can advertise the same label for k1 and k2.
[Lucy] Maybe not, N can allocate if all or XX% downstream neighbors are the same such as 90%.  The higher %, the less packets are discarded at downstream node.
It is true that the hard requirements causes more updates when downstream come and go, but that dynamic does not increase the complexity of the logic that allocates the label, and there are ways (e.g. dampening) to mitigate the thrashing. One may argue that the dampening will cause the same issue I mentioned in the previous paragraph, but I think it's better to have precise/hard rules on label allocation.
[Lucy] However it is increasing router process, state changes, and forwarding update, which means increasing the complexity.

Thanks,
Lucy

Jeffrey

Hi Jeffery,

Regards,
Lucy

Lucy,

Jeffrey

Lucy,

Please see zzh2> below.

Hi Jeffery,

Hi Lucy,

Please see zzh> below.

Hi Authors,

Thanks,
Lucy

Jeffrey

Thanks,
Lucy

Jeffrey

Thanks.
Lucy

---

From: Lucy yong <[email-masked]>
Date: Wed, 2 Sep 2015 16:41:58 +0000

Hi Jeffery,

I did not complete the typing in previous mail, which makes unclear text. Revised text is inline below.

Hi Lucy,

Besides, w/o requiring the set of matching neighbors (and the matching encapsulation for each neighbor), it becomes hard for N to decide if it can advertise the same label for k1 and k2.
[Lucy] Maybe not, N can allocate the same label for two tunnels if all or >XX% downstream neighbors are the same for K1 and K2 such as 90%.  The higher %, the less packets will be discarded at downstream nodes.
It is true that the hard requirements causes more updates when downstream come and go, but that dynamic does not increase the complexity of the logic that allocates the label, and there are ways (e.g. dampening) to mitigate the thrashing. One may argue that the dampening will cause the same issue I mentioned in the previous paragraph, but I think it's better to have precise/hard rules on label allocation.
[Lucy] However it is increasing router process, state changes, and forwarding update, which means increasing the complexity.

Thanks,
Lucy

Jeffrey

Hi Jeffery,

Regards,
Lucy

Lucy,

Jeffrey

Lucy,

Please see zzh2> below.

Hi Jeffery,

Hi Lucy,

Please see zzh> below.

Hi Authors,

Thanks,
Lucy

Jeffrey

Thanks,
Lucy

Jeffrey

Thanks.
Lucy

---

From: Lucy yong <[email-masked]>
Date: Fri, 4 Sep 2015 02:41:33 +0000

Hi Eric and Jeffery,

Think more about using BGP mechanism to achieve the make before break at a child. 

The child can do it without parent cooperation. When a child changes the parent for a Leaf A-D route, it first sends out the route with the new parent address encoded in RT; when old parent receives the route, it does not need to take any action on it; the node that RT indicates receives the route make itself as the patent for the child and start sending the mcast to the child; When the child receives the mcast packets from both old parent and new patent, it discard the packet from new parent until timer is out, now child send out withdraw Leaf A-D route with old patent ID encoded in RT. The old patent updates multicast state and new patent do nothing when receiving the withdraw leaf A-D route.

Therefore, when a node receives a leaf A-D route, it first checks RT, if RT does not indicate this node, the node should not take any action. Only the child needs to set a timer. IMO: this is better approach than the one in the draft.

Regarding suppress the non-parent node to re-distribute the leaf A-D route, if we take RR as an exception case and require RR to re-distribute leaf A-D; IMO, it MAY work too. This will significantly reduce Leaf A-D route messages in BGP network and reduces node process on the messages, which makes the mechanism scale better in many ways.

Regarding relaxing the second rule in 6.2, IMO, it is better than the current rule because the solution allows a child to discard the packet if it comes from non-patent node. This improves network dampening upon dynamical membership changes. 

Regards,
Lucy

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Tuesday, September 01, 2015 3:15 PM
To: Lucy yong; Jeffrey (Zhaohui) Zhang; [email-masked]
Cc: [email-masked]
Subject: Re: [bess] comment on draft-ietf-bess-ir

Lucy,

Eric

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 21 Sep 2015 09:36:15 -0400

> The child can do it without parent cooperation. When a child changes
> the parent for a Leaf A-D route, it first sends out the route with
> the new parent address encoded in RT; when old parent receives the
> route, it does not need to take any action on it;

Note that if Constrained Route Distribution (RFC4684) is running, the
old parent will see an explicit withdraw when the RT is changed.

Even if Constrained Route Distribution is not running, once the 
attributes of a route are modified, the route is considered to have been 
implicitly withdrawn, and the route with the new attributes is 
considered to be a replacement route.  (See section 3.1 of RFC 4271.)

So once the RT no longer identifies the old parent, the old parent must
consider the route to have been withdrawn and replaced.  Since the 
replacement route does not identify the old parent, it does not impact 
the old parent's multicast state.

> The old parent updates multicast state and new parent do nothing when
> receiving the withdraw leaf A-D route.

As indicated above, the old parent will have seen an implicit or
explicit withdraw as soon as the RT was changed.

Further, if the new parent sees a withdraw, it cannot decide to maintain
the route anyway, as this would violate BGP semantics.

> Regarding suppress the non-parent node to re-distribute the leaf A-D
> route, if we take RR as an exception case and require RR to
> re-distribute leaf A-D; IMO, it MAY work too.

There are a variety of deployment scenarios in which a received Leaf A-D
route must be redistributed, even by a router that is not identified in
the route's RT and that is not an RR.  For instance, this will be
necessary if non-segmented P-tunnels are being used, but the routes need
to be distributed through multiple EBGP sessions in order to travel from
egress to ingress.  The only time it is safe to not redistribute a Leaf
A-D route is when one knows that the route has already reached its
target, or that it will reach its target through some other path.  There
is no simple set of rules to determine this.  If you want to constrain
the distribution of the Leaf A-D routes, you either need to use
Constrained Route Distribution, or to set up policies that are specific
to a particular deployment.

> I suggest to relax the second rule in Section 6.2, i.e. no need to
> require N to have exact same set of downstream neighbors in two
> tunnels. For example, if K1 has downstream neighbors n1~n10 and K2
> the upstream for both tunnels. As a result, the packet with this
> label from upstream node will be sent to downstream neighbors n1-n10;
> n1 accepts the packets that associate with K1 and discard the packets
> that associate with K2. N2-N10 will accept the packets that associate
> with either K1 or K2.

As Jeffrey has explained, there is no way in this scenario for N1 to 
determine that a particular packet should be associated with K1 rather 
than with K2.  Suppose the parent node receives packet P1 on tunnel K1 
and packet P2 on tunnel K2.  Since  those packets carry the same label, 
the parent node doesn't know which packet has arrived on which tunnel. 
The parent node will just do a label swap and send the packets along to 
N1-N10.  When N1 gets packets P1 and P2, they both have the same label, 
and therefore N1 has no way to determine that one of the two packets is 
on tunnel K2 and should be discarded.

---

From: Lucy yong <[email-masked]>
Date: Mon, 21 Sep 2015 18:30:20 +0000

Hi Eric,

Please see inline below,

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Monday, September 21, 2015 8:36 AM
To: Lucy yong; Jeffrey (Zhaohui) Zhang; [email-masked]
Cc: [email-masked]
Subject: Re: [bess] comment on draft-ietf-bess-ir

> the parent for a Leaf A-D route, it first sends out the route with the 
> new parent address encoded in RT; when old parent receives the route, 
> it does not need to take any action on it;

Note that if Constrained Route Distribution (RFC4684) is running, the old parent will see an explicit withdraw when the RT is changed.

Even if Constrained Route Distribution is not running, once the attributes of a route are modified, the route is considered to have been implicitly withdrawn, and the route with the new attributes is considered to be a replacement route.  (See section 3.1 of RFC 4271.)

So once the RT no longer identifies the old parent, the old parent must consider the route to have been withdrawn and replaced.  Since the replacement route does not identify the old parent, it does not impact the old parent's multicast state.

[Lucy] An patent for a mcast group can not consider the route to have been withdrawn and replaced because of RT is not indicate the parent. The parent must check if the leaf A-D for the mcast is from its child. There is a case, a patent for a mcast group receives an leaf A-D of the group from a downstream node whose patent is not this patent. In this case, the patent must not treat it as implicitly withdraw. The solution requires that, 

upon receiving leaf A-D route, every node does 

if it is the patent for this mcast, 
    if sending node is its child,
       if RT is the same as the node address
          update the mcast state as update
       else
          treat as withdraw and update accordingly;
       end if
    else 
        do nothing;
    end if
else 
    if RT is the same as the node address
       update the mcast state as new join
    else 
       do nothing
    end if
end if 
        
[Lucy] BGP is a distribution protocol and require every node performing the logic, it does not scale. If we use BGP as signaling purpose, a receiving node should first check if the RT is the same as the node address; if not, do nothing; if yes, act on it. This is a simpler logic. This requires that a child node has to explicitly send the withdraw leaf A-D when changing its patent; as a result, the parent no longer need to sync with the child on "make before break" process. -end
 
> receiving the withdraw leaf A-D route.

As indicated above, the old parent will have seen an implicit or explicit withdraw as soon as the RT was changed.

Further, if the new parent sees a withdraw, it cannot decide to maintain the route anyway, as this would violate BGP semantics.

> re-distribute leaf A-D; IMO, it MAY work too.

There are a variety of deployment scenarios in which a received Leaf A-D route must be redistributed, even by a router that is not identified in the route's RT and that is not an RR.  For instance, this will be necessary if non-segmented P-tunnels are being used, but the routes need to be distributed through multiple EBGP sessions in order to travel from egress to ingress.  The only time it is safe to not redistribute a Leaf A-D route is when one knows that the route has already reached its target, or that it will reach its target through some other path.  There is no simple set of rules to determine this.  If you want to constrain the distribution of the Leaf A-D routes, you either need to use Constrained Route Distribution, or to set up policies that are specific to a particular deployment.
[Lucy] Leaf A-D is for downstream to inform upstream patent, shouldn't be the same for segmented P-tunnels (IR) or non-segmented P-tunnels? If not, please explain.

> tunnels. For example, if K1 has downstream neighbors n1~n10 and K2 has 
> downstream neighbors n2-n10. N node can assign a single label for the 
> upstream for both tunnels. As a result, the packet with this label 
> from upstream node will be sent to downstream neighbors n1-n10;

As Jeffrey has explained, there is no way in this scenario for N1 to determine that a particular packet should be associated with K1 rather than with K2.  Suppose the parent node receives packet P1 on tunnel K1 and packet P2 on tunnel K2.  Since  those packets carry the same label, the parent node doesn't know which packet has arrived on which tunnel. 
The parent node will just do a label swap and send the packets along to N1-N10.  When N1 gets packets P1 and P2, they both have the same label, and therefore N1 has no way to determine that one of the two packets is on tunnel K2 and should be discarded.
[Lucy] The case you describe is the case that N1 also merges packets from tunnel K1 and K2. At an egress node, it knows which receivers should get a packet from K1 and which from K2. In another case, the N1 may have two downstream neighbors, one is for K1 tunnel only and another for K2 tunnel only, although N1 allocates the same label for both, downstream nodes are different, it is OK to merge. IMO: this also makes simpler for some case.

Thanks,
Lucy

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 21 Sep 2015 20:41:04 +0000

Lucy,

[Lucy] ... If we use BGP as signaling purpose, a receiving node should first check if the RT is the same as the node address; if not, do nothing; if yes, act on it. This is a simpler logic.

That is exactly how it works.

Originally, a parent receives a Leaf route from its child with matching RT. Later, the child sends an update with a different RT because the child now chooses a different parent. To the original parent, this updated route the new RT is treated as an implicit withdraw (the route is no long imported). An explicit withdraw is not used.

Jeffrey

> Sent: Monday, September 21, 2015 2:30 PM
> To: Eric Rosen <[email-masked]>; Jeffrey (Zhaohui) Zhang
> <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Note that if Constrained Route Distribution (RFC4684) is running, the old
> parent will see an explicit withdraw when the RT is changed.
> 
> Even if Constrained Route Distribution is not running, once the attributes
> of a route are modified, the route is considered to have been implicitly
> withdrawn, and the route with the new attributes is considered to be a
> replacement route.  (See section 3.1 of RFC 4271.)
> 
> replacement route does not identify the old parent, it does not impact the
> old parent's multicast state.
> 
> [Lucy] An patent for a mcast group can not consider the route to have been
> withdrawn and replaced because of RT is not indicate the parent. The
> parent must check if the leaf A-D for the mcast is from its child. There
> is a case, a patent for a mcast group receives an leaf A-D of the group
> from a downstream node whose patent is not this patent. In this case, the
> patent must not treat it as implicitly withdraw. The solution requires
> that,
> 
> [Lucy] BGP is a distribution protocol and require every node performing
> the logic, it does not scale. If we use BGP as signaling purpose, a
> receiving node should first check if the RT is the same as the node
> address; if not, do nothing; if yes, act on it. This is a simpler logic.
> This requires that a child node has to explicitly send the withdraw leaf
> A-D when changing its patent; as a result, the parent no longer need to
> sync with the child on "make before break" process. -end
> 
> egress to ingress.  The only time it is safe to not redistribute a Leaf A-
> D route is when one knows that the route has already reached its target,
> or that it will reach its target through some other path.  There is no
> simple set of rules to determine this.  If you want to constrain the
> distribution of the Leaf A-D routes, you either need to use Constrained
> Route Distribution, or to set up policies that are specific to a
> particular deployment.
> [Lucy] Leaf A-D is for downstream to inform upstream patent, shouldn't be
> the same for segmented P-tunnels (IR) or non-segmented P-tunnels? If not,
> please explain.
> 
> than with K2.  Suppose the parent node receives packet P1 on tunnel K1 and
> packet P2 on tunnel K2.  Since  those packets carry the same label, the
> parent node doesn't know which packet has arrived on which tunnel.
> and therefore N1 has no way to determine that one of the two packets is on
> tunnel K2 and should be discarded.
> [Lucy] The case you describe is the case that N1 also merges packets from
> tunnel K1 and K2. At an egress node, it knows which receivers should get a
> packet from K1 and which from K2. In another case, the N1 may have two
> downstream neighbors, one is for K1 tunnel only and another for K2 tunnel
> only, although N1 allocates the same label for both, downstream nodes are
> different, it is OK to merge. IMO: this also makes simpler for some case.
> 
> Thanks,
> Lucy
> 
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 22 Sep 2015 02:20:02 +0000

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Monday, September 21, 2015 3:41 PM
To: Lucy yong; Eric Rosen; [email-masked]
Cc: [email-masked]
Subject: Re: [bess] comment on draft-ietf-bess-ir

Lucy,

That is exactly how it works.
[Lucy1] IMO: what you describe below does not confirm this statement. At the first, what is used for a node to determine itself as of a parent, what in the RT and/or if the sender is in the child list? The latter is an expensive check.

Lucy

Jeffrey

> attributes of a route are modified, the route is considered to have 
> been implicitly withdrawn, and the route with the new attributes is 
> So once the RT no longer identifies the old parent, the old parent 
> must consider the route to have been withdrawn and replaced.  Since 
> the replacement route does not identify the old parent, it does not 
> impact the old parent's multicast state.
> 
> [Lucy] An patent for a mcast group can not consider the route to have 
> been withdrawn and replaced because of RT is not indicate the parent. 
> The parent must check if the leaf A-D for the mcast is from its child. 
> There is a case, a patent for a mcast group receives an leaf A-D of 
> the group from a downstream node whose patent is not this patent. In 
> this case, the patent must not treat it as implicitly withdraw. The 
> solution requires that,
> 
> [Lucy] BGP is a distribution protocol and require every node 
> performing the logic, it does not scale. If we use BGP as signaling 
> purpose, a receiving node should first check if the RT is the same as 
> the node address; if not, do nothing; if yes, act on it. This is a simpler logic.
> This requires that a child node has to explicitly send the withdraw 
> leaf A-D when changing its patent; as a result, the parent no longer 
> need to sync with the child on "make before break" process. -end
> 
> > The old parent updates multicast state and new parent do nothing 
> > when receiving the withdraw leaf A-D route.
> 
> Further, if the new parent sees a withdraw, it cannot decide to 
> maintain the route anyway, as this would violate BGP semantics.
> 
> There are a variety of deployment scenarios in which a received Leaf 
> A-D route must be redistributed, even by a router that is not 
> identified in the route's RT and that is not an RR.  For instance, 
> this will be necessary if non-segmented P-tunnels are being used, but 
> the routes need to be distributed through multiple EBGP sessions in 
> order to travel from egress to ingress.  The only time it is safe to 
> not redistribute a Leaf A- D route is when one knows that the route 
> has already reached its target, or that it will reach its target 
> through some other path.  There is no simple set of rules to determine 
> this.  If you want to constrain the distribution of the Leaf A-D 
> routes, you either need to use Constrained Route Distribution, or to 
> set up policies that are specific to a particular deployment.
> [Lucy] Leaf A-D is for downstream to inform upstream patent, shouldn't 
> be the same for segmented P-tunnels (IR) or non-segmented P-tunnels? 
> If not, please explain.
> 
> > has downstream neighbors n2-n10. N node can assign a single label 
> > for the upstream for both tunnels. As a result, the packet with this 
> > n1 accepts the packets that associate with K1 and discard the 
> > packets that associate with K2. N2-N10 will accept the packets that 
> > associate with either K1 or K2.
> 
> and packet P2 on tunnel K2.  Since  those packets carry the same 
> label, the parent node doesn't know which packet has arrived on which tunnel.
> The parent node will just do a label swap and send the packets along 
> to N1-N10.  When N1 gets packets P1 and P2, they both have the same 
> label, and therefore N1 has no way to determine that one of the two 
> packets is on tunnel K2 and should be discarded.
> [Lucy] The case you describe is the case that N1 also merges packets 
> from tunnel K1 and K2. At an egress node, it knows which receivers 
> should get a packet from K1 and which from K2. In another case, the N1 
> may have two downstream neighbors, one is for K1 tunnel only and 
> another for K2 tunnel only, although N1 allocates the same label for 
> both, downstream nodes are different, it is OK to merge. IMO: this also makes simpler for some case.
> 
> Thanks,
> Lucy
> 
> 

_______________________________________________
BESS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bess

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 22 Sep 2015 13:19:50 -0400

Hi Lucy,

[Lucy] A parent for a mcast group can not consider the route to have
been withdrawn and replaced because of RT is not indicate the parent.
The parent must check if the leaf A-D for the mcast is from its child.
There is a case, a parent for a mcast group receives an leaf A-D of the
group from a downstream node whose parent is not this parent. In this
case, the parent must not treat it as implicit withdraw.

I believe your suggestion is in violation of the BGP specification.

[Lucy] Leaf A-D is for downstream to inform upstream parent, shouldn't
be the same for segmented P-tunnels (IR) or non-segmented P-tunnels? If
not, please explain.

When non-segmented ingress replication is used, the ingress PE needs to 
see the Leaf A-D routes from all the egress PEs.  (The ingress PE is the 
upstream parent in this case, even if the ingress PE is not a BGP peer 
of the egress PEs.)  This means that the RT on the Leaf A-D routes needs 
to identify the ingress PE.  However, the Leaf A-D routes may need to 
travel over multiple BGP sessions before they reach the ingress PE. 
Some of these BGP sessions may be IBGP sessions, some may be EBGP 
sessions. It's rather important that the route not get discarded before 
it reaches the ingress PE, even though it passes through multiple BGP 
speakers.  If one wants to constrain the distribution of the routes, one 
still has to guarantee that the routes will reach their targets.

Now let's turn to the issue you raised with regard to section 6.2 of the 
draft -- when is it is safe for an intermediate node to assign the same 
label to two tunnels?

Consider two flows that originate from the same ingress PE (and same 
ingress VRF).  Call these flows K1 and K2.  We'll call the ingress PE 
"I-PE".

Let's consider a single egress PE, "E-PE", and let's suppose that we are 
using segmented ingress replication.

The following diagram depicts a possible way that the Leaf A-D routes 
may flow from E-PE to I-PE (thanks, Jeffrey, for the diagram):

                    K1: L4 <----       K1: L2 <----
       <------    -------------- N2 -----------------      <-----
       K1&K2: L6 /                                   \    K1&K2: L1
I-PE --------- N1                                   N3 ----------- E-PE
                 \                                   /
                  -------------- N4 -----------------
                    K2: L5 <----       K2: L3 <----
In words:

- E-PE sends Leaf(K1) to N3 with label L1.

- E-PE sends Leaf(K2) to N3 with label L1. (Flows K1 and K2 have same 
ingress PE and same parent node, so can be assigned the same label.)

- N3 sends Leaf(K1) to N2 with label L2.

- N3 sends Leaf(K2) to N4 with label L3.  (The choice of N4 rather than 
N2 as parent might be due to ECMP.)

- N2 sends Leaf(K1) to N1, with label L4.

- N4 sends Leaf(K2) to N1, with label L5.

Now N1 has to send both Leaf(K1) and Leaf(K2) to I-PE.  Per section 6.2, 
it will assign a different label in each Leaf A-D route, since K1 and K2 
have different children.  But let's suppose for now we follow your 
suggestion, and allow N1 to assign the same label (L6) in both Leaf A-D 
routes.

Let's look at the resulting data flow.  Suppose I-PE sends a K1 packet 
to N1, with label L6.  N1 will have to send this packet to N2 with label 
L4, and to N4 with label L6.

N2 will send the packet to N3 with label L2, and N4 will send the packet 
to N3 with label L3.

N3 will send both packets to E-PE with label L1.

E-PE will then have received two copies of the K1 packet, and both 
copies carry label L1.  Therefore E-PE has no way of knowing that it 
needs to discard one copy.  The result is that E-PE will forward 
duplicate traffic out its VRF interface.

On the other hand, if we follow the procedure specifies in section 6.2, 
N1 will not forward K1 packets to N4, and E-PE will not forward 
duplicate traffic.

Eric

---

From: Lucy yong <[email-masked]>
Date: Tue, 22 Sep 2015 22:09:41 +0000

Hi Eric,

Please see inline below with [Lucy1]

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]]
Sent: Tuesday, September 22, 2015 12:20 PM
To: Lucy yong; Jeffrey (Zhaohui) Zhang; [email-masked]
Cc: [email-masked]
Subject: Re: [bess] comment on draft-ietf-bess-ir

Hi Lucy,

[Lucy] A parent for a mcast group can not consider the route to have been withdrawn and replaced because of RT is not indicate the parent.

There is a case, a parent for a mcast group receives an leaf A-D of the group from a downstream node whose parent is not this parent. In this case, the parent must not treat it as implicit withdraw.

[Lucy1] Above is not my suggestion. My suggestion has been lost in "copy/paste". What is the violation of the BGP specification? Do you mean: A node sends a leaf A-D route with a RT first and then sends the withdraw leaf A-D route with different RT value?

[Lucy] Leaf A-D is for downstream to inform upstream parent, shouldn't be the same for segmented P-tunnels (IR) or non-segmented P-tunnels? If not, please explain.

When non-segmented ingress replication is used, the ingress PE needs to see the Leaf A-D routes from all the egress PEs.  (The ingress PE is the upstream parent in this case, even if the ingress PE is not a BGP peer of the egress PEs.)  This means that the RT on the Leaf A-D routes needs to identify the ingress PE.  However, the Leaf A-D routes may need to travel over multiple BGP sessions before they reach the ingress PE.

Some of these BGP sessions may be IBGP sessions, some may be EBGP sessions. It's rather important that the route not get discarded before it reaches the ingress PE, even though it passes through multiple BGP speakers.  If one wants to constrain the distribution of the routes, one still has to guarantee that the routes will reach their targets.

[Lucy1] Thx. IMO: this mechanism for membership announcement raises a BIG concern on the scalability and performance. Why is it not a concern for you?

Now let's turn to the issue you raised with regard to section 6.2 of the draft -- when is it is safe for an intermediate node to assign the same label to two tunnels?

[Lucy1] Agree, it has an issue in this ECMP example (for N3). Thanks.

Lucy

Consider two flows that originate from the same ingress PE (and same ingress VRF).  Call these flows K1 and K2.  We'll call the ingress PE "I-PE".

Let's consider a single egress PE, "E-PE", and let's suppose that we are using segmented ingress replication.

The following diagram depicts a possible way that the Leaf A-D routes may flow from E-PE to I-PE (thanks, Jeffrey, for the diagram):

       K1&K2: L6 /                                   \    K1&K2: L1

                 \                                   /

                  -------------- N4 -----------------

In words:

routes.

to N3 with label L3.

duplicate traffic.

Eric

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 13:58:26 +0000

Hi Eric,

[Lucy] If each BGP session keeps track of P-tunnel neighbor state: 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A simple policy can suppress a lot distribution: redistribute a Leaf A-D route if and only if it is sent by a downstream neighbor. This ensures that ingress PE receives all the Leaf A-D routes from all the egress PEs.

Thanks,
Lucy

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Sep 2015 14:16:35 +0000

Lucy,

Let's use this example to illustrate the points we tried to get through:

        N1        N2
          \      /
           \    /
             RR
              |
              |
             N3

N3 originates a Leaf AD route. Originally the parent is N1 so the Leaf AD route has RT(N1). Then the parent changes to N2 so N3 sends an update with new RT(N2). There is no withdraw from N3 at all.

The route and its update is sent by N3 to only the RR.

If Constraint Route Distribution (RFC 4684) is used, only N1 will get the initial route, and when N3 sends the update, RR will withdraw it from N1 and send the route to N2.

If that is not used, then both N1 and N2 will get the original route and the update. Because the RT(N2) in the update does not match N1, N1 will treat the update as an implicit withdraw.

So, in the first case, N1 will get the withdraw that is controlled by the RR, which only follows BGP route distribution process and does not understand MVPN/IR rules at all. In the second case, there is no explicit withdraw at all. In both cases, N3 only sends an update.

Jeffrey

> Sent: Wednesday, September 23, 2015 9:58 AM
> upstream parent in this case, even if the ingress PE is not a BGP peer of
> the egress PEs.)  This means that the RT on the Leaf A-D routes needs to
> identify the ingress PE.  However, the Leaf A-D routes may need to travel
> over multiple BGP sessions before they reach the ingress PE.
> Some of these BGP sessions may be IBGP sessions, some may be EBGP sessions.
> It's rather important that the route not get discarded before it reaches
> the ingress PE, even though it passes through multiple BGP speakers.  If
> one wants to constrain the distribution of the routes, one still has to
> guarantee that the routes will reach their targets.
> 
> 
> [Lucy] If each BGP session keeps track of P-tunnel neighbor state: 1) the
> downstream neighbor, 2) the upstream neighbor, or 3) N/A. A simple policy
> can suppress a lot distribution: redistribute a Leaf A-D route if and only
> if it is sent by a downstream neighbor. This ensures that ingress PE
> receives all the Leaf A-D routes from all the egress PEs.
> 
> Thanks,
> Lucy
> 
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 14:25:47 +0000

Hi Jeff,

We seem across each other. Two potential optimizations I proposed: 1) suppress unnecessary redistribution; 2) method for child to change its patent. I am not clear which one example illustrates. Both need to work with and without RR. 

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Wednesday, September 23, 2015 9:17 AM
To: Lucy yong; Eric Rosen; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Lucy,

        N1        N2
          \      /
           \    /
             RR
              |
              |
             N3

Jeffrey

> When non-segmented ingress replication is used, the ingress PE needs 
> to see the Leaf A-D routes from all the egress PEs.  (The ingress PE 
> is the upstream parent in this case, even if the ingress PE is not a 
> BGP peer of the egress PEs.)  This means that the RT on the Leaf A-D 
> routes needs to identify the ingress PE.  However, the Leaf A-D routes 
> may need to travel over multiple BGP sessions before they reach the ingress PE.
> It's rather important that the route not get discarded before it 
> reaches the ingress PE, even though it passes through multiple BGP 
> speakers.  If one wants to constrain the distribution of the routes, 
> one still has to guarantee that the routes will reach their targets.
> 
> 
> [Lucy] If each BGP session keeps track of P-tunnel neighbor state: 1) 
> the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A simple 
> policy can suppress a lot distribution: redistribute a Leaf A-D route 
> if and only if it is sent by a downstream neighbor. This ensures that 
> ingress PE receives all the Leaf A-D routes from all the egress PEs.
> 
> Thanks,
> Lucy
> 
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Sep 2015 14:28:04 +0000

Lucy,

The point is that we rely on BGP distribution mechanism, and we cannot expect RRs to do more than basic route distribution.

Jeffrey

> Sent: Wednesday, September 23, 2015 10:26 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Eric Rosen
> <[email-masked]>; [email-masked]
> Cc: [email-masked]
> We seem across each other. Two potential optimizations I proposed: 1)
> suppress unnecessary redistribution; 2) method for child to change its
> patent. I am not clear which one example illustrates. Both need to work
> with and without RR.
> 
> N3 originates a Leaf AD route. Originally the parent is N1 so the Leaf AD
> route has RT(N1). Then the parent changes to N2 so N3 sends an update with
> new RT(N2). There is no withdraw from N3 at all.
> 
> If Constraint Route Distribution (RFC 4684) is used, only N1 will get the
> initial route, and when N3 sends the update, RR will withdraw it from N1
> and send the route to N2.
> 
> If that is not used, then both N1 and N2 will get the original route and
> the update. Because the RT(N2) in the update does not match N1, N1 will
> treat the update as an implicit withdraw.
> 
> So, in the first case, N1 will get the withdraw that is controlled by the
> RR, which only follows BGP route distribution process and does not
> understand MVPN/IR rules at all. In the second case, there is no explicit
> withdraw at all. In both cases, N3 only sends an update.
> 
> Jeffrey
> 
> 
> sessions.

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 14:31:15 +0000

Hi Jeff,

As I said before, RR always need to distribute Leaf A-D routes.

Lucy

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Wednesday, September 23, 2015 9:28 AM
To: Lucy yong; Eric Rosen; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Lucy,

Jeffrey

> patent. I am not clear which one example illustrates. Both need to 
> work with and without RR.
> 
> N3 originates a Leaf AD route. Originally the parent is N1 so the Leaf 
> AD route has RT(N1). Then the parent changes to N2 so N3 sends an 
> update with new RT(N2). There is no withdraw from N3 at all.
> 
> If Constraint Route Distribution (RFC 4684) is used, only N1 will get 
> the initial route, and when N3 sends the update, RR will withdraw it 
> from N1 and send the route to N2.
> 
> If that is not used, then both N1 and N2 will get the original route 
> and the update. Because the RT(N2) in the update does not match N1, N1 
> will treat the update as an implicit withdraw.
> 
> So, in the first case, N1 will get the withdraw that is controlled by 
> the RR, which only follows BGP route distribution process and does not 
> understand MVPN/IR rules at all. In the second case, there is no 
> explicit withdraw at all. In both cases, N3 only sends an update.
> 
> Jeffrey
> 
> 
> > routes needs to identify the ingress PE.  However, the Leaf A-D 
> > routes may need to travel over multiple BGP sessions before they 
> > reach the
> ingress PE.
> > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: 
> > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A 
> > simple policy can suppress a lot distribution: redistribute a Leaf 
> > A-D route if and only if it is sent by a downstream neighbor. This 
> > ensures that ingress PE receives all the Leaf A-D routes from all the egress PEs.
> >
> > Thanks,
> > Lucy
> >
> >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Sep 2015 14:35:30 +0000

Lucy, 

Perhaps you can elaborate the following then?

There is no BGP session between N1/N2 and N3. RR does not understand "upstream/downstream" neighbor.
Even on N1/N2/N3, upstream/downstream are wrt different flows. How do you configure such policies?

Jeffrey

> Sent: Wednesday, September 23, 2015 10:31 AM
> The point is that we rely on BGP distribution mechanism, and we cannot
> expect RRs to do more than basic route distribution.
> 
> Jeffrey
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 14:47:35 +0000

Jeff,

RR does not change BGP next hop on the update. N1 and N2 can determine P-tunnel neighbor based on BGP next hop.

Lucy

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Wednesday, September 23, 2015 9:36 AM
To: Lucy yong; Eric Rosen; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Lucy, 

Jeffrey

> > We seem across each other. Two potential optimizations I proposed: 
> > 1) suppress unnecessary redistribution; 2) method for child to 
> > change its patent. I am not clear which one example illustrates. 
> > Both need to work with and without RR.
> >
> > N3 originates a Leaf AD route. Originally the parent is N1 so the 
> > Leaf AD route has RT(N1). Then the parent changes to N2 so N3 sends 
> > an update with new RT(N2). There is no withdraw from N3 at all.
> >
> > If Constraint Route Distribution (RFC 4684) is used, only N1 will 
> > get the initial route, and when N3 sends the update, RR will 
> > withdraw it from N1 and send the route to N2.
> >
> > and the update. Because the RT(N2) in the update does not match N1, 
> > N1 will treat the update as an implicit withdraw.
> >
> > So, in the first case, N1 will get the withdraw that is controlled 
> > by the RR, which only follows BGP route distribution process and 
> > does not understand MVPN/IR rules at all. In the second case, there 
> > is no explicit withdraw at all. In both cases, N3 only sends an update.
> >
> > Jeffrey
> >
> >
> > > When non-segmented ingress replication is used, the ingress PE 
> > > needs to see the Leaf A-D routes from all the egress PEs.  (The 
> > > ingress PE is the upstream parent in this case, even if the 
> > > ingress PE is not a BGP peer of the egress PEs.)  This means that 
> > > the RT on the Leaf A-D routes needs to identify the ingress PE.  
> > > However, the Leaf A-D routes may need to travel over multiple BGP 
> > > sessions before they reach the
> > ingress PE.
> > > speakers.  If one wants to constrain the distribution of the 
> > > routes, one still has to guarantee that the routes will reach their targets.
> > >
> > >
> > > ensures that ingress PE receives all the Leaf A-D routes from all 
> > > the
> egress PEs.
> > >
> > > Thanks,
> > > Lucy
> > >
> > >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Sep 2015 14:51:30 +0000

So it's not "BGP session keeps track"; and what's your policy like?

Back to your proposals:

>Two potential optimizations I proposed:
> 1) suppress unnecessary redistribution; 2) method for child to change its patent.

Using the simple example, what's exactly the proposal for 1) and 2)?

Jeffrey

> Sent: Wednesday, September 23, 2015 10:48 AM

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 15:16:06 +0000

Hi Jeff,

To suppress unnecessary redistribution, a P-tunnel BGP node tracks P-tunnel neighbor state. A BGP next hop is one of P-tunnel downstream neighbor, upstream neighbor, and N/A. The policy is, if the BGP next hop of the UPDATE of Leaf A-D route is the downstream neighbor, redistribution the route; if not, no redistribution. (there may be other polices)

To change the parent, a child sends out the UPDATE of Leaf A-D route with new patent address in RT, a BGP node receives the update, check the RT on the UPDATE, 
if RT points to the BGP node, 
  updates mcast state; 
end if

after child timer expires, the child sends out the UPDATE of withdraw Leaf A-D route with old patent address in RT, the old patent will update the mcast state once receiving the UPDATE.

Lucy

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]] 
Sent: Wednesday, September 23, 2015 9:52 AM
To: Lucy yong; Eric Rosen; [email-masked]
Cc: [email-masked]
Subject: RE: [bess] comment on draft-ietf-bess-ir

Jeffrey

> RR does not change BGP next hop on the update. N1 and N2 can determine 
> P- tunnel neighbor based on BGP next hop.
> 
> Lucy
> 
> > The point is that we rely on BGP distribution mechanism, and we 
> > cannot expect RRs to do more than basic route distribution.
> >
> > Jeffrey
> >
> > > Leaf AD route has RT(N1). Then the parent changes to N2 so N3 
> > > sends an update with new RT(N2). There is no withdraw from N3 at all.
> > >
> > > If that is not used, then both N1 and N2 will get the original 
> > > route and the update. Because the RT(N2) in the update does not 
> > > match N1,
> > > does not understand MVPN/IR rules at all. In the second case, 
> > > there is no explicit withdraw at all. In both cases, N3 only sends an update.
> > >
> > > Jeffrey
> > >
> > >
> > > > ingress PE is not a BGP peer of the egress PEs.)  This means 
> > > > that the RT on the Leaf A-D routes needs to identify the ingress PE.
> > > > However, the Leaf A-D routes may need to travel over multiple 
> > > > BGP sessions before they reach the
> > > ingress PE.
> > > > reaches the ingress PE, even though it passes through multiple 
> > > > BGP speakers.  If one wants to constrain the distribution of the 
> > > > routes, one still has to guarantee that the routes will reach 
> > > > their
> targets.
> > > >
> > > >
> > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. 
> > > > A simple policy can suppress a lot distribution: redistribute a 
> > > > Leaf A-D route if and only if it is sent by a downstream 
> > > > neighbor. This ensures that ingress PE receives all the Leaf A-D 
> > > > routes from all the
> > egress PEs.
> > > >
> > > > Thanks,
> > > > Lucy
> > > >
> > > >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Sep 2015 16:58:32 +0000

Lucy,

> Sent: Wednesday, September 23, 2015 11:16 AM
> To suppress unnecessary redistribution, a P-tunnel BGP node tracks P-
> tunnel neighbor state. A BGP next hop is one of P-tunnel downstream
> neighbor, upstream neighbor, and N/A. The policy is, if the BGP next hop
> of the UPDATE of Leaf A-D route is the downstream neighbor, redistribution
> the route; if not, no redistribution. (there may be other polices)

Let me skip this for now. Maybe it'll become a moot point, but we can come back.

> 
> To change the parent, a child sends out the UPDATE of Leaf A-D route with
> new patent address in RT, a BGP node receives the update, check the RT on
> the UPDATE,

This is the current behavior.

> 
> after child timer expires, the child sends out the UPDATE of withdraw Leaf
> A-D route with old patent address in RT, the old patent will update the
> mcast state once receiving the UPDATE.

My example explains that, N3 can only send one update, with the new RT. How does the above proposal work in my example setup?

Thanks.
Jeffrey

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 18:24:32 +0000

Hi Jeff,

Please see inline below.
> neighbor, upstream neighbor, and N/A. The policy is, if the BGP next 
> hop of the UPDATE of Leaf A-D route is the downstream neighbor, 
> redistribution the route; if not, no redistribution. (there may be 
> other polices)

> 
> To change the parent, a child sends out the UPDATE of Leaf A-D route 
> with new patent address in RT, a BGP node receives the update, check 
> the RT on the UPDATE, if RT points to the BGP node,
>   updates mcast state;
> end if

This is the current behavior.
[Lucy] No, it is not. This is only half of the current behavior. Current solution also requires a node to update mcast state even the RT does not point to the BGP node (as long as the sender node is the child of the node).

> 
> after child timer expires, the child sends out the UPDATE of withdraw 
> Leaf A-D route with old patent address in RT, the old patent will 
> update the mcast state once receiving the UPDATE.

My example explains that, N3 can only send one update, with the new RT. How does the above proposal work in my example setup?
[Lucy] In my proposed solution, N3 will send two updates, the first one with new parent address in RT, the second one is withdraw and have old patent address in RT. RR distributes both two N1 and N2. N2 acts on the first update and become the parent; N1 acts on the second update and remove this child from mcast state.

Thanks,
Lucy

Thanks.
Jeffrey

> >change
> its patent.
> > > > N3 originates a Leaf AD route. Originally the parent is N1 so 
> > > > the Leaf AD route has RT(N1). Then the parent changes to N2 so 
> > > > N3 sends an update with new RT(N2). There is no withdraw from N3 at all.
> > > >
> > > > If Constraint Route Distribution (RFC 4684) is used, only N1 
> > > > will get the initial route, and when N3 sends the update, RR 
> > > > will withdraw it from N1 and send the route to N2.
> > > >
> > > > So, in the first case, N1 will get the withdraw that is 
> > > > controlled by the RR, which only follows BGP route distribution 
> > > > process and does not understand MVPN/IR rules at all. In the 
> > > > second case, there is no explicit withdraw at all. In both 
> > > > cases, N3 only sends
> an update.
> > > >
> > > > Jeffrey
> > > >
> > > >
> > > > > needs to see the Leaf A-D routes from all the egress PEs.  
> > > > > (The ingress PE is the upstream parent in this case, even if 
> > > > > the ingress PE is not a BGP peer of the egress PEs.)  This 
> > > > > means that the RT on the Leaf A-D routes needs to identify the 
> > > > > ingress
> PE.
> > > > > It's rather important that the route not get discarded before 
> > > > > it reaches the ingress PE, even though it passes through 
> > > > > multiple BGP speakers.  If one wants to constrain the 
> > > > > distribution of the routes, one still has to guarantee that 
> > > > > the routes will reach their
> > targets.
> > > > >
> > > > >
> > > > > A simple policy can suppress a lot distribution: redistribute 
> > > > > a Leaf A-D route if and only if it is sent by a downstream 
> > > > > neighbor. This ensures that ingress PE receives all the Leaf 
> > > > > A-D routes from all the
> > > egress PEs.
> > > > >
> > > > > Thanks,
> > > > > Lucy
> > > > >
> > > > >

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Sep 2015 19:07:20 +0000

Lucy,

> [Lucy] In my proposed solution, N3 will send two updates, the first one
> with new parent address in RT, the second one is withdraw and have old
> patent address in RT.

That violates BGP rules. The withdraw will reach N2 as well and be treated as withdraw.

Jeffrey

> Sent: Wednesday, September 23, 2015 2:25 PM
> [Lucy] No, it is not. This is only half of the current behavior. Current
> solution also requires a node to update mcast state even the RT does not
> point to the BGP node (as long as the sender node is the child of the
> node).
> 
> 
> >
> My example explains that, N3 can only send one update, with the new RT.
> How does the above proposal work in my example setup?
> [Lucy] In my proposed solution, N3 will send two updates, the first one
> with new parent address in RT, the second one is withdraw and have old
> patent address in RT. RR distributes both two N1 and N2. N2 acts on the
> first update and become the parent; N1 acts on the second update and
> remove this child from mcast state.
> 
> Thanks,
> Lucy
> 
> Thanks.
> Jeffrey
> 
> >
> >
> > Lucy
> >
> >
> >
> >
> >

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Sep 2015 19:15:59 +0000

> [Lucy] In my proposed solution, N3 will send two updates, the first

> one with new parent address in RT, the second one is withdraw and have

> old patent address in RT.

[Lucy1] If a node takes an action for a withdraw Leaf A-D route without checking the RT for parenting; the withdraw mechanism does not work. Different PEs may have different parents, one PE sends out a withdraw, MUST NOT result all PEs withdrawing.

Lucy

Jeffrey

> To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Eric Rosen

> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> > To suppress unnecessary redistribution, a P-tunnel BGP node tracks

> > P- tunnel neighbor state. A BGP next hop is one of P-tunnel

> > downstream neighbor, upstream neighbor, and N/A. The policy is, if

> > the BGP next hop of the UPDATE of Leaf A-D route is the downstream

> > neighbor, redistribution the route; if not, no redistribution.

> > (there may be other polices)

> Let me skip this for now. Maybe it'll become a moot point, but we can

> come back.

> [Lucy] No, it is not. This is only half of the current behavior.

> Current solution also requires a node to update mcast state even the

> RT does not point to the BGP node (as long as the sender node is the

> child of the node).

> > after child timer expires, the child sends out the UPDATE of

> > withdraw Leaf A-D route with old patent address in RT, the old

> > patent will update the mcast state once receiving the UPDATE.

> [Lucy] In my proposed solution, N3 will send two updates, the first

> one with new parent address in RT, the second one is withdraw and have

> old patent address in RT. RR distributes both two N1 and N2. N2 acts

> on the first update and become the parent; N1 acts on the second

> update and remove this child from mcast state.

> > To: Lucy yong; Eric Rosen; [email-masked]<mailto:[email-masked]>

> > > To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Eric Rosen

> > > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> > > RR does not change BGP next hop on the update. N1 and N2 can

> > > determine

> > > To: Lucy yong; Eric Rosen; [email-masked]<mailto:[email-masked]>

> > > There is no BGP session between N1/N2 and N3. RR does not

> > > understand "upstream/downstream" neighbor.

> > > Even on N1/N2/N3, upstream/downstream are wrt different flows. How

> > > do you configure such policies?

> > > > To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Eric Rosen

> > > > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> > > > To: Lucy yong; Eric Rosen; [email-masked]<mailto:[email-masked]>

> > > > > To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Eric Rosen

> > > > > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> > > > > To: Lucy yong; Eric Rosen; [email-masked]<mailto:[email-masked]>

> > > > > Let's use this example to illustrate the points we tried to

> > > > > get

> > > through:

> > > > > N3 sends an update with new RT(N2). There is no withdraw from

> at all.

> > > > > route and the update. Because the RT(N2) in the update does

> > > > > not match N1,

> > > > > controlled by the RR, which only follows BGP route

> > > > > distribution process and does not understand MVPN/IR rules at

> > > > > all. In the second case, there is no explicit withdraw at all.

> > > > > In both cases, N3 only sends

> > > > > > To: Eric Rosen <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang

> > > > > > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> > > > > > When non-segmented ingress replication is used, the ingress

> > > > > > PE needs to see the Leaf A-D routes from all the egress PEs.

> > > > > > means that the RT on the Leaf A-D routes needs to identify

> > > > > > the ingress

> > > > > > However, the Leaf A-D routes may need to travel over

> > > > > > multiple BGP sessions before they reach the

> > > > > > Some of these BGP sessions may be IBGP sessions, some may be

> > > > > > EBGP

> > > > > > It's rather important that the route not get discarded

> > > > > > before it reaches the ingress PE, even though it passes

> > > > > > through multiple BGP speakers.  If one wants to constrain

> > > > > > the distribution of the routes, one still has to guarantee

> > > > > > that the routes will reach their

> > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor

> state:

> > > > > > A simple policy can suppress a lot distribution:

> > > > > > redistribute a Leaf A-D route if and only if it is sent by a

> > > > > > downstream neighbor. This ensures that ingress PE receives

> > > > > > all the Leaf A-D routes from all the

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 23 Sep 2015 16:26:05 -0400

Lucy,

1. Constraining the distribution of Leaf A-D routes.

If you look at sections 9.2.3.2.1 and 9.2.3.4.1 of RFC 6514, you'll see 
that there are some rules that enable you to avoid sending a Leaf A-D 
route on an EBGP session unless a corresponding I/S-PMSI A-D route was 
received over that session.  There are similar rules in RFC 6514 
governing the distribution of C-multicast routes.  These rules are 
intended to prevent the Leaf A-D routes and C-multicast routes from 
being distributed more widely than necessary.  Whether these rules 
always work is questionable; they tend to have hidden assumptions about 
the deployment.

But if you want to investigate ways to optimize the distribution of the 
Leaf A-D routes, that's a good place to start.

One might try the following rule.  If R1 receives a Leaf A-D route, and 
if R1 is not identified in the route's RT, and if the Leaf A-D route has 
a route key that is the NLRI of an S-PMSI A-D route that R1 has 
installed, then only distribute the Leaf A-D route on a BGP session that 
leads to the BGP speaker that is the next hop of the S-PMSI A-D route. 
Whether this rule actually works in various deployment scenarios would 
require further investigation.

[Lucy] To suppress unnecessary redistribution, a P-tunnel BGP node 
tracks P-tunnel neighbor state. A BGP next hop is one of P-tunnel 
downstream neighbor, upstream neighbor, and N/A. The policy is, if the 
BGP next hop of the UPDATE of Leaf A-D route is the downstream neighbor, 
redistribution the route; if not, no redistribution.

I don't understand this proposal; I don't see how you can tell by 
examining the next hop of the Leaf A-D route whether you need to 
redistribute the route.  A rule based on the next hop of the 
corresponding I/S-PMSI A-D route sounds more promising.

Another approach would be to use Constrained Route Distribution.  This 
would ensure that the Leaf A-D route reaches its target, and would 
prevent the route from traveling over "unnecessary" alternate paths.  In 
certain deployment scenarios, ORF is also available as a way to prevent 
routes from being distributed unnecessarily.  Both these methods are 
forms of RT-based filtering, and both are independent of MVPN.

Of course, one also has to worry about creating a robustness problem if 
route distribution is constrained so that routes follow only one path.

Since the topic of this thread is "comment on draft-ietf-bess-ir", and 
since that draft is in WGLC, I'll just point out again that this issue 
is not specific to ingress replication.

[Lucy] IMO: this mechanism for membership announcement raises a BIG 
concern on the scalability and performance. Why is it not a concern for you?

I wouldn't say it's not a concern, but it's important not to focus 
exclusively on the worst case.  Typical deployment scenarios don't come 
close to the worst case, and there are various tools and filtering 
policies that can be used to constrain the distribution of updates based 
on the RTs.

2. Changing your parent on an IR tree

I think we have a disconnect here, having to do with the layering 
between the MVPN application and BGP.

MVPN can create a route and give it to BGP.  MVPN can set and modify 
attributes of the route.  MVPN can withdraw the route.  But the 
distribution of the route is controlled by BGP.

MVPN cannot tell BGP "send an update for NLRI X with attribute A1 on BGP 
session S1, but send an update for NLRI X with attribute A2 on BGP 
session S2".  MVPN cannot tell BGP "send an update for NLRI X on session 
S1 but send a withdraw for NLRI X on session S2."  And MVPN cannot 
control the timing of BGP's route distribution procedures.

In short, MVPN does not create and send the update messages.

[Lucy] To change the parent, a child sends out the UPDATE of Leaf A-D 
route with new parent address in RT.

MVPN can tell BGP to change the RT and the PMSI Tunnel attribute on a 
given Leaf A-D route.  Suppose MVPN replaces the RT so that the RT now 
identifies the new parent rather than the old one.

If Constrained Route Distribution is being used, this will cause an 
explicit withdraw to be sent to the old parent.  There is no way for the 
MVPN process in the child node to control the timing of this BGP message.

If Constrained Route Distribution is not being used, changing the RT 
will cause BGP to send a new update to the old parent as well as to the 
new parent.  The old parent will treat this as a replacement route, and 
will consider the old route to have been (implicitly) withdrawn.  This 
behavior is mandated by section 3.1 of RFC4271.  Since the old parent is 
not identified in the RT, the action it must take is the action 
specified for the withdrawal of a Leaf A-D route.

Now suppose MVPN doesn't simply replace the RT on the Leaf A-D route, 
but adds a second RT, identifying the new parent.  MVPN would also have 
to replace the PMSI Tunnel attribute, to specify a new label for the new 
parent to use.  The old parent would see this route as a replacement 
route.  The route still identifies the old parent, but has a new label 
in its PMSI Tunnel attribute.  So the old parent will continue sending 
traffic to the child, but will use the new label.  Now both old and new 
parents are using the same label, and the result will be data duplication.

I don't think there is any feasible way to switch parents in a "make 
before break" fashion without requiring the old parent to have some 
explicit knowledge that the switch is taking place.  The procedure we 
chose is to have the old parent time out the data plane entry for the 
child.  While this is not the only possible procedure, I don't think 
there is anything both (a) simpler and (b) compatible with BGP's route 
distribution procedures and with the layering between MVPN and BGP.

Of course, one could modify the MVPN/BGP layering by building more 
MVPN-specific knowledge into BGP, one one could even decide that section 
3.1 of RFC4271 shouldn't apply to Leaf A-D routes .  Certainly there are 
some cases where BGP knows that certain MCAST-VPN routes have to be 
handled in a special way.  But that's a lot more complicated than having 
the parent node simply run a timer to time out the data plane states 
when a route is withdrawn.

Eric