Subject: [forces] Item #14: ForCES Topology LFB

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 14 Jan 2013 08:13:24 -0500

What it is
----------
Mechanism to provide topology of a ForCES NE that operates
in the ForCES post-association phase. Described as an LFB with
a topology database.
Essentially this is a call to revive in some shape or form:
https://tools.ietf.org/html/draft-ietf-forces-discovery-02

Why it is needed
----------------
By providing runtime topology updates to the CE it is feasible
for the CE to optimize certain NE activities, such as
path selection from the ingress to egress FE.
It is also possible to have primary/backup handover by FE without
aid from CE.
Item #3, InterFE LFB would be a beneficiary
Item #7, Northbound interface/Services definition
Item #9, Network virtualization

Please respond whether you:
a) are interested in doing the work
b) will review the work
c) find the work interesting and it should be done in the WG
d) do not think we should do this work

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Mon, 14 Jan 2013 16:39:19 +0200

Greetings to the list,

We think that this is an important addendum to ForCES.
We're very interested in doing the work, we will review and we believe this
should be done within the wg.

Therefore a), b) and c).

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jamal Hadi Salim
> Sent: Monday, January 14, 2013 3:13 PM
> To: [email-masked]
> Subject: [forces] Item #14: ForCES Topology LFB
> 
> What it is
> ----------
> Mechanism to provide topology of a ForCES NE that operates in the
> ForCES post-association phase. Described as an LFB with a topology
> database.
> By providing runtime topology updates to the CE it is feasible for the
> CE to optimize certain NE activities, such as path selection from the
> ingress to egress FE.
> It is also possible to have primary/backup handover by FE without aid
> from CE.
> Item #3, InterFE LFB would be a beneficiary Item #7, Northbound
> interface/Services definition Item #9, Network virtualization
> 
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Joel <[email-masked]>
Date: Mon, 14 Jan 2013 10:52:35 -0500

While itneresting, this seems to me to be a lower priority work item. 
Even if we do nothing, there are a number of mechanisms that a CE can 
use to meet this need already.
Also, depending upon what functions the FEs have, the right answer may 
be different.  (For example, if the FEs all have BFD LFBs, then enabling 
that, waiting a little while, and reading the results probably tells te 
CE the entire intra-NE topology and external adjacencies.  But I would 
not want to mandate BFD on every FE.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 14 Jan 2013 11:58:13 -0500

My thinking is we need at least some "generic" Topology description.
How that information is acquired (BFD, IGP or otherwise) is something we
cant mandate.

For the record: #a-#c.

cheers,
jamal

On Mon, Jan 14, 2013 at 10:52 AM, Joel <[email-masked]> wrote:
> While itneresting, this seems to me to be a lower priority work item. Even
> if we do nothing, there are a number of mechanisms that a CE can use to meet
> this need already.
> Also, depending upon what functions the FEs have, the right answer may be
> different.  (For example, if the FEs all have BFD LFBs, then enabling that,
> waiting a little while, and reading the results probably tells te CE the
> entire intra-NE topology and external adjacencies.  But I would not want to
> mandate BFD on every FE.)
>
> Yours,
> Joel
>
>

---

From: Joel <[email-masked]>
Date: Mon, 14 Jan 2013 12:53:11 -0500

I don't follow.
A generic topology description wold be something that the CE provides 
upwards (a service abstraction LFB).  While useful, that is related to 
northbound operation, not element connectivity discovery.

Put differently, FEs are not supposed to have protocol smarts, except 
via LFBs.  So they can no run a generic topology discovery mechanism, or 
provide generic topology information.  Rather, they can run specific 
protocols, under the control of CEs.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 15 Jan 2013 07:53:24 -0500

On Mon, Jan 14, 2013 at 12:53 PM, Joel <[email-masked]> wrote:
> upwards (a service abstraction LFB).

Agreed it would make a lot more sense (for generic TD)
as a service abstraction.

FEO already has the concept of adjacencies. Maybe we should make
this the simple bootstrapping. Perhaps leave out the discovery part undefined.

cheers,
jamal