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

From: Christopher Morrow <[email-masked]>
Date: Fri, 10 Jan 2014 15:17:46 -0500

link to draft: http://trac.tools.ietf.org/id/draft-ga-idr-as-migration-03.txt

This doesn't point or ask for new BGP features/functions, why is this
in IDR? It sounds/reads/looks like it is 'operations stuff', which
would fall into GROW, no?

-chris

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jan 2014 22:22:20 +0100

Hi Chris,

Well this draft discusses applicability of local-as, no-prepend and
replace-as knobs. I would also augment it with a BGP policy function
available in some ASes to replace operator's defined arbitrary string in
AS_PATH with your own AS which is different then replace-as knob and turns
pretty useful in some scenarios.

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.

While it does not change protocol encoding it does change the RFC behavior
of BGP AS_PATH handling so I would recommend to keep it in IDR even from
operational perspective.

Best,
R.

On Fri, Jan 10, 2014 at 9:17 PM, Christopher Morrow <
[email-masked]> wrote:

> link to draft:
> http://trac.tools.ietf.org/id/draft-ga-idr-as-migration-03.txt
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 10 Jan 2014 21:30:27 +0000

On Fri Jan 10 2014 at 4:22:20 PM, Robert Raszuk <[email-masked]> wrote:

> replace-as knobs. I

right, vendor specific configuration options, not changes to the bgp
protocol itself... I thought.

> would also augment it with a BGP policy function available in some ASes to
> replace operator's defined arbitrary string in AS_PATH with your own AS
> which is different then replace-as knob and turns pretty useful in some
> scenarios.
>
>
sure, I'm not saying that the migration document isn't interesting and
useful, nor the knobs.

> support it (better or worse :) there are number of other BGP code basis

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

> of BGP AS_PATH handling so I would recommend to keep it in IDR even from
I await chair direction.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jan 2014 22:35:40 +0100

Chris,

I am actually fine to see this draft in either groups. After all the
audience of both groups is very similar :)

But the precedence with IX route servers where we were recommended to split
spec into two documents just since it changes default BGP RFC behavior -
yet no new protocol extension needed - lead me to believe that this would
also fit a bit better to IDR.

Best,
R.

On Fri, Jan 10, 2014 at 10:30 PM, Christopher Morrow <
[email-masked]> wrote:

>> would also augment it with a BGP policy function available in some ASes
>> to replace operator's defined arbitrary string in AS_PATH with your own AS
>> While it does not change protocol encoding it does change the RFC
>> behavior of BGP AS_PATH handling so I would recommend to keep it in IDR
>> even from operational perspective.
>>
>>
> I await chair direction.
>
>
>> Best,
>> R.
>>
>>
>>

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Jan 2014 10:18:11 +0900

> want more work in grow, but this just doesn't seem like IDR to

<aol>

randy, who thinks we really need a wg called (and doing) shrink

---

From: "George, Wes" <[email-masked]>
Date: Wed, 15 Jan 2014 10:07:46 -0500

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

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

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Jan 2014 10:13:16 -0500

> explicitly gain consensus to deprecate/break it.

I don't disagree that documenting the use/practice is a good thing, but:
  Internet Engineering Task Force                                W. George
  Internet-Draft                                         Time Warner Cable
  Intended status: Informational                                 S. Amante
                          ^^^^^^^^^^^^^
  Expires: July 10, 2014

not 'Standard'.

> BGP Spec, it really should be standardized first, and IDR is where BGP

s/standardized/documented/

> protocol work is done. Hence the dependent normative reference between

'protocol' not operational practice... or so I thought, but I'm new
and maybe confused, which was why I asked for some guidance from the
idr-chairs.

> need some solid direction one way or the other.

yup! and again, I support the draft/documentation.
thanks!
-chris

---

From: Shane Amante <[email-masked]>
Date: Wed, 15 Jan 2014 21:33:32 -0800

> and maybe confused, which was why I asked for some guidance from the

In my understanding, "protocol" encompasses not only the exact bits on the wire, but also what stimuli cause those bits to be received from or sent on the wire and, more importantly, generate errors causing the "protocol" to malfunction.  Example: A (well-formed) TCP SYN causes a receiver to modify it's state machine and emit a SYN-ACK to the sender.  Surely it does no good to document a TCP header if you don't have a decent description of what causes TCP flags to be sent and when?  

Please also consider that the de facto standards documented in this draft have /also/ been implemented to avoid error conditions in the protocol, as called out in RFC 4271.
<http://tools.ietf.org/html/rfc4271#section-6.2> -- relates to use of local-as
---snip---
   If the Autonomous System field of the OPEN message is unacceptable,
   then the Error Subcode MUST be set to Bad Peer AS.  The determination
   of acceptable Autonomous System numbers is outside the scope of this
   protocol.
---snip---

<http://tools.ietf.org/html/rfc4271#section-6.3> -- relates to use of replace-as
---snip---
   If the UPDATE message is received from an external peer, the local
   system MAY check whether the leftmost (with respect to the position
   of octets in the protocol message) AS in the AS_PATH attribute is
   equal to the autonomous system number of the peer that sent the
   message.  If the check determines this is not the case, the Error
   Subcode MUST be set to Malformed AS_PATH.
---snip---

I'll grant you there's enough wiggle room in the above language to drive a tractor-trailer through easily; however, we all know several real-world implementations are extremely conservative in what they will receive (by default), hence why these de facto standards have gone to great lengths in order to ensure they work reliably in the hostile conditions of the real-world.

In case it's not clear, I also support this being adopted as a WG draft in IDR.

-shane

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Jan 2014 06:23:43 -0500

Chris: 

After hearing George and  Shane's comment, we should at least cross-post
this draft to grow. 
It sounds based on George's document like the draft should be fast tracked. 

 If operators really want this documented, then going through list
discussion plus adoption, and WG LC call within 8 weeks is a good idea.   I
think we can both run this through the groups in this time period.   The WG
LC in IDR depends on their being 2 implementations of the knobs. 

It really needs to be reviewed by both the implementers and the operations
people.  I'm fine with accepting it into to IDR and Grow.  Perhaps we should
investigate adopting in both groups (radical thought!) to get approval the
cycles going. 

In the end, it just becomes and RFC that operators like Shane can point to
get the appropriate behavior. 

If this sounds fine, let's take the mechanism to the 2 ADs.

Sue Hares 

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

not 'Standard'.

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

'protocol' not operational practice... or so I thought, but I'm new and
maybe confused, which was why I asked for some guidance from the idr-chairs.

> 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

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 16 Jan 2014 10:07:09 -0500

> LC in IDR depends on their being 2 implementations of the knobs.

both sets of knobs exist ... one on juniper, one on cisco. (I think
wes/shane document these in the draft)

> investigate adopting in both groups (radical thought!) to get approval the

ha :) so... sure? I suppose in the end as you say having the document
published is the goal.

> If this sounds fine, let's take the mechanism to the 2 ADs.

ok.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Jan 2014 11:13:12 -0500

Chris: 

Agree - that's my understanding from the document.  Therefore:  2
implementation of knobs - means IDR will process adoption plus WG LC.  

Ok, I will start at WG adoption in IDR call with indication that it will go
rapidly to WG LC.  In IDR with a draft with two implementations, the chairs
normally give people the option to do adoption/WG LC in the same call.  I
would tend to do this in this case.   

I propose we both an adoption call/WG LC in both WGs (Grow /IDR).  We can
then write up shepherd reports and let the ADs sort it out at the IESG.  

Sue 

-----Original Message-----
From: Christopher Morrow [mailto:[email-masked]] 
Sent: Thursday, January 16, 2014 10:07 AM
To: Susan Hares
Cc: George, Wes; idr wg; Robert Raszuk; John G. Scudder; John G. Scudder
Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt

On Thu, Jan 16, 2014 at 6:23 AM, Susan Hares <[email-masked]> wrote:
> Chris:
>
> After hearing George and  Shane's comment, we should at least 
> cross-post this draft to grow.

> It really needs to be reviewed by both the implementers and the 
> operations people.  I'm fine with accepting it into to IDR and Grow.  
> Perhaps we should investigate adopting in both groups (radical 
> thought!) to get approval the cycles going.

> In the end, it just becomes and RFC that operators like Shane can 
> point to get the appropriate behavior.
>

ok.

>>>>> 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.
>
>>>>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.
>>>>
>> 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
>
idr-chairs.
>> Anything below this line has been added by my company's mail server, 
>> I have no control over it.
>> -----------
>>
>>
> 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: "UTTARO, JAMES" <[email-masked]>
Date: Sat, 18 Jan 2014 17:50:36 +0000

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

Thanks
Wes George