On Monday, November 2, 2015, Christopher Morrow <
christopher.mor...@gmail.com> wrote:
> Howdy Grow folk (again),
> Please consider this as the start of a 3wk working group adoption call
> for the subject draft who's abstract is:
>
> "This document defines the default behaviour of a BGP speaker
> On Nov 2, 2015, at 4:04 PM, Jeffrey Haas wrote:
>
>
>> On Nov 2, 2015, at 3:57 PM, Christopher Morrow
>> wrote:
>>
>> Please read/comment/advise before 11/23/2015 - Nov 23, 2015.
>
> I support adopting this draft.
>
> I suggest it be considered for BCP status. Why BCP?
Support, agree
On Mon, Nov 02, 2015 at 05:57:54PM +1100, Christopher Morrow wrote:
> Howdy Grow folk (again),
> Please consider this as the start of a 3wk working group adoption call
> for the subject draft who's abstract is:
>
> "This document defines the default behaviour of a BGP speaker when no
>explic
> On Nov 2, 2015, at 3:57 PM, Christopher Morrow
> wrote:
>
> Howdy Grow folk (again),
> Please consider this as the start of a 3wk working group adoption call
> for the subject draft who's abstract is:
>
> "This document defines the default behaviour of a BGP speaker when no
> explicit pol
On Mon, Nov 2, 2015 at 5:50 PM, Job Snijders wrote:
> Notes from the IETF94 GROW meeting in Yokohama, Japan.
>
> Chairs: Christopher Morrow & Peter Schoenmaker
> Jabber: Colin Petrie, Notes: Job Snijders
These are uploaded to the tools-site.
thanks!
-chris
Howdy Grow folk (again),
Please consider this as the start of a 3wk working group adoption call
for the subject draft who's abstract is:
"This document defines the default behaviour of a BGP speaker when no
explicit policy is associated with a BGP peering session."
Please read/comment/advise
Notes from the IETF94 GROW meeting in Yokohama, Japan.
Chairs: Christopher Morrow & Peter Schoenmaker
Jabber: Colin Petrie, Notes: Job Snijders
#0 Thomas King - draft-ymbk-grow-blackholing
King offers background information on why a standardized blackhole
BGP community is useful. Presen
Howdy WG folks,
Please consider this the start of a 3 week Adoption call for the noted
draft who's abstract is:
"This document updates the Multi-threaded Routing Toolkit (MRT) export
format for Border Gateway Protocol (BGP) routing information by
extending it to support the Advertisement
I recommend people read Jared's draft and provide comments on both IDR and
Grow.
Sue
-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Jared Mauch
Sent: Sunday, November 01, 2015 11:19 PM
To: GROW@ietf.org; idr wg list
Subject: [Idr] draft-mauch-bgp-reject
I plan
I plan on covering this briefly in the GROW meeting today and uploaded the
revised text that has been sitting in my output queue since August.
This is basically codifying the fact that you MUST NOT default to "bgp
unsafe-ebgp-policy” for any BGP speaking device.
- Jared
On 11/2/15 8:39 AM, Christopher Morrow wrote:
> oh well, since this conversation got re-ingnited..
>
> On Sat, Oct 31, 2015 at 1:15 AM, Job Snijders wrote:
>> I think "type 5: U-Shaped Turn with More Specific Prefix" should be
>> removed from the document.
>>
>> Given the description:
>>
>> "
howdy!
after a long delay this pops out the 'adoption call' chute as 'adopted'.
The authors can spin a re-named draft when the gates re-open for draft
submission (probably monday?) and we can progress along as we should.
thanks for reading the draft, providing comments and
support/no-support comme
Howdy!
For the folk in Yokohama, we posted the agenda yesterday, I think
there's only one presenter planned? (Thomas and blackhole community
work)
If there are others please speak up 'now' (with slides as well
please), I probably forgot a presenter and 'search your mail for the
right phrase' is fa
oh well, since this conversation got re-ingnited..
On Sat, Oct 31, 2015 at 1:15 AM, Job Snijders wrote:
> I think "type 5: U-Shaped Turn with More Specific Prefix" should be
> removed from the document.
>
> Given the description:
>
> "A multi-homed AS learns a route from one upstream ISP and
>There's seemingly 1 comment set not responded to on-list (job's last),
>but overall support seems positive.
I have just posted responses to Job's comments.
>I'll ship a document shepherd
>review northbound post-ietf-meeting week.
Thank you.
>by then sriram should have an updated revision with
Job,
Thanks for your comments. My responses below.
>I think "type 5: U-Shaped Turn with More Specific Prefix" should be
>removed from the document.
>Given the description:
>"A multi-homed AS learns a route from one upstream ISP and announces
>a subprefix (subsumed in the prefix) to another
Thinking about this a bit, I prefer "hairpin turn" over "U-turn". In my mind a
"hairpin turn" is talking about a tight turn in a road and by necessity a tight
turn for the traffic on the road, the road itself turns back on itself. Where
as a "U-turn" talks about a tight turn traffic makes on r
I just went hunting for an instance of this in IETF land, and only found
references related to two hosts talking to one another from behind the
same NAT.
So, I went hunting on the internet, and everywhere I saw an explanation,
it was of the variant "going out the same interface it came in on" and
u
18 matches
Mail list logo
