Subject: [Idr] Comments on presentation on Constrained route target constrain with multiple address familiies

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Mar 2014 09:06:59 -0500

Saikat (and other authors),

I support the problem statement.  I support the idea of using ext comm
tagging for AF filtering.

I do not support the duplicate update mechanism.  Instead, I'd suggest
something that better permits the change to cleanly percolate throughout the
rest of the AS.    An example of this is some community with a monotonically
increasing number that effectively says "refresh me".

-- Jeff

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Tue, 11 Mar 2014 15:09:46 +0000

Thanks Jeff for your comments.

To clarify:

1. The draft describes two problems.
      (a) Unused route advertisement and retention, 
      (b) Need for route-refresh on some configuration changes

I am assuming you support working on both of these problems.

2. You support the AFI-SAFI extended community proposed in the draft.

3. You do not support the changes of "identical path check" described in the presentation. Instead you prefer to use an extended community, similar to MAC mobility extended community, to signal a change in the path.

Do you envision any case where the "refresh me" paths need to propagate in the AS (or across ASes)?

Thanks.

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, March 06, 2014 6:07 AM
To: [email-masked]
Subject: [Idr] Comments on presentation on Constrained route target constrain with multiple address familiies

I support the problem statement.  I support the idea of using ext comm tagging for AF filtering.

I do not support the duplicate update mechanism.  Instead, I'd suggest something that better permits the change to cleanly percolate throughout the
rest of the AS.    An example of this is some community with a monotonically
increasing number that effectively says "refresh me".

-- Jeff

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Mar 2014 14:47:50 -0400

Saikat,

> I am assuming you support working on both of these problems.

Yes.

> 2. You support the AFI-SAFI extended community proposed in the draft.

Yes.  I'm not sure I fully support making this a generic mechanism and would
suggest instead that this community is scoped to constrained route target
distribution.

> 3. You do not support the changes of "identical path check" described in the presentation. Instead you prefer to use an extended community, similar to MAC mobility extended community, to signal a c…

Correct.  It's very difficult to distinguish an intentional refresh request
for a given filter update contrasted against duplicate UPDATE bugs.  

I have two further thoughts on this issue:
- The change in the set of extended communities is sufficient to trigger the
  refresh for an AFI/SAFI that is being added.  It could also trigger the
  sending of withdrawals for the case of an AFI/SAFI being deleted, although
  arguably there may not be a need for this since the PE can simply discard
  the reachability.
- This proposal probably needs work with respect to the legacy behavior.

That legacy behavior means that if the router received a RT-C route with
communities and doesn't understand them, it can't provide the additional
filtering.  More importantly, it will require a refresh of the AFI in
question to work.  

What is thus required is a mechanism by which we can determine if the
peering session supports the feature or not.  This traditionally implies
BGP capabilities.  

> Do you envision any case where the "refresh me" paths need to propagate in the AS (or across ASes)?

I don't foresee that.  However, it does mean routers supporting this
mechanism must be willing to generate the union of AFI/SAFI ECs from all
input RT-C routes, which may include "all" when receiving a route from a
legacy RT-C router.

-- Jeff