Subject: [GROW] Are there IDR drafts the Grow WG needs completed quickly?

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Jul 2017 03:57:27 -0400

Grow and IDR groups: 

As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft that
was so long in becoming an RFC that the Grow authors took another approach
(which was less desired).  

We would like to know what IDR drafts need to be moved forward quickly.  If
you would send the name of these drafts to the chairs, it would help us push
forward these critical drafts.  You can send these names in response to this
email or send a private note to the IDR chairs. 

Sue Hares

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 20 Jul 2017 10:33:04 +0200

On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <[email-masked]> wrote:

> Grow and IDR groups:
>
>
>
> As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft
> that was so long in becoming an RFC that the Grow authors took another
> approach (which was less desired).
>
>
I'm unsure what draft this is? this might be the gshut draft?
I don't believe we have other work waiting in a similar state, Peter, do
any come to mind for you?

>
>
> We would like to know what IDR drafts need to be moved forward quickly.
> If you would send the name of these drafts to the chairs, it would help us
> push forward these critical drafts.  You can send these names in response
> to this email or send a private note to the IDR chairs.
>
>
>
> Sue Hares
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Jul 2017 04:35:04 -0400

Chris: 

Yes – it is gshust. 

Please see slide 3 of the gshut presentation. 

Waiting for the dependency on a draft 

-          Draft-ietf-idr-reserved-extended-communities

-          Draft-ietf-idr-as4octet-exztcomm-generic-subtype 

We will do early allocation of code points for any draft adopted by IDR.   Either the authors or another WG can asked us to do these early code point allocation. 

See 

From: Idr [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Thursday, July 20, 2017 4:33 AM
To: Susan Hares
Cc: [email-masked] List; [email-masked] [email-masked]
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

Grow and IDR groups: 

As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft that was so long in becoming an RFC that the Grow authors took another approach (which was less desired).  

I don't believe we have other work waiting in a similar state, Peter, do any come to mind for you?

We would like to know what IDR drafts need to be moved forward quickly.  If you would send the name of these drafts to the chairs, it would help us push forward these critical drafts.  You can send these names in response to this email or send a private note to the IDR chairs. 

Sue Hares

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Jul 2017 10:42:07 +0200

On Thu, Jul 20, 2017 at 10:33:04AM +0200, Christopher Morrow wrote:
> > As the IDR co-chairs sat in the grow meeting, we heard of an IDR
> > draft that was so long in becoming an RFC that the Grow authors took
> > another approach (which was less desired).
> 

GROW's draft-ietf-grow-bgp-gshut had a dependency on
draft-ietf-idr-reserved-extended-communities which related to
draft-ietf-idr-as4octet-extcomm-generic-subtype - eventually this was
resolved by just working with RFC 1997 well-known communities.

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Jul 2017 04:52:58 -0400

Job: 

If this solution was good was the best solution,  there is no further work. 

If this solution was due to the slow progress of IDR, I'd like to know.
We've been trying to fast track all operator needs. 

Sue 

-----Original Message-----
From: Job Snijders [mailto:[email-masked]] 
Sent: Thursday, July 20, 2017 4:42 AM
To: Christopher Morrow
Cc: Susan Hares; [email-masked] List; [email-masked] [email-masked]
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Jul 2017 11:09:51 +0200

> If this solution was good was the best solution,  there is no further

Correct. Upon further discussion in GROW, consensus seems to be that the
transitive nature of the GRACEFUL_SHUTDOWN signal is a feature, not a
bug. There is no IDR blocker for draft-ietf-grow-bgp-gshut to proceed.

However, somewhere in the future it might be useful to have the ability
to assign functions to well-known non-transitive extended community
values. So while we may not need
draft-ietf-idr-reserved-extended-communities today, it might be useful
tomorrow - moving draft-ietf-idr-reserved-extended-communities
forward might be a good thing.

> We've been trying to fast track all operator needs. 

I appreciate that - and I think the approach is working.

Kind regards,

Job

---

From: Peter Schoenmaker <[email-masked]>
Date: Thu, 20 Jul 2017 09:14:16 +0000

Hi Sue,

I don’t believe that there are any more drafts dependant on work progressing through idr.

gshut had additional reasons for not progressing, which have been solved and last call will be issued.

The gshut draft has an informative reference to draft-ietf-idr-best-external.  I see from the mailing list there was a last call, but no conclusion, and the draft subsequently expired.  Is there an expectation this draft will continue to progress?

thanks

peter

On 20 July 2017 at 10:41:22, Susan Hares ([email-masked]<mailto:[email-masked]>) wrote:
Chris:

Yes – it is gshust.

See

On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Grow and IDR groups:

Sue Hares

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Jul 2017 05:18:03 -0400

Peter:

After discussion on the WG list, the draft-ietf-idr-best-external decided to revise their approach.  We are awaiting the authors to indicate: a) draft is now ready for WG LC, and b) there are implementations. 

Perhaps the authors could let you on by responding to this email. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Peter Schoenmaker
Sent: Thursday, July 20, 2017 5:14 AM
To: 'Christopher Morrow'; Susan Hares
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

Hi Sue,

thanks

peter

On 20 July 2017 at 10:41:22, Susan Hares ([email-masked]) wrote:

Chris: 

Yes – it is gshust. 

See 

 

Grow and IDR groups: 

 

Sue Hares

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 20 Jul 2017 11:41:09 +0200

Sue/ draft-ietf-idr-best-external authors,

Don’t recall call for implementations, there’s an implementation in Ericsson’s SEOS/IPOS 

Cheers,

Jeff

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, July 20, 2017 at 11:24
To: 'Peter Schoenmaker' <[email-masked]>, 'Christopher Morrow' <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

Peter:

Sue 

Hi Sue,

thanks

peter

Chris: 

Yes – it is gshust. 

See 

 

Grow and IDR groups: 

 

Sue Hares

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Jul 2017 05:53:15 -0400

Thank you for reference to Ericsson’s implementation.  Please send me offline a contact for this implementation. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Thursday, July 20, 2017 5:41 AM
To: Susan Hares; 'Peter Schoenmaker'; 'Christopher Morrow'
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

Cheers,

Jeff

Peter:

Sue 

Hi Sue,

thanks

peter

Chris: 

Yes – it is gshust. 

See 

 

Grow and IDR groups: 

 

Sue Hares

---

From: <[email-masked]>
Date: Thu, 20 Jul 2017 12:36:43 +0000

Hi Susan, all

> From Susan Hares
 > Sent: Thursday, July 20, 2017 10:53 AM
 
 > If this solution was good was the best solution,  there is no further work.
 
This is the case.
 
 > We've been trying to fast track all operator needs.

As the author of the offending sentence/slide and co-author of the g-shut document, I can assure you that I had zero (b) intention to put the responsibility on IDR or on an IDR draft (a).
I'm sorry if it felt that way.

--Bruno

(a) Plus being an author of draft-ietf-idr-reserved-extended-communities, I would have been the one to blame.
(b) zero as per https://en.wikipedia.org/wiki/0 not as per https://en.wikipedia.org/wiki/Zero-point_energy

 > resolved by just working with RFC 1997 well-known communities.

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Thu, 20 Jul 2017 12:50:48 +0000

Susan, all

> From: Job Snijders
 > Sent: Thursday, July 20, 2017 11:10 AM
> 

+1
 
 > values.

+1
I would personally put it a bit more strongly: IMHO it would be useful to have non-transitive (well-known) communities.

> So while we may not need
 
Or another draft/solution providing the feature.
(Note: being a co-author of that draft, this is not a political statement to push my/other solution.)
 
 > I appreciate that - and I think the approach is working.
 
+1

Kind regards,
--Bruno
 
 > GROW mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/grow

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Jul 2017 10:15:46 -0400

Bruno:

Thank you for letting John and I know you found the best solution.  

Sue Hares 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 20, 2017 8:37 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Job Snijders'; 'Christopher Morrow'
Subject: RE: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

Hi Susan, all

 
This is the case.
 
 > We've been trying to fast track all operator needs.

As the author of the offending sentence/slide and co-author of the g-shut
document, I can assure you that I had zero (b) intention to put the
responsibility on IDR or on an IDR draft (a).
I'm sorry if it felt that way.

--Bruno

(a) Plus being an author of draft-ietf-idr-reserved-extended-communities, I
would have been the one to blame.
(b) zero as per https://en.wikipedia.org/wiki/0 not as per
https://en.wikipedia.org/wiki/Zero-point_energy

 > From: Job Snijders [mailto:[email-masked]]  > Sent: Thursday, July 20, 2017
4:42 AM  > To: Christopher Morrow  > Cc: Susan Hares; [email-masked] List;
[email-masked] [email-masked]  > Subject: Re: [Idr] Are there IDR drafts the
Grow WG needs completed quickly?
 > > > As the IDR co-chairs sat in the grow meeting, we heard of an IDR  > >
> draft that was so long in becoming an RFC that the Grow authors took  > >
 > GROW's draft-ietf-grow-bgp-gshut had a dependency on  >
draft-ietf-idr-reserved-extended-communities which related to  >
draft-ietf-idr-as4octet-extcomm-generic-subtype - eventually this was  >
resolved by just working with RFC 1997 well-known communities.
 > 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.