Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-03.txt

From: Paul Jakma <[email-masked]>
Date: Mon, 30 Jul 2007 14:24:19 +0100 (IST)

Hi Tony,

A query on the following language in the draft:

    If the AS_PATHLIMIT attribute is attached to a prefix by a private
    AS, then when the prefix is advertised outside of the parent AS, the
    AS number contained in the AS_PATHLIMIT attribute should be replaced
    by the AS number of the parent AS.

Could it be made more explicit here as to which speaker is 
responsible here?

E.g. is it the responsibility of /all/ pathlimit capable speakers to 
update a private-AS in a pathlimit with a public one (the attribute 
may transit one or more non-pathlimit capable ASes while containing a 
private AS)?

Should a speaker with a private AS, implementing this attribute, be 
pro-active and, when sending an UPDATE to a non-private-AS, set the 
pathlimit AS in such an UPDATE to the peer's ASN?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
No man would listen to you talk if he didn't know it was his turn next.
 		-- E.W. Howe

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Tony Li <[email-masked]>
Date: Mon, 30 Jul 2007 06:36:13 -0700

Hi Paul,

> Could it be made more explicit here as to which speaker is  

Certainly.  Wording improvements are certainly welcome.

> E.g. is it the responsibility of /all/ pathlimit capable speakers  
> to update a private-AS in a pathlimit with a public one (the  
> attribute may transit one or more non-pathlimit capable ASes while  
> containing a private AS)?

Hmm...  Well, I'd like to say yes, but then we have to explain how a  
speaker that is remote from the private-AS should behave.  What  
number does it insert?  Unless it has implemented some type of  
oracle, I don't see how it can reasonably infer the correct public AS  
number.

> pathlimit AS in such an UPDATE to the peer's ASN?

I had always thought of this as the responsibility of the speakers  
within the public AS infrastructure, as they are already responsible  
for stripping the private ASNs from the AS_PATH.  However, what you  
propose certainly sounds reasonable.

I'm amenable if there's consensus around specific wording.  Do you  
have a proposal?

Tony

---

From: Paul Jakma <[email-masked]>
Date: Mon, 30 Jul 2007 14:58:10 +0100 (IST)

> Hmm...  Well, I'd like to say yes, but then we have to explain how 
> a speaker that is remote from the private-AS should behave.  What 
> oracle, I don't see how it can reasonably infer the correct public 
> AS number.

Indeed.

Though, in such a situation, is it better to update the private AS 
(in the belief that closest identifiable public AS to the source is 
better than a private AS)? I guess that's best of a bad lot..

> within the public AS infrastructure, as they are already 
> responsible for stripping the private ASNs from the AS_PATH.
> However, what you propose certainly sounds reasonable.

It seems like it add a bit of pro-active robustness for 
mixed-speaker environments (?).

> I'm amenable if there's consensus around specific wording.  Do you 

Hmm, how about adding an example?

    E.g. When sending an AS_PATHLIMIT with a private-ASN to an EBGP
    neighbour outside of the parent AS, a speaker should update the
    ASN in the attribute with preferrably its own ASN, if that is a
    public ASN, or else the ASN of the EBGP peer the attribute is
    being sent to, if that is a public ASN.

That still allows for the discretion around determining 'parent AS' 
which the original wording carefully put there, but gives a gentle 
hint as to expected behaviour..

Or somesuch..

regards,
If in doubt, mumble.

---

From: Tony Li <[email-masked]>
Date: Mon, 30 Jul 2007 07:11:59 -0700

> better than a private AS)? I guess that's best of a bad lot..

Agreed.

> It seems like it add a bit of pro-active robustness for mixed- 
> speaker environments (?).
>

Works for me.  Other folks?

Tony