Subject: [Teas] WG Last Call: draft-ietf-teas-interconnected-te-info-exchange

From: Lou Berger <[email-masked]>
Date: Mon, 7 Mar 2016 12:29:55 -0500

All,
This starts a two-week working group last call on
draft-ietf-teas-interconnected-te-info-exchange-03.

The working group last call ends on March 21. Please send your comments
to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
TEAS Chairs

---

From: Gert Grammel <[email-masked]>
Date: Mon, 7 Mar 2016 17:48:28 +0000

"I've reviewed this document and believe it is ready for publication"

Gert

On 2016-07-03 18:29, "Teas on behalf of Lou Berger" <[email-masked]
on behalf of [email-masked]> wrote:

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

---

From: John E Drake <[email-masked]>
Date: Mon, 7 Mar 2016 20:05:14 +0000

Hi,

It's ready for publication, as it was several years ago.

Yours Irrespectively,

John

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Monday, March 07, 2016 12:30 PM
> To: TEAS WG
> Cc: [email-masked]; TEAS WG Chairs
> Subject: [Teas] WG Last Call: draft-ietf-teas-interconnected-te-info-exchange
> 
> All,
> This starts a two-week working group last call on draft-ietf-teas-interconnected-te-info-
> exchange-03.
> 
> The working group last call ends on March 21. Please send your comments to the teas
> mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready for
> publication", are welcome!

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 7 Mar 2016 20:09:02 +0000

Lou,
It is ready for publication

Thanks!

Regards,
Jeff

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 8 Mar 2016 03:29:35 +0000

I have reviewed this draft and believe it is ready for publication. 

Regards,
Xian (as co-author)

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2016年3月8日 1:30
To: TEAS WG
Cc: [email-masked]; TEAS WG Chairs
Subject: [Teas] WG Last Call: draft-ietf-teas-interconnected-te-info-exchange

All,

Thank you,
TEAS Chairs

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 8 Mar 2016 12:30:54 +0000

Same here.

The drafts is ready as there is nothing left to remove (as a wise man said once)

BR
Daniele

> From: Zhangxian (Xian) [mailto:[email-masked]]
> Sent: martedì 8 marzo 2016 04:30
> To: Lou Berger; TEAS WG
> Subject: RE: [Teas] WG Last Call: draft-ietf-teas-interconnected-te-info-
> exchange
> 
> This starts a two-week working group last call on draft-ietf-teas-
> interconnected-te-info-exchange-03.
> 
> The working group last call ends on March 21. Please send your comments to
> the teas mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready
> for publication", are welcome!

---

From: Lou Berger <[email-masked]>
Date: Sun, 20 Mar 2016 13:18:31 -0400

Hi,
    I think the document is really very good and almost ready to submit
for publication.   I have one issue that I think has to be addressed
and, since a change is needed, I'll also propose one addition.

1. The document says:
    Intended status: Standards Track

    As the document doesn't include any new behaviors "on the wire" or
any 2119 conformance language it seems to me (with all hats) that
"Standards Track" isn't the right track.  Given all the work that went
into this document and all that it captures, I'd like to propose  "Best
Current Practice".  If there are no objections from the authors, please
make this change.  If there are objections (from the authors) please use
"Informational".

2.  As contributor: I think something like the following should be added
to section  1.1 given that the term is used in the document and has been
around for quite a while, and also that another revision of the draft is
needed to address 1. (above):

   1.1.x Abstract Node

   An abstract node was defined in [RFC3209] as a group of nodes whose
   internal topology is opaque to an ingress node of the LSP.  More 
   generally, an abstract node is the representation of the characteristics
   of one or more a nodes within a domain produced by abstraction.  An
   abstract node may be advertised outside that domain as a TE node for
   use in signaling in other domains. 

   More details on abstract nodes are provided in Section 4.2.2.1.

Lou

PS I'm sending this before the end of LC so that there's a chance to
have an updated rev before tomorrow's cutoff, in the hopes of getting
the document submitted for publication before BA.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 20 Mar 2016 19:58:54 -0000

Lou,

Thanks.
I'll try to do this before the submission deadline so that you can get it in the
AD's queue ASAP.

> make this change.  If there are objections (from the authors) please use

Our thinking on Standards Track was that it is quite strong guidance on how to
build and deploy.

The IESG has undamped oscillations wrt the use of BCP. If they are currently
supportive of this type of use then I'm OK with this being a BCP.

OTOH, maybe this fits as an RFC 2026 "Applicability Statement" which would put
it on the Standards Track (see section 3.2). The concept of an AS has been one
of the things that has led the IESG to brief against the use of BCP.

I'd be a bit disappointed with Informational, but wouldn't push back on that if
directed.

Can I suggest that we ask the AD what she'd support and that we don't make any
change at this stage?

>    More details on abstract nodes are provided in Section 4.2.2.1.

Hmmm. 4.2.2.1 actually has a very different view of a "node in the abstraction
layer". 4.2.2.1 is talking about server layer nodes that have a presence within
the abstraction layer network, and makes a strong recommendation against using
this type of abstract node.

Section 3.5 describes this type of abstraction as a "virtual node".

So, if we do add this, I think it would go in as...

1.1.8 Abstract Node or Virtual Node

   An abstract node was defined in [RFC3209] as a group of nodes whose
   internal topology is opaque to an ingress node of the LSP.  More 
   generally, an abstract node or virtual node is the representation as a
   single node in a TE topology of one or more nodes and the links that
   connect them.  An abstract node may be advertised outside the
   domain as a TE node for use in path computation and signaling in
   other domains.

   Sections 3.5 and 4.2.2.1 provide more information about the uses
   and issues of abstract nodes and virtual nodes.

> the document submitted for publication before BA.

Ack.
Adrian

---

From: Lou Berger <[email-masked]>
Date: Sun, 20 Mar 2016 16:28:40 -0400

Adrian,

> I'd be a bit disappointed with Informational, but wouldn't push back on that if

Completely agree.

> Can I suggest that we ask the AD what she'd support and that we don't make any

Sure, if she responds before you need to submit to make the submission 
deadline.  If not, submit as BCP and we can let the ad/iesg work it out.

>    and issues of abstract nodes and virtual nodes.

Perfect. Thank you.

Lou

---

From: George Swallow <[email-masked]>
Date: Mon, 21 Mar 2016 11:50:29 -0400

Last time I looked into making something a BCP (around 18-24 months ago) I
was advised that that was the highest hurdle one could ask for.  Anyone
more up-to-date on the current climate?

George

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Mar 2016 12:18:24 -0400

All,
The last call is complete.

Authors

Please let me know if you are planning an additional update to address any 
comments.

Thank you,
Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Mar 2016 19:41:54 -0000

We're done and good to go, thanks.
Adrian

> Sent: 22 March 2016 16:18
> To: TEAS WG
> Subject: Re: [Teas] WG Last Call:
draft-ietf-teas-interconnected-te-info-exchange