Subject: [Idr] RTC and Routes w/o RTs

From: [email-masked]
Date: Tue, 17 Jun 2014 11:30:59 -0400

Those who have been following the thread on "RFC4684 pedantry" ;-) may wish
to look at draft-rosen-idr-rtc-no-rt-00.txt.

This draft establishes a new "default behavior" for RTC which takes account
of the peculiarities of SAFIs 66 and 5, while applying the old "default
behavior" to other SAFIs.  It also states that the specification of a new
SAFI should may specify the default RTC behavior for that SAFI, and it
allows implementations to override the default behaviors.

The draft does not add any new BGP capabilities.

Comments are welcome.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 18 Jun 2014 03:55:51 +0000

Hi Eric, 

Thanks for the information. Here are some comments on this new draft.

1. In Section 1, Paragraph 2, it says:

"In [RFC4684] it is implicitly assumed that RTC will only by applied to AFI/SAFIs where all the routes carry RTs."

This may not be quite accurate. In RFC 4684 the RTC capability is negotiated between the BGP speakers for the whole BGP session, not for specific AFI/SAFIs. Thus RTC should apply to ANY route which use RT to control the distribution, unless some knob is used to control the applicability of RTC. In another word, RFC 4684 does not specify AFI/SAFI specific behaviors.

Thus if this draft propose some AFI/SAFI specific RTC behavior update, do we need some specification to make the RTC mechanism AFI/SAFI specific first?

2. This draft does not define new capability for the new "default behaviors", then in deployment how could we know whether a BGP speaker supports the "default behaviors" in this draft or not?

Best regards,
Jie

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, June 17, 2014 11:31 PM
> To: IDR WG
> Subject: [Idr] RTC and Routes w/o RTs
> 
> This draft establishes a new "default behavior" for RTC which takes account of
> the peculiarities of SAFIs 66 and 5, while applying the old "default behavior" to
> other SAFIs.  It also states that the specification of a new SAFI should may
> specify the default RTC behavior for that SAFI, and it allows implementations to
> override the default behaviors.
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Jun 2014 09:27:10 -0400

Jie,

> 2. This draft does not define new capability for the new "default behaviors", then in deployment how could we know whether a BGP speaker supports the "default behaviors" in this draft or not?

The routers that care about whether this is present in the network or not
may be multiple BGP hops away.  I don't think a capability is terribly
helpful here.

More to the point, this becomes akin to policy.  Policy isn't generally
signaled.

-- Jeff

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Jun 2014 10:32:17 -0400

> In RFC 4684 the RTC capability is negotiated between the BGP speakers for
> the whole BGP session, not for specific AFI/SAFIs.

The capability just indicates that updates of AFI/SAFI 1/132 can be sent and
received.  It's only real purpose is to prevent a BGP speaker from sending
1/132 updates to a peer that can't handle them.

> Thus RTC should apply to ANY route which use RT to control the
> distribution,

The discussion has revealed a few cases where RTC doesn't seem to do the
right thing, and the purpose of the draft is to establish default behaviors
that make it more likely for the right thing to happen.  (The "right thing"
being that RTC passes routes that need to pass in order for proper
operation, and RTC only filters routes that can be filtered without
impairing proper operation.)

> This draft does not define new capability for the new "default behaviors",
> then in deployment how could we know whether a BGP speaker supports the
> "default behaviors" in this draft or not?

To use RTC, the desired behavior (which is not necessarily the default
behavior) has to be supported throughout the network.  A per-session
mechanism like Capability isn't really helpful in determining whether all
the network's BGP speakers support a particular RTC behavior for a
particular AFI/SAFI.