Subject: [irs-discuss] Rough Draft IRS Charter

From: Ross Callon <[email-masked]>
Date: Thu, 18 Oct 2012 11:55:07 -0400

Attached (in Word format) is a very rough initial draft charter (for a potential IRS WG) that the BOF chairs have been discussing with our friendly sponsoring routing area AD.

Comments are welcome. We will be discussing the draft IRS WG charter in Atlanta.

Thanks, Ross
(with input from Dave and Adrian)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 18 Oct 2012 14:12:22 -0400

It seems to me that the second paragraph of the description is 
misleading and unfortunate.  The proposed interface is not inherently 
any faster (or slower) than any other existing interface.  It may in 
fact use existing protocols and mechanisms.  At the same time, the 
stated goal is to expose information and models that are generalizations 
or synthesized combinations of what the devices currently expose.  This 
is unlikely to be meaningfully manipulated using the same paradigms that 
operators currently use.

Would it still hang together if he paragraph were simply removed?

Yours,
Joel

On 10/18/2012 11:55 AM, Ross Callon wrote:
> Attached (in Word format) is a very rough initial draft charter (for a
> potential IRS WG) that the BOF chairs have been discussing with our
> friendly sponsoring routing area AD.
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 18 Oct 2012 18:07:00 -0400

I have to say I agree with Joel on this.

Also, an unrelated comment: do you/we want to scope what is meant by
"Topology"?  For example, is TE/resource information in or out of scope?
 What about LFIB?  TMF.DM-1 of draft-medved-irs-topology-requirements
has a long list, are any out of scope?

Lou

---

From: David Meyer <[email-masked]>
Date: Thu, 18 Oct 2012 15:23:39 -0700

On Thu, Oct 18, 2012 at 11:12 AM, Joel M. Halpern <[email-masked]> wrote:
> It seems to me that the second paragraph of the description is misleading
> and unfortunate.  The proposed interface is not inherently any faster (or
> slower) than any other existing interface.  It may in fact use existing
> protocols and mechanisms.  At the same time, the stated goal is to expose
> information and models that are generalizations or synthesized combinations
> of what the devices currently expose.  This is unlikely to be meaningfully
> manipulated using the same paradigms that operators currently use.

Agree Joel. In addition, there can easily be confusion as terms like
"fast path" are more conventionally used to refer to switching paths.

--dmm

---

From: Russ White <[email-masked]>
Date: Thu, 18 Oct 2012 20:14:23 -0400

> "fast path" are more conventionally used to refer to switching paths.

+1

It's always easy to say, "this will be faster," but it's going to wind
up being far too implementation dependent to be a really meaningful or
useful measure.

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 19 Oct 2012 14:43:25 +0200

Hello,
 I have a question on working item 2:

"The working group is chartered to work on the following items:

2.       Tightly scoped key use cases for operational use of IRS. These use cases will include at least:

a.      Interactions with the RIB

b.      Association of routing policies with routing state

c.      The ability to extract information about topology from the network
"
Does this bullet exclude the possibility to use IRS to gather information about network measurements such as available bandwidth on a link, information related to jitter delay for specific flows etc. ?

Thanks,
Roberta
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Thursday, October 18, 2012 5:55 PM
To: [email-masked]
Cc: Ross Callon; [email-masked]
Subject: [irs-discuss] Rough Draft IRS Charter

Thanks, Ross

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

---

From: Russ White <[email-masked]>
Date: Mon, 22 Oct 2012 13:50:07 -0400

I think this has already been brought up on the list once before, but
I'd just like to repeat my concerns on it:

==
Thus, the IRS is a "fast path" that can be used to program routing and
policy state in a router using operational paradigms familiar to
operators of traditional distributed devices. This differs from the
programmatic "slow state" that is commonly a device's configuration
interface because those mechanisms impose many transactional mechanisms
and requirements, that may slow down the interaction.
==

Describing the CLI or other existing interfaces as the "slow path," and
the proposed as the "fast path," is problematic. First, it implies that
there is a specific path already available into all control plane
devices, and that single path is "too slow," for some meaning of "too
slow." Second, it implies, from the start, that we need new path, rather
than a possible structure around existing paths that we can use to make
sense of the routing system as a whole.

I think 2a needs to be better defined so it doesn't overlap with 2c, or
2c needs to be made a part of 2a in some way (?).

Thanks!

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 22 Oct 2012 19:57:13 +0200

It may be also worth to document the conflict resolution mechanism
when "fast path" contradicts with "slow path" configurations ...

r.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Oct 2012 07:55:02 -0700

Hi,

This charter text is very puzzling:

     ..those mechanisms impose many transactional mechanisms
    and requirements, that may slow down the interaction

What are these "slow path" mechanisms that IRS will not need?

Andy