Re: [Idr] 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?)

> 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.

Even simpler: the above draft could make it crystal clear that the 
AS4 ext-com format should be used only where the ASN values require 
it, and should probably also warn against the use of values > 2^16-1 
in some appropriate way.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Chewing gum on /dev/sd3c
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr