Subject: RE: [Forces-protocol] RE: GET/SET in one msg ?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 19 Oct 2004 00:51:51 -0700

Weiming,

In majority of cases, most of us have only seen single LFB instances on
FEs.
In any case, your requirement can easily be solved by defining a special
Instance ID for LFBs that addresses all instances of that LFB on the FE.
I thought we already had some text along these lines in the protocol
draft (probably the header section)

regards
Hormuzd
p.s. I haven't read Zsolt's email on this yet...

-----Original Message-----
From: Wang,Weiming [mailto:[email-masked]] 
Sent: Monday, October 18, 2004 9:00 PM
To: [email-masked]
Cc: Khosravi, Hormuzd M; [email-masked]; Steven Blake (petri-meat);
Joel M. Halpern; Alan DeKok; [email-masked]; [email-masked];
Deleganes, Ellen M; Yang, Lily L
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?

Jamal,Hormuzd, and Joel,

I think we have already have the issue as an editorial note as below:

       Editorial Note:
                        1.  Under discussion is, when an 'FE Protocol
...

                        2.  Under discussion is, do we need to support
                            multiple objects addressing at the LFB Type
                            and LFB Instance layer? One simple way to
                            support multiple LFB types or instances is
                            to use TLVs to identify the group of Type
                            IDs and Instance IDs, rather than only one
                            Type and Instance ID.  A range of Instance
                            IDs may also be supported in this way.

Hormuzd and Joel, do you really think it is not the case? I remember
Joel
supposed there might be thousands of instances with same LFB calss.  In
this
case, if we do not support a range of intance addressing, it actually
makes our
protocol unpractical.

regards,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
>
> So far you are the second person who has shown desire for this. I was
> the other person; both of us are driven by implementation experience.
> How about we just keep it as a note in the draft for now (for progress
> reasons)?
> Hopefully implementation experience will show the error of whats being
> proposed right now, then we can come back and fix it?
>
> cheers,
> jamal
>
>
> On Mon, 2004-10-18 at 10:20, Weiming Wang wrote:
> > Hi Jamal,
> >
> > main hdr (eg type = config)
> >      |
> >      |
> >      +--- T = LFBselect
> >      |        |
> >      |        +-- LFBCLASSID = target LFB class
> >      |        |
> >      |        |
> >      |        +-- LFBInstance = target LFB instance
> >
> > [Weiming] The more I'm thinking, the more I see the value to address
multipul
> > LFB instances here (I can now live with single LFB class). To speak
of this,
I
> > have an aspire  to show my yesterday experience with my GRMP test
platform
> > (sorry I have to mention it). As you know, GRMP  does not support
multipul
LFB
> > instance addressing.  Yesterday, we had to prepare a show of the
platform to
> > guests from our sponsors. Before the show, we spent near one hour to
operate
on
> > the menu to construct a scenario, in which there were 5 output port,
5
> > associated schedulers (LFBs), and several other LFBs that have many
instances.
> > unfortunately, we faced a problem with one of the machine. Then we
had to do
it
> > again.  At that time, I had a VERY VERY strong desire that batch
configuration
> > based on multipul LFB isntance addressing can be used.
> >
> > I can see very simple scheme to include multipul instances here (by
ranging,
or
> > by enum, or by both). Definitely, I believe this will greatly
improve our
> > protocol.
> >
> > I sincerely hope this be considered seriously by gentlemen.
> >
> > Best regards,
> > Weiming
> >
> >      |        |
> >      |        |
> >      |        +-- T = operation { ADD, DEL, GET, etc}
> >      |        |   |
> >      |        |   +--  // one or more path targets
> >      |        |        // under discussion
> >      |        |
> >      |        +-- T = operation { ADD, DEL, GET, etc}
> >      |        |   |
> >      |        |   +--  // one or more path targets
> >      |        |        // under discussion
> >      |        |
> >      |        +-- T = operation { ADD, DEL, GET, etc}
> >      |        |   |
> >      |        |   +--  // one or more path targets
> >      |        |        // under discussion
> >      |        |
> >
> > In other words: Very similar to the way we have it already except
> > the naming has changed and we can target multiple
> > operations and multiple paths in an LFB instance
> > ----- Original Message -----
> > From: "Jamal Hadi Salim" <[email-masked]>
> > >
> > > Welcome back Weiming. I have updated the text with the
query/response.
> > > The only outstanding issue is 6.7. Please weigh in.
> > > I think we are ready top start making updates.
> > >
> > > cheers,
> > > jamal
> > >
> >
> >
>

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 19 Oct 2004 18:33:29 +0800

Hormuzd,

Thanks for reply.

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>
Weiming,

In majority of cases, most of us have only seen single LFB instances on
FEs.
[Weiming] I'm afraid this is not true. From my experience, it's very often we
have more than  one instances.

In any case, your requirement can easily be solved by defining a special
Instance ID for LFBs that addresses all instances of that LFB on the FE.
I thought we already had some text along these lines in the protocol
draft (probably the header section)
[Weiming] Yes, we have proposed using an insatnce broadcast address to address
all instances. It's useful, but still from my experience, it's not enough. I'v
very often seen the case where there is only one insatnce that has different
config requriement than all other instances.

regards
Hormuzd

-----Original Message-----
From: Wang,Weiming [mailto:[email-masked]]
Sent: Monday, October 18, 2004 9:00 PM
To: [email-masked]
Cc: Khosravi, Hormuzd M; [email-masked]; Steven Blake (petri-meat);

Jamal,Hormuzd, and Joel,

       Editorial Note:

regards,
Weiming

----- Original Message -----
multipul
of this,
I
platform
multipul
LFB
platform to
operate
on
5
instances.
had to do
it
configuration
ranging,
or
improve our
query/response.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 19 Oct 2004 08:49:40 -0400

Folks,

There are two issues at stake:
- Single class, multiple instances, same data -> multicast solves it.
We have started such discussions in current protocol draft. Lets just
continue along that line.

- Single class, multiple instances, different data -> multicast not
useful.  We know how to achieve this; however, lets shelf it for now
by adding a note to the draft and revisit it after some more
implementation experiences. This should help us progress. Note that i
agree with you Weiming on the need for this. Hormuzd, Steve/Zsolt and
Joel disagree. Thats 4-2. Lets give them time to play with this some
more and they may come to the same conclusion;-> The weigh in is
efficiency between wasted bandwidth vs wasted compute cycles.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Tue, 19 Oct 2004 22:07:04 +0200

I think Zsolt has specified the multicast at LFB Instance-level very 
well. We had some discussions with Joel a while back and such a table 
with pointers from a -virtualID- to a list of LFB Instances was 
considered the way to go.

But the subtle difference betwen Zsolt's proposal and the current 
approach taken in the protocol draft is that the PL-message destination 
ID is the -virtualID-, instead of introducing a new MIID. See Section 5 
point g in the protocol draft.

I would favor the current approach for the following reasons (but I am 
not religious and want to hear other opinions):

1)  -virtualID- must be unique NE-wide. The PL-level addressing IDs are 
by definition unique NE-wide.

2)  Messages addressed to a group of LFBs that spans FE A and B should 
not be delivered to FE C. So a PL-level multicasting is anyway needed . 
Adding an additional MIID would then be redundant.

To cover the case of a list of LFB Instances (reminds me of xcast ;-) we 
can modify the LFBSelect TLV as follows:

main hdr (eg type = config)
|
+--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- one more LFBInstance(s) = target LFB instance(s). 
                  [the size of this TLV tells how long the list is]

But in the case of a multicast, I would simply drop the LFBSelect TLV altogether as it is redundant (the LFB Instances are already selected by the -virtualID-). What do you think ?

Regards,
-Robert

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 20 Oct 2004 12:16:34 +0800

Hi Robert,

>To cover the case of a list of LFB Instances (reminds me of xcast ;-) we can
>                  [the size of this TLV tells how long the list is]
[Weiming]That's just the point I propose. I can see the TLV with three more
types (the types can firther be represented by tags or purely by different TLV
type):
1. List of Instances
The V format is a list of instances,  as InstanceId1, Instance Id 2, ...
Instance Id N, representing to address the insatnces individually
2. A range of Insatnces
The V format is a range of Insatnce, as InsatnceId1, Instance Id2, representing
to addresss insatnces from Id1 to Id2.
3. A combination of above two.
We may use some flags to represent if it is for individual instance or for range
instance description.
[/Weiming]

But in the case of a multicast, I would simply drop the LFBSelect TLV altogether
as it is redundant (the LFB Instances are already selected by the -virtualID-).
What do you think ?
[Weiming] I just think the virtualID scheme and the above explicit ID (real ID)
scheme are all necessary. virtualID multicast can address comparatively
infrequent change LFB groups, while real ID mulitpul addressing can address some
instant and frequent changed LFB groups.

Thank you for the post.

Weiming

Regards,
-Robert

Wang,Weiming wrote:
Hormuzd,

Thanks for reply.

----- Original Message -----

regards
Hormuzd

-----Original Message-----
From: Wang,Weiming [mailto:[email-masked]]
Sent: Monday, October 18, 2004 9:00 PM
To: [email-masked]
Cc: Khosravi, Hormuzd M; [email-masked]; Steven Blake (petri-meat);

Jamal,Hormuzd, and Joel,

       Editorial Note:

regards,
Weiming

----- Original Message -----

cheers,
jamal

Hi Jamal,

multipul

of this,
I

platform

multipul
LFB

platform to

operate
on

5

instances.

had to do
it

configuration

ranging,
or

improve our

protocol.

Best regards,
Weiming

     |        |
     |        |

----- Original Message -----

query/response.

cheers,
jamal

---

From: Steven Blake <[email-masked]>
Date: Thu, 21 Oct 2004 15:00:17 -0400

> considered the way to go.

Agreed.

> approach taken in the protocol draft is that the PL-message
> destination ID is the -virtualID-, instead of introducing a new MIID.
> See Section 5 point g in the protocol draft.
> 
> 1)  -virtualID- must be unique NE-wide. The PL-level addressing IDs
> are by definition unique NE-wide.

Agreed.

> not be delivered to FE C. So a PL-level multicasting is anyway needed
> . Adding an additional MIID would then be redundant.

Eliminating the MIID (or any LFB instance ID) from these messages would
be a very bad layering violation.  We need the PL-level multicast to
scope the message delivery to FEs A & B, but not C (in fact, for
efficiency, we need the multicast FEID to map to a TML "multicast"
group).  I wouldn't suggest mixing in any LFB class/instance ID
semantics into the FEID beyond that.

LFBclass/instance ID multicasting is still needed primarily for scoping
messages to instances of a class on multiple FEs that need to share a
configuration (e.g., global prefix/nexthop table updates).
Since we have assumed that the FE assigns LFB instance IDs, the CE
cannot normally coordinate LFB instance ID assignment between FEs such
that a single PL message addressed to a FE multicast group will be
accepted by multiple LFB instances.  But if we introduce MIIDs which are
assigned by the CE, then the CE can achieve the coordination.

So for the canonical case of being able to multicast routing updates to
multiple FEs, we would need both a PL-level multicast FEID, and a
LFBselect TLV-level mulicast LFB instance ID (MIID).

> To cover the case of a list of LFB Instances (reminds me of xcast ;-)
> we can modify the LFBSelect TLV as follows:
> main hdr (eg type = config)|
> +--- T = LFBselect
>      |        |

I'm not sure this is needed.  If we have multiple LFB instances of a
certain class on an FE sharing configuration data, I would like to see
that explicitly represented in the model (a todo from the August IETF
that I haven't followed through on yet), rather than xcast'ing config
messages.

Regards,

// Steve

---

From: Robert Haas <[email-masked]>
Date: Thu, 21 Oct 2004 22:16:21 +0200

Steve,

>assigned by the CE, then the CE can achieve the coordination.
Let me disuss this with a more detailed example. Suppose instances LFBx1 
and LFBx2 in FE x and LFBy1 in FE y must be configured with the same values.

With the "layer-breaking" model, the CE assigns a mcast ID m to which FE 
x and FE y listen. FE x has a table with an entry (m, {LFBx1, LFBx2}), 
and FE y an entry (m, {LFBy1}).

With Zsolt's model, the CE assigns a mcast ID m to which FE x and FE y 
listen. The CE also defines an MIID M. FE x has a table with an entry 
(m) and FE y an entry (m) (basically, the groups those FEs belong to). 
Then FE x has another table (M, {LFBx1, LFBx2}), and FE y (M, {LFBy1}).

I do agree that in your model, if you wanted to address another set of 
LFBs, say LFBx3 in FE x and LFBy2 and LFBy3 in FE y, then the same mcast 
id m could be used, and you would simply define another M'. The tables 
would be in FE x (M', {LFBx3}) and in FE y (M',{LFBy2, LFBy3}).

Now, even though we have way enough ~2^30 mcast IDs, I understand why 
you favor your approach. Note that in the current draft, this was stated 
as a possiblity (but instead of specifying a -virtualID-, I wrote VPN 
ID, quite the same idea).

Do you think we should explicitely forbid the "layer-breaking" option, 
or could we use both ?

Regards,

---

From: Steven Blake <[email-masked]>
Date: Thu, 21 Oct 2004 16:27:53 -0400

On Thu, 2004-10-21 at 16:16, Robert Haas wrote:

> Let me disuss this with a more detailed example. Suppose instances
> LFBx1 and LFBx2 in FE x and LFBy1 in FE y must be configured with the
> same values.
> 
> With the "layer-breaking" model, the CE assigns a mcast ID m to which
> FE x and FE y listen. FE x has a table with an entry (m, {LFBx1,
> LFBx2}), and FE y an entry (m, {LFBy1}).
> 

Right.

> LFBs, say LFBx3 in FE x and LFBy2 and LFBy3 in FE y, then the same
> mcast id m could be used, and you would simply define another M'. The
> tables would be in FE x (M', {LFBx3}) and in FE y (M',{LFBy2, LFBy3}).
> 
> you favor your approach. Note that in the current draft, this was
> stated as a possiblity (but instead of specifying a -virtualID-, I
> wrote VPN ID, quite the same idea).
> 

Yes.  I consider it analogous to mixing IP addresses and ports.  It
requires a special case in the message parser, and it just doesn't look
clean.

Note that I don't see much use in needing to map a single LFB instance
ID (MIID) to multiple instance IDs on a single ID; i.e., I don't see the
need for multicast within the FE.  What is really needed is a
CE-assigned LFB instance ID alias that can be used on many FEs to allow
coordination of multicast table updates.

Regards,

// Steve

---

From: Robert Haas <[email-masked]>
Date: Thu, 21 Oct 2004 22:42:37 +0200

>requires a special case in the message parser, and it just doesn't look

As we don't mix layers, you could have the following scenario: MIID M 
"contains" LFBx1, LFBy1, LFBz1 (on FEs x, y, z).
But mcast ID m only spans FE x and FE y.

So a PL message addressed to mcast ID m, and MIID M, would only act on 
LFBx1 and LFBy1.

Or do you want to require that messages to MIID m MUST go to a mcastID 
(m or sth else) that spans at least FEs x and y ? This would be a layer 
violation too, no ?

>coordination of multicast table updates.
I agree, but Zsolt example, if I recall well, included some level of 
intra-LFB multicasting.

Regards,

---

From: Steven Blake <[email-masked]>
Date: Thu, 21 Oct 2004 16:47:42 -0400

> ID (MIID) to multiple instance IDs on a single ID; i.e., I don't see the
                                                 ^FE

BTW, Wieming's address always bounces when I respond to these threads.

// Steve

---

From: Steven Blake <[email-masked]>
Date: Thu, 21 Oct 2004 17:23:15 -0400

> "contains" LFBx1, LFBy1, LFBz1 (on FEs x, y, z).

I would rephrase it differently.  MIID M could be configured
individually on FEs x/y/z by the CE to alias to LFBx1, LFBy1, and LFBz1.

Right.

> (m or sth else) that spans at least FEs x and y ? This would be a
> layer violation too, no ?

I don't see any reason to require it in the protocol, but I also don't
see much reason to use it any other way.

> I agree, but Zsolt example, if I recall well, included some level of

I think it did.  I still don't think it is very useful, since I think
there is a better alternative for intra-FE/inter-LFB state sharing, but
it doesn't cost much to support it either.

Regards,

// Steve

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 22 Oct 2004 10:29:24 +0800

----- Original Message -----
From: "Steven Blake" <[email-masked]>
> that I haven't followed through on yet), rather than xcast'ing config
I can not catch any idea on how a model can do this, could you present more on
this?

Thanks.
Weiming