Subject: [sidr] Minutes of 6/6/12 meeting uploaded

From: Chris Morrow <[email-masked]>
Date: Fri, 15 Jun 2012 22:37:53 -0400

Thanks to the minutes taker (Anuja) we have minutes, I uploaded them to:

<http://www.ietf.org/proceedings/interim/2012/06/06/sidr/minutes/minutes-interim-2012-sidr-3.txt>

-chris
co-chair

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Jun 2012 13:50:31 +0900

bgpsec and confederations

allow me to try to state clearly for the list

    When an update enters the first AS in a confederation, all last
    internal ASBRs within the entry AS of the confederation, i.e the
    first signers within the confederation, set a flag in the signature
    block that says "I am the first signature within the confederation."

    The update wanders around normally in the confederation and every
    sending internal confederation ASBR signs it with their internal AS.

    A confederation's exit router looks backwards in the AS sequence
    until it finds the first, i.e. most recent, instance of that flag.
    If it finds no flag, the update is treated as originated within the
    confederation.

    It strips the signature block containing the flag and all subsequent
    signature blocks.  All signs of the internals of the confederation
    have now been removed.

    It then forward signs to the next AS, using the identity of the
    public confederation AS.

    While the update is traversing the confederation, if it should hit a
    peering where the peer is is not bgpsec capable, it strips all
    bgpsec gloop and reconstructs a classic AS_path.

this is believed to handle the loop disease (e.g. the cisco "neighbor
allowas-in" command).

what if anything should be done if you find the confed flag when you are
not inside a confed is a topic for discussion.

does anyone see a flaw in the above?  please please review so we can put
it to bed.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 16 Jun 2012 03:31:29 -0400

All the effort to sign the confed AS got me thinking.
A route reflector cluster is like a member AS in a confed.
Is there a case for signing the cluster list too?

IMHO: AS boundaries are for marking boundaries of trust.
Confeds are for achieving scalability within an AS.
I think signatures are only needed across trust boundaries.
More is unnecessary complexity.

--
Jakob Heitz.

On Jun 15, 2012, at 9:50 PM, "Randy Bush" <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sat, 16 Jun 2012 10:21:25 -0400

My notes / suggested wording changes inline below, marked with "KS:".

One other observation:
We also discussed Lazy and Super Lazy modes of router operation at 6/6/12 meeting.
If we were to include descriptions for those cases for the confed ASBRs,
the description gets a bit more complicated.
Especially because the ASBR has to perform operations that are different depending on 
whether it is in an AS in the middle of the confed or in an exit AS connecting to an external peer.

Sriram
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Randy Bush [[email-masked]]
Sent: Saturday, June 16, 2012 12:50 AM
To: sidr wg list
Subject: [sidr] bgpsec and confeds [was: Minutes of 6/6/12 meeting uploaded]

KS: Please add:
However, the flag MUST NOT be set if the update entered the confed
at an AS and also exits from the same AS to go to an external peer AS.
(In this case, the update is not traversing any eBGP peering links internal to
the confed.)

KS: The last sentence above is not true. Explanation as follows.
Consider: 
AS1 --- (AS2 --- AS3 --- AS4) --- AS5
AS2, AS3, AS4  form a confed. AS1 and AS5 are external peers.
Consider an update that is exiting the confed at AS4 and being forward signed to AS5.
If the update originated from AS2 or AS3, then it is an update that indeed
originated from within the confed but it *will* come with the flag set.
And if the update originated in AS4, it should not have any signatures yet;
AS4 will add the first signature when it forward signs to AS5.
So I suggest the following change of wording: 
"If the ASBR finds no flag, then it means that the update has entered the
confed at this AS (i.e., the same AS where the ASBR is) and hence
it has not traversed any confed internal eBGP links."

KS: Please add the following:
It also strips from the Secure_Path segment the sequence of 
ASN and pCount fields corresponding to the internal ASs in the confed.

KS: Suggest adding the following for clarity:
The classic AS_path will include the standard confed sequence that is 
reconstructed from the Secure_Path and includes the sequence of 
ASNs starting with the ASN with the flag set and all ASNs that follow.

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 18 Jun 2012 13:35:03 -0400

This is consistent with my understanding of the consensus at the interim 
meeting.  I am happy with this approach as a way forward.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 18 Jun 2012 16:09:08 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jakob Heitz
> Sent: Saturday, June 16, 2012 3:31 AM
>

[WEG] Yes and no. While confeds are sometimes used for scale, they aren't *exclusively* used for scale, and therefore your two statements are in conflict with one another. In some cases Confeds have nothing to do with scale and everything to do with boundaries of trust for those of us with different internal and autonomous organizations responsible for managing different parts of our network. A confed requires some manner of coordination between the members of the confed, but it in no way implies that all of the members of the confed are centrally managed, nor should it.

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: Stephen Kent <[email-masked]>
Date: Mon, 18 Jun 2012 18:00:13 -0400

some typos in the minutes:

"Randy eludes to the discussion"   =>

"Randy alludes to the discussion"

"He says ambulating (?) alias AS"  => (my best guess)

"He says emulating alias AS"

in several places:  "As" => "AS"

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2012 07:03:55 +0900

> "Randy alludes to the discussion"

maybe it was actually elides.  i was pretty whacked :)

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2012 07:09:41 +0900

> In some cases Confeds have nothing to do with scale and everything to
> do with boundaries of trust for those of us with different internal
> and autonomous organizations responsible for managing different parts
> of our network. A confed requires some manner of coordination between
> the members of the confed, but it in no way implies that all of the
> members of the confed are centrally managed, nor should it.

for sure.  in verio, it was all about trust boundaries and segregating
igps.  66 acquisitions in three years, and sharing needles was just not
in the cards.

randy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Jun 2012 18:12:29 -0400

>maybe it was actually elides.  i was pretty whacked :)

I defer to the judgement of the speaker ;-).

Steve

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 19 Jun 2012 15:19:26 -0400

In addition to Wes and Randy's observations about trust boundaries, it's also the case that mechanically, the confederation embeds its loop prevention information in the AS path, so we have to have *some* way of dealing with it since bgpsec is monkeying with the AS path. The same problem doesn't exist for the cluster list since it's a separate attribute.

--John