Subject: Re: draft-nait-forces-pap-00.txt

From: "Rachid Nait Takourout (QB/LMC)" <[email-masked]>
Date: Fri, 11 Jul 2003 14:03:17 -0400

Hi Alex, 

        Thank you for your comments. I will answer your questions, but first I would like to 
explain some aspects which I should have clarified earlier (sorry...): 
        The two documents about the pre-association phase (pap) protocol and the 
xml modeling are complementary. In fact, the idea behind the first document is to provide 
a simple mechanism to automate and optimize the pap in order to assume the scalabity of the ForCES 
architecture. The Managers are responsible of determining which CEs and FEs should communicate 
with each other, while the CEs are the only ones who decide to accept or reject a bind request 
from a FE. In the ForCES architecture, only Managers have a global vision of the NE state 
and capabilities and we could use this fact to optimize the internal NE behavior. Each 
CE has some particular needs (and restrictions) and the CE Manager becomes aware of 
these through the CE Specification of the CE. 

Correspondingly, the FE Manager knows the FE capabilities (with the FE Model) of each FE. The 
FE Manager could provide to the FEs a pertinent list of CEs  needing their capabilities. 
The system overview  kept by the Managers thus allows to minimize the number of FE bind 
requests (potentially rejected) inside the NE, above all when there is a large number of FEs. 

        Moreover, the pap protocol with the xml models allows to CE Manager to assume the failover 
management inside the Control Plane. To illustrate this, we can imagine that 
3 CEs becomes available inside a NE: 
- CE 1 : its CE Specification indicates that it needs IPv4 forwarding functionality. 
- CE 2 : its CE Specification indicates that it needs DiffServ conditioning functions. 
- CE 3 : its CE Specification indicates that it needs IPv4 forwarding functionality 
         and support the failover mechanisms. 
        The CE Manager could decide to make  CE 3 a backup for CE 1. Of course, 
this example raises the failover support problematic... During the last IETF meeting, Jon 
Maloy presented TIPC ( http://tipc.sourceforge.net ). Even if the user is free to choose 
his underlying communication technology, in my own opinion TIPC provides an interesting 
solution for the failover support. 
        So, the Managers could provide a new valuable feature to the NE: an 'intelligent' 
management of PEs to assume the scalabily of the ForCES architecture. 

About your questions: 
>1) Assuming that CEs and FEs are not up yet, how does the CE or FE 
>    know what manager to send the INIT_CE or INIT_FE message to? 

  In fact, the CE (or FE) Manager needs to have a global identifier mechanism in the 
NE to receive the INIT messages, but this point is highly dependant of the underlying communication 
technology choice. In my own pap protocol implementation, I use TIPC 'port name' (this is 
TIPC terminology, to put it short you can regard  it as a   'well-known'  64-bit port number 
with validity for the whole cluster) which every CE (or FE) must know. 

>2) MODEL message: What does this do? 
  As I said before, the pap protocol uses the PE modeling. The messages of types MODEL just 
send the PE modeling (CE Specification or FE Model) to the Manager. 

>3) Section 6.1 Messages: I am having trouble reconciling the payload 
>    structure defined in section 5.2 with the message payloads in section 6. 
  All the wire coding inside section 6 are just a more detailed decription of the 
'Value' field that we find in the section 5.2. 

        I understand your comment about the manual configuration. But, in the ForCES 
requirements, it is stated that the NE 'must be capable of supporting (i.e., must scale to) 
at least hundreds of FEs'. And, I think that in this case, automatic configuration 
is more practical. 

        I also would like to thank Joel M. Halpern for his comments. As a matter of fact, 
the XML FE Model as I presented is a large tool, which we can use both for the post-association 
and  the pre-association phase. But in the latter case, a subset (the capability 
model) is sufficient. And, the CE Specification was specially designed for the pre-association phase. 

Best Regards 

Rachid Nait Takourout 

-----Message d'origine-----
De : Alex Audu [mailto:[email-masked]]
Envoyé : Wednesday, July 09, 2003 1:18 PM
À : [email-masked]
Objet : Re: draft-nait-forces-pap-00.txt

Hi Rachid,

I am trying to understand your draft a bit better. The Pre-Association
Protocol
provides an automatic discovery of the PEs. I am assuming this discovery is
to
be made by (or made known to) the respective local management (FeMgr, or
CeMgr).

Questions:
1) Assuming that CEs and FEs are not up yet, how does the CE or FE
    know what manager to send the INIT_CE or INIT_FE message to?

2) MODEL message: What does this do?

3) Section 6.1 Messages: I am having trouble reconciling the payload
structure
    defined in section 5.2 with the message payloads in section 6.

General comment:
This is a laudable effort. However, I think you are trying to automate what
comes easily with manual configuration. Having said that, we have to remember

what that manual process entails:  a basic point  is to have a configuration
table
that contains info as to which CE or FE  is to be managed by which CeMgr, or
FeMgr.  The table  could be manually populated. The CEs or FEs read this
table during restore to determine who their manager is. The managers also
read this table to determine what CE or FE they manage.

Regards,
Alex.