RE: RFC 4893 - Question regarding AS-TRANS

How would a NEW speaker know whether the peer is genuinely
OLD speaker
or it's NEW speaker pretending to be OLD (peer didn't send
AS4 support
capability)?

If the session is established with an OLD speaker w/ AS
23456, there are
chances that peer will wrongly detect AS-PATH loops in the
updates it
receives from the NEW peer. If all updates are from a NEW
speaker w/
4-octet non-mappable AS, none of them would be installed in
OLD
speaker's RIB.

OLD speaker's operator has to be aware of such cases. To
avoid
consumption of n/w bandwidth and other resources in cases
like above, I
was wondering of having the check on NEW speaker side.

Let me know your comments.

Thanks,
Kalpesh

-----Original Message-----
From: Paul Jakma [mailto:paulclubi.ie] 
Sent: Tuesday, September 25, 2007 1:00 PM
To: Kalpesh Zinjuwadia
Cc: idrietf.org
Subject: RE: [Idr] RFC 4893 - Question regarding AS-TRANS

On Tue, 25 Sep 2007, Kalpesh Zinjuwadia wrote:

> Kalpesh: True. OLD speaker DON'T follow the RFC. I
meant having the
> check (for OLD peer's AS) on the NEW speaker.

I wouldn't recommend that.

A 'receiving' NEW speaker can't tell if the other side
really is OLD, 
or a NEW speaker pretending to be OLD. E.g. imagine if a NEW
speaker 
had an option to administratively configure 4/2 bytes on a
per 
session basis (e.g. for testing, or as a short-term
workaround for 
some implementation issue).

regards,
-- 
Paul Jakma	paulclubi.ie	pauljakma.org	Key ID: 64A2FF6A
Fortune:
crop circles in the corn shell

_______________________________________________
Idr mailing list
Idrietf.org
https://ww
w1.ietf.org/mailman/listinfo/idr

Hi Kalpesh,

On Tue, 25 Sep 2007, Kalpesh Zinjuwadia wrote:

> How would a NEW speaker know whether the peer is
genuinely OLD 
> speaker or it's NEW speaker pretending to be OLD (peer
didn't send 
> AS4 support capability)?

> If the session is established with an OLD speaker w/ AS
23456, 
> there are chances that peer will wrongly detect AS-PATH
loops in 
> the updates it receives from the NEW peer.

How so?

Over a 2-byte session, the NEW speaker must receive an
AS4_PATH if 
there were any >65535 ASN speakers in the path. The
speaker would 
then reconcile AS4_PATH and the (2-byte) AS_PATH, to form
the full 
(4-byte) AS_PATH.

> If all updates are from a NEW speaker w/ 4-octet
non-mappable AS, 
> none of them would be installed in OLD speaker's RIB.

No. See above. Should get a full (4-byte) AS_PATH by
reconciling 
AS4_PATH and (2-byte) AS_PATH.

> above, I was wondering of having the check on NEW
speaker side.

Bad idea, IMHO.

regards,
-- 
Paul Jakma	paulclubi.ie	pauljakma.org	Key ID: 64A2FF6A
Fortune:
TV is chewing gum for the eyes.
 		-- Frank Lloyd Wright

_______________________________________________
Idr mailing list
Idrietf.org
https://ww
w1.ietf.org/mailman/listinfo/idr