Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt

From: Vitkovský Adam <[email-masked]>
Date: Tue, 1 Jul 2014 07:37:25 +0000

Now that you mentioned it yes that’s exactly the desired behavior.

I see no point in forcing a BGP speaker to accept its own RT membership NRLI in order to start advertising NRLIs with this RT.
I mean if there’s no other RT membership NRLI for a particular RT, than no one really wants to know the NRLIs with this particular RT.

adam

From: Shyam Sethuram [mailto:[email-masked]]
Sent: Tuesday, July 01, 2014 2:29 AM
To: Vitkovský Adam
Cc: Dongjie (Jimmy); Robert Raszuk; [email-masked]
Subject: Re: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-rr-00.txt

> In order to start learning the NRLIs RR has to advertise a desire to receive them and to do that we can use modified rule 3.2.ii.
>
>        When advertising an RT membership NLRI to a client peer, if
>        the best path as selected by the path selection procedure
>        described in Section 9.1 of the base BGP specification [4] is a
>        route received from that client peer in particular, and if there is an
>        alternative path to the same destination from another client or a non-client, the
>        attributes of the other path are advertised to the peer.
>
> Now thinking about it only one rule for reflection of RT membership NLRI is enough I guess.
> If you received RT membership NLRI from only one peer don't advertise it until you have received the RT membership NLRI with the same RT from another peer.
> Then you can advertise the alternate (not the one that the peer sent you) RT membership NLRI to a given peer (simple split horizon).

This sounds like best-external advertisement ?
(Section 5, draft-ietf-idr-best-external-05)

shyam

On Fri, Jun 27, 2014 at 4:52 AM, Vitkovský Adam <[email-masked]<mailto:[email-masked]>> wrote:
Hi folks,

Regarding the rule 3.2.i of RFC4684.

First consider scenario a):
a)
RR----PE1

Why would I want the RR to learn the PE's prefixes if there's no one interested in them (no other clients interested to receive NRLI for given RTs) as PE1 is the only one that advertised the Route Target membership information to RR.

Now let's consider scenario b):
b)
PE2----RR----PE1

Now there is another client (PE2) connected to the RR and it happens to be interested in receiving NRLI for a given RT as designated by the advertised Route Target membership information for the given RT.
Ok now that there are interested receivers for a given NRLI on both sessions - RR should start learning the NRLIs from clients so that it can disseminate the information accordingly.

In order to start learning the NRLIs RR has to advertise a desire to receive them and to do that we can use modified rule 3.2.ii.

        When advertising an RT membership NLRI to a client peer, if
        the best path as selected by the path selection procedure
        described in Section 9.1 of the base BGP specification [4] is a
        route received from that client peer in particular, and if there is an
        alternative path to the same destination from another client or a non-client, the
        attributes of the other path are advertised to the peer.

Now thinking about it only one rule for reflection of RT membership NLRI is enough I guess.
If you received RT membership NLRI from only one peer don't advertise it until you have received the RT membership NLRI with the same RT from another peer.
Then you can advertise the alternate (not the one that the peer sent you) RT membership NLRI to a given peer (simple split horizon).

Then there's no need to modify the update so that it can be accepted by the originator (as in 3.2.i.).
And this also solves the hierarchical RR problem as well.

I'd like the think of it as with multicast flow where RR is like RP and PEs are like Sources + Receivers.
There's no need for the RP (RR) to receive the mcast stream (e.g. VPN Prefixes) when there's just one Source/Receiver (PE) connected to it.
A simple state on the RP saying there is a particular stream available at this particular source is enough (i.e. RT membership NLRI on RR).
Once other source/receivers (PEs) are connected to the RP(RR) and signal their desire to receive the stream (via RT membership NLRI).
Then RP (RR) decides the desire receive the stream (RT membership NLRI) is worth spreading and disseminates the information to the interested sources/receivers (PEs).
Once that happens sources/receivers (PEs) will start sending the mcast stream (e.g. VPN Prefixes) towards the RP (RR) which than reflects this mcase streams to all interested sources/receivers (PEs).

I believe the concerns presented in draft-dong-idr-rtc-hierarchical-rr-00 could be resolved by add-path where at least one additional path is advertised along with the best-path.
But still rule 3.2.i. in RFC4684 is very harmful in scenarios where RRs are clients of other RRs (same level or different level).

 adam

> -----Original Message-----
> From: Dongjie (Jimmy) [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Monday, June 23, 2014 4:59 AM
> To: Vitkovský Adam; Robert Raszuk
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: RE: [Idr] New Version Notification for draft-dong-idr-rtc-hierarchical-
> rr-00.txt
>
> Hi Adam,
>
> If RD is part of the RTC routes, this problem will not occur:) While as analyzed
> in rfc 4684, this requires more RTC routes being exchanged and kept in the
> local AS.
>
> I agree that add-path is a candidate solution to this problem, while when
> enabling add-path on RTC AFI/SAFI, we still need to specify the rules of which
> RTC routes should be advertised to solve this problem. Or we just update the
> rules of RTC advertisement as the other RTC related new drafts?
>
> Many thanks,
> Jie
>
> > -----Original Message-----
> > From: Vitkovský Adam [mailto:[email-masked]<mailto:[email-masked]>]
> > Sent: Sunday, June 22, 2014 3:20 AM
> > To: Robert Raszuk
> > Cc: Dongjie (Jimmy); [email-masked]<mailto:[email-masked]>
> > Subject: RE: [Idr] New Version Notification for
> > draft-dong-idr-rtc-hierarchical-rr-00.txt
> >
> > Aah I see :)
> > Well we could have that one solved if RD would be part of the RTC
> > routes :) (though I understand one could use RTC for non VPN routes as
> > well so...) Anyways so than as you mentioned add-path on the RTC AF
> > seems as the best option then.
> >
> > adam
> > > -----Original Message-----
> > > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> > > Robert Raszuk
> > > Sent: Saturday, June 21, 2014 7:52 PM
> > > To: Vitkovský Adam
> > > Cc: Dongjie (Jimmy); [email-masked]<mailto:[email-masked]>
> > > Subject: Re: [Idr] New Version Notification for
> > > draft-dong-idr-rtc-hierarchical- rr-00.txt
> > >
> > > Hi Adam,
> > >
> > > Jie is describing RT routes not VPN routes. Your story does not
> > > apply to RT routes as format of RT NLRI is well defined by RFC ;)
> > >
> > > Besides MPLS network or not has nothing to do with it ....
> > >
> > > Best,
> > > R.
> > >
> > > On Sat, Jun 21, 2014 at 7:19 PM, Vitkovský Adam
> > > <[email-masked]<mailto:[email-masked]>>
> > > wrote:
> > > > Hi Jie,
> > > > Well the correctly designed MPLS networks use unique per PE per
> > > > VRF RDs
> > > in form of RID:xxxxx.
> > > > Unique per PE RDs makes all copies of the same VPN prefix received
> > > > from
> > > different PEs unique so RRs will select all as best path and
> > > distribute them accordingly, which solves this and many other issues.
> > > >
> > > > In other words if someone tries to shoot himself in the foot I
> > > > wouldn't
> > > develop bulletproof boots for him.
> > > >
> > > > adam
> > > >> -----Original Message-----
> > > >> From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dongjie
> > > >> (Jimmy)
> > > >> Sent: Friday, June 20, 2014 4:55 AM
> > > >> To: [email-masked]<mailto:[email-masked]>
> > > >> Subject: [Idr] FW: New Version Notification for
> > > >> draft-dong-idr-rtc- hierarchical-rr-00.txt
> > > >>
> > > >> Hi all,
> > > >>
> > > >> This is a short draft to make RTC applicable in hierarchical RR scenario.
> > > >>
> > > >> Comments are welcome.
> > > >>
> > > >> Best regards,
> > > >> Jie
> > > >>
> > > >> > -----Original Message-----
> > > >> >
> > > >> > A new version of I-D, draft-dong-idr-rtc-hierarchical-rr-00.txt
> > > >> > has been successfully submitted by Jie Dong and posted to the
> > > >> > IETF
> > > >> repository.
> > > >> >
> > > >> > Name:               draft-dong-idr-rtc-hierarchical-rr
> > > >> > Revision:   00
> > > >> > Title:              Extensions to RT-Constrain in Hierarchical Route
> > Reflection
> > > >> > Scenarios
> > > >> > Document date:      2014-06-19
> > > >> > Group:              Individual Submission
> > > >> > Pages:              5
> > > >> > URL:
> > > >> > http://www.ietf.org/internet-drafts/draft-dong-idr-rtc-hierarch
> > > >> > ic
> > > >> > al
> > > >> > -rr
> > > >> > -00.txt
> > > >> > Status:
> > > >> > https://datatracker.ietf.org/doc/draft-dong-idr-rtc-hierarchica
> > > >> > l-
> > > >> > rr
> > > >> > /
> > > >> > Htmlized:
> > > >> > http://tools.ietf.org/html/draft-dong-idr-rtc-hierarchical-rr-0
> > > >> > 0
> > > >> >
> > > >> >
> > > >> > Abstract:
> > > >> >    The Route Target (RT) Constrain mechanism specified in RFC 4684 is
> > > >> >    used to build a route distribution graph in order to restrict the
> > > >> >    propagation of Virtual Private Network (VPN) routes.  In network
> > > >> >    scenarios where hierarchical route reflection (RR) is used, the
> > > >> >    existing RT-Constrain mechanism cannot build a correct route
> > > >> >    distribution graph.  This document refines the route distribution
> > > >> >    rules of RT-Constrain to address the hierarchical RR scenarios.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > Please note that it may take a couple of minutes from the time
> > > >> > of submission until the htmlized version and diff are available
> > > >> > at
> > > tools.ietf.org<http://tools.ietf.org>.
> > > >> >
> > > >> > The IETF Secretariat
> > > >>
> > > >> _______________________________________________
> > > >> Idr mailing list
> > > >> [email-masked]<mailto:[email-masked]>
> > > >> https://www.ietf.org/mailman/listinfo/idr
> > > >
> > > > _______________________________________________
> > > > Idr mailing list
> > > > [email-masked]<mailto:[email-masked]>
> > > > https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Vitkovský Adam <[email-masked]>
Date: Tue, 1 Jul 2014 08:03:36 +0000

Jeff,

> 
> Adam,
> 
> On Fri, Jun 27, 2014 at 11:52:33AM +0000, Vitkovsk?? Adam wrote:
> > Hi folks,
> >
> > Why would I want the RR to learn the PE's prefixes if there's no one
> interested in them (no other clients interested to receive NRLI for given RTs)
> as PE1 is the only one that advertised the Route Target membership
> information to RR.
> >
> PE1 and PE2 advertise RT-C route R to RR.
> RR selects one of R(PE1) or R(PE2).
> It then would go to reflect that route back to the originator.
> 
> Using standard rules, even with modification, loop suppression occurs either
> by the originator or via proxy at the reflector.
> 
And I think it's a good think. 

> The rule accommodates this case.  The fact that it also incidentally serves as
> an attractor to the RR can be perceived as a bug or as a feature.  Mostly it
> tends to be viewed as a feature.
> 

As I have mentioned already if there's no other RT membership NRLI for a particular RT, than no one really wants to know the NRLIs with this particular RT. 

> > I believe the concerns presented in draft-dong-idr-rtc-hierarchical-rr-00
> could be resolved by add-path where at least one additional path is
> advertised along with the best-path.
> > But still rule 3.2.i. in RFC4684 is very harmful in scenarios where RRs are
> clients of other RRs (same level or different level).
> 
> My current thinking is that add-path - within the RR hierarchy only - is
> perhaps a sufficient solution to this problem.  This would avoid the need to
> implement RT-C add-path at the PEs, an important detail for faster
> deployment of a fix for this issue.  (I have my doubts about the number of
> providers currently experiencing this issue.)
> 

Yes please certainly add-path only between RRs, there's absolutely no need for add-path between PEs and RRs. 

> 
> A rough version of a proposal using add-path only among reflectors would
> look like the following:
> 
> Reflector clients are tagged as being route-reflectors or not via configuration.
> Among RR clients that are also RRs:
> - Do not use 4684 3.2.i/ii
> - RT-C paths are advertised using add-path with the ORIGINATOR attribute
>   preserved as it would otherwise be attached by a RR not doing 3.2.i
> 

I believe the above could be used with any type of route-reflection RR-to-RR or RR-to-PE. 

> The above procedure would permit routes received by the edge of a
> hierarchy of RRs to pass along RT-C routes within the hierarchy and build a
> loop-free graph following standard BGP distribution rules.
> 
> At a RR that has as candidates RT-C routes either non-hierarchy routes or
> hierarchy routes, active route selection is performed as normal.  When
> advertising to non-RR client routers, 3.2.i is performed.  This ensures that an
> active path selected using best-path originating from that router may be
> advertised back as per above.
> 
> (Similarly follow 3.2.ii, if necessary.)
> 
> I have that nagging feeling that I've missed an important detail, so the above
> may not survive scrutiny.  (But that's how engineering and science is
> supposed to work.)
> 
> -- Jeff

adam