Subject: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

From: [email-masked]
Date: Thu, 09 Apr 2015 07:02:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

        Title           : Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
        Authors         : Wesley George
                          Shane Amante
	Filename        : draft-ietf-idr-as-migration-04.txt
	Pages           : 16
	Date            : 2015-04-09

Abstract:
   This draft discusses some commonly-used BGP mechanisms for ASN
   migration that are not formally part of the BGP4 protocol
   specification and may be vendor-specific in exact implementation.  It
   is necessary to document these de facto standards to ensure that they
   are properly supported in future BGP protocol work.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-idr-as-migration-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as-migration-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "George, Wes" <[email-masked]>
Date: Thu, 9 Apr 2015 10:13:18 -0400

Shane and I believe that this revision addresses the majority of concerns
raised during IESG evaluation, including Alvaro's review.

I don't know if this has to go back through WGLC or if it can just be put
back on IESG schedule, as a good bit of the text was changed to address
the concerns about this being too vendor-specific, including some of the
normative language, so I'll leave that to the chairs and ADs to decide.

Thanks,

Wes

On 4/9/15, 10:02 AM, "[email-masked]" <[email-masked]>
wrote:

>        Title           : Autonomous System Migration Mechanisms and
>Their Effects on the BGP AS_PATH Attribute
>        Authors         : Wesley George
>                          Shane Amante
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

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: Thu, 9 Apr 2015 12:43:29 -0400

George: 

Let me review the document and query Alvaro to make sure it addresses his concerns.  

On re-doing WG LC, we can do this in parallel with the other reviews I'll need to redo (security directorate, routing directorate, ops-directorate and gen-art). I'll start both sequences at the same time once I've heard from Alvaro.  

Sue 

-----Original Message-----
From: George, Wes [mailto:[email-masked]] 
Sent: Thursday, April 09, 2015 10:13 AM
To: [email-masked]; Alvaro Retana (aretana); Alia Atlas; Susan Hares
Cc: Adrian Farrel
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Shane and I believe that this revision addresses the majority of concerns raised during IESG evaluation, including Alvaro's review.

I don't know if this has to go back through WGLC or if it can just be put back on IESG schedule, as a good bit of the text was changed to address the concerns about this being too vendor-specific, including some of the normative language, so I'll leave that to the chairs and ADs to decide.

Thanks,

Wes

On 4/9/15, 10:02 AM, "[email-masked]" <[email-masked]>
wrote:

>Please note that it may take a couple of minutes from the time of 
>submission until the htmlized version and diff are available at 
>tools.ietf.org.
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 9 Apr 2015 17:48:23 +0000

On 4/9/15, 12:43 PM, "Susan Hares" <[email-masked]> wrote:

>On re-doing WG LC, we can do this in parallel with the other reviews I'll
>need to redo (security directorate, routing directorate, ops-directorate
>and gen-art). I'll start both sequences at the same time once I've heard
>from Alvaro.  

I¹ll go read it, but my gut reaction is that we should go back through
(WGLC, etc.).

Thanks!

Alvaro.

---

From: Juan Alcaide <[email-masked]>
Date: Thu, 16 Apr 2015 17:26:36 -0400 (EDT)

Hi,

Let me chip using a previous discussion inputs.

When using local-as, Cisco prepends AS on inbound updates from eBGP peers. 
I understand Juniper prepends AS on outbounds updates towards eBGP peers. 
In most cases, Cisco approach is better.

> > > > Consider
> > > >
> > > > R1 (AS1) ----(local-as 2) R2(AS3)--- R3(AS3) --- R4 (AS4)
> > > >          ebgp                    iBGP
> > > >
> > > > Cisco:
> > > >
> > > > R1: X
> > > > R2: 2 X
> > > > R3: 2 X
> > > > R4: 3 2 X
> > > >
> > > > Juniper
> > > >
> > > > R1: X
> > > > R2: X
> > > > R3: 2 X
> > > > R4: 3 2 X
> > > >
> > > > I think it's prefereable that R2 and R3 have the same AS-PATH. 
Otherwise
> > > > you can have inconsistent best-path decission inside AS3

-Juan

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Apr 2015 03:53:21 -0400

Juan: 

Do you think something needs to change in this draft?  This is the last day
of the WG adoiption call. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Juan Alcaide
Sent: Thursday, April 16, 2015 5:27 PM
To: Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Hi,

Otherwise

-Juan

On Thu, 9 Apr 2015, Alvaro Retana (aretana) wrote:

>> On re-doing WG LC, we can do this in parallel with the other reviews 
>> I'll need to redo (security directorate, routing directorate, 
>> ops-directorate and gen-art). I'll start both sequences at the same 
>> time once I've heard from Alvaro.
>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Apr 2015 03:55:09 -0400

Hi all: 

It appears that Juan is gone for 1 week, so we will pick-up his comments on
draft-ietf-idr-as-migration-04 during the IESG review time.  

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, April 20, 2015 3:53 AM
To: 'Juan Alcaide'; 'Alvaro Retana (aretana)'
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Juan: 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Juan Alcaide
Sent: Thursday, April 16, 2015 5:27 PM
To: Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Hi,

Otherwise

-Juan

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 20 Apr 2015 12:44:14 +0000

What would be great is that the features that are being used are standardized across vendors. The current approach where each implementation varies in behavior will make life difficult.  

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, April 20, 2015 3:53 AM
To: 'Juan Alcaide'; 'Alvaro Retana (aretana)'
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Juan: 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Juan Alcaide
Sent: Thursday, April 16, 2015 5:27 PM
To: Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Hi,

Otherwise

-Juan

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Apr 2015 14:05:06 -0400

James:

Can you explain what you'd like to see in the changes? 

Sue 

-----Original Message-----
From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Monday, April 20, 2015 8:44 AM
To: 'Susan Hares'; 'Juan Alcaide'; 'Alvaro Retana (aretana)'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

What would be great is that the features that are being used are
standardized across vendors. The current approach where each implementation
varies in behavior will make life difficult.  

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, April 20, 2015 3:53 AM
To: 'Juan Alcaide'; 'Alvaro Retana (aretana)'
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Juan: 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Juan Alcaide
Sent: Thursday, April 16, 2015 5:27 PM
To: Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

Hi,

Otherwise

-Juan

---

From: "George, Wes" <[email-masked]>
Date: Mon, 20 Apr 2015 14:33:03 -0400

On 4/20/15, 8:44 AM, "UTTARO, JAMES" <[email-masked]> wrote:

>standardized across vendors. The current approach where each
>implementation varies in behavior will make life difficult.

WG] While I agree that this could potentially simplify things for
operators, the IETF can't force that to happen. Only those specifying
which features they require from their vendors and signing the large
checks to buy the kit can do that. Anyone who wishes to use an RFC as a
club against a vendor is welcome to do so, but changing the language in
the document to require compliance with our version of already-implemented
features that isn't required for interop reasons will not actually have
any effect.

Thanks,

Wes

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

---

From: Juan Alcaide <[email-masked]>
Date: Mon, 20 Apr 2015 16:21:38 -0400 (EDT)

Hi,

(on PTO with limitted internet access)

Possible updates:

- As we discussed, for ebgp incomming updates for local-as it makes more 
sense to prepend AS on incomming updates. I think we shoudl describe this 
option as the default one and any other one as a variation.

- Cisco plans to implement the internal BGP alias as ibgp local-as 
dual-as. So perhaps we can choose an agnostic name and explain both 
Juniper and Cisco names.

- About "the speaker SHOULD send BGP OPEN using the globally configured 
ASN first". I think we should emphasize how the FSM gets modified. It may 
be implicit, but it may save us from some interoperabilities problems. My 
ideas:

  1) In any case, my-AS and your-AS MUST be equal on any case.
  2) Define what to do if you send global-AS but you receive local-AS. 
Probably respond wiht "Bad Peer AS". But I'd like to understand what 
Juniper is doing as well.
  3) Note that without an agreement of the AS that is used first (both 
peers could decide to use first the local-as if they are both configured as 
such). This would happen in 2)

-Juan

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Apr 2015 16:26:47 -0400

On Mon, Apr 20, 2015 at 04:21:38PM -0400, Juan Alcaide wrote:
> - As we discussed, for ebgp incomming updates for local-as it makes
> more sense to prepend AS on incomming updates. I think we shoudl
> describe this option as the default one and any other one as a
> variation.

I would say that the "Juniper" behavior has quite a bit of history.  Wes and
company have done a good job being agnostic about these long-standing
behaviors and simply documenting them rather than kicking off a particular
religious war on what should be done.

It wouldn't surprise me though that the publication of this document as an
RFC leads to various vendors implementing versions of the knobs they
previously didn't support.

> dual-as. So perhaps we can choose an agnostic name and explain both

I think it's beyond the scope of any IETF document beyond yang and MIB
modules to prescribe the name of a vendor's configuration knob. :-)

(The astute reader will note that we'll have to settle on a name in the yang
module.  See prior comments at the mic during IDR about IETF
vendor-registered augmentation modules.)

> - About "the speaker SHOULD send BGP OPEN using the globally
> configured ASN first". I think we should emphasize how the FSM gets
> modified. It may be implicit, but it may save us from some
> interoperabilities problems. My ideas:

You are welcome to provide text for such a thing but I would suggest it's
not worth the review time of IDR.  The introduction of the internal toggle
would effectively instantiate a sub-state machine within the overall state
machine and be quite the mess.  I have long since lost my notes on the FSM
during RFC 4271 standardization work, but had noted that it had some issues.

Feel free to audit the FSM to see if you can find those issues again and see
how this would interact with the errata. :-)

--Jeff

---

From: Juan Alcaide <[email-masked]>
Date: Wed, 22 Apr 2015 05:20:45 -0400 (EDT)

Jeffrey,

Inline..

> previously didn't support.

You mean vendors implementing 'prepend on incomming ebgp update'?
Possibly, but we shouldn't describe on a RFC only the suboptimal approach 
('prepend on outbound ibgp update')

> vendor-registered augmentation modules.)
So internal-alias, besides Juniper naming, is the 'official' name 
according to the yang module?

In anycase, since the draft describes multiple vendors implementations, it 
may be worth to describe the naming of others.

> how this would interact with the errata. :-)

Don't want to do a deep inspection of the FSM ;-)
It's something more basic. Consider

- You can send only one AS in your open each time you try to establish a 
new session
- The As you send does not depend on the AS you receive (no negotiation)
- You can accept received AS to be accepted if it's one of the 2 
configured ones
- You must force AS you send and AS you receive to be the same.

>From the above, it can be deduced that if both speakers have the internal 
alias feature configured, they must send the same AS ast the first time 
they try to establish the session. And session must be formed with this 
AS. Otherwise, AS never match and session cannot be establish.

We could do something more complicated, but this would really be beyond 
the scope of the draft.

---

From: "George, Wes" <[email-masked]>
Date: Wed, 22 Apr 2015 17:10:29 -0400

>may be worth to describe the naming of others.

WG] It doesn't really describe any vendors' implementations anymore, but
rather an amalgam of multiple implementations, and one of the only places
that it does (section 4.1 title) was a mistake that Alvaro caught and I
have already fixed in the pending revision. I'd encourage you to re-read
the latest draft and identify any places where we are still naming one
vendor's implementation such that we need to discuss the naming of others,
because we probably need to fix that too.

>- You must force AS you send and AS you receive to be the same.

WG] I think the point here is that even this more basic guidance needs to
be bashed against what the FSM currently does vs what the spec says it
should do (or worse, where the spec is ambiguous and has likely been
handled different ways by different vendors) before we can determine
where/if it's actually necessary to provide explicit guidance on the
matter. The philosophy of the draft has generally been to not be overly
proscriptive and discuss the desired behavior, and then let the
implementers figure out how that has to work in the guts of their BGP
implementation, such as within their implementation of FSM. If you can
point to guidance that we need to provide to prevent the desired behavior
from being critically altered if it is incorrectly implemented at the FSM
level or it otherwise creates interoperability issues for something that
is pretty much only locally significant, I can see about adding it, but
you will definitely need to provide text, as I am by no means an expert on
how this interacts with the FSM.

Thanks
Wes

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Apr 2015 19:35:56 -0400

WG, George, Jeff and Juan: 

A revision to the state machine in BGP is outside the scope of this draft.  For those who want to participate in a revision of the state machine, please send me your names.   I will put you on a design team to examine the state machine and provide a draft for the WG group. 

Sue 

-----Original Message-----
From: George, Wes [mailto:[email-masked]] 
Sent: Wednesday, April 22, 2015 5:10 PM
To: Juan Alcaide; Jeffrey Haas
Cc: [email-masked]'; [email-masked]'; UTTARO, JAMES; 'Susan Hares'
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

On 4/22/15, 5:20 AM, "Juan Alcaide" <[email-masked]> wrote:

>
>In anycase, since the draft describes multiple vendors implementations, 
>it may be worth to describe the naming of others.

WG] It doesn't really describe any vendors' implementations anymore, but rather an amalgam of multiple implementations, and one of the only places that it does (section 4.1 title) was a mistake that Alvaro caught and I have already fixed in the pending revision. I'd encourage you to re-read the latest draft and identify any places where we are still naming one vendor's implementation such that we need to discuss the naming of others, because we probably need to fix that too.

>
>> You are welcome to provide text for such a thing but I would suggest 
>>it's  not worth the review time of IDR.  The introduction of the 
>>internal toggle  would effectively instantiate a sub-state machine 
>>within the overall state  machine and be quite the mess.  I have long 
>>since lost my notes on the FSM  during RFC 4271 standardization work, 
>>but had noted that it had some issues.
>>
>> Feel free to audit the FSM to see if you can find those issues again 
>>and see  how this would interact with the errata. :-)
>
>Don't want to do a deep inspection of the FSM ;-) It's something more 
>basic. Consider
>
>- You can send only one AS in your open each time you try to establish 
>a new session

WG] I think the point here is that even this more basic guidance needs to be bashed against what the FSM currently does vs what the spec says it should do (or worse, where the spec is ambiguous and has likely been handled different ways by different vendors) before we can determine where/if it's actually necessary to provide explicit guidance on the matter. The philosophy of the draft has generally been to not be overly proscriptive and discuss the desired behavior, and then let the implementers figure out how that has to work in the guts of their BGP implementation, such as within their implementation of FSM. If you can point to guidance that we need to provide to prevent the desired behavior from being critically altered if it is incorrectly implemented at the FSM level or it otherwise creates interoperability issues for something that is pretty much only locally significant, I can see about adding it, but you will definitely need to provide text, as I am by no means an expert on how this interacts with the FSM.

Thanks
Wes

---

From: Juan Alcaide <[email-masked]>
Date: Thu, 23 Apr 2015 08:12:18 -0400 (EDT)

> because we probably need to fix that too.

My bad then.. I was looking at 
https://tools.ietf.org/html/draft-ietf-idr-as-migration-04. Where can I 
find the latest?

---

From: Juan Alcaide <[email-masked]>
Date: Thu, 23 Apr 2015 08:17:26 -0400 (EDT)

Let me be clear. I don't want to revise the FSM.

With the current FSM, internal BGP alias feature will work if we are 
strict in how it's implemented. Otherwise, we may have interoperability 
problems. Basically, it needs to be specified with AS is tried first.

Just want to make sure the draft says this explicetely (in its current 
form it is implied).

-J