Subject: Re: [Idr] route-capability explained

From: Paul Jakma <[email-masked]>
Date: Fri, 1 Aug 2008 14:34:51 +0100 (BST)

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	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Chewing gum on /dev/sd3c
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 4 Aug 2008 11:16:16 -0700

Hi Paul,
Please see in-line.

>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 :-)

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

>it, and should probably also warn against the use of values > 2^16-1

[SC>] Simpler mandate would be that no 4byte<->2byte mapping takes place for
as4-specific ext-community values and 4B-format can operate with another
4B-format compliant system and 2B-format can work with another 2B-format
system. But this will again be totally configuration dependent. This might
not be easy for large PE deployment scenarios.

Thanks for your comments.
-Samita

---

From: Paul Jakma <[email-masked]>
Date: Mon, 4 Aug 2008 20:02:10 +0100 (BST)

Hi Samita,

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

;)

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

> [SC>] Simpler mandate would be that no 4byte<->2byte mapping takes 
> place for as4-specific ext-community values and 4B-format can 
> operate with another 4B-format compliant system and 2B-format can 
> work with another 2B-format system. But this will again be totally 
> configuration dependent. This might not be easy for large PE 
> deployment scenarios.

Hmm: The 2B form is universally understood, so that should be used if 
the values allow - no translation needed. Surely?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"The great question... which I have not been able to answer... is, `What does
woman want?'"
-- Sigmund Freud
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 4 Aug 2008 12:37:10 -0700

Hi Paul,
>Yakhov's ext-community is probably best place to address these
[SC>] 
       Yes, the transition issues should be addressed at the the
Rekhter-as4octet-ext-community draft.  

>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 :-)

>not translate. So translation is perhaps not a robust answer.
[SC>] 
    Are you sure?
  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.

So, to be clear, we do not need to worry about
draft-chakrabarti-idr-as4-route-cap-01.txt, if a transition solution is
devised at future version of the draft-rekhter-as4octet-ext-community doc.

Thanks,
-Samita

---

From: Paul Jakma <[email-masked]>
Date: Mon, 4 Aug 2008 20:49:29 +0100 (BST)

>    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	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Chemistry is applied theology.
 		-- Augustus Stanley Owsley III
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 4 Aug 2008 13:48:28 -0700

>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