Subject: framework v13 uploaded to IETF

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 14 Jan 2004 10:40:47 -0800

Hi, all --

This new version of framework incorporated the most recent comments from Avri, Jamal and others in the list. Below is a detailed log of the changes. There are numerous clarification and corrections, but no substantial change in the technical content.

This revision is uploaded to IETF and we feel ready to go RFC. 

Lily

 <<draft-ietf-forces-framework-13.txt>> 

-------------------------- summary of changes in v13 --------------------------------------------

#1) Section 1 Dfinition:
[Comment/Reason for change] To clarify that association is a per CE-FE concept.
[old]
        Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element.
            
[new]
        Pre-association Phase - The period of time during which an FE Manager (see below) and a CE Manager (see below) are determining whether an FE and a CE should be part of the same network element.     It is possible for some elements of the NE to be in pre-association 
        phase while other elements are in the post-association phase.

#2) Section 3. Achitecture
[Comment/Reason for change] To avoid the misconception that association is a NE system wide concept.
[deleted] 
        There is no defined role for FE Manager and CE Manager in post-association phase, thus these logical components are not considered part of the ForCES NE. 

3.2 at the end of 1st paragraph:
[Comment/Reason for change] clarify the impact of FE virtualization.
[old]
        However, if FE virtualization results in dynamic resource change on FE during post-association phase, the FE model needs to be able to report such capability and the Protocol needs to be able to inform the CE of such change via asynchronous messages (see [3], Section 5, requirement #6).
[new]
        However, if FE virtualization results in resource change taken from an existing FE (already participating in ForCES post-association phase), the ForCES Protocol needs to be able to inform the CE of such change via asynchronous messages (see [3], Section 5, requirement #6).

#3) 3.2 at the end of the 2nd paragraph
[Comment/Reason for change] To point out the behavior issue of FE accepting commands from multiple CEs.
[add] Unless otherwise configured or determined by a ForCEs Protocol exchange,       each FE will process authorized incoming commands directed at it as it        receives them on a first come first serve basis.  

#4) 4.1 Pre_association Phase
[Comment/Reason for change] same as #1)
[old]
        Pre-association phase is the period of time during which an FE Manager and a CE Manager are determining which FE and CE should be part of the same network element.  

[new]
        Pre-association phase is the period of time during which an FE Manager and a CE Manager are determining whether an FE and a CE should be part of the same network element.  

#5) 4.1.1 Fl Reference Point
[Comment/Reason for change] same as #1)
[old]
        CE managers and FE managers may communicate across the Fl reference point in the pre-association phase in order to determine which CEs and FEs should communicate with each other.  
[new]
        CE managers and FE managers may communicate across the Fl reference point in the pre-association phase in order to determine whether an individual CE and FE, or a set of CEs and FEs should be associated.  

#6) 4.2.2 Figure 9
[Comment/Reason for change] inter-FE topology exchange is optional in the protocol.
deleted the inter-FE topology msg exchange.
at the beginning of last paragraph:
[old]
        After the successful security handshake, the FE needs to inform the CE of its own capability and its topology in relation to other FEs. 
[new]
        After the successful security handshake, the FE needs to inform the CE of its own capability and optionally its topology in relation to other FEs. 

#7) 4.2.2: end of last paragraph:
[Comment/Reason for change] more accurate wording.
[old]
        Once FE starts accepting packets for processing, we say the association of this FE with its CE is now established.  From then on, the CE and FE enter steady-state communication.
[new]
        Once the necessary initial information is exchanged, the process of association is completed.  Packet processing and forwarding at the FE cannot begin until association is established.  

#8) 4.2.5 FE Proxy
[Comment/Reason for change] Clarify that FE Proxy terminates ForCES itself.
[old]
        In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE.  ... It is also possible that one proxy act on behalf of multiple physical FEs.
[new] 
        In the case where a physical FE cannot implement (e.g., due to the lack of a general purpose CPU) the ForCES protocol directly, a proxy FE can be used to terminate the Fp reference point instead of the physical FE.  ... It is also possible that one proxy act on behalf of multiple physical FEs.

#9) 4.3 Association Re-establishment
[Comment/Reason for change] same as #1).
[old]
        When an FE leaves or joins an existing NE that is already in post-association phase, the CE needs to be aware of the impact on FE topology and deals with the change accordingly.
[new]
        When an FE leaves or joins an existing NE that is already in operation, the CE needs to be aware of the impact on FE topology and deals with the change accordingly.

#9.1) Section 7 Acknowledgement (updated)

#9.5) Merged the paragraph in old section 8.2.1 to the beginning of section 8 as part of the introduction. Following sections readjusted accordingly.

#10) 8.1.4 Attack during Fail Over
[Comment/Reason for change] Better wording.
[old]
        Threat: ... A malicious node can take over as CE-B if such trusted relationship is not established during the fail-over. 
[new]
        A malicious node can take over as CE-B if such trusted relationship has not been established prior or during the fail-over. 

#11) 8.1.8
[Comment/Reason for change] Remove congestion control.
[old]
        Requirement: Some sort of rate limiting mechanism MUST to be in place at both the FE and CE.  Examples of such mechanisms include explicit rate limiters or congestion control algorithms.  Rate Limiter SHOULD be configured at the FE for each message type that are being received through Fi/F interface.
[new]
        Requirement: Some sort of rate limiting mechanism MUST to be in place at both the FE and CE.  Rate Limiter SHOULD be configured at the FE for each message type that are being received through Fi/F interface.

#12) Section 9/10: references
Adding one more reference for security:
        [18] S. Bellovin, J. Schiller, and C. Kaufman, "Security Mechanisms for the Internet", RFC 3631, December, 2003.
Updated most references to reflect the current status (RFC, or new revision/date)

---

From: "Putzolu, David" <[email-masked]>
Date: Wed, 14 Jan 2004 16:30:48 -0800

All,

This document has received good detailed review and 
the changes made are clarifications and not major
technical changes.  

Please review the change list (included below) and
comment before January 20 if there are any significant 
issues with this document.

Thanks,
David

> -----Original Message-----
> From: Forwarding and Control Element Separation 
> [mailto:[email-masked]] On Behalf Of Yang, Lily L
> Sent: Wednesday, January 14, 2004 10:41 AM
> To: [email-masked]
> Subject: [FORCES] framework v13 uploaded to IETF
> 
> Hi, all --
> 
> This new version of framework incorporated the most recent 
> comments from Avri, Jamal and others in the list. Below is a 
> detailed log of the changes. There are numerous clarification 
> and corrections, but no substantial change in the technical content.
> 
> -------------------------- summary of changes in v13 
> --------------------------------------------
> 
> #1) Section 1 Dfinition:
>         Pre-association Phase - The period of time during 
> which an FE Manager (see below) and a CE Manager (see below) 
> are determining which FE and CE should be part of the same 
> network element.
>             
> [new]
>         Pre-association Phase - The period of time during 
> which an FE Manager (see below) and a CE Manager (see below) 
> are determining whether an FE and a CE should be part of the 
> same network element.     It is possible for some elements of 
> the NE to be in pre-association 
>         There is no defined role for FE Manager and CE 
> Manager in post-association phase, thus these logical 
> components are not considered part of the ForCES NE. 
> 
>         However, if FE virtualization results in dynamic 
> resource change on FE during post-association phase, the FE 
> model needs to be able to report such capability and the 
> Protocol needs to be able to inform the CE of such change via 
> asynchronous messages (see [3], Section 5, requirement #6).
> [new]
>         However, if FE virtualization results in resource 
> change taken from an existing FE (already participating in 
> ForCES post-association phase), the ForCES Protocol needs to 
> be able to inform the CE of such change via asynchronous 
> messages (see [3], Section 5, requirement #6).
> 
> 
> [Comment/Reason for change] To point out the behavior issue 
> of FE accepting commands from multiple CEs.
> [add] Unless otherwise configured or determined by a ForCEs 
> Protocol exchange,       each FE will process authorized 
> incoming commands directed at it as it        receives them 
> on a first come first serve basis.  
> 
>         Pre-association phase is the period of time during 
> which an FE Manager and a CE Manager are determining which FE 
> and CE should be part of the same network element.  
> 
> [new]
>         Pre-association phase is the period of time during 
> which an FE Manager and a CE Manager are determining whether 
> an FE and a CE should be part of the same network element.  
> 
>         CE managers and FE managers may communicate across 
> the Fl reference point in the pre-association phase in order 
> to determine which CEs and FEs should communicate with each other.  
> [new]
>         CE managers and FE managers may communicate across 
> the Fl reference point in the pre-association phase in order 
> to determine whether an individual CE and FE, or a set of CEs 
> and FEs should be associated.  
> 
> #6) 4.2.2 Figure 9
>         After the successful security handshake, the FE needs 
> to inform the CE of its own capability and its topology in 
> relation to other FEs. 
> [new]
>         After the successful security handshake, the FE needs 
> to inform the CE of its own capability and optionally its 
> topology in relation to other FEs. 
> 
>         Once FE starts accepting packets for processing, we 
> say the association of this FE with its CE is now 
> established.  From then on, the CE and FE enter steady-state 
> communication.
> [new]
>         Once the necessary initial information is exchanged, 
> the process of association is completed.  Packet processing 
> and forwarding at the FE cannot begin until association is 
> established.  
> 
> #8) 4.2.5 FE Proxy
>         In the case where a physical FE cannot implement 
> (e.g., due to the lack of a general purpose CPU) the ForCES 
> protocol directly, a proxy FE can be used to terminate the Fp 
> reference point instead of the physical FE.  ... It is also 
> possible that one proxy act on behalf of multiple physical FEs.
> [new] 
>         In the case where a physical FE cannot implement 
> (e.g., due to the lack of a general purpose CPU) the ForCES 
> protocol directly, a proxy FE can be used to terminate the Fp 
> reference point instead of the physical FE.  ... It is also 
> possible that one proxy act on behalf of multiple physical FEs.
> 
>         When an FE leaves or joins an existing NE that is 
> already in post-association phase, the CE needs to be aware 
> of the impact on FE topology and deals with the change accordingly.
> [new]
>         When an FE leaves or joins an existing NE that is 
> already in operation, the CE needs to be aware of the impact 
> on FE topology and deals with the change accordingly.
> 
> #9.5) Merged the paragraph in old section 8.2.1 to the 
> beginning of section 8 as part of the introduction. Following 
> sections readjusted accordingly.
> 
>         Threat: ... A malicious node can take over as CE-B if 
> such trusted relationship is not established during the fail-over. 
> [new]
>         A malicious node can take over as CE-B if such 
> trusted relationship has not been established prior or during 
> the fail-over. 
> 
> #11) 8.1.8
>         Requirement: Some sort of rate limiting mechanism 
> MUST to be in place at both the FE and CE.  Examples of such 
> mechanisms include explicit rate limiters or congestion 
> control algorithms.  Rate Limiter SHOULD be configured at the 
> FE for each message type that are being received through Fi/F 
> interface.
> [new]
>         Requirement: Some sort of rate limiting mechanism 
> MUST to be in place at both the FE and CE.  Rate Limiter 
> SHOULD be configured at the FE for each message type that are 
> being received through Fi/F interface.
> 
>         [18] S. Bellovin, J. Schiller, and C. Kaufman, 
> "Security Mechanisms for the Internet", RFC 3631, December, 2003.

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 15 Jan 2004 16:47:50 -0800

Lily et al.

This looks pretty good to me for final submission.

Regards
Hormuzd

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

Hi, all --

This new version of framework incorporated the most recent comments from
Avri, Jamal and others in the list. Below is a detailed log of the
changes. There are numerous clarification and corrections, but no
substantial change in the technical content.

Lily

#1) Section 1 Dfinition:
[Comment/Reason for change] To clarify that association is a per CE-FE
concept.
[old]
        Pre-association Phase - The period of time during which an FE
Manager (see below) and a CE Manager (see below) are determining which
FE and CE should be part of the same network element.
            
[new]
        Pre-association Phase - The period of time during which an FE
Manager (see below) and a CE Manager (see below) are determining whether
an FE and a CE should be part of the same network element.     It is
possible for some elements of the NE to be in pre-association 
        phase while other elements are in the post-association phase.

#2) Section 3. Achitecture
[Comment/Reason for change] To avoid the misconception that association
is a NE system wide concept.
[deleted] 
        There is no defined role for FE Manager and CE Manager in
post-association phase, thus these logical components are not considered
part of the ForCES NE. 

3.2 at the end of 1st paragraph:
[Comment/Reason for change] clarify the impact of FE virtualization.
[old]
        However, if FE virtualization results in dynamic resource change
on FE during post-association phase, the FE model needs to be able to
report such capability and the Protocol needs to be able to inform the
CE of such change via asynchronous messages (see [3], Section 5,
requirement #6).
[new]
        However, if FE virtualization results in resource change taken
from an existing FE (already participating in ForCES post-association
phase), the ForCES Protocol needs to be able to inform the CE of such
change via asynchronous messages (see [3], Section 5, requirement #6).

#3) 3.2 at the end of the 2nd paragraph
[Comment/Reason for change] To point out the behavior issue of FE
accepting commands from multiple CEs.
[add] Unless otherwise configured or determined by a ForCEs Protocol
exchange,       each FE will process authorized incoming commands
directed at it as it        receives them on a first come first serve
basis.  

#4) 4.1 Pre_association Phase
[Comment/Reason for change] same as #1)
[old]
        Pre-association phase is the period of time during which an FE
Manager and a CE Manager are determining which FE and CE should be part
of the same network element.  

[new]
        Pre-association phase is the period of time during which an FE
Manager and a CE Manager are determining whether an FE and a CE should
be part of the same network element.  

#5) 4.1.1 Fl Reference Point
[Comment/Reason for change] same as #1)
[old]
        CE managers and FE managers may communicate across the Fl
reference point in the pre-association phase in order to determine which
CEs and FEs should communicate with each other.  
[new]
        CE managers and FE managers may communicate across the Fl
reference point in the pre-association phase in order to determine
whether an individual CE and FE, or a set of CEs and FEs should be
associated.  

#6) 4.2.2 Figure 9
[Comment/Reason for change] inter-FE topology exchange is optional in
the protocol.
deleted the inter-FE topology msg exchange.
at the beginning of last paragraph:
[old]
        After the successful security handshake, the FE needs to inform
the CE of its own capability and its topology in relation to other FEs. 
[new]
        After the successful security handshake, the FE needs to inform
the CE of its own capability and optionally its topology in relation to
other FEs. 

#7) 4.2.2: end of last paragraph:
[Comment/Reason for change] more accurate wording.
[old]
        Once FE starts accepting packets for processing, we say the
association of this FE with its CE is now established.  From then on,
the CE and FE enter steady-state communication.
[new]
        Once the necessary initial information is exchanged, the process
of association is completed.  Packet processing and forwarding at the FE
cannot begin until association is established.  

#8) 4.2.5 FE Proxy
[Comment/Reason for change] Clarify that FE Proxy terminates ForCES
itself.
[old]
        In the case where a physical FE cannot implement (e.g., due to
the lack of a general purpose CPU) the ForCES protocol directly, a proxy
FE can be used to terminate the Fp reference point instead of the
physical FE.  ... It is also possible that one proxy act on behalf of
multiple physical FEs.
[new] 
        In the case where a physical FE cannot implement (e.g., due to
the lack of a general purpose CPU) the ForCES protocol directly, a proxy
FE can be used to terminate the Fp reference point instead of the
physical FE.  ... It is also possible that one proxy act on behalf of
multiple physical FEs.

#9) 4.3 Association Re-establishment
[Comment/Reason for change] same as #1).
[old]
        When an FE leaves or joins an existing NE that is already in
post-association phase, the CE needs to be aware of the impact on FE
topology and deals with the change accordingly.
[new]
        When an FE leaves or joins an existing NE that is already in
operation, the CE needs to be aware of the impact on FE topology and
deals with the change accordingly.

#9.5) Merged the paragraph in old section 8.2.1 to the beginning of
section 8 as part of the introduction. Following sections readjusted
accordingly.

#10) 8.1.4 Attack during Fail Over
[Comment/Reason for change] Better wording.
[old]
        Threat: ... A malicious node can take over as CE-B if such
trusted relationship is not established during the fail-over. 
[new]
        A malicious node can take over as CE-B if such trusted
relationship has not been established prior or during the fail-over. 

#11) 8.1.8
[Comment/Reason for change] Remove congestion control.
[old]
        Requirement: Some sort of rate limiting mechanism MUST to be in
place at both the FE and CE.  Examples of such mechanisms include
explicit rate limiters or congestion control algorithms.  Rate Limiter
SHOULD be configured at the FE for each message type that are being
received through Fi/F interface.
[new]
        Requirement: Some sort of rate limiting mechanism MUST to be in
place at both the FE and CE.  Rate Limiter SHOULD be configured at the
FE for each message type that are being received through Fi/F interface.

#12) Section 9/10: references
Adding one more reference for security:
        [18] S. Bellovin, J. Schiller, and C. Kaufman, "Security
Mechanisms for the Internet", RFC 3631, December, 2003.
Updated most references to reflect the current status (RFC, or new
revision/date)

---

From: Alex Audu <[email-masked]>
Date: Fri, 16 Jan 2004 10:10:31 -0600

Hi Lily,

Is there supposed to be a change in the FE Proxy section? I can see the
difference
between the [old] and the [new] text.   Sorry for the late notice.

Regards,
Alex.

#8) 4.2.5 FE Proxy

---

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 16 Jan 2004 09:22:36 -0800

Oops! I knew that it would be a miracle if all those cut and paste would always land them in the right spots ...
I am also impressed that somebody actually read the list carefully! Good catch!

Here is what it is supposed to be:

[old]
In the case where a physical FE cannot implement (e.g., due to 
the lack of a general purpose CPU) the ForCES protocol 
directly, a proxy FE can be used in the middle of Fp reference point  
... In such an implementation, the combination of the proxy and the 
physical FE becomes one logical FE entity. 
  
[new]
In the case where a physical FE cannot implement (e.g., due to
the lack of a general purpose CPU) the ForCES protocol 
directly, a proxy FE can be used to terminate the Fp reference point instead of the
physical FE.  ... In such an implementation, the combination of the proxy 
and the physical FE becomes one logical FE entity. 
It is also possible that one proxy act on behalf of
multiple physical FEs.
 
Lily

> [mailto:[email-masked]]On Behalf Of Alex Audu
> Sent: Friday, January 16, 2004 8:11 AM
> Subject: Re: framework v13 uploaded to IETF
> 
> 
> Hi Lily,
>

---

From: "Putzolu, David" <[email-masked]>
Date: Wed, 21 Jan 2004 15:36:34 -0800

All,

The revised Framework has not received further comment
and thus is now being forwarded back to the IESG for 
final review.

Cheers,
David

> [mailto:[email-masked]] On Behalf Of Putzolu, David
> Sent: Wednesday, January 14, 2004 4:31 PM
> Subject: Re: [FORCES] framework v13 uploaded to IETF
> 
> All,
> 
> This document has received good detailed review and the 
> changes made are clarifications and not major technical changes.  
> 
> Please review the change list (included below) and comment 
> before January 20 if there are any significant issues with 
> this document.
> 
> Thanks,
> David
> 
> 
> > This new version of framework incorporated the most recent comments 
> > from Avri, Jamal and others in the list. Below is a detailed log of 
> > the changes. There are numerous clarification and 
> corrections, but no 
> which an FE 
> which an FE 
> > Manager (see below) and a CE Manager (see below) are determining 
> > whether an FE and a CE should be part of the
> > post-association phase, thus these logical components are not 
> > considered part of the ForCES NE.
> > 
> >         However, if FE virtualization results in dynamic resource 
> > change on FE during post-association phase, the FE model 
> needs to be 
> > able to report such capability and the Protocol needs to be able to 
> > inform the CE of such change via asynchronous messages (see [3], 
> > Section 5, requirement #6).
> > [new]
> change taken