Subject: Re: [sidr] Acceptance call for draft-george-sidr-as-migration-01.txt

From: "George, Wes" <[email-masked]>
Date: Wed, 3 Jul 2013 13:11:22 -0400

Thanks for the review. I made most of the nits changes, and will post a revision soon. Some comments below inline

> -----Original Message-----
> From: Sriram, Kotikalapudi [mailto:[email-masked]]
>
> Please note that some minor omissions have resulted in technical
> inaccuracies
> in the AS_PATH and/or bgpsec update representation in the example
> scenarios/solutions
> (see pages 21, 23 of the attached).
[WEG] I reviewed that, (eg "Comment: AS_PATH must show the actual path traversed; cannot hide AS 200.") and I don't think that's correct. The entire point behind this draft and its companion is that when using Local/replace AS functions, the AS_PATH is actually manipulated and the AS that we desire to hide *is* hidden from the AS_PATH, so I believe that the example is correct as it stands.

>
> One key technical comment is related to an additional scenario
> that may be worthwhile including for the proposed solution.
> It has to do with three ISP's (or ASes) being involved in the migration
> scenario:
>
>                         ISP A'                           ISP A'
> CE-1 ---------> PE-1 -------------------> PE-3 -----------> CE-3
> 100        Old_ASN: 300              Old_ASN: 500          600
>                New_ASN: 200            New_ASN: 200
>                     |                                          |
>                     |                                          |
>                     |                                          |
>                     |               ISP A'                 |
>                      ------------PE-2----------------
>                                  Old_ASN: 200
>                                  New_ASN: 200
>
> Here both PE's (PE-1 on left and PE-3 right) are using Local ASN with
> their respective CEs.
> I have worked out (illustrated) a solution for this scenario (see page
> 24 of the attachment).
> This should hopefully round up (complete) the basic set of scenarios
> operators
> may encounter in the real world.
[WEG] In looking at your example, I'm not sure whether it's totally necessary as a separate scenario - it doesn't seem that the process changes any, and dealing with all of these different ASNs starts becoming hard to parse. Would it suffice to add a simple statement that this will work the same way if there are multiple different ASNs simultaneously being migrated into the subsuming ASN?
Anyone else in the WG have an opinion on this matter?

Thanks
Wes George

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: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 3 Jul 2013 16:30:51 -0400

Thanks, George. Some comments in line.

>> inaccuracies in the AS_PATH and/or bgpsec update representation in the
>> example scenarios/solutions (see pages 21, 23 of the attached).
>[WEG] I reviewed that, (eg "Comment: AS_PATH must show the actual path
>traversed; cannot hide AS 200.") and I don't think that's correct. The entire point
>behind this draft and its companion is that when using Local/replace AS
>functions, the AS_PATH is actually manipulated and the AS that we desire to
>hide *is* hidden from the AS_PATH, so I believe that the example is correct as it
>stands.

The AS_PATH is a BGP-4 attribute. We shouldn't be ideally using it when we
illustrate a BGPSEC update with signatures etc. in the examples
(unless we refer to it as Equivalent AS_PATH or something).
BGPSEC has the Secure_Path attribute instead (pages 8, 9 of the spec)
http://tools.ietf.org/pdf/draft-ietf-sidr-bgpsec-protocol-07.pdf

+----------------------------+
| AS Number (4 octets) |
+----------------------------+
| pCount (1 octet) |
+----------------------------+
| Flags (1 octet) |
+----------------------------+

All ASes in the path are included in the Secure_Path, including the "hidden" ones (w/ pCount=0).
In BGPSEC, the AS intended to be hidden is only implicitly hidden.
The receiver cannot verify the update signatures unless all ASNs that signed  
are included in the Secure_Path.
For the examples, I think that showing a condensed version of the Secure_Path works, 
where the hidden ASes are shown with pcount=0 next to them, like,
Secure_Path = 200, 300(pcount=0), 100
length = sum(pcount) = 2 (length is NOT 3)

>
>>
>> One key technical comment is related to an additional scenario that
>> may be worthwhile including for the proposed solution.
>> operators may encounter in the real world.
>[WEG] In looking at your example, I'm not sure whether it's totally necessary as
>a separate scenario - it doesn't seem that the process changes any, and dealing
>with all of these different ASNs starts becoming hard to parse. Would it suffice
>to add a simple statement that this will work the same way if there are multiple
>different ASNs simultaneously being migrated into the subsuming ASN?

I would like to hear others' thoughts on this.
The solution (worked out on p. 24) seems not so hard to parse to me.
But it is your call.
You can keep this in the reserve if you like and we can ruminate over it.
There is still time until this goes to WGLC.

Sriram

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 3 Jul 2013 20:53:38 +0000

I'm not sure about the intent of Sriram's comment, but I'd like to note that the protocol spec says the AS_PATH is not in the BGP Update when the neighbor has negotiated bgpsec (because the AS_PATH is encapsulated in the BGPSEC_PATH attribute):

                                                                    A BGPSEC update message
   containing the BGPSEC_PATH attribute MUST NOT contain the AS_PATH
   attribute.

And when the neighbor is not bgpsec capable, the AS_PATH is reconstructed from the BGPSEC_Path attribute (sec 4.4), and as Wes says, that leaves the "pcount=0" AS out of the reconstructed AS_PATH.

--Sandy, speaking as regular ol' member

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 3 Jul 2013 20:54:15 +0000

>(unless we refer to it as Equivalent AS_PATH or something).

As the intent of showing that line in the example was to demonstrate the AS_PATH that would be reconstructed from the BGPSEC_Path attribute, I think this suggestion works.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Jul 2013 09:59:25 +0100

On 03/06/2013 13:27, Alexey Melnikov wrote:
> On behalf of SIDR chairs (Chris and myself, as Sandy is a co-author) I 
> am starting 2 weeks WG acceptance call onthis document, ending on June 
> 17th. Please send your comments, positive or negative to the mailing 
> list or directly to WG chairs.
I've seen 6 or so people speaking in favour of adopting the document 
(with some comments which can be addressed later) and nobody against, so 
this document is now accepted as a WG document.

Thank you,
Alexey, as a co-chair.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 5 Jul 2013 09:11:16 -0400

>As the intent of showing that line in the example was to demonstrate the AS_PATH that would be reconstructed from the BGPSEC_Path attribute, I think this suggestion works.

Yep, would be fine with me.
If you wished to stick with bgpsec taxonomy, the alternate suggestion was (example): 
Secure_Path = 200, 300(pcount=0), 100
length = sum(pcount) = 2 (length is NOT 3)

Conveys the same message that the AS path length would not be increased.

Sriram

---

From: "George, Wes" <[email-masked]>
Date: Mon, 8 Jul 2013 08:56:48 -0400

Thanks for clarifying, that makes sense to me as well, and I'll work to clarify in the examples and elsewhere in the document where appropriate.

Wes

> Sent: Friday, July 05, 2013 9:11 AM
> To: Murphy, Sandra; George, Wes; sidr wg
> Subject: RE: [sidr] Acceptance call for draft-george-sidr-as-migration-
> 01.txt
>
> >As the intent of showing that line in the example was to demonstrate
> the AS_PATH that would be reconstructed from the BGPSEC_Path attribute,
> I think this suggestion works.
>

---

From: "George, Wes" <[email-masked]>
Date: Mon, 8 Jul 2013 11:13:13 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Terry Manderson
> Sent: Monday, June 10, 2013 8:45 PM
> To: Alexey Melnikov; sidr wg
> Subject: Re: [sidr] Acceptance call for draft-george-sidr-as-migration-
> 01.txt
> >
> As NIT fodder, I'd prefer to see documentation ASNs used (that applies
> to
> draft-ga-idr-as-migration as well, but that might be just me ;)
>
[WEG] Terry - I was working to incorporate comments, and wanted to address this one... I was hesitant to use the documentation ASNs because they are easily confused with private ASNs, and since I am explicitly talking about something that deals with public ASNs (vs confeds with private), I wanted to avoid confusion. So it was a conscious decision, but one that I can certainly change if others also believe that this is best suited to use the documentation ASNs.

Thanks
Wes George

---

From: Randy Bush <[email-masked]>
Date: Mon, 08 Jul 2013 13:00:41 -1000

> I was hesitant to use the documentation ASNs because they are easily
> confused with private ASNs

so we should have the iana throw away the doc as numbers?  this makes no
sense to me.

randy