Subject: [Idr] http://ietfreport.isoc.org/ids/draft-muley-hares-idr-orf-order-00 .txt

From: "Praveen Muley" <[email-masked]>
Date: Wed, 11 Aug 2004 20:11:28 -0700

Hello Pedros,
          A simple example for Group ORF can be multiple VRFs having
different set of prefix filters. In that case say extended community Green
for Green VRF and Red extended community for Red VRF with different prefix
filters need to be send to the BGP peer. 
                                     Today there is difficulty in expressing
this, while carrying multiple ORF entries as relationship between the ORF
entries of one type of ORF to another cannot be expressed ( or rather say
its strict) as same ORF types are clubbed together and hence applying
granular policy is an issue. Grouping helps in solving this.  
                         
Regards,
Praveen
                             
_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 12 Aug 2004 10:05:43 -0700

Praveen Muley writes:

> Hello Pedros, A simple example for Group ORF can be multiple VRFs
> having different set of prefix filters. In that case say extended
> community Green for Green VRF and Red extended community for Red VRF
> with different prefix filters need to be send to the BGP peer.

Praveen,
the orf-order draft, as currently specified, does not seem to me to be
able to express that problem...

i.e. you seem to want to express a set of expressions such as
   (a && b) || (c && d) || ...

it would also be an inneficient way to solve the problem you
mention... you do not want to perform a sequential search through the
extended community space.

But all of these are, imho, quite secondary compared to the
question of why would you do this in the first place...

I would expect that if you want prefix filters torwards you VRF client
that you would want to apply them in the PE-CE routing adjacency...

> Today there is difficulty in expressing this, while carrying
> multiple ORF entries as relationship between the ORF entries of one
> type of ORF to another cannot be expressed ( or rather say its
> strict) as same ORF types are clubbed together and hence applying

There may be applications that require the ability to combine
different filters... but ORF should not become a replacement for a
configuration distribution mecanism. imho, ORF should be reserved for
situations where there is a clear advantage in performing the
filtering outbound *as well as* inbound on a session.

I think it is important to define what problems you intend to solve,
to demonstrate how you solve the problem and compare with other
possible solutions.

  Pedro.