Re: [GROW] Fwd: RFC 4384 rejected errata, wrong call

[Warren Kumari]

On Mon, Jan 30, 2023 at 12:19 PM, Jeffrey Haas  wrote:

> At the request of Warren, making this observation in public.
>

Thank you, Jeff! I requested this so that there is some traceability /
transparency. I think that this is especially important when changing the
state of a previous Errata call.

I went to go edit the Errata and change it, but was thwarted with:
"
Access Denied
Report 4550 for RFC4384 has already been classified as Rejected. Please
contact the RFC Editor if you want to edit this report.
"

So, I'll be contacting the RFC Editor to, but in the mean time:

Does anyone disagree with marking this Errata as Verified?
Link: https://www.rfc-editor.org/errata/eid4550
Link to Registry:
https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-two-octet-as

I sort of get where Joel was coming from, but to me Verified seems much
more correct than Rejected. Also, seeing 0x0008 in a 1 octet field is
disconcerting and makes me want to hide under my blankie and hope it goes
away…

W



> -- Jeff
>
>
> Begin forwarded message:
>
> *From: *Jeffrey Haas 
> *Subject: **RFC 4384 rejected errata, wrong call*
> *Date: *January 30, 2023 at 11:03:39 AM EST
> *To: *grow-...@ietf.org
>
> https://www.rfc-editor.org/errata_search.php?rfc=4384
>
> I think Joel made the wrong call when he rejected the point about 0x0008
> in the diagrams should be 0x08.  I went here to report the exact same
> errata. :-)
>
> -- Jeff
>
>
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC7854 (7194)

[Warren Kumari]

Ooof.

Yes, this seems to be correct (but I wouldn't mind someone else confirming)
— what I don't know is how we get the IANA registry updated — can an errata
do this (with a note to the IANA), or does it need a new document ? I'll
email the IANA and ask…

W




On Sun, Oct 30, 2022 at 8:32 AM, RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC7854,
> "BGP Monitoring Protocol (BMP)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7194
>
> --
> Type: Technical
> Reported by: Ahmed Elhassany 
>
> Section: 10.8
>
> Original Text
> -
> Information type values 0 through 32767 MUST be assigned using the
> "Standards Action" policy, and values 32768 through 65530 using the
> "Specification Required" policy, defined in [RFC5226]. Values 65531
> through 65534 are Experimental, and values 0 and 65535 are Reserved.
>
> Corrected Text
> --
> Information type values 0 through 127 MUST be assigned using the
> "Standards Action" policy, and values 128 through 250 using the
> "Specification Required" policy, defined in [RFC5226]. Values 251 through
> 254 are Experimental, and values 0 and 255 are Reserved.
>
> Notes
> -
> In Section 4.9 Peer Down Notification. The "Reason" field is defined as
> one octet, while the IANA consideration section is defining values as
> 2-octets range. This errata suggests updating the IANA registry, instead of
> the size of the "Reason" field in the Peer Down Notification message to
> avoid breaking existing implementations that use one-octet reason.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party can log in to change the status
> and edit the report, if necessary.
>
> --
> RFC7854 (draft-ietf-grow-bmp-17)
> --
> Title : BGP Monitoring Protocol (BMP) Publication Date : June 2016
> Author(s) : J. Scudder, Ed., R. Fernando, S. Stuart Category : PROPOSED
> STANDARD
> Source : Global Routing Operations
> Area : Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Fwd: Reminder: Call for Papers: IAB workshop on Management Techniques in Encrypted Networks (M-TEN)

[Warren Kumari]

Hi there all,

The IAB is organizing a workshop on Management Techniques in Encrypted
Networks (M-TEN), and I figured that this might be interesting and relevant
to many people in this WG.

Please see below for details,
W



-- Forwarded message --
From: IAB Executive Administrative Manager 
Date: Monday, August 15 2022 at 11:40 AM EDT
Subject: Reminder: Call for Papers: IAB workshop on Management Techniques
in Encrypted Networks (M-TEN)
To: IETF Announcement List 
Cc: architecture-disc...@ietf.org

IAB workshop on Management Techniques in Encrypted Networks (M-TEN)

Web page: https://www.iab.org/activities/workshops/m-ten/

User privacy and security are constantly being improved by increasingly
strong and more widely deployed encryption. This workshop aims to discuss
ways to improve network management techniques in support of even broader
adoption of encryption on the Internet.

Network management techniques need to evolve to work effectively and
reliably in the presence of ubiquitous traffic encryption and support
techniques that enhance user privacy. In an all-encrypted network, it is
not viable to rely on unencrypted metadata for network monitoring and
security functions, troubleshooting devices, and passive traffic
measurements. New approaches are needed to track network behaviors,
e.g., by directly cooperating with endpoints and applications, increasing
use of in-band telemetry, increasing use of active measurement approaches,
and privacy-preserving inference techniques.

The aim of this workshop is to provide a platform to explore the
interaction between network management and traffic encryption and initiate
new work on collaborative approaches that promote security and user privacy
while supporting operational requirements. As such the workshop aims to
address the following questions:

• What are actionable network management requirements?
• Who is willing to work on collaborative solutions?
• What are the starting points for collaborative solutions?

The following topics are considered in-scope; however, this list is non-
exhaustive:

• Actionable requirements for network management, including:
- Troubleshooting needs
- Metrics for network performance measurements
- Requirements for security functions
• Proposals or reports on improvements to network management
- Ways to support evolving, encrypted traffic better
- Measurement techniques for encrypted traffic
- New privacy-preserving active measurement methods
- Direct communication with endpoints or applications
- Secure and privacy-preserving data collection, storage, and sharing
- Adoption of encryption for the management functions themselves

Interested participants are invited to submit position papers on the
workshop topics; it may take the form of an Internet-Draft. Paper size is
not limited, but brevity is encouraged. Interested participants who have
published relevant academic papers may submit these as a position paper,
optionally with a short abstract explaining their interest and the paper’s
relevance to the workshop. The workshop itself will be focused on
discussions based on the position paper topics received.

All inputs submitted and considered relevant will be published on the
workshop website. The organizers will issue invitations based on the
submissions received. Sessions will be organized according to content, and
not every accepted submission or invited attendee will have an opportunity
to present; the intent is to foster an active discussion and not simply to
have a sequence of presentations. A workshop report covering all
submissions and the workshop discussion will be published afterwards.

The workshop will be by invitation only. Those wishing to attend should
submit a position paper to the address above topics and questions. Position
papers from those not planning to attend the workshop themselves are also
encouraged.

Please indicate your interest by submitting a research proposal by August
19, 2022 to mten-workshop...@iab.org

The Program Committee members are Wes Hardaker (IAB, USC/ISI), Mallory
Knodel (IAB, Center for Democracy and Technology), Mirja Kühlewind (IAB,
Ericsson), Tommy Pauly (IAB, Apple), Russ White (IAB, Juniper), Qin Wu
(IAB, Huawei).

Feel free to contact the program committee with any further questions:
mten-workshop...@iab.org

This workshop will be held remotely during the week of Oct 17-21, 2022,
likely supporting three 2-3h sessions spread over the week based on
submissions and the availability of the invited participants. Additionally,
an in-person wrap-up or dissemination session may be organized in
co-location with RIPE85 (Belgrade, Serbia) on Monday Oct 24 if there is
sufficient interest by the participants. Please indicate with your
submission if you are interested in this option.

Logistics

• Submissions Due: Aug 19, 2022
• Invitations Issued by: Sep 2, 2022
• Workshop Date: Oct 17-21, 2022, optionally Oct 24
• Location: Online, optionally one day Belgrade, Serbia

Re: [GROW] Proposing a well-known BGP community for Anycast

[Warren Kumari]

On Mon, Jul 11, 2022 at 12:46 PM, heasley  wrote:

> Sat, Jul 09, 2022 at 09:32:51PM +0200, Robert Raszuk:
>
> And here comes I think need for authors to clarify something. They said
> that such marking is going to be used along with NO-EXPORT.
>
> no, you might have misread that; with no-export is possible but not
> necessary.
>
> Eg: several (perhaps all now?) of the root servers lie within anycast
> prefixes.
>

All.

These should not be marked no-export, but *could* be marked ANYCAST.
>

Many of the root server operators have the concept of "local" and "global"
nodes.
If the root server's address is e.g 10.0.0.17 [0],  global nodes will
announce 10.0.0.0/23 and local nodes announce 10.0.0.0/24, but tagged with
NO-EXPORT. This will[1] make it that networks that the node peers with
directly will use this local node, without having the great unwashed
hitting that node - this allows scaling the nodes appropriately.  If the
node falls over, traffic will simply follow the shorter /23.  This is much
better explained in ISC's "Hierarchical Anycast for Global Service
Distribution" -  https://www.isc.org/pubs/tn/isc-tn-2003-1.html ,
https://www.caida.org/catalog/papers/2007_dns_anycast/dns_anycast.pdf ,
etc..

Many nodes might be both global and local - they announce the /23 and /24,
so that networks peering with the node prefer this particular instance over
some other instance. Every now and then some network will ignore or strip
NO-EXPORT and announce the "local" prefix - this suddenly makes that node
the "bet" (longest-match), and hilarity ensues..
BGP does have many knobs that can be twiddled, but unfortunately some of
the inbound ones are still fairly heavy hammers...

W
[0]: G. The IPv4 Documentation prefixes are all /24s, and I needed
something larger, so just pretend, 'k?
[1]: Ok, should...
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

[Warren Kumari]

On Sat, Jul 09, 2022 at 6:33 AM, Robert Raszuk  wrote:

> Hi,
>
> While it may sound like I am against it - I am not. I am just trying to
> make sure what we ship can actually effectively work.
>
> One key question for example which no one answered so far is this:
>
> If I have one very important service for which I would like to use ANYCAST
> address across my geo distributed load balancers does this make my entire
> /24 or /22 I advertise any ANYCAST prefix ? I hope not.
>

Unless I'm misunderstanding this completely, the community doesn't "make" a
prefix an ANYCAST prefix, it simply **marks** (denotes) it as being used
for anycast — this is subtle, but important to note, and seems to have
caused some confusion in discussions. It an informational tag that people
can use for debugging to to apply policy...

But, getting back to your question — the smallest v4 prefix you can
realistically announce[0] on the Internet is a /24, and so the smallest
granularity you can mark at is the same.
So, if you are only using one address out of a /24  as an "anycast" address
**and for some reason you want to use this to mark the address as being
anycast** you will have to tag the whole /24. If you are only announcing a
/22, you could have to have 2 announcements, with one of the /24's tagged,
or you could tag the whole /22.

Generally when one is talking about Anycast one is talking about it at a
prefix level anyway (and often it is "these sites are announcing the same
address space and aren't intending to carry traffic between sites").
E.g: Let's say you have 192.0.2.0/24, and most of the addresses are
assigned to single machines, other than 192.0.2.17, which you has assigned
both to a machine in LA and Singapore. Technically 192.0.2.17 is anycast,
but that's not something that you need to or should share with the outside
world - it's not helpful for other people to use to build their routing
policy towards you...


W
[0]: Pedant: Acshually, you can announce fairly much whatever, but the the
smallest prefix people are likely to accept…



> 100s of hosts within my blocks may use high volume torrent which I really
> do not need to ANYCAST at the network/routing layer - I use geo
> extensions in the DNS for it.
>
> So just asking simple operational question - when do we mark prefix block
> as ANYCAST ?
>
> I think if we are serious about actually helping ANYCASTs perhaps we
> should allow to advertise those addresses separate from allocated PI or PA
> blocks  For PA it will get aggregated. For PI it will a little bit
> pollute the table - I guess this is why the current version of the draft
> says that ANYCAST prefixes will be advertised with NO-EXPORT community.
>
> Thx,
> R.
>
>
>
>
>
>
>
>
> On Sat, Jul 9, 2022 at 11:37 AM Alejandro Acosta  gmail.com> wrote:
>
>> Hello,
>>
>>After reading the draft and the comments on the list. I think this is
>> going to be useful and will make BGP take better decisions. +1 to move
>> this draft forward.
>>
>>I wonder about the misuse of the community ANYCAST when the prefix
>> being announced is not actually an anycast prefix, can be there a kind
>> of abuse from some operators?. Do we need -if not out there already- a
>> list of public anycasted prefixes (and I believe I have seem this
>> question somewhere).
>>
>>
>> Regards,
>>
>>
>> Alejandro,
>>
>>
>> On 5/7/22 5:40 AM, Maximilian Wilhelm wrote:
>> > Hey folks,
>> >
>> > after some discussion at RIPE84 we took the time to formalize a draft
>> > to define a well-known BGP community to indicate a given prefix is
>> > carrying Anycast traffic. The intent is to allow ISPs to do well
>> > informed TE, especially in cases where they want to diverge from the
>> > hot potato principle.
>> >
>> > You can find the draft at
>> >
>> > https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
>> >
>> > Happy to share this at the upcoming meeting and hear your thoughts!
>> >
>> > Thanks and best,
>> > Max
>> >
>> > ___
>> > GROW mailing list
>> > GROW@ietf.org
>> > https://www.ietf.org/mailman/listinfo/grow
>>
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>>
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] IETF "leadership pipeline"

[Warren Kumari]

Hi there all,
An ongoing topic in the IETF & IESG is how to grow the IETF "leadership
pipeline", so that when we need new AD and / or chairs, we have good
candidates.

Currently when a new chair needs to be appointed the process goes something
like this (with some added hyperbole):
The AD(s) thinks "Hmmm.. I need a chair for FOOWG, and so I need someone
who understands FOO protocol. Erm Oh! Mary! Mary knows FOO, and she's
sane and friendly and organized and will keep things moving. Everyone knows
Mary, she's strong enough to push back on the crazy, she'll keep the
meetings running along... She has the added advantage of not working for
the same company as $other_chair, but gets on well with $other_chair.  Oh!
She's also already chaired BARWG and BAZWG and that went OK... She's
perfect, I'll appoint Mary!".

(In practice there is usually also discussions with the other chair (if
any), a mail to the WG asking for volunteers, some discussions with key WG
participants to see if they have any suggestions, etc, but there is still a
tendency / bias to appoint someone known to the AD / "the obvious"
candidate / people who have already demonstrated competence.  Clearly this
is suboptimal... If  it is a new WG there is usually a BOF and
additional discussions on BOF proponents and chairs, but the general
principle holds)

Often, when appointing a chair, there is a bit of a rush - a meeting is
coming up, a new WG is being formed, etc, and people who would make good
candidates are overlooked, or are not really confident enough to put
themselves forward for a specific role.

So, what I'd like to try is asking for volunteers who'd like to be
considered when we are looking for chairs. In some cases it is important
that the chair(s) are experts in the technology - but a lot of chairing
also involves more general technical knowledge,
"leadership"/diplomacy/mediation, organizational skills, babysitting, etc.

I've created a Google form to record answers / help me keep track of
volunteers: https://forms.gle/P8dZ8diT7Y5kFsNA7

Don't worry, filling in the form isn't a commitment to serve, but rather a
"Hey, I'm interested, please keep me in mind when choosing a new
FOOWG chair".
Information will be shared with the current (and future) Ops & Mgmt ADs,
unless you tick the "Any WG in the IETF", in which case your interest will
be shared with other IESG members.

Obviously, if you are not comfortable filling in the form but still want to
volunteer, just email Warren and/or Rob.

 Also, as always, if you have any questions, comments, etc do the same
Warren and Rob

-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft minutes. ietf 112

[Warren Kumari]

Email the secretariat -- they can do, AFACIT, anything :-)

W

On Thu, Dec 9, 2021 at 12:43 PM Christopher Morrow <
christopher.mor...@gmail.com> wrote:

>
>
> On Thu, Dec 9, 2021 at 12:25 PM tom petch  wrote:
>
>> From: Christopher Morrow 
>> Sent: 09 December 2021 15:42
>>
>> On Thu, Dec 9, 2021 at 5:07 AM tom petch > ie...@btconnect.com>> wrote:
>> Sent: 09 November 2021 16:26
>> To: grow@ietf.org
>> Subject: [GROW] draft minutes. ietf 112
>>
>> I place these in the ietf notes app:
>>
>> https://notes.ietf.org/notes-ietf-112-grow
>>
>> pretty short so it shouldn't be hard to review.
>>
>> 
>>
>> They do not appear to be in the datatracker
>>
>>
>> apparently adding to a previous meeting is 'unpossible'... or
>> my clicking / reading / poking at datatracker hasn't shown me how to add
>> the notes to the 112 meeting.
>>
>> happy to be shown otherwise though :)
>>
>> 
>> Well, minutes were being added to 112 for weeks after 112 ended so
>> someone somewhere knows how to do it.  Perhaps
>>
>
> Sorry I didn't mean to say that this was your fault :)
> You could add minutes to the materials page up until they moved the
> materials page from 112 -> 113 ;(
>
>
>> "If you think this is a server error, please contact
>> datatracker-proj...@ietf.org."
>>
>
> yes... perhaps: "Hey, maybe less speed on jumping forward would be nice??"
>
>
>>
>> If I click on the link you gave, I get a page of hedgehogs - well that is
>> what it looks like:-)
>>
>>
> I think the original link was from Joel... but for completeness:
>   https://datatracker.ietf.org/ -> meetings->materials
> https://datatracker.ietf.org/meeting/materials/
>
> shows me 'IETF 113 meeting materials' and no way to add to the 112 meeting
> materials :(
>
>
>> Tom Petch
>>
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>>
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Fwd: NomCom 2021-2022 Call for Community Feedback

[Warren Kumari]

Please provide feedback to the NomCom -- the IESG you get is the one that
*you* help select.

Even a few sentences help...
W

-- Forwarded message -
From: NomCom Chair 2021 
Date: Tue, Oct 19, 2021 at 10:28 AM
Subject: NomCom 2021-2022 Call for Community Feedback
To: IETF Announcement List 


Hi IETF,

The deadline for nominee acceptance and questionnaire submission was
yesterday,
Oct 18.

As of today, Oct 19, NomCom is accepting feedback on nominees for
IAB, IESG Area Directors, IETF Trust and LLC Board. NomCom is also
accepting
feedback on other topics (more on this below).

You can see the list of nominees for the 2021 nomination cycle at
https://datatracker.ietf.org/nomcom/2021/feedback/
[If you are a nominee and submitted a questionnaire your name should appear
on that page,
otherwise, please let me know.]

You may provide feedback using the web form. Any submitted feedback is
encrypted with a key I created and gave only to NomCom members.
Without this key, your feedback cannot be seen by the secretariat, the
tools people, or any of the management.

Your feedback through the web form is not anonymous when shown to
NomCom members as you need an IETF login to provide it.

You may also send feedback directly to the NomCom via nomcom-2021 at
ietf.org

If you want to give more anonymous feedback, please contact one
of the NomCom members that you trust directly, and ask that person to
relay the feedback anonymously to the NomCom.

You can also submit feedback via email to nomcom-chair-2021 at
ietf.org and I will enter it in the datatracker (one email per
candidate, please). Please indicate if I should share your identity
with the full NomCom.

The positions to be filled and the desired expertise are listed at:
https://datatracker.ietf.org/nomcom/2021/

Some of you may be aware of the "360-degree reviews" of the current IESG
ADs:
https://mailarchive.ietf.org/arch/msg/ietf-announce/DecFofU9c-svf_yiCPQDi6nLOQg/

I encourage you to provide that feedback as well. I wish to clarify that
personnel feedback to
NomCom should be limited to nominees (some of which may also be IESG
incumbents).
This should clarify the difference of NomCom feedback with the "360-degree
reviews".

NomCom also welcomes feedback on topics related to the nomination process.
Please submit via email as suggested above, although some topics may start
showing up in the above feedback web form at
https://datatracker.ietf.org/nomcom/2021/feedback/.


Thanks in advance for your feedback - we really value it and
appreciate your time taken to submit it.

Gabriel

Gabriel Montenegro
IETF NomCom Chair 2021-22
nomcom-chair-2021 at ietf dot org

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] IRTF - An "interim" workshop on Evolving Routing Security in the Internet

[Warren Kumari]

On Wed, Sep 22, 2021 at 12:41 AM Christopher Morrow <
christopher.mor...@gmail.com> wrote:

> odd that this didn't:
>   1) get sent to grow directly?
>   2) get sent to sidroops directly?
>
>
Probably and probably.

Although, with further looking it isn't actually an IETF/IRTF thing:
"(Please note, this is not an IETF/IRTF meeting, but we thought the
IETF/IRTF
community would be interested.)" and seems to be organized by Daniel King /
SARAH / JISC.

It's always hard to know if it's worth sending these sorts of
announcements to WGs, or it they'll run into the "Stop sending my spam
about random conferences" response :-)

I've CCed in Adrian, who probably has more details and can provide
background so GROWers know if they should attend...

W


> On Fri, Sep 17, 2021 at 12:42 PM Warren Kumari  wrote:
>
>> Hi there,
>>
>> I stumbled across an announcement of a workshop on Evolving Routing
>> Security in the Internet on the IRTF list:
>> https://mailarchive.ietf.org/arch/msg/irtf-discuss/1TshQOGrKGe-5QsLn7OeYwa3_vg/
>>
>> And figured it might be of interest to SIDROPS/GROW, etc.
>>
>> ---
>> [irtf-discuss] An "interim" workshop on Evolving Routing Security in the
>> Internet
>> Adrian Farrel  Thu, 16 September 2021 10:19 UTCShow
>> header
>>
>> Hi,
>>
>> We've put together a small workshop on Evolving Routing Security in the
>> Internet to be held on Thursday 30th September at 3pm UTC [1]
>>
>> Our objective is to bring relevant information and research to the routing
>> community and spark discussion about routing research.
>>
>> Attendance is open and free.
>>
>> Meeting materials will be at
>>
>> https://github.com/danielkinguk/sarah/tree/main/conferences/security-worksho
>> p
>>
>> We will use Webex :
>>
>> https://htf-paris.my.webex.com/htf-paris.my-en/j.php?MTID=mc8bb1a7bcda855d14
>> 060678f65272117 and stream the meeting on YouTube at
>> https://youtu.be/V9CZC42BTDc
>>
>> Our agenda for this meeting features three presentations and a period for
>> open discussion.
>> * Mutually Agreed Norms for Routing Security
>>Andrei Robachevsky, Internet Society
>> * Lightweight blockchain assisted secure routing of swarm UAS networking
>>Houbing Song and Jian Wang, Embry-Riddle Aeronautical University
>> * On-Demand Blind Packet Forwarding
>>Irfan Simsek, University of Duisburg-Essen
>>
>> We hope you can fit this into your schedule.
>>
>> (Please note, this is not an IETF/IRTF meeting, but we thought the
>> IETF/IRTF
>> community would be interested.)
>>
>> Best,
>> Adrian and Dan
>>
>> [1]
>>
>> https://www.timeanddate.com/worldclock/converter.html?iso=20210930T15
>> =1440=tz_pt=tz_et=tz_bst=tz_cest=tz_cst-china
>>
>> 
>>
>> --
>> Perhaps they really do strive for incomprehensibility in their specs.
>> After all, when the liturgy was in Latin, the laity knew their place.
>> -- Michael Padlipsky
>> ___
>> GROW mailing list
>> GROW@ietf.org
>> https://www.ietf.org/mailman/listinfo/grow
>>
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] IRTF - An "interim" workshop on Evolving Routing Security in the Internet

[Warren Kumari]

Hi there,

I stumbled across an announcement of a workshop on Evolving Routing
Security in the Internet on the IRTF list:
https://mailarchive.ietf.org/arch/msg/irtf-discuss/1TshQOGrKGe-5QsLn7OeYwa3_vg/

And figured it might be of interest to SIDROPS/GROW, etc.

---
[irtf-discuss] An "interim" workshop on Evolving Routing Security in the
Internet
Adrian Farrel  Thu, 16 September 2021 10:19 UTCShow
header

Hi,

We've put together a small workshop on Evolving Routing Security in the
Internet to be held on Thursday 30th September at 3pm UTC [1]

Our objective is to bring relevant information and research to the routing
community and spark discussion about routing research.

Attendance is open and free.

Meeting materials will be at
https://github.com/danielkinguk/sarah/tree/main/conferences/security-worksho
p

We will use Webex :
https://htf-paris.my.webex.com/htf-paris.my-en/j.php?MTID=mc8bb1a7bcda855d14
060678f65272117 and stream the meeting on YouTube at
https://youtu.be/V9CZC42BTDc

Our agenda for this meeting features three presentations and a period for
open discussion.
* Mutually Agreed Norms for Routing Security
   Andrei Robachevsky, Internet Society
* Lightweight blockchain assisted secure routing of swarm UAS networking
   Houbing Song and Jian Wang, Embry-Riddle Aeronautical University
* On-Demand Blind Packet Forwarding
   Irfan Simsek, University of Duisburg-Essen

We hope you can fit this into your schedule.

(Please note, this is not an IETF/IRTF meeting, but we thought the IETF/IRTF
community would be interested.)

Best,
Adrian and Dan

[1]
https://www.timeanddate.com/worldclock/converter.html?iso=20210930T15
=1440=tz_pt=tz_et=tz_bst=tz_cest=tz_cst-china



-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Fwd: NomCom 2021-2022 Call for Nominations

[Warren Kumari]

Dear all,

You've probably already seen this multiple times by now, but it's
sufficiently important that I figured I'd send it again.

There are many open positions that the NomCom needs to fill:
ART AD: 1 position
INT AD: 1 position
OPS AD: 1 position
RTG AD: 1 position
SEC AD: 1 position
TSV AD: 1 position
IETF Trust: 1 position
IETF LLC: 1 position
IAB: 6 positions

Please consider running for one or more of these positions.

Note: I personally think that Rob is doing a great job as the Management
side of Ops & Management (even if he does insist on calling it Management &
Ops :-)), but, obviously, feel free to run for this position as well..

In addition, I haven't decided if I'm likely to run again at the end of my
term (March 2023) -- I love y'all dearly, but you sure are a lot of
work(!), and some turnover/competition is good. Please let me know if you'd
like to chat about what all the OpsAD role requires, if you have
any questions, etc.

W

-- Forwarded message -
From: NomCom Chair 2021 
Date: Mon, Aug 30, 2021 at 10:04 AM
Subject: NomCom 2021-2022 Call for Nominations
To: IETF Announcement List 
Cc: 


Finally! The moment we've all been waiting for:

   C A L L   F O R   N O M I N A T I O N S  ! ! !

The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations
from now until Monday, October 11, 2021.

The open positions and more information are found at the NomCom web site:

https://datatracker.ietf.org/nomcom/2021/

They are also included below for convenience.

Nominations may be made by selecting the Nominate link at the top of the
NomCom 2021 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2021/nominate/

Self-nomination is welcome!

Note:  Nominations made using the web tool require an ietf.org datatracker
account. You can create a datatracker ietf.org account if you don't have
one
already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

If you are unable to use the web form, nominations may instead be made by
email
to nomcom-2021 at ietf dot org. If using email, please include the word
"Nominate"
in the Subject and indicate in the email who is being nominated, their
email
address (to confirm acceptance of the nomination), and the position for
which you
are making the nomination. If you are nominating someone other than
yourself,
please tell us if we may tell the nominee that you were the one who made
the
nomination. If you wish to nominate someone via email for more than one
position, please use separate emails to do so.

Willing nominees will be asked to fill out a questionnaire specific to the
position
for which they are nominated. The finalized questionnaires will be
available no
later than Monday, September 6, 2021 (preliminary versions are already
posted)
and have a submission deadline of Monday, October 18, 2021.

NomCom 2021-22 will follow the policy for "Open Disclosure of Willing
Nominees" described in BCP 10/RFC 8713: "The list of
nominees willing to be considered for positions under review in the current
NomCom cycle is not confidential". Willing nominees for each position will
be
listed in a publicly accessible way, e.g., anyone with a datatracker
account may
access the lists. Additionally, the nomination form asks if we may share
your own
name with the nominee. In all other ways, the confidentiality requirements
of BCP
10 remain in effect. All feedback and all NomCom deliberations will remain
confidential and will not be disclosed.

There is a field on the form you can mark in order to allow the NomCom to
tell
the nominee that you were the one who made the nomination. This defaults to
“no” - so if you don't mark the field we won’t tell.

In order to ensure time to collect sufficient community feedback about each
of
the willing nominees, nominations must be received by the NomCom on or
before
Monday, October 11, 2021.

Please submit your nominations as early as possible for the sake of your
nominees. Note that nominations should not wait for nominee management
permission, as it is easier to decline the nomination than put one in late.

The NomCom appoints individuals to fill open slots on the IAB, IESG, the
IETF
Trust and the LLC Board:

ART AD: 1 position
INT AD: 1 position
OPS AD: 1 position
RTG AD: 1 position
SEC AD: 1 position
TSV AD: 1 position
IETF Trust: 1 position
IETF LLC: 1 position
IAB: 6 positions

The list of people and posts whose terms end with the
March 2022 IETF meeting, and thus the positions for which this NomCom is
responsible, is:

[An asterisk (*) next to a person's name indicates they do not intend to
accept
renomination.]

LLC Board (3-year term)
Jason Livingood

IETF Trust (3-year term)
Kathleen Moriarty

IAB (2-year term)
Ben Campbell *
   

Re: [GROW] [Technical Errata Reported] RFC6396 (6640)

[Warren Kumari]

Awesome thanks Colin!
W

On Thu, Jul 15, 2021 at 5:03 AM Colin Petrie  wrote:
>
> I checked the encoding of the attribute, the errata looks correct to me
> also.
>
> Thanks,
> Colin
>
>
>
>
> On 13/07/2021 15:22, Warren Kumari wrote:
> > [ - RFC Editor (for clutter) ]
> >
> > Dear GROW,
> >
> > AFAICT, this errata is correct, and should be Verified, but I'd like
> > some confirmation / double-checkin'.
> >
> > Note that there is already a somewhat related errata:
> > https://www.rfc-editor.org/errata_search.php?rfc=6396_status=0
> >
> > Please let me know by Friday (July 16th) if you disagree with the Errata.
> > W
> >
> > On Tue, Jul 13, 2021 at 9:01 AM RFC Errata System
> >  wrote:
> >>
> >> The following errata report has been submitted for RFC6396,
> >> "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format".
> >>
> >> --
> >> You may review the report below and at:
> >> https://www.rfc-editor.org/errata/eid6640
> >>
> >> --
> >> Type: Technical
> >> Reported by: Claudio Jeker 
> >>
> >> Section: Appendix A
> >>
> >> Original Text
> >> -
> >>|   BGP Path Attributes =
> >>
> >>40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00
> >>fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d
> >>b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00
> >>00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20
> >>20 01 0d b8
> >>
> >>Figure 19: MRT RIB_IPV6_UNICAST Example
> >>
> >> The contents of the BGP Path Attribute field above are as follows:
> >>
> >> ORIGIN: IGP
> >> ASPATH: 64496 64511 64502
> >> MP_REACH_NLRI(IPv6 Unicast)
> >> NEXT_HOP: 2001:db8:d:ff::187
> >> NEXT_HOP: fe80::212:f2ff:fe9f:1b00
> >> NLRI: 2001:0DB8::/32
> >>
> >>Figure 20: BGP Path Attribute Contents
> >>
> >>
> >> Corrected Text
> >> --
> >>|   BGP Path Attributes =
> >>
> >>40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00
> >>fb ff 00 00 fb f6 80 0e 21 20 20 01 0d b8 00 0d
> >>00 ff 00 00 00 00 00 00 01 87 fe 80 00 00 00 00
> >>00 00 02 12 f2 ff fe 9f 1b 00
> >>
> >>Figure 19: MRT RIB_IPV6_UNICAST Example
> >>
> >> The contents of the BGP Path Attribute field above are as follows:
> >>
> >> ORIGIN: IGP
> >> ASPATH: 64496 64511 64502
> >> MP_REACH_NLRI(IPv6 Unicast)
> >> NEXT_HOP: 2001:db8:d:ff::187
> >> NEXT_HOP: fe80::212:f2ff:fe9f:1b00
> >>
> >>Figure 20: BGP Path Attribute Contents
> >>
> >>
> >> Notes
> >> -
> >> The encoding of the MP_REACH_NLRI attribute is not in the form according 
> >> to Section 4.3.4.  RIB Entries:
> >>
> >> There is one exception to the encoding of BGP attributes for the BGP
> >> MP_REACH_NLRI attribute (BGP Type Code 14) [RFC4760].  Since the AFI,
> >> SAFI, and NLRI information is already encoded in the RIB Entry Header
> >> or RIB_GENERIC Entry Header, only the Next Hop Address Length and
> >> Next Hop Address fields are included.  The Reserved field is omitted.
> >> The attribute length is also adjusted to reflect only the length of
> >> the Next Hop Address Length and Next Hop Address fields.
> >>
> >> The example includes a full MP_REACH_NLRI attribute. This is a common 
> >> issue with TABLE_DUMP_V2 and parsers need to implement a workaround to 
> >> support the broken form.
> >>
> >> One way of solving this is to compare the attribute length of 
> >> MP_REACH_NLRI with the first byte of the attribute.
> >> If the value of the first byte is equal to the attribute lenght - 1 then 
> >> it is the RFC encoding else assume that a full MP_REACH_NLRI attribute was 
> >> dumped in which case the parser needs to skip the first 3 bytes to get to 
> >> the nexthop.
> >>
> >> Instructions:
> >> -
> >> This erratum is currently posted as "Re

Re: [GROW] [Technical Errata Reported] RFC6396 (6640)

[Warren Kumari]

[ - RFC Editor (for clutter) ]

Dear GROW,

AFAICT, this errata is correct, and should be Verified, but I'd like
some confirmation / double-checkin'.

Note that there is already a somewhat related errata:
https://www.rfc-editor.org/errata_search.php?rfc=6396_status=0

Please let me know by Friday (July 16th) if you disagree with the Errata.
W

On Tue, Jul 13, 2021 at 9:01 AM RFC Errata System
 wrote:
>
> The following errata report has been submitted for RFC6396,
> "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6640
>
> --
> Type: Technical
> Reported by: Claudio Jeker 
>
> Section: Appendix A
>
> Original Text
> -
>   |   BGP Path Attributes =
>
>   40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00
>   fb ff 00 00 fb f6 80 0e 2b 00 02 01 20 20 01 0d
>   b8 00 0d 00 ff 00 00 00 00 00 00 01 87 fe 80 00
>   00 00 00 00 00 02 12 f2 ff fe 9f 1b 00 00 00 20
>   20 01 0d b8
>
>   Figure 19: MRT RIB_IPV6_UNICAST Example
>
>The contents of the BGP Path Attribute field above are as follows:
>
>ORIGIN: IGP
>ASPATH: 64496 64511 64502
>MP_REACH_NLRI(IPv6 Unicast)
>NEXT_HOP: 2001:db8:d:ff::187
>NEXT_HOP: fe80::212:f2ff:fe9f:1b00
>NLRI: 2001:0DB8::/32
>
>   Figure 20: BGP Path Attribute Contents
>
>
> Corrected Text
> --
>   |   BGP Path Attributes =
>
>   40 01 01 00 50 02 00 0e 02 03 00 00 fb f0 00 00
>   fb ff 00 00 fb f6 80 0e 21 20 20 01 0d b8 00 0d
>   00 ff 00 00 00 00 00 00 01 87 fe 80 00 00 00 00
>   00 00 02 12 f2 ff fe 9f 1b 00
>
>   Figure 19: MRT RIB_IPV6_UNICAST Example
>
>The contents of the BGP Path Attribute field above are as follows:
>
>ORIGIN: IGP
>ASPATH: 64496 64511 64502
>MP_REACH_NLRI(IPv6 Unicast)
>NEXT_HOP: 2001:db8:d:ff::187
>NEXT_HOP: fe80::212:f2ff:fe9f:1b00
>
>   Figure 20: BGP Path Attribute Contents
>
>
> Notes
> -
> The encoding of the MP_REACH_NLRI attribute is not in the form according to 
> Section 4.3.4.  RIB Entries:
>
>There is one exception to the encoding of BGP attributes for the BGP
>MP_REACH_NLRI attribute (BGP Type Code 14) [RFC4760].  Since the AFI,
>SAFI, and NLRI information is already encoded in the RIB Entry Header
>or RIB_GENERIC Entry Header, only the Next Hop Address Length and
>Next Hop Address fields are included.  The Reserved field is omitted.
>The attribute length is also adjusted to reflect only the length of
>the Next Hop Address Length and Next Hop Address fields.
>
> The example includes a full MP_REACH_NLRI attribute. This is a common issue 
> with TABLE_DUMP_V2 and parsers need to implement a workaround to support the 
> broken form.
>
> One way of solving this is to compare the attribute length of MP_REACH_NLRI 
> with the first byte of the attribute.
> If the value of the first byte is equal to the attribute lenght - 1 then it 
> is the RFC encoding else assume that a full MP_REACH_NLRI attribute was 
> dumped in which case the parser needs to skip the first 3 bytes to get to the 
> nexthop.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC6396 (draft-ietf-grow-mrt-17)
> --
> Title   : Multi-Threaded Routing Toolkit (MRT) Routing 
> Information Export Format
> Publication Date: October 2011
> Author(s)   : L. Blunk, M. Karir, C. Labovitz
> Category: PROPOSED STANDARD
> Source  : Global Routing Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG



-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-ietf-grow-bmp-local-rib-11 Peer Flags IANA Conflict Resolution

[Warren Kumari]

[ + John Scudder ]
Just a quick note.

The latest version (-12) of the document was just published; the diff is
here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-grow-bmp-local-rib-11=draft-ietf-grow-bmp-local-rib-12

I'm planning on releasing it by Friday unless I hear any strong
objections...

W

On Fri, Apr 30, 2021 at 6:00 PM Tim Evens (tievens)  wrote:

> There is a conflict between the IANA registry
> https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags
> and
> https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-10#section-4.2.
> Originally, we defined that flag 0 would indicate the F flag but IANA put
> this as flag 4 under the existing peer flags registry.
>
>
>
> Does anyone know if any implementation exists today expecting flag 0? If
> so, is it a significant problem if we changed it to flag 4 to be consistent
> with IANA draft assignment?  We are still requesting a new registry "BMP
> Peer Flags for Loc-RIB Instance Peer Type 3."   This registry will start
> off with flag 4 being assigned as the F flag.
> https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-11#section-8.2
> describes this request.
>
>
>
>
>
> Thanks,
>
> Tim
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Alvaro Retana's Discuss on draft-ietf-grow-bmp-local-rib-10: (with DISCUSS and COMMENT)

[Warren Kumari]

On Wed, Apr 28, 2021 at 11:12 AM Job Snijders  wrote:

> Hi all,
>
> We (GROW chairs + Alvaro + draft authors Tim & Paolo) had a productive
> call, a number of suggestions for clarification came to light.
>
> Tim will follow up by sending a summary of proposed changes to the list.
> And some questions for the GROW group.
>
>
Awesome, thank you!
W



> Thanks!
>
> Job
>
> On Wed, Apr 21, 2021 at 07:34:22PM +0200, Job Snijders wrote:
> > Dear Alvaro, draft authors,
> >
> > Perhaps it would be good to have a voice discussion? This might expedite
> > figuring out a solution to how we describe things.
> >
> > From what I understand the BMP Loc-RIB draft to propose is that all BMP
> > messages of the Loc-RIB instance type are 'synthesized', as the
> > Information Base contains the router's best paths (regardless of
> > original protocol). It indeed would be good if the document is very
> > clear on this aspect.
> >
> > I'm happy to organize a call for early next week (early PST / afternoon
> > CEST timeslot).
> >
> > Kind regards,
> >
> > Job & Chris
> > GROW Chairs
> >
> > On Mon, Apr 05, 2021 at 12:43:02PM -0700, Alvaro Retana via Datatracker
> wrote:
> > > Alvaro Retana has entered the following ballot position for
> > > draft-ietf-grow-bmp-local-rib-10: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/
> > >
> > >
> > >
> > > --
> > > DISCUSS:
> > > --
> > >
> > > I am balloting DISCUSS because there are significant clarity issues.
> > >
> > > (1) 4.2.  Peer Flags
> > >
> > >In section 4.2 of [RFC7854], the "locally sourced routes" comment
> > >under the L flag description is removed.  If locally sourced routes
> > >are communicated using BMP, they MUST be conveyed using the Loc-RIB
> > >instance peer type.
> > >
> > > This change is bigger than simply removing a comment: it is changing
> the
> > > behavior.  Note that §8.2/rfc7854 also talks about the L flag.  Do the
> same
> > > considerations apply?   I would like to see a clearer treatment of the
> change
> > > related to locally sourced routes -- a separate section/sub-section
> seems
> > > appropriate.
> > >
> > > (2) §4.2/8.2: Peer Flags
> > >
> > > §4.2 defines a new Flag as follows:
> > >
> > >   0 1 2 3 4 5 6 7
> > >  +-+-+-+-+-+-+-+-+
> > >  |F|  Reserved   |
> > >  +-+-+-+-+-+-+-+-+
> > >
> > > But it doesn't mention that this field is intended to be specific to
> the
> > > Loc-RIB peer-type.  OTOH, §8.2 (IANA Considerations) does:
> > >
> > >This document defines a new flag (Section 4.2) and proposes that
> peer
> > >flags are specific to the peer type:
> > >
> > > The registry [1] shows that the early allocation was made in the
> "generic" (not
> > > per-peer-type) Peer Flags field.  The flags defined in rfc7854 and
> rfc8671 both
> > > assume the same set of Flags for all peer types.
> > >
> > > [1]
> > >
> https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags
> > >
> > > (3) §5.4 (Route Monitoring)  The implication in this section is that a
> BGP
> > > UPDATE includes the route information -- but the information in the
> Loc-RIB may
> > > not have come from BGP, so there is no BGP UPDATE to propagate.  This
> clearly
> > > is a case where the UPDATE is fabricated.  Please provide specific
> instructions
> > > on how this UPDATE is constructed, including any path attributes.
> > >
> > >
> > > --
> > > COMMENT:
> > > --
> > >
> > > (1) §3 (Definitions)
> > >
> > >*  Post-Policy Adj-RIB-Out: The result of applying outbound policy
> to
> > >   an Adj-RIB-Out. This MUST be what is actually sent to the peer.
> > >
> > > s/This MUST be what is actually sent to the peer./This is what is sent
> to the
> > > peer.
> > >
> > > Note that this document should not use Normative language related to
> what a BGP
> > > session does.  In this case, that is rfc4271's job.
> > >
> > > (2) §5.2 (Peer UP Notification): "Capabilities MUST include the
> 4-octet ASN and
> > > all necessary capabilities to represent the Loc-RIB route monitoring
> messages.
> > > Only include capabilities if they will be used for Loc-RIB monitoring
> messages."
> > >
> > > Which are 

Re: [GROW] Alvaro Retana's Discuss on draft-ietf-grow-bmp-local-rib-10: (with DISCUSS and COMMENT)

[Warren Kumari]

On Wed, Apr 21, 2021 at 1:34 PM Job Snijders  wrote:

> Dear Alvaro, draft authors,
>
> Perhaps it would be good to have a voice discussion? This might expedite
> figuring out a solution to how we describe things.
>

Yup, that sounds like a good idea to me.

Also, I'd like to apologize to the authors for not having made the meaning
of "DISCUSS" clearer; hopefully the blog post (
https://www.ietf.org/blog/handling-iesg-ballot-positions/) helps.

I don't think I need to be at the meetin' (scheduling difficulties scale
exponentially with the number of participants), but happy to show up if
useful...

W



>
> >From what I understand the BMP Loc-RIB draft to propose is that all BMP
> messages of the Loc-RIB instance type are 'synthesized', as the
> Information Base contains the router's best paths (regardless of
> original protocol). It indeed would be good if the document is very
> clear on this aspect.
>
> I'm happy to organize a call for early next week (early PST / afternoon
> CEST timeslot).
>
> Kind regards,
>
> Job & Chris
> GROW Chairs
>
> On Mon, Apr 05, 2021 at 12:43:02PM -0700, Alvaro Retana via Datatracker
> wrote:
> > Alvaro Retana has entered the following ballot position for
> > draft-ietf-grow-bmp-local-rib-10: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > I am balloting DISCUSS because there are significant clarity issues.
> >
> > (1) 4.2.  Peer Flags
> >
> >In section 4.2 of [RFC7854], the "locally sourced routes" comment
> >under the L flag description is removed.  If locally sourced routes
> >are communicated using BMP, they MUST be conveyed using the Loc-RIB
> >instance peer type.
> >
> > This change is bigger than simply removing a comment: it is changing the
> > behavior.  Note that §8.2/rfc7854 also talks about the L flag.  Do the
> same
> > considerations apply?   I would like to see a clearer treatment of the
> change
> > related to locally sourced routes -- a separate section/sub-section seems
> > appropriate.
> >
> > (2) §4.2/8.2: Peer Flags
> >
> > §4.2 defines a new Flag as follows:
> >
> >   0 1 2 3 4 5 6 7
> >  +-+-+-+-+-+-+-+-+
> >  |F|  Reserved   |
> >  +-+-+-+-+-+-+-+-+
> >
> > But it doesn't mention that this field is intended to be specific to the
> > Loc-RIB peer-type.  OTOH, §8.2 (IANA Considerations) does:
> >
> >This document defines a new flag (Section 4.2) and proposes that peer
> >flags are specific to the peer type:
> >
> > The registry [1] shows that the early allocation was made in the
> "generic" (not
> > per-peer-type) Peer Flags field.  The flags defined in rfc7854 and
> rfc8671 both
> > assume the same set of Flags for all peer types.
> >
> > [1]
> >
> https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags
> >
> > (3) §5.4 (Route Monitoring)  The implication in this section is that a
> BGP
> > UPDATE includes the route information -- but the information in the
> Loc-RIB may
> > not have come from BGP, so there is no BGP UPDATE to propagate.  This
> clearly
> > is a case where the UPDATE is fabricated.  Please provide specific
> instructions
> > on how this UPDATE is constructed, including any path attributes.
> >
> >
> > --
> > COMMENT:
> > --
> >
> > (1) §3 (Definitions)
> >
> >*  Post-Policy Adj-RIB-Out: The result of applying outbound policy to
> >   an Adj-RIB-Out. This MUST be what is actually sent to the peer.
> >
> > s/This MUST be what is actually sent to the peer./This is what is sent
> to the
> > peer.
> >
> > Note that this document should not use Normative language related to
> what a BGP
> > session does.  In this case, that is rfc4271's job.
> >
> > (2) §5.2 (Peer UP Notification): "Capabilities MUST include the 4-octet
> ASN and
> > all necessary capabilities to represent the Loc-RIB route monitoring
> messages.
> > Only include capabilities if they will be used for Loc-RIB monitoring
> messages."
> >
> > Which are the capabilities that "will be used for Loc-RIB monitoring
> messages"?
> >  The action above is required (MUST), but no specifics are given.
> >
> > (3) §5.2.1: "The Information field contains a UTF-8 

Re: [GROW] AD Review of draft-ietf-grow-bmp-local-rib

[Warren Kumari]

On Mon, Mar 8, 2021 at 7:16 PM Tim Evens (tievens) 
wrote:

> Hi Warren,
>
>
>
> I have just submitted revision 10 with the updates.
>

Ta! IETF LC has just been requested.

Thanks again to the authors and WG.
W



>
>
> Thanks,
>
> Tim
>
>
>
>
>
> On 2/24/21, 3:18 PM, "Warren Kumari"  wrote:
>
>
>
>
>
>
>
> On Wed, Feb 24, 2021 at 3:22 PM Tim Evens (tievens) 
> wrote:
>
> Hi Warren,
>
>
>
> Thank you so much for the review.   We agree with those changes. We have
> made the requested changes, but we cannot submit them until after Mar-8th.
> Until then, I have attached a text diff output.  You can also see the
> changes at https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib.  You
> can compare tag revisions.
>
>
>
> Awesome, thank you very much. Please let me know LOUDLY once
> you've submitted, and I'll kick off IETF LC. It will probably have to wait
> until just after IETF ends, so that people can pay attention...
>
>
>
> Thank again for the quick turn around,
>
> W
>
>
>
>
>
>
>
> Thanks,
>
> Tim
>
>
>
> On 2/22/21, 9:27 AM, "Warren Kumari"  wrote:
>
>
>
> Hi authors and WG,
>
>
>
> Thank you for this document, I believe that allowing BMP to share Loc-RIB
> is clearly a good thing.
>
>
>
> I do have a few comments/nits that addressing now should help the IETF
> LC and IESG eval go more smoothly.
>
>
>
> Please SHOUT loudly once you've had a chance to address these.
>
>
>
> AD Review of draft-ietf-grow-bmp-local-rib
> 
>
> 1: "As shown in Figure 2, Locally originated section 9.4 of [RFC4271]"
> I'm unable to parse this - changing "As shown in Figure 2, Locally
> originated" into "As shown in Figure 2, Locally Originated into Loc-RIB,
> ..." doesn't fix it, because the figure doesn't really "show what Sec 9.4
> of RFC4271" says.
>
> Perhaps something like: "Figure 2 (Locally Originated into Loc-RIB)
> illustrates how redistributed or otherwise originated routes get installed
> into the Loc-RIB based on the decision process selection in [RFC4271]"
>
>
> 2: In Section 1.1 the document says things like: "The current method
> introduces the need..."
> Once the document is published, the phrase "the current method" seems
> incorrect, but I don't have a better suggestion...
>
> 3: "Locally sourced routes MUST be conveyed using the Loc-RIB instance
> peer type."
> Should this be "locally sourced BGP routes"? It would be silly to think
> that this might carry e.g OSPF only routes, but you have a MUST, so
> important to be explicit.
> This also seems to conflict with "The F flag indicates that the Loc-RIB is
> filtered". Perhaps that above is better worded something like:
> "If locally sourced routes are communicated using BMP, they MUST be
> conveyed using the Loc-RIB instance peer type." ?
>
> 4: " The Loc-RIB contains all routes selected by the BGP protocol Decision
> Process section 9.1 of [RFC4271]."
> Similar to #1 - perhaps this is just missing a "in section of..."? Still
> needs rewording.
>
> 5: "These routes include those learned from BGP peers via its Adj-RIBs-In
> post-policy, as well as routes learned by other means section 9.4 of
> [RFC4271]."
> Similar -- I suspect that there was an errant search and replace which
> clobbered some text?
>
> 6: "Peer AS: Set to the BGP instance global or default ASN value."
> Erm, what's this default ASN value?
>
> 7: "5.1.  Per-Peer Header"
> I think that this section needs a pointer to RFC7854 Sec 4.2.
>
> 8: "Capabilities MUST include 4-octet ASN"
> s/include 4/include the 4/
>
> 9: "For example, prefix 10.0.0.0/8 is updated "
> Please use RFC5737 examples instead.
>
>
> Nit:
> 1: "This is overly complex for such a simple application that only needed
> to have access to the Loc-RIB."
> s/needed/needs/
>
> 2: It can greatly reduce time to troubleshoot and resolve issues if
> operators had the history of Loc-RIB changes.
> s/had/have/
>
> 3: "BGP Instance: it refers to an"
> s/it//
>
>
>
> --
>
> Perhaps they really do strive for incomprehensibility in their specs.
> After all, when the liturgy was in Latin, the laity knew their place.
> -- Michael Padlipsky
>
>
>
>
> --
>
> The computing scientist’s main challenge is not to get confused by the
> complexities of his own making.
>   -- E. W. Dijkstra
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AD Review of draft-ietf-grow-bmp-local-rib

[Warren Kumari]

On Wed, Feb 24, 2021 at 3:22 PM Tim Evens (tievens) 
wrote:

> Hi Warren,
>
>
>
> Thank you so much for the review.   We agree with those changes. We have
> made the requested changes, but we cannot submit them until after Mar-8th.
> Until then, I have attached a text diff output.  You can also see the
> changes at https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib.  You
> can compare tag revisions.
>

Awesome, thank you very much. Please let me know LOUDLY once
you've submitted, and I'll kick off IETF LC. It will probably have to wait
until just after IETF ends, so that people can pay attention...

Thank again for the quick turn around,
W



>
>
> Thanks,
>
> Tim
>
>
>
> On 2/22/21, 9:27 AM, "Warren Kumari"  wrote:
>
>
>
> Hi authors and WG,
>
>
>
> Thank you for this document, I believe that allowing BMP to share Loc-RIB
> is clearly a good thing.
>
>
>
> I do have a few comments/nits that addressing now should help the IETF
> LC and IESG eval go more smoothly.
>
>
>
> Please SHOUT loudly once you've had a chance to address these.
>
>
>
> AD Review of draft-ietf-grow-bmp-local-rib
> 
>
> 1: "As shown in Figure 2, Locally originated section 9.4 of [RFC4271]"
> I'm unable to parse this - changing "As shown in Figure 2, Locally
> originated" into "As shown in Figure 2, Locally Originated into Loc-RIB,
> ..." doesn't fix it, because the figure doesn't really "show what Sec 9.4
> of RFC4271" says.
>
> Perhaps something like: "Figure 2 (Locally Originated into Loc-RIB)
> illustrates how redistributed or otherwise originated routes get installed
> into the Loc-RIB based on the decision process selection in [RFC4271]"
>
>
> 2: In Section 1.1 the document says things like: "The current method
> introduces the need..."
> Once the document is published, the phrase "the current method" seems
> incorrect, but I don't have a better suggestion...
>
> 3: "Locally sourced routes MUST be conveyed using the Loc-RIB instance
> peer type."
> Should this be "locally sourced BGP routes"? It would be silly to think
> that this might carry e.g OSPF only routes, but you have a MUST, so
> important to be explicit.
> This also seems to conflict with "The F flag indicates that the Loc-RIB is
> filtered". Perhaps that above is better worded something like:
> "If locally sourced routes are communicated using BMP, they MUST be
> conveyed using the Loc-RIB instance peer type." ?
>
> 4: " The Loc-RIB contains all routes selected by the BGP protocol Decision
> Process section 9.1 of [RFC4271]."
> Similar to #1 - perhaps this is just missing a "in section of..."? Still
> needs rewording.
>
> 5: "These routes include those learned from BGP peers via its Adj-RIBs-In
> post-policy, as well as routes learned by other means section 9.4 of
> [RFC4271]."
> Similar -- I suspect that there was an errant search and replace which
> clobbered some text?
>
> 6: "Peer AS: Set to the BGP instance global or default ASN value."
> Erm, what's this default ASN value?
>
> 7: "5.1.  Per-Peer Header"
> I think that this section needs a pointer to RFC7854 Sec 4.2.
>
> 8: "Capabilities MUST include 4-octet ASN"
> s/include 4/include the 4/
>
> 9: "For example, prefix 10.0.0.0/8 is updated "
> Please use RFC5737 examples instead.
>
>
> Nit:
> 1: "This is overly complex for such a simple application that only needed
> to have access to the Loc-RIB."
> s/needed/needs/
>
> 2: It can greatly reduce time to troubleshoot and resolve issues if
> operators had the history of Loc-RIB changes.
> s/had/have/
>
> 3: "BGP Instance: it refers to an"
> s/it//
>
>
>
> --
>
> Perhaps they really do strive for incomprehensibility in their specs.
> After all, when the liturgy was in Latin, the laity knew their place.
> -- Michael Padlipsky
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] AD Review of draft-ietf-grow-bmp-local-rib

[Warren Kumari]

Hi authors and WG,

Thank you for this document, I believe that allowing BMP to share Loc-RIB
is clearly a good thing.

I do have a few comments/nits that addressing now should help the IETF
LC and IESG eval go more smoothly.

Please SHOUT loudly once you've had a chance to address these.

AD Review of draft-ietf-grow-bmp-local-rib


1: "As shown in Figure 2, Locally originated section 9.4 of [RFC4271]"
I'm unable to parse this - changing "As shown in Figure 2, Locally
originated" into "As shown in Figure 2, Locally Originated into Loc-RIB,
..." doesn't fix it, because the figure doesn't really "show what Sec 9.4
of RFC4271" says.
Perhaps something like: "Figure 2 (Locally Originated into Loc-RIB)
illustrates how redistributed or otherwise originated routes get installed
into the Loc-RIB based on the decision process selection in [RFC4271]"


2: In Section 1.1 the document says things like: "The current method
introduces the need..."
Once the document is published, the phrase "the current method" seems
incorrect, but I don't have a better suggestion...

3: "Locally sourced routes MUST be conveyed using the Loc-RIB instance peer
type."
Should this be "locally sourced BGP routes"? It would be silly to think
that this might carry e.g OSPF only routes, but you have a MUST, so
important to be explicit.
This also seems to conflict with "The F flag indicates that the Loc-RIB is
filtered". Perhaps that above is better worded something like:
"If locally sourced routes are communicated using BMP, they MUST be
conveyed using the Loc-RIB instance peer type." ?

4: " The Loc-RIB contains all routes selected by the BGP protocol Decision
Process section 9.1 of [RFC4271]."
Similar to #1 - perhaps this is just missing a "in section of..."? Still
needs rewording.

5: "These routes include those learned from BGP peers via its Adj-RIBs-In
post-policy, as well as routes learned by other means section 9.4 of
[RFC4271]."
Similar -- I suspect that there was an errant search and replace which
clobbered some text?

6: "Peer AS: Set to the BGP instance global or default ASN value."
Erm, what's this default ASN value?

7: "5.1.  Per-Peer Header"
I think that this section needs a pointer to RFC7854 Sec 4.2.

8: "Capabilities MUST include 4-octet ASN"
s/include 4/include the 4/

9: "For example, prefix 10.0.0.0/8 is updated "
Please use RFC5737 examples instead.


Nit:
1: "This is overly complex for such a simple application that only needed
to have access to the Loc-RIB."
s/needed/needs/

2: It can greatly reduce time to troubleshoot and resolve issues if
operators had the history of Loc-RIB changes.
s/had/have/

3: "BGP Instance: it refers to an"
s/it//



-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Barry Leiba's No Objection on charter-ietf-grow-03-00: (with COMMENT)

[Warren Kumari]

On Thu, Jan 28, 2021 at 11:19 AM Barry Leiba via Datatracker
 wrote:
>
> Barry Leiba has entered the following ballot position for
> charter-ietf-grow-03-00: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-grow/
>
>
>
> --
> COMMENT:
> --
>
> Two editorial things:
>
>GROW will also advise various working groups, mainly IDR and SIDROPS,
>with respect to whether it is addressing the relevant operational and
>routing security requirements of Internet-connected networks, and where
>appropriate, suggest course corrections.
>
> The antecedent to "it" appears to be "GROW", but I think it's supposed to 
> refer
> to those various working groups.  Maybe "it" should be "they"?  (Also,
> super-nit, there should be an additional comma before "where appropriate".)
>
> And there appears to be some bad punctuation problems in the "goals" paragraph
> -- missing periods, at least.


Gah! Rob and I ran into this with the IOTOPS charter -- see for
example https://datatracker.ietf.org/doc/charter-ietf-iotops/00-05/
through https://datatracker.ietf.org/doc/charter-ietf-iotops/00-14/
(inclusive!), and my comments in the histroy:
"Excuse all of the revisions. For some reason DT is breaking the
hyphens in the list. This is happening even when uploading a
(confirmed to be clean) .txt file..."

I'll go edit the text, and also see abut filing a bug.


>
>
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] grow - Requested session has been scheduled for IETF 108

[Warren Kumari]

On Fri, Jul 3, 2020 at 5:16 AM Nick Hilliard  wrote:
>
> "IETF Secretariat" wrote on 03/07/2020 01:20:
> >  grow Session 1 (1:40 requested)
> >  Monday, 27 July 2020, Session III 1410-1550
>
> Is this UTC?

Yes -- the attached ICS file contains:
DTSTART;TZID="UTC":20200727T141000 (and the agenda is here as well:
https://datatracker.ietf.org/meeting/108/agenda-utc)

W

>
> Nick



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Warren Kumari]

Thank you Sriram and Lilia -- this is helpful / useful.

I wonder if the people who configured the 21 "Routes that seem
meaningful" still know that they are doing this, or if it is a lurking
horror

W

On Wed, Oct 23, 2019 at 11:45 AM Sriram, Kotikalapudi (Fed)
 wrote:
>
> Earlier in this thread, there was discussion about some measurements that 
> were shared  (by Jared, Warren, myself).
> Jeff's suggestion: why don't we list all routes with AS_SET in addition to 
> the stats.
> Now we have a detailed analysis (thanks once again to Lilia Hannachi my 
> colleague at NIST):
> https://www.nist.gov/sites/default/files/documents/2019/10/23/detailed-as_set-analysis.txt
>
> The analysis includes the following:
> 1. Summary stats
> 2. List of ASes (AGGREGATORs) Ranked according to # Routes with AS_SET
> (including the organization name of the AGGREGATOR)
> 3. List of routes with AS_SET that seem meaningless or malformed.
> 4. List of routes with AS_SET that seem meaningful.
> 3. List of all routes with AS_SET (listed per AGGREGATOR)
>
> The summary stats are copied here, but please see other details at the link 
> provided.
>
> AS_SET ANALYSIS (OREGON 2019-10-03:00)
> The Routeviews OREGON collector peers with 43 ASes.
>
> Summary stats:
>
> Total # Updates : 30052331
> # Updates with AS_SET : 14348
> Percentage of Updates with AS_SET : 0.048%
> # Total # ASes (globally) : 66205
> # ASes that create Updates with AS_SET : 144
> % ASes that create Updates with AS_SET : 0.218%
>
> # Routes with AS_SET (after eliminating AS path redundancy): 477
> Explanation: These are routes with unique {prefix, AS_SET, 1st AS 
> after AS_SET, AGGREGATOR} combinations.
>
> Out of the 477 routes with AS_SETs:
> *** Identifying Routes with AS_SET that seem meaningless or malformed 
> ***
> # Routes with only one AS in AS_SET : 383
> # Routes with Reserved ASN in AS_SET : 131
> # Routes with common AS in the AS_SEQUENCE and AS_SET : 139
> # Routes with repeated ASes in the AS_SET : 0
> # Routes that are /24 prefix (aggregate) announcements : 239
> Total # Routes that seem meaningless or malformed : 456
>
> Total # Routes that seem meaningful : 21
>
> Distribution of # unique ASes in the AS_SET : 1:383, 2:68, 3:14, 4:5, 
> 5:2, 6:3, 23:1, 31:1
>
> # Routes with AS_SET where AGGREGATOR does not match the right most 
> AS in AS_SEQUENCE : 47
>
> # Routes with unique {prefix, AS_SET, AGGREGATOR} : 469
> # Routes with unique {prefix, AS_SET} : 455
>
> *** When there is an AGGREGATOR but no AS_SET ***
> # Unique prefixes (with or without AS_SET) : 826535
> # Unique prefixes without AS_SET but with AGGREGATOR: 75698
> % Unique prefixes without AS_SET but with AGGREGATOR: 9.158%
>
> Sriram



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Warren Kumari]

On Thu, Sep 26, 2019 at 10:52 PM Jeffrey Haas  wrote:
>
>
>
> On Sep 26, 2019, at 6:43 PM, Warren Kumari  wrote:
>
> This is nice, but what would make it more useful would be if it also
> reported if there are *useful* AS_SETS / if the AS_SET means anything.
>
> For example, from Jared's email below:
> AS path:  14061 3356 6762 23487 27738 27738 27738 27738 27738 27738
> {27738} -- the 27738 AS already shows up as a non-AS_SET in the path.
>
>
> This one is on the buggy end of things, but still reasonably valid.  It 
> smells like something that passed through remove-private of some flavor.

Yes, it is valid, but it doesn't "mean" anything more than AS path:
14061 3356 6762 23487 27738 27738 27738 27738 27738 27738 27738 - I
cannot see a scenario where the lack of {} causes loop detection or
anything else to fail.
I *guess* it's possible that there was something like ... 27738 65533
{ 27738 65534 }. The { 27738 65534 } is "interesting" to 65533, and
remote-private could have removed both 65533 and 65534.

Ugh, aggregation for others is ugly (yes, I know, but...)

>
>
> I've also seen a number of instances where the AS_SET contains many
> repeated instances, e.g:
> AS path: 6939 3356 42020 39010 {39275 39275 39275 39275 39275 39275
> 39275 39275 39275 39275} -- this doesn't seem to actually mean
> anything...
>
>
> This one seems very buggy.  The protocol still knows what to do with it.
>
> It'd be interesting to find out what code these folk are running. Hopefully 
> not one of my bugs. :-)

They are all your bugs, Jeff :-)

W

>
> -- Jeff
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Warren Kumari]

On Wed, Sep 25, 2019 at 11:32 PM Sriram, Kotikalapudi (Fed)
 wrote:
>
> Jared,
>
> >(Obviously my search in e-mail today went afoul, I see it’s adopted..
>
> Yes, the draft was adopted. You can see the discussion here:
> https://mailarchive.ietf.org/arch/browse/idr/?gbt=1=WG%20adoption%20for%20draft-kumari-deprecate-as-set-confed-set
>
> One key point of the discussion was about the specification for action at
> a receiver when an update with AS_SET or AS_CONFED_SET is received.
> The consensus seemed to be: treat as Withdraw.
> We'll soon update the draft to add that.
>
> You had observed in that thread:
> >We should also (in parallel) reach out to some of the networks
> >still using as_sets that are visible in the global BGP table.
>
> How do we do this? On NANOG, RIPE, etc. lists? Please advise.
>
> >I did notice after this a few more BGP announcements with AS_SET
> >occurring on a very regular basis.  I suspect someone is doing some
> >research on it, perhaps someone reading this e-mail :-)
>
> The percentage of updates with AS_SET is observed to be about 0.05%.
> This has been in that ballpark for a long time.
> Are you computing the percentages in what you observe?
> Is it much different from 0.05%?
>
> Some recent measurements we have at NIST about this are as follow:
> (thanks to Lilia Hannachi - my colleague)
>

This is nice, but what would make it more useful would be if it also
reported if there are *useful* AS_SETS / if the AS_SET means anything.

For example, from Jared's email below:
AS path:  14061 3356 6762 23487 27738 27738 27738 27738 27738 27738
{27738} -- the 27738 AS already shows up as a non-AS_SET in the path.

I've also seen a number of instances where the AS_SET contains many
repeated instances, e.g:
AS path: 6939 3356 42020 39010 {39275 39275 39275 39275 39275 39275
39275 39275 39275 39275} -- this doesn't seem to actually mean
anything...

Looking at the top few AS paths with AS_SETs I see:
  28 12127
  27 27738
  24 11139
  17 23383
  13 12849

AS12127 - Telefonica Moviles El Salvador S.A. de C.V., SV (these are
all behind AS263783 - Telefonica Moviles El Salvador S.A. de C.V., SV
)
AS27738 - Ecuadortelecom S.A., EC
AS11139 - CWC-ROC-11139 - Cable & Wireless Dominica, DM
AS23383 - METRORED S.A. DE C.V., HN   (this also seems to provide
transit to AS267737? (advertising 45.168.172.0/24))
AS12849 HOTNET-IL AMS-IX Admin LAN, IL

W




> *** OREGON3 Collector (20190827.00) **
> August 27, 2019
>
> IPV4 : {normal=16540660, AGGREGATOR=1718902, ATOMIC_AGGREGATE=1086313, 
> AS_CONFED_SET=0, AS_SET=8971, AS_CONFED_SEQUENCE=0}
> IPV4 Total 18323517
> IPV4 Percentage
> normal : 90.27%
> AGGREGATOR : 9.38%
> ATOMIC_AGGREGATE : 5.93%
> AS_CONFED_SET : 0.0%
> AS_SET : 0.05%
> AS_CONFED_SEQUENCE : 0.0%
> Number of ASs in the AS_SET Paths (IPV4) {1=7837, 2=876, 3=144, 4=50, 5=53, 
> 6=2, 7=9}
> Position of AS_SET (IPV4) {Beginning=8971, Middle=0, Left_Most=0}
> Number of AS_SET with Reserver ASes (IPV4) 248
> Number of no-export and no-advertise (IPV4) {no-export=0, no-advertise=751278}
> no-export : 0.0%
> no-advertise : 4.95%
> ---
> IPV6 : {normal=67633, AGGREGATOR=8297, ATOMIC_AGGREGATE=3548, 
> AS_CONFED_SET=0, AS_SET=36, AS_CONFED_SEQUENCE=0}
> IPV6 Total 76128
> IPV6 Percentage
> normal : 88.84%
> AGGREGATOR : 10.9%
> ATOMIC_AGGREGATE : 4.66%
> AS_CONFED_SET : 0.0%
> AS_SET : 0.05%
> AS_CONFED_SEQUENCE : 0.0%
> Number of ASs in the AS_SET Paths (IPV6) {1=24, 2=8, 3=1, 4=2, 8=1}
> Position of AS_SET (IPV6) {Beginning=36, Middle=0, Left_Most=0}
> Number of AS_SET with Reserver ASes (IPV6) 0
> Number of no-export and no-advertise (IPV6) {no-export=0, no-advertise=3765}
> no-export : 0.0%
> no-advertise : 4.95%
> ---
>
> *** LINX Collector (20190827.00) **
> August 27, 2019
>
> IPV4 : {normal=21697743, AGGREGATOR=2255396, ATOMIC_AGGREGATE=1425305, 
> AS_CONFED_SET=0, AS_SET=11353, AS_CONFED_SEQUENCE=0}
> IPV4 Total 24036253
> IPV4 Percentage
> normal : 90.27%
> AGGREGATOR : 9.38%
> ATOMIC_AGGREGATE : 5.93%
> AS_CONFED_SET : 0.0%
> AS_SET : 0.05%
> AS_CONFED_SEQUENCE : 0.0%
> Number of ASs in the AS_SET Paths (IPV4) {1=9890, 2=1130, 3=188, 4=64, 5=65, 
> 6=2, 7=14}
> Position of AS_SET (IPV4) {Beginning=11353, Middle=0, Left_Most=0}
> Number of AS_SET with Reserver ASes (IPV4) 348
> Number of no-export and no-advertise (IPV4) {no-export=6, no-advertise=0}
> no-export : 0.0%
> no-advertise : 0.0%
> *
> IPV6 : {normal=69177, AGGREGATOR=8335, ATOMIC_AGGREGATE=3543, 
> AS_CONFED_SET=0, AS_SET=37, AS_CONFED_SEQUENCE=0}
> IPV6 Total 77712
> IPV6 Percentage
> normal : 89.02%
> AGGREGATOR : 10.73%
> ATOMIC_AGGREGATE : 4.56%
> AS_CONFED_SET : 0.0%
> AS_SET : 0.05%
> AS_CONFED_SEQUENCE : 0.0%
> Number of ASs in the AS_SET Paths (IPV6) {1=24, 2=9, 3=1, 4=2, 8=1}
> Position of AS_SET (IPV6) {Beginning=37, 

[GROW] AD review of: draft-ietf-grow-bmp-adj-rib-out

[Warren Kumari]

Hi there,

Thanks to the authors and WG for this document -- it provides a useful
mechanism / enhancement, is well written, and easy to understand.

I do have a few editorial comments that I'd like to see addressed
before starting IETF LC. Note that these are mostly nit type things,
and could be handled by the RFC Editor; but fixing them now will both
remove load from the RFC Ed, and also make it easier / more pleasant
for people reading during IETF LC, directorate reviewers and the IESG
(also, once people start complaining about editorial stuff it often
spirals into larger issues :-)).

1: "This document updates BGP Monitoring Protocol ..." - I think this
is missing "the"

2: "Adding Adj-RIB-Out enables the ability for a BMP sender... " - I
suggest "provides the ability"

3: "As with Adj-RIB-In policy validation, there are use-cases that
pre-policy Adj-RIB-Out is used to validate and audit outbound
policies."  - I find this sentence confusing. How is: "Similarly to
Adj-RIB-In policy validation, pre-policy Adj-RIB-Out can be used to
validate and audit outbound policies."? Or can the sentence be
reworded?

4: "Some attributes are set only during transmission of the BGP
message, e.g.  Post-Policy."  -- I don't think the "e.g. Post-Policy"
bit makes sense here - perhaps "ie. Post-Policy" was what was
intended? Or can that just be dropped (I don't think it adds
anything).

5: "In this use-case, there maybe hundreds of wholesale peers but a
single peer could have represented the  group.
  A single peer could be used to represent a group." -- duplicate?
Also, "maybe" should be "may be".

Again, I fully get that these are nits / editorial issues, but
addressing them now help avoid issues later in the process...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Some comments on draft-chen-grow-enhanced-as-loop-detection-00

[Warren Kumari]

On Thu, Mar 21, 2019 at 12:59 AM Jeffrey Haas  wrote:

> Authors,
>
> Some various comments on the draft in no particular order:
> - Consider using the document ASes from the reserved ranges; i.e. RFC 5398
> - Construct a unified table of the "results" and a short term for their
>   meaning.  One of my least favorite thing in RFCs that tend to be placed
>   into code is calling something a "type X".  It leads to rather confusing
>   conversations unless you're a protocol expert.
>
>
Case in point -- one of my "favorite" RFCs -- RFC7281 - Adding Acronyms to
Simplify Conversations about DNS-Based Authentication of Named Entities
(DANE)

Basically, we realized that arguing whether users should publish TLSA
records of type 3, selector 1, matching 1,  or 3, 0, 1 or ... is
super-unhelpful, but recommending DANE-TA, SPKI, SHA2-256 is much simpler.

W


> A final comment is another infrequent case a provider's AS may end up in
> the
> AS-Path: Intentionally forcing that provider to discard a route *you* own.
>
> Consider the case where AS 64512 owns 192.0.2/24.  AS 64512 is under a
> heavy
> DDoS attack that is substantially originated from AS 65535.  By prepending
> 65535 to the AS-Path upon origination, 65535 will lose the route to
> 192.0.2/24 and, if default-free, much of the attack traffic goes away.
>
> -- Jeff
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC6396 (5511)

[Warren Kumari]

James is correct -- I'll mark this one as verified.

For those whose hex-dump reading skill have atrophied, here is the fixed
version:
Border Gateway Protocol - UPDATE Message
Marker: 
Length: 62
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 35
Path attributes
Path Attribute - ORIGIN: INCOMPLETE
Type Code: ORIGIN (1)
Length: 1
Origin: INCOMPLETE (2)
Path Attribute - AS_PATH: 64496 64511 64502
Type Code: AS_PATH (2)
Length: 14
AS Path segment: 64496 64511 64502
Segment type: AS_SEQUENCE (2)
Segment length (number of ASN): 3
AS4: 64496
AS4: 64511
AS4: 64502
Path Attribute - NEXT_HOP: 198.51.100.188
Type Code: NEXT_HOP (3)
Length: 4
Next hop: 198.51.100.188
Path Attribute - COMMUNITIES: 64496:14
Type Code: COMMUNITIES (8)
Length: 4
Communities: 64496:14
Community: 64496:14
Community AS: 64496
Community value: 14
Network Layer Reachability Information (NLRI)
203.0.113.0/24
NLRI prefix length: 24
NLRI prefix: 203.0.113.0


and here is what the RFC says the UPDATE should look like:

ORIGIN: INCOMPLETE
 ASPATH: 64496 64511 64502
 NEXT_HOP: 198.51.100.188
 COMMUNITY: 64496:14
 NLRI: 203.0.113.0/24



Thanks!
W


On Mon, Oct 1, 2018 at 5:41 PM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC6396,
> "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5511
>
> --
> Type: Technical
> Reported by: James Clarke 
>
> Section: Appendix A
>
> Original Text
> -
> |  BGP Update =
>
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00 3e 02 00 00 00 1f 40 01 01 02 40 02 0e 02 03
> 00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6
> 33 64 55 c0 08 04 fb f0 00 0e 18 cb 00 71
>
>  Figure 16: MRT BGP4MP_MESSAGE_AS4 Example
>
> Corrected Text
> --
> |  BGP Update =
>
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00 3e 02 00 00 00 23 40 01 01 02 40 02 0e 02 03
> 00 00 fb f0 00 00 fb ff 00 00 fb f6 40 03 04 c6
> 33 64 bc c0 08 04 fb f0 00 0e 18 cb 00 71
>
>  Figure 16: MRT BGP4MP_MESSAGE_AS4 Example
>
> Notes
> -
> The total path attribute length is incorrectly encoded as 0x001F when it
> should be 0x0023 and the next hop ip address is incorrectly encoded as
> 0xc6336455 when it should be 0xc63364bc
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC6396 (draft-ietf-grow-mrt-17)
> --
> Title   : Multi-Threaded Routing Toolkit (MRT) Routing
> Information Export Format
> Publication Date: October 2011
> Author(s)   : L. Blunk, M. Karir, C. Labovitz
> Category: PROPOSED STANDARD
> Source  : Global Routing Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Discourage asdot+/asdot?

[Warren Kumari]

On Mon, Aug 13, 2018 at 7:33 AM Nick Hilliard  wrote:
>
> Daniel Shaw wrote on 10/08/2018 08:29:
> > I think that on closer examination you may find the AFRINIC whois also
> > changed around the same timeframe, perhaps a year later. It seems that
> > there may be one (or possibly some other very small number of) test
> > objects that did not get converted/clean-up.
>
> my mistake - afrinic changed to asplain some time in 2012.  The AS-TEST
> object predates this change (and isn't operationally relevant anyway).

This may be (ok, is) off-topic, but this has always really annoyed me:
wkumari@Dulles-rtr:~$ show arp
Address  HWtype  HWaddress   Flags Mask
Iface
192.168.0.122(incomplete)  eth1
192.168.0.187ether   00:e0:86:02:da:0b   C eth1
192.168.0.188ether   20:3c:ae:5a:dd:4d   C eth1

vs:
Dulles-Switch#show arp
Protocol  Address  Age (min)  Hardware Addr   Type   Interface
Internet  192.168.0.320   a866.7f04.4f92  ARPA   Vlan1
Internet  192.168.0.35-   0015.621c.6540  ARPA   Vlan1

vs:
TestSwitch#show arp
Protocol  Address  Age (min)  Hardware Addr   Type   Interface
Internet  192.168.0.320   A866.7F04.4F92  ARPA   Vlan1
Internet  192.168.0.35-   0015.621F.6540  ARPA   Vlan1

vs:
About System

Model Number  : AP7900
Serial Number : ZA0644029848
NMC Serial Number : ZA0644028843
Manufacture Date  : 10/29/2006
Hardware Revision : B2
MAC Address   : 00 C0 B7 2C 17 C9
Flash Type: AMD A29DL322DB

vs:
Network Statistics
General
Hardware Address:001321C2DE82
HP JetDirect:J7949E
Firmware Version:V.33.19

vs:
LAN1
MAC address00-11-32-16-F7-6F

Seriously, 6 different ways to notate a MAC address...
Nope, this isn't actionable, but thank you for letting me vent!

W



>
> Nick
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC8326 (5402)

[Warren Kumari]

On Thu, Jun 21, 2018 at 3:36 PM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8326,
> "Graceful BGP Session Shutdown".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5402
>
> --
> Type: Technical
> Reported by: John Scudder 
>
> Section: C.2.2.
>
> Original Text
> -
>   4.  If, for any reason, RR3 processes the withdraw generated in
>   step 3 before processing the update generated in step 2, RR3
>   transiently suffers from unreachability for the affected
>   prefix.
>
> Corrected Text
> --
>   4.  If, for any reason, RR2 processes the withdraw generated in
>   step 3 before processing the update generated in step 2, RR2
>   transiently suffers from unreachability for the affected
>   prefix.
>
> Notes
> -
> The original text names RR3, but it should be RR2. This becomes evident
> when one works through the example using a diagram.
>

​I believe that this is right -- ​does anyone disagree? If not I'll plan on
approving it.
W




>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8326 (draft-ietf-grow-bgp-gshut-13)
> --
> Title   : Graceful BGP Session Shutdown
> Publication Date: March 2018
> Author(s)   : P. Francois, Ed., B. Decraene, Ed., C. Pelsser, K.
> Patel, C. Filsfils
> Category: PROPOSED STANDARD
> Source  : Global Routing Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC7948 (5366)

[Warren Kumari]

On Wed, May 23, 2018 at 1:09 PM Nick Hilliard  wrote:

> This errata report isn't wrong, but belongs to a bigger category of
> problems relating to how the IETF handles third party references in RFCs.
>
> It's unlikely that the researchgate url will be persistent in the longer
> term, at least any more than any other URL.
>

​I marked it as Hold for Document Update -- this seems to be the "best" way
to annotate documents with things like this. ​

Thanks!
W



>
> Nick
>
> RFC Errata System wrote:
> > The following errata report has been submitted for RFC7948,
> > "Internet Exchange BGP Route Server Operations".
> >
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5366
> >
> > --
> > Type: Technical
> > Reported by: Greg Skinner 
> >
> > Section: 6.2
> >
> > Original Text
> > -
> > [RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
> > Estrin, "A Route Server Architecture for Inter-Domain
> > Routing", 1995,
> > .
> >
> > Corrected Text
> > --
> > [RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
> > Estrin, "A Route Server Architecture for Inter-Domain
> > Routing", 1995,
> >  > publication/
> > 2297181_A_Route_Server_Architecture_for_Inter-Domain_Routing>
> >
> > Notes
> > -
> > The paper is no longer accessible from the www.cs.usc.edu site.  A
> related paper can be accessed at
> https://doi.org/10.1016/S0169-7552(98)8-7 by those who are registered
> members or will pay for the paper.  It would be cited as:
> > [RS-ARCH]  Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
> >Estrin, "A Route Server Architecture for Inter-Domain
> >Routing", Computer Networks and ISDN Systems, Volume
> 30,
> >Issue 12, 13 July 1998, Pages 1157-1174,
> >.
> >
> > Sorry, I had to split the link in the corrected text to satisfy the
> 72-character line length requirement in the corrected text.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC7948 (draft-ietf-grow-ix-bgp-route-server-operations-05)
> > --
> > Title   : Internet Exchange BGP Route Server Operations
> > Publication Date: September 2016
> > Author(s)   : N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker
> > Category: INFORMATIONAL
> > Source  : Global Routing Operations
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> >
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://www.ietf.org/mailman/listinfo/grow
> >
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peter stepping down as chair - volunteers?

[Warren Kumari]

Dear GROWlers[0],

I'd like to thank everyone who put their names forward - after my
second note I got a number of good candidates volunteering.
After much thought (and it wasn't an easy decision) I've decided to
select Job Snijders as the new chair.

I'd like to thank everyone who volunteered again - I really appreciate
your willingness to step forward when needed.
Also, I'd like to thank Peter again for all of this time and energies
running the group.

Thanks and see you all in London,
W

[0]: I've decided that this is the new collective noun :-P

On Tue, Feb 27, 2018 at 9:28 AM, Warren Kumari <war...@kumari.net> wrote:
> Hi there GROWers,
>
> Sadly, Peter has just let me know that, due to other time commitments,
> he will be stepping down as one of the GROW chairs.
> I'd like to take a moment to thank him for all of his hard work, and
> also to ask for volunteers who would be willing to set up and serve.
>
> GROW is always a low drama WG (thanks!) , and Chris is a very
> accomplished chair, and so this would be a fine WG to gain experience
> with if you've never chaired before.
>
> Many / most of the GROW participants are also long time IETF
> participants, and so are likely somewhat familiar with what chairing a
> WG involves, but those who are not:
> The Tao is always a good reference: https://www6.ietf.org/tao.html, as
> is the WG chairs page: https://www.ietf.org/chairs/
>
> I, and I'm sure Chris, will be happy to provide more info / details as well.
>
> Please let me know if you're interested in being considered,
> preferably by Friday.
>
> W
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peter stepping down as chair - volunteers?

[Warren Kumari]

Hi all,

So far I have one good candidate, but I felt it only correct to give
everyone a chance, and so I’ll wait till Tuesday to select a chair.

W

On Tue, Feb 27, 2018 at 9:28 AM Warren Kumari <war...@kumari.net> wrote:

> Hi there GROWers,
>
> Sadly, Peter has just let me know that, due to other time commitments,
> he will be stepping down as one of the GROW chairs.
> I'd like to take a moment to thank him for all of his hard work, and
> also to ask for volunteers who would be willing to set up and serve.
>
> GROW is always a low drama WG (thanks!) , and Chris is a very
> accomplished chair, and so this would be a fine WG to gain experience
> with if you've never chaired before.
>
> Many / most of the GROW participants are also long time IETF
> participants, and so are likely somewhat familiar with what chairing a
> WG involves, but those who are not:
> The Tao is always a good reference: https://www6.ietf.org/tao.html, as
> is the WG chairs page: https://www.ietf.org/chairs/
>
> I, and I'm sure Chris, will be happy to provide more info / details as
> well.
>
> Please let me know if you're interested in being considered,
> preferably by Friday.
>
> W
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Peter stepping down as chair - volunteers?

[Warren Kumari]

Hi there GROWers,

Sadly, Peter has just let me know that, due to other time commitments,
he will be stepping down as one of the GROW chairs.
I'd like to take a moment to thank him for all of his hard work, and
also to ask for volunteers who would be willing to set up and serve.

GROW is always a low drama WG (thanks!) , and Chris is a very
accomplished chair, and so this would be a fine WG to gain experience
with if you've never chaired before.

Many / most of the GROW participants are also long time IETF
participants, and so are likely somewhat familiar with what chairing a
WG involves, but those who are not:
The Tao is always a good reference: https://www6.ietf.org/tao.html, as
is the WG chairs page: https://www.ietf.org/chairs/

I, and I'm sure Chris, will be happy to provide more info / details as well.

Please let me know if you're interested in being considered,
preferably by Friday.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AD Review of draft-ietf-grow-bgp-session-culling

[Warren Kumari]

On Mon, Sep 11, 2017 at 12:16 PM, Warren Kumari <war...@kumari.net> wrote:
> On Mon, Sep 11, 2017 at 11:57 AM, Job Snijders <j...@ntt.net> wrote:
>> Dear Warren,
>>
>> On Sun, Sep 10, 2017 at 06:55:00PM -0400, Warren Kumari wrote:
>>> I've just completed my AD review of draft-ietf-grow-bgp-session-culling.
>>>
>>> I only had a few small nits:
>>>
>>> Section 3:
>>> "Involuntary BGP Session Teardown: The Caretaker of the lower layer
>>>   network disrupts BGP control-plane traffic in the upper layer,
>>>   causing the BGP Hold Timers of the affected BGP session to expire,"
>>> -- it took me a few readings to parse this sentence -- I think that
>>> the "in the upper layer" is redundant and confuses the sentence.
>>> I think just removing it and
>>>
>>> "Involuntary BGP Session Teardown:  The Caretaker of the lower layer
>>>   network disrupts (higher layer) BGP control-plane traffic,
>>>   causing the BGP Hold Timers of the affected BGP session to expire,..." ?
>>
>> works for me!
>>
>>> 2: Section 3.2. Involuntary BGP Session Teardown Recommendations
>>> "Such culling of control-plane traffic will pre-empt the" - 
>>> s/pre-empt/preempt/
>>
>> Thanks
>>
>>> 3: I really like the fact that this has actual exmaple config. I think
>>> it would be nice it if also included some more vendors.
>>
>> Even more?! We already have config for four vendors in the Internet-Draft 
>> itself. :-)
>
> Your counting and my counting differ:
> A.1.  Cisco IOS, IOS XR & Arista EOS Firewall Example Configuration
> A.2.  Nokia SR OS Filter Example Configuration
>
>
> Are you counting IOS and IOS XR as 2 vendors? :-P
>
> Anyway, as I said, I really like the examples, and the GH solution WFM.
>
>
>>
>> There also is a link to 
>> https://github.com/bgp/bgp-session-culling-config-examples which is a
>> more 'live' version which can be updated as we go. The github repo
>> currently has 7 platforms, and perhaps over time will grow based on
>> contributions.
>>
>> The configuration example in the Internet-Draft itself mostly serves to
>> demonstrate the concept in the universal language other than English:
>> router configs. The example configs are not meant to be an exhaustive
>> overview.
>>
>>> Anyway, I'm fine to start IETF LC like this, but it you are able to
>>> post a new version I think things might go smoother.
>>>
>>> Please let me know either way.
>>
>> Sure, I'll bump.
>>
>
> Okey dokey. I'll hit the go button when you do - please poke me if I
> happen to miss it.


... and I just saw the New Version email -- I'll hit "go" once it propagates.
W
> W
>
>> Kind regards,
>>
>> Job
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AD Review of draft-ietf-grow-bgp-session-culling

[Warren Kumari]

On Mon, Sep 11, 2017 at 11:57 AM, Job Snijders <j...@ntt.net> wrote:
> Dear Warren,
>
> On Sun, Sep 10, 2017 at 06:55:00PM -0400, Warren Kumari wrote:
>> I've just completed my AD review of draft-ietf-grow-bgp-session-culling.
>>
>> I only had a few small nits:
>>
>> Section 3:
>> "Involuntary BGP Session Teardown: The Caretaker of the lower layer
>>   network disrupts BGP control-plane traffic in the upper layer,
>>   causing the BGP Hold Timers of the affected BGP session to expire,"
>> -- it took me a few readings to parse this sentence -- I think that
>> the "in the upper layer" is redundant and confuses the sentence.
>> I think just removing it and
>>
>> "Involuntary BGP Session Teardown:  The Caretaker of the lower layer
>>   network disrupts (higher layer) BGP control-plane traffic,
>>   causing the BGP Hold Timers of the affected BGP session to expire,..." ?
>
> works for me!
>
>> 2: Section 3.2. Involuntary BGP Session Teardown Recommendations
>> "Such culling of control-plane traffic will pre-empt the" - 
>> s/pre-empt/preempt/
>
> Thanks
>
>> 3: I really like the fact that this has actual exmaple config. I think
>> it would be nice it if also included some more vendors.
>
> Even more?! We already have config for four vendors in the Internet-Draft 
> itself. :-)

Your counting and my counting differ:
A.1.  Cisco IOS, IOS XR & Arista EOS Firewall Example Configuration
A.2.  Nokia SR OS Filter Example Configuration


Are you counting IOS and IOS XR as 2 vendors? :-P

Anyway, as I said, I really like the examples, and the GH solution WFM.


>
> There also is a link to 
> https://github.com/bgp/bgp-session-culling-config-examples which is a
> more 'live' version which can be updated as we go. The github repo
> currently has 7 platforms, and perhaps over time will grow based on
> contributions.
>
> The configuration example in the Internet-Draft itself mostly serves to
> demonstrate the concept in the universal language other than English:
> router configs. The example configs are not meant to be an exhaustive
> overview.
>
>> Anyway, I'm fine to start IETF LC like this, but it you are able to
>> post a new version I think things might go smoother.
>>
>> Please let me know either way.
>
> Sure, I'll bump.
>

Okey dokey. I'll hit the go button when you do - please poke me if I
happen to miss it.
W

> Kind regards,
>
> Job



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] AD Review of draft-ietf-grow-bgp-session-culling

[Warren Kumari]

Hi there,

I've just completed my AD review of draft-ietf-grow-bgp-session-culling.

I only had a few small nits:

Section 3:
"Involuntary BGP Session Teardown: The Caretaker of the lower layer
  network disrupts BGP control-plane traffic in the upper layer,
  causing the BGP Hold Timers of the affected BGP session to expire,"
-- it took me a few readings to parse this sentence -- I think that
the "in the upper layer" is redundant and confuses the sentence.
I think just removing it and

"Involuntary BGP Session Teardown:  The Caretaker of the lower layer
  network disrupts (higher layer) BGP control-plane traffic,
  causing the BGP Hold Timers of the affected BGP session to expire,..." ?


2: Section 3.2. Involuntary BGP Session Teardown Recommendations
"Such culling of control-plane traffic will pre-empt the" - s/pre-empt/preempt/


3: I really like the fact that this has actual exmaple config. I think
it would be nice it if also included some more vendors.

Anyway, I'm fine to start IETF LC like this, but it you are able to
post a new version I think things might go smoother.

Please let me know either way.
W



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Genart telechat review of draft-ietf-grow-large-communities-usage-07

[Warren Kumari]

On Mon, May 8, 2017 at 12:48 PM, Job Snijders  wrote:
> Thanks Stewart!

Yes, indeed. Thank you Stewart - Directorate reviews are always appreciated.

W

>
> On Mon, 8 May 2017 at 18:42, Stewart Bryant 
> wrote:
>>
>> Reviewer: Stewart Bryant
>> Review result: Ready
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair. Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>>
>> For more information, please see the FAQ at
>>
>> .
>>
>> Document: draft-ietf-grow-large-communities-usage-??
>> Reviewer: Stewart Bryant
>> Review Date: 2017-05-08
>> IETF LC End Date: 2017-04-21
>> IESG Telechat date: 2017-05-11
>>
>> Summary: This is now ready for publication.
>>
>> Major issues: None.
>>
>> Minor issues: None.
>>
>> Nits/editorial comments: None.
>>
>>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[Warren Kumari]

[ + authors ]

On Sat, May 6, 2017 at 3:16 AM, Robert Raszuk  wrote:
> Hi Warren,
>
>> This is clearly not unanimous/ not everyone is happy, but (in my view)
>> there is *rough* consensus for this to progress.
>
>
> The group of users of BGP which this update impacts the most are members
> of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies
> to all AFI/SAFIs.

I'll happily admit that I have not been following BESS at all, and so
know very little of what y'all do ("Hi Bess!"). Alvaro, please advise
if BESS is affected to the level that they should have been explicitly
invited to comment?

> IMO before you progress anywhere with this IETF LC BESS WG should express
> their formal opinion on it.
>
> Example of in or out eBGP policy where you are sending MAC addresses in
> EVPN AF needs to be provided and explained why it makes sense. Likewise
> examples of RTC AF for L3VPN Inter-as needs to be discussed.
>
> Otherwise the group of people which defined a lot of non ISP uses of BGP may
> be
> suddenly surprised down the read for keeping them out of the loop and have
> customers loosing reachability upon compliant non sequential router OS
> upgrade.

The authors are busy incorporating some final edits (including some
suggested by Alvaro). I would have hoped that all affected parties
would have seen the discussions on GROW / IDR / the IETF LC.

I ask people to please withhold judgment until the new version is released.


I'm about to board a plane (to Budapest), and will be out of email for
many hours...
W

 >
> Cheers,
> Robert.

>
> REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06
>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

[Warren Kumari]

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 when no
>explicit policy is associated with a BGP peering session."
>
> Please read/comment/advise before 11/23/2015 - Nov 23, 2015.
>
>

Yah.

This shouldn't be needed... but is.
Support adoption, willing to edit / contribute / review / whatever is
needed.

W



> Thanks!
> -chris
> grow-co-chair
>
> ___
> GROW mailing list
> GROW@ietf.org 
> https://www.ietf.org/mailman/listinfo/grow
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Requesting Grow's review of draft-ietf-idr-as-private-reservation-02.txt

[Warren Kumari]

On Dec 21, 2012, at 5:37 PM, Susan Hares sha...@ndzh.com wrote:

 Peter and Chris:
  
 We request that the GROW WG review  
 draft-ietf-idr-as-private-reservation-02.txt?   
 (http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/)
  
 Since it modifies RFC 1930, a BCP, it is likely to be a BCP.  The draft deals 
 with the creation of Private USE ASN space in 4 byte octets.
  
 Two additional questions we’d love input on:  
  
 1. Do they think the range is too big, too small, or just right”  (We’ll 
 call this the 3 bears question (smile))
 2. Would they prefer to see the range reserved with some portion of the 
 range allocated?
  
 For example, reserve all the space but allocate only 50% of the space.
  
 This draft has had substantial IDR debate which is (of course) online, and 
 has been through IDR WG LC.
  
 We’d appreciate hearing about any operational issues GROW finds with this 
 draft.

As someone who reads both GROW and IDR I'd just like to more that there has 
already been some operators providing input over on the IDR list...
This is not intended to discourage GROWers from commenting, but rather a 
suggestion that before erupting in indignation (or giggles!) you have a quick 
look @ the IDR threads on this…
They may:
a: address your concerns or
b: provide you with more ammunition for making your case :-P

W

  
 Thank you,
  
 John and Sue
  
 ___
 GROW mailing list
 GROW@ietf.org
 https://www.ietf.org/mailman/listinfo/grow

--
For every complex problem, there is a solution that is simple, neat, and wrong.
-- H. L. Mencken




___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] RouteLeaks - problem or not?

[Warren Kumari]

On Nov 15, 2012, at 11:46 PM, Christopher Morrow christopher.mor...@gmail.com 
wrote:

 On Thu, Nov 15, 2012 at 11:10 PM, Shane Amante sh...@castlepoint.net wrote:
 
 is that better? I'm really asking whether or not there is a problem
 and if we (ietf in general) can get a solution (or even the
 requirements for a solution?) defined...
 
 Yes, there is a (big) operational problem wrt route-leaks.
 
 it'd be good to outline that as well in the document... often the
 'mitm' problem is brought up, but honestly there are probably more
 cases of:
  1) suboptimal routing (why am I routing through Chile to get to my
 next-door-asn?)
  2) traffic loss (via too-small-pipes + congestion)
  3) link costs (lookie at the transit pipe being full instead of the
 other one!)
 
 that happen and are simpler to show than other issues.

… and easier to talk about as well :-)

I think that you left out:
2.5) Hey, where the hell did my traffic go?! Bah, someone over there fat 
fingered and all my traffic follo .. and it's back...

W

 
 
 Yes, we (IETF in general) should work toward a solution.  As I stated 
 previously, I hope we remain open-minded as to the solution space and do not 
 pigeon-hole ourselves into thinking that one must exist inside BGP, either 
 solely or at all.
 
 -shane
 
 
 
 -chris
 
 
 The end result of the above 3 steps is to push back into IDR one of
 two action requests:
 1) Yes, route leaks are a problem, please fix them.
   or
 2) No, route leaks are not a problem, take no action.
 
 If #1 above is the answer, and IDR decides that changes to the BGP
 protocol are warranted (or are a possible solution to the problem)
 then SIDR has agreed to do what they can to 'secure' the bits
 added/changed/used in that endeavor.
 
 Dare I ask what happens if IDR decides they do not have an answer?
 
 
 Could we have some discussion on-list about this problem, and some
 discussion about whether or not the draft referenced above fits the
 definition we would like to use for 'route leak'?
 
 Um, yes, but then again I'm a co-author, so clearly you should take this 
 answer with a healthy dose of salt.  :-)
 
 
 I would also like
 the authors of the draft to decide where they would like to take their
 draft:
 1) SIDR
 2) IDR
 3) GROW
 4) other
 
 IMO, since you're asking GROW, the answer should hopefully present itself. 
  :-)
 
 -shane
 
 
 
 ___
 GROW mailing list
 GROW@ietf.org
 https://www.ietf.org/mailman/listinfo/grow
 

--
Do not meddle in the affairs of dragons, for you are crunchy and taste good 
with ketchup. 



___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes

[Warren Kumari]

On Aug 27, 2012, at 10:43 AM, Noel Chiappa wrote:

 From: Nick Hilliard n...@inex.ie
 
 Overall, then, it is desirable to remove overlapping routes from the
 global routing table where possible.
 
 People inject prefixes into the DFZ for specific reasons. If they are
 pruned by some upstream providers but not others, then the traffic
 engineering model is broken because you can no longer depend on
 more-specifics having visibility around the dfz.
 
 Doing traffic engineering by injecting more-specifics into the global
 destination-vector routing is a top pick on my list of 'optimal illustration
 for hammer-nail syndrome'. So if we break that approach, that's not a bug,
 that's a feature.

Sez you -- but there are a large number of folk that are currently doing this, 
and doing this for a reason, and will no doubt be very surprised when it 
suddenly stops working…

Removing their ability to use this feature because it violates your (and to 
honest, my) views of elegance seems, um, impolite at best.

 
 Of course, doing traffic engineering 'right' would involve getting rid of
 this archaic, creaky destination-vector routing architecture, and that is
 going to be a huge project.
 

Yup.

 But in the meantime, there are approaches that are create slightly less
 overhead for everyone in the entire system: e.g. using the identity/location
 binding layer - there are several choices available at the moment.

Deployed ones? That I can actually use, now?

 They're
 just as ugly (architecturally), but at least fewer entities have to bear the
 overhead costs (which are less in toto, too).



W

 
   Noel
 ___
 GROW mailing list
 GROW@ietf.org
 https://www.ietf.org/mailman/listinfo/grow
 

--
What our ancestors would really be thinking, if they were alive today, is: Why 
is it so dark in here?

-- (Terry Pratchett, Pyramids)


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WGLC: draft-ietf-grow-no-more-unallocated-slash8s-01 - ABBREVIATED - Ends 7/5/2011

[Warren Kumari]

On Jun 28, 2011, at 5:59 AM, Christopher Morrow wrote:

 Hello GROW Folks,
 We'd like to start an abbreviated Working-Group Last Call for:
   http://tools.ietf.org/html/draft-ietf-grow-no-more-unallocated-slash8s-01

Read and support.

W

 
 Leo kicked out a new revision after LC comments last time around, diff:
  
 http://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-no-more-unallocated-slash8s-01.txt
 
 If we could read/comment/etc by 7/5/2011 that would be grand!
 
 -Chris
 ___
 GROW mailing list
 GROW@ietf.org
 https://www.ietf.org/mailman/listinfo/grow
 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Call for WG Adoption - draft-shakir-idr-ops-reqs-for-bgp-error-handling

[Warren Kumari]

And another support...
On Apr 1, 2011, at 4:19 AM, Christopher Morrow wrote:


(+wg this time, for realz)

On Fri, Apr 1, 2011 at 9:20 AM, Christopher Morrow
christopher.mor...@gmail.com wrote:

Given the discussion in the room today, and the overlap of
readers-of-draft + folk-asking-for-adoption a call to the list is
appropriate.

For the draft: draft-shakir-idr-ops-reqs-for-bgp-error-handling
 http://tools.ietf.org/id/draft-shakir-idr-ops-reqs-for-bgp-error-handling-01.txt 



BGP-4 is utilised as a key intra- and inter-Autonomous System  
routing
  protocol in modern IP networks.  The failure modes as defined by  
the

  original protocol standards are based on a number of assumptions
  around the impact of session failure.  Numerous incidents both in  
the

  global Internet routing table and within Service Provider networks
  have been caused by strict handling of a single invalid UPDATE
  message causing large-scale failures in one or more Autonomous
  Systems.

  This memo describes the current use of BGP-4 within Service  
Provider

  networks, and outlines a set of requirements for further work to
  enhance the mechanisms available to a BGP-4 implementation when
  erroneous data is detected.  Whilst this document does not provide
  specification of any standard, it is intended as an overview of a  
set
  of enhancements to BGP-4 to improve the protocol's robustness to  
suit

  its current deployment.

can we have some discussion about adoption in GROW for this at this
time, please?

Call ends 4/14/2011

Thanks!
-Chris
grow-wg-co-chair


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow



___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01

[Warren Kumari]

aol

Me too!

/aol
On Feb 25, 2011, at 11:44 AM, Renwei li wrote:


+1

Renwei

-Original Message-
From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf  
Of Henderickx, Wim (Wim)

Sent: Wednesday, February 23, 2011 9:57 PM
To: Chris White; Smith, Donald
Cc: i...@ietf.org; grow@ietf.org
Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- 
shakir-idr-ops-reqs-for-bgp-error-handling-01


+1

-Original Message-
From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf  
Of Chris White

Sent: woensdag 23 februari 2011 23:57
To: Smith, Donald
Cc: i...@ietf.org; grow@ietf.org
Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- 
shakir-idr-ops-reqs-for-bgp-error-handling-01


+1

Chris


On Feb 23, 2011, at 8:32 AM, Smith, Donald wrote:

+1 reasonable bgp error handling (rather then dropping sessions and  
flushing routes) is a good idea.



Ignorance is Bliss. Bliss (Basic Language for Implementation of  
System Software) was a
systems programming language originally for the PDP-10 and  
DECsystem-20 written at CMU. K-Oberman

donald.sm...@qwest.com



-Original Message-
From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On  
Behalf Of

Colin Petrie
Sent: Wednesday, February 23, 2011 2:25 AM
To: i...@ietf.org
Cc: grow@ietf.org
Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft-
shakir-idr-ops-reqs-for-bgp-error-handling-01

On 22/02/11 14:50, Neil J. McRae wrote:

Rob,
This is a great document and as a network operator I think this is
something that I'd like to see implemented. The downsides of a  
minute
inconsistency are not great enough compared to a complete BGP  
failure

with

my organisations network*



I totally agree. This document is a pretty good summary of the
requirements on this, and a reasonable suggested implementation to
mitigate the problems we have seen before too many times.

Great work, thanks Rob :)

Cheers
Colin
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


This communication is the property of Qwest and may contain  
confidential or
privileged information. Unauthorized use of this communication is  
strictly
prohibited and may be unlawful.  If you have received this  
communication
in error, please immediately notify the sender by reply e-mail and  
destroy

all copies of the communication and any attachments.
___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow



___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] draft-ietf-grow-unique-origin-as-00 looks cooked to me...

[Warren Kumari]

Hi,

I have reviewed draft-ietf-grow-unique-origin-as-00 and I believe it is fully 
cooked...

W
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] last call for draft-ietf-grow-unique-origin-as-00

[Warren Kumari]

On Dec 16, 2010, at 11:54 PM, Peter Schoenmaker wrote:

 Hi,
 
 I would like to issue last call for draft-ietf-grow-unique-origin-as-00.  We
 will close last call Jan 2nd 2011.

Read it and support (and apologies, I didn't notice this thread when I sent out 
mail a short while ago, saying basically the same thing...)

W

 
 Please review the draft and provide any last comments.
 
 Thanks
 
 Peter
 
 
 
 ___
 GROW mailing list
 GROW@ietf.org
 https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow