Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt

From: "George, Wes" <[email-masked]>
Date: Thu, 13 Feb 2014 18:40:25 -0500

James -

I was doing some reading about AS_OVERRIDE in preparation to try to
incorporate your comments into the draft, and I’m not sure I understand
how this is related to AS migration, which is what this draft discusses.
While there may be additional BGP Manipulation cases that are
vendor-specific and need to be documented, this may not be the right fit
for this specific draft, especially since this draft originated from the
fact that we needed to document something that is today unofficially used
in BGP in order to prevent SIDR’s path validation from breaking the
process. Since SIDR is not used in VPN networks at all, we didn’t see that
as overly necessary, at least right now.

Am I missing something?

Thanks,

Wes

On 1/18/14, 12:50 PM, "UTTARO, JAMES" <[email-masked]> wrote:

>It would seem to me that this is primarily informational in nature. There
>are other methods of manipulating AS-PATH i.e AS_OVERRIDE that are used.
>As these tools are also used in other spaces i.e VPN it would seem
>prudent to include other use cases.. One is the ability to have multiple
>customer endpoints using the same AS to communicate over the SPs network.
>In this case an approach may be to use AS_OVERRIDE to disable the AS_PATH
>loop prevention method..

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 14 Feb 2014 09:01:06 -0500

This draft has been accepted by the IDR WG.   Will the authors please submit this as: 

Draft-ietf-idr-migration-01.txt

The Grow co-chair (Chris Marrow)  will serve as the document shepherd. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of UTTARO, JAMES
Sent: Saturday, January 18, 2014 12:51 PM
To: George, Wes; Christopher Morrow
Cc: idr wg; Robert Raszuk
Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt

It would seem to me that this is primarily informational in nature. There are other methods of manipulating AS-PATH i.e AS_OVERRIDE that are used. As these tools are also used in other spaces i.e VPN it would seem prudent to include other use cases.. One is the ability to have multiple customer endpoints using the same AS to communicate over the SPs network. In this case an approach may be to use AS_OVERRIDE to disable the AS_PATH loop prevention method..  

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of George, Wes
Sent: Wednesday, January 15, 2014 10:08 AM
To: Christopher Morrow
Cc: idr wg; Robert Raszuk
Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt

Thought I should maybe weigh in as an author...

>>> Well this draft discusses applicability of local-as, no-prepend and 
>>> replace-as knobs. I
>>
>> right, vendor specific configuration options, not changes to the bgp 
>> protocol itself... I thought.
>>
The stated goal is to codify this behavior as a standard so that it is clear that future changes to BGP must either support this function or explicitly gain consensus to deprecate/break it.
>>
>>> IMO it does belong to IDR as implementations first need to support 
>>> such knobs in order for operators to discuss its use in GROW. And 
>>> for that implementors need to understand them. While 3 quoted 
>>> implementations support it (better or worse :) there are number of 
>>> other BGP code basis which still do not.
>>
>> wait, so now IDR is going to spec implementation knobs? that seems 
>>like  it's outside of the charter to me... or rather I don't see this 
>>in the list  of work items or in the generic charter fluff before work 
>>items.
>>
>> it seems much more clearly to fit in the grow world view... (not that 
>> I want more work in grow, but this just doesn't seem like IDR to
This is a little hinky as “protocol work” because it’s local only, rather than something that requires interop between BGP speakers at an implementation level, but as noted, SIDR was about to introduce protocol changes that would have broken it. In putting this draft into IDR, I’m going by the recommendations from the folks involved in SIDR (of which the IDR overlap is nonzero) that in order to expect SIDR to change the BGPSec design for something that is heavily used but not technically part of the BGP Spec, it really should be standardized first, and IDR is where BGP protocol work is done. Hence the dependent normative reference between draft-ietf-sidr-as-migration and this draft.
I’m open to putting it in GROW if that’s where it makes more sense, just need some solid direction one way or the other.

Thanks
Wes George

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 14 Feb 2014 14:25:45 +0000

Wes,

	We have multiple AS domains that have been created for various reasons under our own administrative authority. We have used a number of the tools mentioned in your draft but also we have use AS-OVERRIIDE to "appear" as a different AS to an eBGP peer within our own admin authority or with customers.  I thought the draft was wider in scope and was intended to document and provide guidance as to the various vendor tools and there ramifications in the L3VPN context. If it is specific to only IPV4 then I believe it is missing out on an opportunity to identify multiple AS domains, migration etc... across L2VPN, L3VPN, SDN Controller ( Flowspec ) .... 

Jim Uttaro

-----Original Message-----
From: George, Wes [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 6:40 PM
To: UTTARO, JAMES; Christopher Morrow
Cc: idr wg; Robert Raszuk
Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt

James -

Am I missing something?

Thanks,

Wes