Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 3 Jun 2019 01:36:56 +0000

Hello All,

The WG version of this draft has been posted as below

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-00

We would like to request for early code point allocation from IANA to enable implementations with suggested code points as indicated below:

   The following codepoints is suggested (to be assigned by IANA) from
   within the sub-registry called "BGP-LS NLRI-Types":

    +------+----------------------------+---------------+
    | Type | NLRI Type                  |   Reference   |
    +------+----------------------------+---------------+
    |  6   | SRv6 SID                   | this document |
    +------+----------------------------+---------------+

   The following TLV codepoints are suggested (to be assigned by IANA)
   from within the sub-registry called "BGP-LS Node Descriptor, Link
   Descriptor, Prefix Descriptor, and Attribute TLVs":

   +----------+----------------------------------------+---------------+
   | TLV Code |             Description                | Value defined |
   |  Point   |                                        |       in      |
   +----------+----------------------------------------+---------------+
   |  1038    |   SRv6 Capabilities TLV                | this document |
   |  1106    |   SRv6 End.X SID TLV                   | this document |
   |  1107    |   IS-IS SRv6 LAN End.X SID TLV         | this document |
  |  1108    |   OSPFv3 SRv6 LAN End.X SID TLV        | this document |
   |  1162    |   SRv6 Locator TLV                     | this document |
   |   518    |   SRv6 SID Information TLV             | this document |
   |  1250    |   SRv6 Endpoint Function TLV           | this document |
   |  1251    |   SRv6 BGP Peer Node SID TLV           | this document |
   +----------+----------------------------------------+---------------+

Thanks,
Ketan

From: Susan Hares <[email-masked]>
Sent: 30 May 2019 06:07
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]

draft-dwara-idr-bgpls-srv6-ext has been adopted.
The authors should submit the draft as:  draft-ietf-idr-bgpls-srv6-ext-00.txt.

As soon as this draft has been submitted, an early code point allocation call will begin.

Cheerily, Sue

---

From: tom petch <[email-masked]>
Date: Tue, 4 Jun 2019 08:43:38 +0000

----- Original Message -----
From: "Ketan Talaulikar (ketant)" <[email-masked]>
Sent: Monday, June 03, 2019 2:36 AM

Hello All,

<tp>

You have done exactly what you were asked to do, but it is unfortunate
that all the other ID have bgp-ls while this has bgpls.

Sue,

Are you happy to live with this?

Tom Petch

We would like to request for early code point allocation from IANA to
enable implementations with suggested code points as indicated below:

Thanks,
Ketan

From: Susan Hares <[email-masked]>
Sent: 30 May 2019 06:07
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext
[5/2 - 5/16/2018]

draft-dwara-idr-bgpls-srv6-ext has been adopted.
The authors should submit the draft as:
draft-ietf-idr-bgpls-srv6-ext-00.txt.

As soon as this draft has been submitted, an early code point allocation
call will begin.

Cheerily, Sue

------------------------------------------------------------------------
--------

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 4 Jun 2019 06:07:15 -0400

Tom:

Your short mail usually has good suggestions, so I tried to decode this
message - but I failed.  I'm guessing at the question.  

If this question is about the multiple drafts for the BGP-LS, see my message
yesterday to Jeff regarding drafts from LSR with BGP-LS code points and
early allocations. 
If this question is about BGP-LS error handling, see my wish/hope that draft
the draft-ketana-rfc7752bis.txt will be ready for adoption soon. 
If this question is about early code point allocation,  this early
allocation policy is IESG/IANA policy.  If you wish me to ask for a change,
please unpack the message so I can work on it. 

Cheerily, Susan 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of tom petch
Sent: Tuesday, June 4, 2019 4:44 AM
To: Ketan Talaulikar (ketant); Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 -
5/16/2018]

----- Original Message -----
From: "Ketan Talaulikar (ketant)" <[email-masked]>
Sent: Monday, June 03, 2019 2:36 AM

Hello All,

<tp>

You have done exactly what you were asked to do, but it is unfortunate that
all the other ID have bgp-ls while this has bgpls.

Sue,

Tom Petch

We would like to request for early code point allocation from IANA to enable
implementations with suggested code points as indicated below:

Thanks,
Ketan

Cheerily, Sue

---

From: Christoph Loibl <[email-masked]>
Date: Tue, 4 Jun 2019 12:29:49 +0200

Hi,

> On 04.06.2019, at 12:07, Susan Hares <[email-masked]> wrote:
> 

I think the point here is a simple “naming” inconsistency of the draft itself. *Most* of the BGP-LS drafts have

	“bgp-ls” 

in the document name while this one (not the only one btw) uses

	“bgpls”

in the name.

Cheers Christoph

Appendix: Datatracker research

draft-ietf-idr-bgpls-inter-as-topology-ext-02 
draft-ietf-idr-bgpls-segment-routing-epe-19
draft-ietf-idr-bgpls-srv6-ext-00 <<<< this is the new one

vs.

draft-ietf-idr-bgp-ls-app-specific-attr-00 
draft-ietf-idr-bgp-ls-flex-algo-00 
draft-ietf-idr-bgp-ls-sbfd-extensions-00
draft-ietf-idr-bgp-ls-segment-routing-ext-15
draft-ietf-idr-bgp-ls-segment-routing-msd-05
draft-ietf-idr-bgp-ls-segment-routing-rld-03 
draft-ietf-bier-bgp-ls-bier-ext-05 

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Jun 2019 12:29:58 +0200

Hi Sue,

To me Tom was simply pointing out difference in name if the draft where
dash is missing in "bgp-ls" string in this specific case.

On the other points you have raised I think it is missing the fundamental
one ... since when what used to be a wg focused in the past on interdomain
routing became a mainstream of link state, topology, bfd, pce data
collection and distribution.

Even charter aside IMO by shifting IDR focus and processing 99% of BGP-LS
related documents we are doing huge disservice to Internet and routing
related needs without even bringing the aspect of protocol pollution.

Kind regards,
R.

On Tue, Jun 4, 2019, 12:07 Susan Hares <[email-masked]> wrote:

> enable

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 4 Jun 2019 06:50:15 -0400

Robert: 

Ah…  thanks for unpacking Tom’s message.    Since John and I are focused on getting all the WG drafts toward RFC (where the draft name does not matter), I had not consider this point.  Acee and Chris in LSR have standardized on a particular form of bgp-ls.   Tom Petch has a good point.   

As to the 99% of BGP-LS,  that’s a question the chairs and ADs tried to ask the WG in 2018.   The WG did not engage on that discussion.  

In order to protect the BGP stream,  the ADs/Chairs pushed for draft-ketana-rfc7752bis.txt (for improved error handling) and larger BGP messages (see raft-ietf-idr-bgp-extended-messages-30.txt).   

Cheerily, 

 Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, June 4, 2019 6:30 AM
To: Susan Hares
Cc: idr@ietf. org
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]

Hi Sue,

To me Tom was simply pointing out difference in name if the draft where dash is missing in "bgp-ls" string in this specific case.

On the other points you have raised I think it is missing the fundamental one ... since when what used to be a wg focused in the past on interdomain routing became a mainstream of link state, topology, bfd, pce data collection and distribution.

Even charter aside IMO by shifting IDR focus and processing 99% of BGP-LS related documents we are doing huge disservice to Internet and routing related needs without even bringing the aspect of protocol pollution.

Kind regards,

R.

Tom:

Cheerily, Susan 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of tom petch
Sent: Tuesday, June 4, 2019 4:44 AM
To: Ketan Talaulikar (ketant); Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 -
5/16/2018]

----- Original Message -----
From: "Ketan Talaulikar (ketant)" <[email-masked]>
Sent: Monday, June 03, 2019 2:36 AM

Hello All,

<tp>

Sue,

Tom Petch

https://datatracker..ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-00 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-00> 

Thanks,
Ketan

Cheerily, Sue

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 4 Jun 2019 07:44:34 -0400

Christoph: 

This is a good point.   The LSR chairs (Chris and Acee) have made this point.  I will address this problem in the next week. 

Cheerily, Susan Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Christoph Loibl
Sent: Tuesday, June 4, 2019 6:30 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]

Hi,

> Your short mail usually has good suggestions, so I tried to decode 
> this message - but I failed.  I'm guessing at the question.

	“bgp-ls” 

	“bgpls”

in the name.

Cheers Christoph

vs.

---

From: tom petch <[email-masked]>
Date: Tue, 4 Jun 2019 12:01:32 +0000

Sue

Sorry I was too terse, but yes, Christoph and Robert provided the
expansion.

Draft names do disappear with the RFC but then there are times we need
to look back at the history, and then, having a single name for the
adopted I-D is simplest. On the other hand, when I search or collate the
names, in folders, e-mails etc having a common string - bgp-ls rather
than bgpls - makes things easier for me to find.

So changing the name complicates things, leaving it as-is complicates
things. Grrr why did I not spot this prior to adoption?

On balance, I think leave the name as is but I want you to agree with
this.

Tom Petch

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'Robert Raszuk'" <[email-masked]>
Cc: "'idr@ietf. org'" <[email-masked]>
Sent: Tuesday, June 04, 2019 11:50 AM
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext
[5/2 - 5/16/2018]

Robert:

Ah…  thanks for unpacking Tom’s message.    Since John and I are focused
on getting all the WG drafts toward RFC (where the draft name does not
matter), I had not consider this point.  Acee and Chris in LSR have
standardized on a particular form of bgp-ls.   Tom Petch has a good
point.

As to the 99% of BGP-LS,  that’s a question the chairs and ADs tried to
ask the WG in 2018.   The WG did not engage on that discussion.

In order to protect the BGP stream,  the ADs/Chairs pushed for
draft-ketana-rfc7752bis.txt (for improved error handling) and larger BGP
messages (see raft-ietf-idr-bgp-extended-messages-30.txt).

Cheerily,

 Sue Hares

Hi Sue,

On the other points you have raised I think it is missing the
fundamental one ... since when what used to be a wg focused in the past
on interdomain routing became a mainstream of link state, topology, bfd,
pce data collection and distribution.

Even charter aside IMO by shifting IDR focus and processing 99% of
BGP-LS related documents we are doing huge disservice to Internet and
routing related needs without even bringing the aspect of protocol
pollution.

Kind regards,

R.

Tom:

If this question is about the multiple drafts for the BGP-LS, see my
message
yesterday to Jeff regarding drafts from LSR with BGP-LS code points and
early allocations.
If this question is about BGP-LS error handling, see my wish/hope that
draft
the draft-ketana-rfc7752bis.txt will be ready for adoption soon.
If this question is about early code point allocation,  this early
allocation policy is IESG/IANA policy.  If you wish me to ask for a
change,
please unpack the message so I can work on it.

Cheerily, Susan

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of tom petch
Sent: Tuesday, June 4, 2019 4:44 AM
To: Ketan Talaulikar (ketant); Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext
[5/2 -
5/16/2018]

----- Original Message -----
From: "Ketan Talaulikar (ketant)" <[email-masked]>
Sent: Monday, June 03, 2019 2:36 AM

Hello All,

<tp>

that

Sue,

Tom Petch

https://datatracker..ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-00
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-00>

Thanks,
Ketan

Cheerily, Sue

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 4 Jun 2019 08:42:14 -0400

Tom:

It is easy to have the authors change the name, and link the old draft to the new draft's name.    I'll address this issue later today or early tomorrow.   

I'm pushing out WG LC, shepherd reports, adoption calls, and issue calls before I attend to name changes today.   People have 4 weeks to finalize drafts before IETF 106 - so I'm completing the things that WG members need to take action on.   

Cheerily, Susan Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of tom petch
Sent: Tuesday, June 4, 2019 8:02 AM
To: Susan Hares; 'Robert Raszuk'
Cc: 'idr@ietf. org'
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]

Sue

Sorry I was too terse, but yes, Christoph and Robert provided the expansion.

Draft names do disappear with the RFC but then there are times we need to look back at the history, and then, having a single name for the adopted I-D is simplest. On the other hand, when I search or collate the names, in folders, e-mails etc having a common string - bgp-ls rather than bgpls - makes things easier for me to find.

So changing the name complicates things, leaving it as-is complicates things. Grrr why did I not spot this prior to adoption?

On balance, I think leave the name as is but I want you to agree with this.

Tom Petch

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'Robert Raszuk'" <[email-masked]>
Cc: "'idr@ietf. org'" <[email-masked]>
Sent: Tuesday, June 04, 2019 11:50 AM
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext
[5/2 - 5/16/2018]

Robert:

Ah…  thanks for unpacking Tom’s message.    Since John and I are focused
on getting all the WG drafts toward RFC (where the draft name does not matter), I had not consider this point.  Acee and Chris in LSR have
standardized on a particular form of bgp-ls.   Tom Petch has a good
point.

Cheerily,

 Sue Hares

Hi Sue,

Kind regards,

R.

Tom:

Your short mail usually has good suggestions, so I tried to decode this message - but I failed.  I'm guessing at the question.

If this question is about the multiple drafts for the BGP-LS, see my message yesterday to Jeff regarding drafts from LSR with BGP-LS code points and early allocations.
If this question is about BGP-LS error handling, see my wish/hope that draft the draft-ketana-rfc7752bis.txt will be ready for adoption soon.
If this question is about early code point allocation,  this early allocation policy is IESG/IANA policy.  If you wish me to ask for a change, please unpack the message so I can work on it.

Cheerily, Susan

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of tom petch
Sent: Tuesday, June 4, 2019 4:44 AM
To: Ketan Talaulikar (ketant); Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext
[5/2 -
5/16/2018]

----- Original Message -----
From: "Ketan Talaulikar (ketant)" <[email-masked]>
Sent: Monday, June 03, 2019 2:36 AM

Hello All,

<tp>

You have done exactly what you were asked to do, but it is unfortunate that all the other ID have bgp-ls while this has bgpls.

Sue,

Tom Petch

Thanks,
Ketan

Cheerily, Sue

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Jun 2019 15:45:46 +0200

Hi Sue,

> ask the WG in 2018.   The WG did not engage on that discussion.

I reread the IDR charter ,,, https://datatracker.ietf.org/wg/idr/about/

I did not find anything there which would justify any of the work related
to BGP-LS needs in this WG for example - topology or link state information
transport.

IMO AD should recognize the need for various non routing information
transport and steer this towards BOF and new WG creation to define new
protocol for it.. Even if rather from scratch such effort would reuse some
of the BGP features. And while it was not done up front it is not too late
now.

> messages (see raft-ietf-idr-bgp-extended-messages-30.txt).

Improving error handling is always good.

But how making the message larger helps to protect the BGP stream ? Its
like opening the window wider when cloud of wild insects approaches ....

Best,
R.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 4 Jun 2019 10:35:32 -0400

Robert:

You are welcome to send these comments to Alvaro and to the IESG regarding IDR’s charter and the impact on SPRING. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, June 4, 2019 9:46 AM
To: Susan Hares
Cc: idr@ietf. org
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]

Hi Sue,

I did not find anything there which would justify any of the work related to BGP-LS needs in this WG for example - topology or link state information transport. 

IMO AD should recognize the need for various non routing information transport and steer this towards BOF and new WG creation to define new protocol for it.. Even if rather from scratch such effort would reuse some of the BGP features. And while it was not done up front it is not too late now. 

But how making the message larger helps to protect the BGP stream ? Its like opening the window wider when cloud of wild insects approaches .... 

Best,

R.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 5 Jun 2019 05:43:35 -0700

On June 4, 2019 at 9:46:23 AM, Robert Raszuk ([email-masked]) wrote:

[Changed the subject.  Explicitly added rtgwg-chairs/rtg-ads: take a look
at the last part of this message.]

Robert:

Hi!

As to the 99% of BGP-LS,  that’s a question the chairs and ADs tried to ask
the WG in 2018.   The WG did not engage on that discussion.

According to the datatracker, the last revision of the Charter was in
2010.  It still includes items such as MIBs and four-octet ASNs... I think
it is time for an update!  This is a conversation that I’ve already had
with the Chairs and they have the AI to kick off that discussion.  Among
other things, more clarity is needed on the overall responsibility around
BGP.

To your point about BGP-LS; I think that a liberal interpretation of the
Charter and the general understanding that this WG is responsible for BGP
allows that work.  It would have been ideal if the question had come at the
time when the work was started….

It would also be ideal if the Charter (all charters) always reflected what
a WG is working on…but sometimes the process of updating can get in the way
of getting work done.

[Bringing in your other point.]

On June 4, 2019 at 6:30:26 AM, Robert Raszuk ([email-masked]) wrote:

...

I have also had the conversation with the Chairs about the load that BGP-LS
represents to idr and the general topic of information transport (note that
BGP is not the only protocol in the Routing Area being used to transport
stuff…so it is a much wider topic).  The last time was a few months ago.  I
don’t remember having the discussion on the list.

At that time, the general consensus (between the Chairs and me) was that
the operation of BGP-LS should be maintained in idr (it is BGP!).  I don’t
remember any objection about having a discussion about the wider topic.  A
non-WG forming BOF seems like the right place to do that.

I would be happy to sponsor that discussion at IETF 105.  See more below...

I think there are a couple of actions that should come out of this thread:

(1) idr Charter Update.  I’ll rely on the Chairs to move this topic
forward.  Even though the time is short, it would be ideal to have a
focused discussion in Montreal.

(2) Non-Routing Information Transport (nRIT).  This is clearly a
non-idr-specific topic. If you (and/or someone else) wants to propose a BOF
for Montreal, I will sponsor it — note that the deadline for BOF proposals
is this Friday [1].  Realizing that a BOF proposal might be too rushed, we
could also talk about this in rtgwg (their Charter clearly talks about
being a "venue to discuss, evaluate, support and develop proposals for new
work in the Routing Area”).  If we want to have a fruitful discussion (and
not just statements in one direction or another), then I expect to start
working on this right away.

Thanks!

Alvaro.

[1] https://trac.tools.ietf.org/bof/trac/

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Jun 2019 20:20:56 +0200

Hello Alvaro,

Thank you for your below note.  Few additional points to think about.

* The comment I made about the BOF was just a retrospect. By today we do
know there is need to transport various opaque to BGP  information around.
Moreover there is clear IETF people who are working on it so also the
aspect of who would continue to actively work seems clear too. In that
light I am really not sure what would be the point of organizing non WG
creation BOF. I think as you suggest routing-wg could be a good venue.

* To your point of  calling it Non-Routing Information Transport (nRIT).
Great abbreviation, but one may correctly say that link state or topology
is routing information. One may even claim that BFD or SR is also routing
information. I think we need to segregate what belongs in BGP or what
belongs in IGP a bit differently. And here I like recent suggestion from
Les - objection to add any information to a routing protocol not directly
relevant to its operation. Quote:

"The restriction was introduced because of general concern that using IGPs
to advertise information not directly relevant to the operation of the IGP
as a routing protocol is sub-optimal and negatively impacts the performance
of the primary IGP functions.

* I think as next steps we have two options (could be proceeded in parallel
... )

- look for IETF community to standardize alternative transports for opaque
information routing protocols (as starter for example we could take Open/R)

- take BGP snapshot of the protocol specifications and define a subset
required to realize distribution of various no directly relevant to IP
reachability information and ask for new port #,  maybe new name to
separate it completely from BGP-4 we know to glue the networks together.

It is up to IESG to decide if we need new WG for the above or any of the
existing WG is so idle that it could take this work on. Maybe from routing
area .. maybe from transport area.

Kind regards,
Robert.

On Wed, Jun 5, 2019 at 2:43 PM Alvaro Retana <[email-masked]> wrote:

> I have also had the conversation with the Chairs about the load that
> BGP-LS represents to idr and the general topic of information transport
> (note that BGP is not the only protocol in the Routing Area being used to
> transport stuff…so it is a much wider topic).  The last time was a few
> months ago.  I don’t remember having the discussion on the list.
>

---

From: John Scudder <[email-masked]>
Date: Fri, 7 Jun 2019 15:27:04 +0000

On Jun 5, 2019, at 8:43 AM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

I have also had the conversation with the Chairs about the load that BGP-LS represents to idr and the general topic of information transport (note that BGP is not the only protocol in the Routing Area being used to transport stuff…so it is a much wider topic).  The last time was a few months ago.  I don’t remember having the discussion on the list.

At that time, the general consensus (between the Chairs and me) was that the operation of BGP-LS should be maintained in idr (it is BGP!).

One further outcome of that discussion was that we agreed that LSR would include a BGP-LS encoding when progressing uncomplicated drafts that already contain OSPF and IS-IS encodings. We reported this to the WG at our meeting and it’s come up on the mailing list since then. My hope is this will reduce overhead for all concerned.

—John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 7 Jun 2019 18:44:17 +0200

> My hope is this will reduce overhead for all concerned.

While clearly it may reduce the IDR WG work overhead in the same time
aren't we worried that it may generate uncontrolled overhead of the
protocol itself ?

Thx,
R.

On Fri, Jun 7, 2019 at 5:27 PM John Scudder <[email-masked]> wrote:

> On Jun 5, 2019, at 8:43 AM, Alvaro Retana <[email-masked]> wrote:
>
> the operation of BGP-LS should be maintained in idr (it is BGP!).
>
> One further outcome of that discussion was that we agreed that LSR would
> include a BGP-LS encoding when progressing uncomplicated drafts that
> already contain OSPF and IS-IS encodings. We reported this to the WG at our
> meeting and it’s come up on the mailing list since then. My hope is this
> will reduce overhead for all concerned.
>
> —John
>
>

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 7 Jun 2019 17:58:39 -0400

On June 5, 2019 at 2:21:07 PM, Robert Raszuk ([email-masked]) wrote:

Hi!

Yes.

To be clear, the IESG can make that decision based on a specific work
proposal *and* interest from the community.  IOW, just like any other work
we need members of the community to drive it.

It would be great if you and/or other interested people started work on
specific proposals for discussion.

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 7 Jun 2019 18:19:10 -0400

Robert: 

It is a good weekend to think about those proposal.   We’ll start the discussion next week.   Please consider having a proposal for any additional work you’d like IDR to take on. 

In order to pay appropriate attention to a charter discussion, John and I would like to complete sending drafts to the IESG, WG LCs, and adoption calls.    I’m down to my final IESG one ( <https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/> draft-ietf-idr-bgp-optimal-route-reflection-18) and 3 WG LCs.  John’s got two (draft-ietf-idr-rfc5575bis-16 and draft-ietf-idr-tunnel-encaps-12).   John’s second one may slip to early next week (draft-ietf-idr-tunnel-encaps-12).  In order to pay appropriate attention to a charter discussion, John and I would like to complete these items so that WG members can work while we discuss the charter.  

I’ve also got another issue (auto-discovery) that I will also spin up to the WG on Monday as well.  The two issues may intersect. 

Thanks for your input!

Sue 

From: Alvaro Retana [mailto:[email-masked]] 
Sent: Friday, June 7, 2019 5:59 PM
To: Robert Raszuk
Cc: Susan Hares; rtgwg-chairs; <[email-masked]>; idr@ietf. org
Subject: Re: [Idr] IDR WG Charter (Re: Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018])

Hi!

It is up to IESG to decide if we need new WG for the above or any of the existing WG is so idle that it could take this work on. Maybe from routing area .. maybe from transport area. 

Yes.

To be clear, the IESG can make that decision based on a specific work proposal *and* interest from the community.  IOW, just like any other work we need members of the community to drive it.

It would be great if you and/or other interested people started work on specific proposals for discussion.

Thanks!

Alvaro.