Subject: Re: [Idr] IDR Charter discussion

From: Job Snijders <[email-masked]>
Date: Mon, 22 Jul 2019 15:11:51 +0000

Dear Susan, group,

On Mon, Jun 10, 2019 at 03:51:03PM -0400, Susan Hares wrote:
> The IDR Charter was last revised in March, 2010. 
> 
> It's time to reconsider what needs to go in the charter: 
> 
> Somethings we might include are:

It may be good to consider some operations and management functions to
be specced out in IDR.

>From the operational side of the house I recall a few long-standing
wishes:

    - ability to see which prefixes are accepted/rejected by the
      EBGP neighbor
    - ability to see the maximum prefix limits configured by the
      EBGP neighbor
    - ability to relay some contact / circuit details over an EBGP
      session to facilitate inter-organization coordination

All of the above can be accomplished in non-realtime through out-of-band
mechanisms like e-mail and phone; but this type of out-of-band channels
often are error-prone.

I think we would benefit from actively shifting some of this OAM from
out-of-band into the BGP protocol itself so less coordination is needed
between autonomous system operators.

I am not sure how to exactly word a high level milestone suitable for
the charter. "Add more OAM"? "Add more operational debugging capabilities"? 

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 22 Jul 2019 11:24:12 -0400

Job:

Thanks for the feedback.   Let me think on the wordsmithing of the charter. 

Sue 

-----Original Message-----
From: Job Snijders [mailto:[email-masked]] 
Sent: Monday, July 22, 2019 11:12 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] IDR Charter discussion

Dear Susan, group,

> Somethings we might include are:

It may be good to consider some operations and management functions to be
specced out in IDR.

wishes:

I am not sure how to exactly word a high level milestone suitable for the
charter. "Add more OAM"? "Add more operational debugging capabilities"? 

Kind regards,

Job

---

From: "Neil J. McRae" <[email-masked]>
Date: Tue, 23 Jul 2019 12:36:38 +0000

I think 1+2 have some merit but 3 is not managing routing at a human level and shouldn't be here. IMO

wishes:

Kind regards,

Job

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 23 Jul 2019 10:33:05 -0400

Neil:

On 1 + 2:  NM/OPS groups such as GROW have more expertise to decide requirements regarding E-BGP maximum prefixes and appropriate actions. IDR will be glad to review proposed requirements, appropriate action and any proposals on BGP changes.   

On 3, proposals on sending key contact info over BGP have been proposed for 15 years.   People in operations have stated: "Please do not put this information in".  Other operations have stated - "Please put contact info" so I can survive outages without looking up phone numbers. Unless there are clear operational requirements,  IDR working on protocol changes will end up in the same debates.   So we will look to NM/OPS WGs to provide better requirements. 

Sue 

-----Original Message-----
From: Neil J. McRae [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2019 8:37 AM
To: Job Snijders; Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] IDR Charter discussion

> Somethings we might include are:

It may be good to consider some operations and management functions to be specced out in IDR.

wishes:

All of the above can be accomplished in non-realtime through out-of-band mechanisms like e-mail and phone; but this type of out-of-band channels often are error-prone.

I think we would benefit from actively shifting some of this OAM from out-of-band into the BGP protocol itself so less coordination is needed between autonomous system operators.

I am not sure how to exactly word a high level milestone suitable for the charter. "Add more OAM"? "Add more operational debugging capabilities"? 

Kind regards,

Job

---

From: Jared Mauch <[email-masked]>
Date: Tue, 23 Jul 2019 15:32:07 -0400

> On 1 + 2:  NM/OPS groups such as GROW have more expertise to decide requirements regarding E-BGP maximum prefixes and appropriate actions. IDR will be glad to review proposed requirements, appropri…

	I have partial XML for something doing this but think as it's a protcol extension it will end up in IDR vs GROW.  I'll try to finish getting the text done and send it to both lists.  If you want a private copy to help make sense of it - ping me off-list.

	think route-refresh type message that provides info on-demand.

	- jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Job Snijders <[email-masked]>
Date: Tue, 23 Jul 2019 19:36:43 +0000

Dear Susan,

Perhaps "clean-up of some old things" can be added to the charter. 

As an example, I think a draft like this should go through the WG
towards publication: https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set

Kind regards,

Job

On Mon, Jun 10, 2019 at 03:51:03PM -0400, Susan Hares wrote:
> ..         BGP Yang modules, 
> ..         A general BGP Layer 3 auto-configuration or liveness, 
> 
> ..         Additional  tunnel features for a optional tunnel encapsulation (a
> follow-on to draft-ietf-idr-tunnel-encaps), 
> 
> ..         Upgrade of the base BGP specification to Full Standard, 
> 
> ..         Flow specification additions, 
> 
> ..         BGP-LS basic functions (e.g.
> <https://datatracker.ietf.org/doc/draft-ketant-idr-rfc7752bis/>
> draft-ketant-idr-rfc7752bis-00) error handling
> 
> ..         Segment routing additions to BGP, 
> 
> ..         Wide Communities and other "bigger" communities , 
> 
> ..         Revisions to Existing features. 
> 
>  
> 
>  
> 
> Things which will be removed because we are done: 
> 
> ..         Support for 4-octet AS numbers, 
> 
> ..         Add path related additions, 
> 
> ..         Error handling rules for BGP in general, 
> 
> ..         Revisions to the BGP 'Minimum Route Advertisement Interval', 
> 
> ..         The definition of an "Accumulated IGP Metric".
> 
>  
> 
> In 2010, IDR started an advancement of BGP to full standard, but stopped. 
> 
> WG members indicated they wanted us to focus on the feature revisions. 
> 
>  
> 
> Is there anything we missed? 
> 
>  
> 
> Please use this thread to suggest things we should keep or drop in the
> charter. 
> 
>  
> 
> Cheerily, Susan Hares
>

---

From: Jared Mauch <[email-masked]>
Date: Tue, 23 Jul 2019 15:38:16 -0400

> towards publication: https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set

	I would like to see that work proceed.

	- jared

---

From: <[email-masked]>
Date: Wed, 24 Jul 2019 19:16:18 +0000

Dear Susan,

May be adding "BGP persistence",
(possibly depending on whether we believe the charter will be updated before or after we send this draft to IESG)
possibly under the umbrella "Improving BGP resiliency" which IMHO may be a general subject which should be of interest.

Kind regards,
--Bruno

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Tuesday, July 23, 2019 3:37 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] IDR Charter discussion

Dear Susan,

Kind regards,

Job

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 25 Jul 2019 11:01:25 +0000

+1.

Thanks,
	Jim Uttaro

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, July 24, 2019 3:16 PM
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] IDR Charter discussion

Dear Susan,

Kind regards,
--Bruno

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Tuesday, July 23, 2019 3:37 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] IDR Charter discussion

Dear Susan,

As an example, I think a draft like this should go through the WG
towards publication: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dkumari-2Ddeprecate-2Das-2Dset-2Dconfed-2Dset&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=AYAzJIWAdfG6oJV_HANFmeQx9Us3rQHhwPYg-qhD3Gk&s=wxwU9vgPykqi78ct7aDclyjClHviwN60zGkgICp4wdQ&e=

Kind regards,

Job

On Mon, Jun 10, 2019 at 03:51:03PM -0400, Susan Hares wrote:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dketant-2Didr-2Drfc7752bis_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=AYAzJIWAdfG6oJV_HANFmeQx9Us3rQHhwPYg-qhD3Gk&s=xsdmD6TNZklFu28809bEFYvbt3bZRC6QwW8eyvqQxT0&e=>

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=AYAzJIWAdfG6oJV_HANFmeQx9Us3rQHhwPYg-qhD3Gk&s=Jf_H1hSTcqGjf15nRiqNQt11ibvDliWiRymQ3jPRE8Q&e=

_______________________________________________
Idr mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=AYAzJIWAdfG6oJV_HANFmeQx9Us3rQHhwPYg-qhD3Gk&s=Jf_H1hSTcqGjf15nRiqNQt11ibvDliWiRymQ3jPRE8Q&e=

_______________________________________________
Idr mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=AYAzJIWAdfG6oJV_HANFmeQx9Us3rQHhwPYg-qhD3Gk&s=Jf_H1hSTcqGjf15nRiqNQt11ibvDliWiRymQ3jPRE8Q&e=