[Idr] route-capability explained

["Samita Chakrabarti" <[e-mail]>]

Reference: draft-chakrabarti-idr-as4-route-cap-01.txt
Slides: http://www.ietf.org/proceedings/08jul/slides/idr-7.ppt


Purpose of the proposal: Optimize to dynamically handle the BGP
configuration mismatch when As4byte extended-
community attributes are not understood by the legacy BGP implementations.

Where is the problem?
draft-rekhter-as4octet-ext-community-03.txt defines AS4octet extended
communities and RFC4893 describes
AS4 capability in general. But there is no explicit specification which says
whether the AS4octet extended
community feature must be turned on when an implementation is compliant to
RFC4893.

The following questions come up for interoperability (Assuming there are
more than one or two routing
vendor implementations in the community):

1. How do we handle interoperability between AS2-byte extended community
compliant peer and AS4-byte 
   implementation that supports or does not support as4octet-ext-comm ?

2. What if a PE is connected with two different PEs where one does not
support AS4 extended community 
format and one that does?
                1. Correct configuration on each PE for its corresponding
peer is the current answer

3. Does the manual configuration scale reasonably in a large provider
network where number of PEs are
   quite large? Or what
   if when there is no administrative control over Inter-AS provider network
option C PE implementing 
   draft-rekhter-as4octet-ext-community or not?

4. Should we optimize to find out the ext-communities capability from the
peer during the transition of
   AS4 extended -communities? 

Here is the optimization scenario described in
draft-chakrabarti-idr-as4-route-cap-01.txt:



      PE1 ------------------------------------------PE2

     implements
     AS4octet-ext-comm                        
                                      Does not implement AS4octet-ext-comm

     and unaware of PE2's              or it is configured for 2byte-support

     AS4octet-ext-comm                           
     exports RT 1:2                              imports RT 1:2

 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)

If a route-capability is introduced then, dynamically PE1 can discover that
PE2 is not capable of supporting
AS4-ext-community and it can send 2byte format, even though it might store
the ext-community in AS4octet format.


NOTE: I understand that this problem scenario exists when there is a
configuration issue due to lack of
knowledge about the implementation and configuration of the peer. BGP may
have traditionally designed for
simplicity and manual configuration only, but it does not really scale well
without spending time debugging
problems. My point is to make the AS4 transition easy for the operators so
that the transition is easy accross
different versions of same implementation and different vendor's
implementations.


Alternately, an AS4octet-ext-community implementation SHOULD check whether
its peer is capable of EXTENDED_AS
CAPABLE (RFC4893 compliant) and then use the AS4-ext-format or 2b:4b format.
But, as per current specifications
there is no guarantee that an implementation supporting RFC 4893 would also
support AS4Octet-ext-community.

If we do not want a separate route-capability, then we should specify in the
rekhter-as4-ext-community document
that AS4-ext-community formatted attribute should be sent to the PE only
when it is AS4-capable. 

     





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.

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. 

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.
    
2. Provide capability exchange to find out if my peer is capable of
understanding AS4byte-extended-community
   for importing or for deciphering Site-Of-Origin or received RD values
correctly

3. Update  RFC4360 to incorporate as4octet-ext-community and discuss
transition sceanrios


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