headers
Paul Francis | 1 Aug 04:11
Picon
Favicon

Re: draft on virtual aggregation

I've been thinking about this, so let me give a more thoughtful answer.

As I said, if you want to be able to do FIB reduction in edge routers whose
eBGP peers require the full DFZ, then either those edge routers must have the
full RIB, or some other router must do the peering (multi-hop).

So one limitation that you've bought yourself is that at least one router has
to have a full FIB.  This might be ok in many ISPs, but nevertheless there it
is.  With VA FIB reduction, all routers can have smaller FIBs.

When you shift peering to in internal router, then that router will have more
peers, and therefore bigger RIB and processing requirements.

You have to configure this internal router to give the appropriate routes to
the edge routers.

If the internal router doing the peering crashes, then a bunch of issues come
up.  Of course, connectivity with the peers is still good, so you need
another router to do the peering.  Without some kind of hot standby scheme,
this would require restarting all the BGP peering sessions.  Of course, it
requires more configuration, and that the internal routers monitor each
other's aliveness so as to know when to start peering.  In short, you step
away from the traditional model whereby the data path and the control path
(routing messages) are closely coupled, and there are a whole chain of
complexities that kick in that we don't know well how to deal with.

Now, if you keep the full RIB, then you get to run routing protocols as we've
run them for 25 years...no change at all.  You just add a new function that
decides what to install and what to suppress from the FIB.  Much of the VA
spec basically describes what these rules are (and they are quite simple).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Jakma | 1 Aug 15:34
Picon

Re: route-capability explained

Hi Samita,

On Thu, 31 Jul 2008, Samita Chakrabarti wrote:

> ext-format-A:                                   ext-format-B:
>      X:000000010002                              Y:000100000002
>      X= Type-subtype for AS4
>                                   Y= Type-subtype for regular ext-community
>
> Now PE1 sends ext-format-A to ext-format-B , one can see that 8byte 
> comparison of ext-community will not match. (X and Y are different 
> and value fields are different)

Explained like this, the problem is pretty clear. But...

> At the idr meeting at IETF on Wednesday, we were told, this is 
> operational or implementation issue - not a protocol issue. I agree 
> it is not exactly a protocol issue.

Based on the above, it is :). But...

> But, given that IETF is all about running "interoperable" code across many
> vendors, I strongly believe this issue should be addressed to clarify the
> specification such that there are less issues during the AS4 transition.

This is only a problem in interoperating with 2-byte speakers, right?

(Also with AS4 speakers that don't implement AS4 extended community - 
but such speakers are unlikely to exist, surely?)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Yakov Rekhter | 4 Aug 18:14
Favicon

volunteer for NomCom

Folks,

Please take a look at
https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617

Yakov.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
Samita Chakrabarti | 4 Aug 20:16

Re: route-capability explained

Hi Paul,
Please see in-line.

>> But, given that IETF is all about running "interoperable" code across
>many
>> vendors, I strongly believe this issue should be addressed to clarify the
>> specification such that there are less issues during the AS4 transition.
>
>This is only a problem in interoperating with 2-byte speakers, right?
>
>(Also with AS4 speakers that don't implement AS4 extended community -
>but such speakers are unlikely to exist, surely?)
[SC>] 
[SC>]  Correct.  You are right about unlikely AS4 speakers without AS4
extended community support -- eventually that should be the case. But, since
these two documents are separate, we can only assume and hope that an
implementation would support both at the same time :-)

>
>> So here are a few alternatives that make sense in my mind:
>>
>> 1. draft-rekhter-as4octet-ext-community-03.txt can specify handling of
>> AS4byte and AS2byte extendend-communities.
>
>A 4-byte speaker could, as a courtesy, translate AS4 extcommunity to
>AS2 when sending to AS2 speakers, where the values fit.
>
[SC>]  Yes. The draft-rekhter-as4octet-ext-community can use the
extended-asn-capability defined in RFC4893 and make the 2byte/4byte mapping
of ext-community decision accordingly. If it is specified in the document,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Jakma | 4 Aug 21:02
Picon

Re: route-capability explained

Hi Samita,

On Mon, 4 Aug 2008, Samita Chakrabarti wrote:

> [SC>]  Correct.  You are right about unlikely AS4 speakers without AS4
> extended community support -- eventually that should be the case. But, since
> these two documents are separate, we can only assume and hope that an
> implementation would support both at the same time :-)

Ok.

Yakhov's ext-community is probably best place to address these 
problems, no?

Also, I'd like to ask the IDR WG to adopt his draft as a working 
group document. Some kind of communication issue with the IDR chair 
seems to have prevented this from appearing on the agenda...

;)

> [SC>] Yes. The draft-rekhter-as4octet-ext-community can use the 
> extended-asn-capability defined in RFC4893 and make the 2byte/4byte 
> mapping of ext-community decision accordingly. If it is specified 
> in the document, then the implementations will behave in a 
> consistent manner. In that case, we don't need a different 
> route-capability [as proposed in my draft] message.

Unfortunately, there are already some 4B speakers deployed which do 
not translate. So translation is perhaps not a robust answer.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeffrey Haas | 4 Aug 21:15

Re: BGP MIBv2 discontinuity objects

Following back up to original list:

On Wed, Jul 16, 2008 at 03:27:30PM -0400, Joan Cucchiara wrote:
> Jeff and I talked on the phone about this one, sorry but there was
> some misunderstandings which were best clarified by an actual conversation.
>
> I'll try to recap as best as I can, and Jeff can correct me if I'm wrong, 
> but
> the upshot is the bgpAfPathAttrIndex OBJECT (contained in the bgpNlriTable)
> and the bgpAfPathAttrIndex which serves as a single index for 
> bgpAfPathAttrTable
> should originally contain the same value to show a relationship between
> the row in the bgpNlriTable and the bgpAfPathAttrTable.  After a 
> discontinuity
> the value of the bgpAfPathAttrIndex (used as an index in the 
> bgpAfPathAttrTable) does
> not change, BUT the bgpAfIndex OBJECT in the bgpNlriTable could change.

bgpAfPathAttrIndex will show the relationship from the bgpNlriTable
entries and their associated bgpAfPathAttrTable entries.  In the event
of a discontinuity, it is highly desired that if the contents of the
bgpAfPathAttrTable change that indexes are not re-used too quickly since
a given index may then refer to different data.

> For those implementations where the bgpAfPathAttrIndex OBJECT in the 
> bgpNlriTable
> changes after a discontinuity, the relationship
> between the NLRI  (Network Layer Reachability Information)
> and the related Path Attribute information is lost.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samita Chakrabarti | 4 Aug 21:37

Re: route-capability explained


Hi Paul,
>
>On Mon, 4 Aug 2008, Samita Chakrabarti wrote:
>
>> [SC>]  Correct.  You are right about unlikely AS4 speakers without AS4
>> extended community support -- eventually that should be the case. But,
>since
>> these two documents are separate, we can only assume and hope that an
>> implementation would support both at the same time :-)
>
>Ok.
>
>Yakhov's ext-community is probably best place to address these
>problems, no?
>
[SC>] 
       Yes, the transition issues should be addressed at the the
Rekhter-as4octet-ext-community draft.  

>Also, I'd like to ask the IDR WG to adopt his draft as a working
>group document. Some kind of communication issue with the IDR chair
>seems to have prevented this from appearing on the agenda...
>
>;)
[SC>]  You can respond to Danny's message on l3vpn to support Yakov's draft
to move forward; I did already :-)

>
>> [SC>] Yes. The draft-rekhter-as4octet-ext-community can use the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Jakma | 4 Aug 21:49
Picon

Re: route-capability explained

On Mon, 4 Aug 2008, Samita Chakrabarti wrote:

>    Are you sure?

Reasonably sure. Whether they're of significance is another matter..

> A deployment should be a RFC compliant. Draft-rekhter-as4octet is 
> an individual contribution now. When it becomes an RFC, the final 
> deployment should follow the RFC. But, folks can discuss more on 
> this and come up with a solution that works and scales.

Ok.

My vote is for constraining originators to encode 2:2 bytes of 
ASN:value (with the 2-byte extcom type code obviously) wherever 
possible, with 4:2 (4B code, obviously) if the AS value requires it.

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
Chemistry is applied theology.
 		-- Augustus Stanley Owsley III
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
Samita Chakrabarti | 4 Aug 22:48

Re: route-capability explained


>> A deployment should be a RFC compliant. Draft-rekhter-as4octet is
>> an individual contribution now. When it becomes an RFC, the final
>> deployment should follow the RFC. But, folks can discuss more on
>> this and come up with a solution that works and scales.
>
>Ok.
>
>My vote is for constraining originators to encode 2:2 bytes of
>ASN:value (with the 2-byte extcom type code obviously) wherever
>possible, with 4:2 (4B code, obviously) if the AS value requires it.
>

[SC>] This is simple and it works for me too.

Any other comments from the wg?

Thanks,
-Samita

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 0 comments |
headers
rfc-editor | 6 Aug 00:47
Favicon

RFC 5291 on Outbound Route Filtering Capability for BGP-4


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5291

        Title:      Outbound Route Filtering Capability for 
                    BGP-4 
        Author:     E. Chen, Y. Rekhter
        Status:     Standards Track
        Date:       August 2008
        Mailbox:    enkechen <at> cisco.com, 
                    yakov <at> juniper.net
        Pages:      12
        Characters: 23949
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-idr-route-filter-17.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5291.txt

This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of Outbound Route Filters (ORFs) that
the peer would use to constrain/filter its outbound routing updates
to the speaker.  [STANDARDS TRACK]

This document is a product of the Inter-Domain Routing Working Group of the IETF.

This is now a Proposed Standard Protocol.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane