RE: RFC 4893 - Question regarding AS-TRANS

I meant that the routing loop would be wrongly detected on
the OLD peer
side as it's AS is 23456 and the AS-PATH from NEW peer may
contain 23456
as place-holders. The actual AS would be some 4-octet
non-mappable ASN
in the AS4-PATH attr, which is unknown opt-trans for the OLD
speaker.

Also, consider the case with a NEW speaker belonging to
4-octet
non-mappable AS. Per RFC, it would send 23456 in the
"My AS" field of
Open Msg and add the 4-BYTE-AS capability with correct AS.
If the peer
is OLD belonging to AS 23456 and if it ignores the
capability as
unrecognized, it will wrongly treat the NEW speaker as IBGP
(instead of
EBGP) peer, which is wrong...

Please let me know if I'm missing something.

Thanks,
Kalpesh

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

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

AS 23456 is reserved.  It means that the AS number is not,
and will not 
be assigned to any organization.  It also means that the AS
number has a 
special use, and must not be used in any way other than as
designated.

If some one insists on using it, bad things (e.g., partial
connectivity) 
will happen.  It is really no different from the
unauthorized use of any 
other AS numbers.

-- Enke

Kalpesh Zinjuwadia wrote:
> I meant that the routing loop would be wrongly detected
on the OLD peer
> side as it's AS is 23456 and the AS-PATH from NEW peer
may contain 23456
> as place-holders. The actual AS would be some 4-octet
non-mappable ASN
> in the AS4-PATH attr, which is unknown opt-trans for
the OLD speaker.
>
> Also, consider the case with a NEW speaker belonging to
4-octet
> non-mappable AS. Per RFC, it would send 23456 in the
"My AS" field of
> Open Msg and add the 4-BYTE-AS capability with correct
AS. If the peer
> is OLD belonging to AS 23456 and if it ignores the
capability as
> unrecognized, it will wrongly treat the NEW speaker as
IBGP (instead of
> EBGP) peer, which is wrong...
>
> Please let me know if I'm missing something.
>
> Thanks,
> Kalpesh
>
> -----Original Message-----
> From: Paul Jakma [mailto:paulclubi.ie] 
> Sent: Wednesday, September 26, 2007 12:11 PM
> To: Kalpesh Zinjuwadia
> Cc: idrietf.org
> Subject: RE: [Idr] RFC 4893 - Question regarding
AS-TRANS
>
> 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,
>   

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