Subject: Re: [sfc] Solicit comments and suggestions to Rendered Service Path control Mechanism

From: "Ken Gray (kegray)" <[email-masked]>
Date: Mon, 3 Nov 2014 14:32:18 +0000

For starters, it seems as if the authors link two statements as
non-debatable fact, when they really Š are debatable:

Section 4.3 "   For the approach 1) above, all the forwarding nodes, e.g.
SFFs, need
   to look up the SFF-sequence or SFF-SF-sequence for every packet to
   determine the next hop. For large flows, i.e. large number of
   packets in the flow, the processing of interpreting the SFF-
   sequence/SFF-SF-sequence is repetitive and can be resource
Intensive."

One would suspect the above is a bad implementation of a forwarder Š

Section 6.1 "  As mentioned in the previous section, encoding exact RSP
path
  requiring all involved nodes to interpret SFF-SF-sequence in each
  packet to establish runtime forwarding policy, which can be resource
  intensive. This approach is not optimal when the RSP doesn't change
  very frequently, as in minutes or hours."

Not a fact just because it was stated above.  You always have to resolve a
next hop if you're a forwarder, regardless of the methodology that you
learn (or maintain) the next hop. How "expensive" this is would be an
implementation detail.  Further, it doesn't really appear as if the
authors are offering an alternative, so these are (IMO) gratuitous
statements that don't have a lot to do with the proposed framework.

For the Global restoration sections (section 6):

Why doesn't updating the classifier at the headend work for global
restoration?

Further, the line "This method won't cause any contention issue among all
the involved
  nodes." in section 6.1 is confusing.  What does it refer to?

Section 6.2 is a boondoggle (we don't need another signaling protocol,
IMHO), as is the idea of having coordinated RSP capabilities between the
classifiers (see - we don't need another signaling protocol).  The SFFs
can be updated without having to maintain their consistency through some
head-end driven state machine.  Changing the SFP on the classifying node
implicitly signals the new path.  Updating the SFFs is an
orchestration/SDN problem.

Section 6.3 is a solvable transaction problem - use NETCONF, use OF with
barrier messages - is coordinated updates of the forwarders your ultimate
concern here?  

BTW (same section), if you have a single NMS node, yeah, you have problems
and restoration of service paths is just one of many.

Which leads us to 6.4, which I think is how most of us imagined that SFC
was supposed to work, but I don't see the need for "until all the involved
SFF nodes complete the installation of the new steering policy for the
path."  Again, is the main point of this whole paper to beware of the
transactional nature of updating the forwarders in the path?

You can completely lose the first paragraph of section 7.  I hope the
authors are not still struggling with the concept of instance anonymity in
load balancing (it seems like you had come to grips with that in your
Local Repair section), because that concept (more than scale) makes it
impossible for the head end to be aware of all instances.

The rest of what you describe is essentially "anycast", IMO.

On 10/27/14 12:21 PM, "Linda Dunbar" <[email-masked]> wrote:

>Rendered Service Path was introduced by draft-ietf-sfc-architecture to
>represent a constrained specification of where packets using a certain
>service chain must go.
>
>This draft proposes a framework to represent RSP and restoration scheme
>when some functions on a RSP fails (or to be replaced by new ones).
>
>We are looking for comments and suggestions.
>
>Linda & Andy
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, October 27, 2014 11:01 AM
>To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar
>Subject: New Version Notification for draft-dunbar-sfc-path-control-00.txt
>
>
>A new version of I-D, draft-dunbar-sfc-path-control-00.txt
>has been successfully submitted by Linda Dunbar and posted to the IETF
>repository.
>
>Name:		draft-dunbar-sfc-path-control
>Revision:	00
>Title:		Framework for Service Function Path Control
>Document date:	2014-10-24
>Group:		Individual Submission
>Pages:		15
>URL:            
>http://www.ietf.org/internet-drafts/draft-dunbar-sfc-path-control-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-dunbar-sfc-path-control/
>Htmlized:       
>http://tools.ietf.org/html/draft-dunbar-sfc-path-control-00
>
>
>Abstract:
>   This draft describes the framework of protection and restoration of
>   Service Function Path when some service functions on the path fail
>   or need to be replaced.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 4 Nov 2014 23:47:16 +0000

Ken, 

Thanks for your comments. Replies are inserted below:

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]] 
Sent: Monday, November 03, 2014 8:32 AM
To: Linda Dunbar; [email-masked]
Subject: Re: [sfc] Solicit comments and suggestions to Rendered Service Path control Mechanism

   sequence/SFF-SF-sequence is repetitive and can be resource Intensive."

[Linda] Yes the wording needs some enhancement. The intent is to say if the forwarding nodes forward traffic based on the SFF-SF-sequence encoded in the packets, the "lookup" entry is the "SFF-SF-sequence" in the packet. Special consideration is needed. 

What do you think of changing to the following text:

 "The approach 1) above is basically "two dimensional" Source Routing, not only with explicit SFF nodes on the path, but also with exact SF sequence by each SFF node. For large flows, i.e. large number of packets in the flow, repeating the SFF-sequence/SFF-SF-sequence encoding in all packets can waste bandwidth, which is not suitable for environment where bandwidth is limited." 

Section 6.1 "  As mentioned in the previous section, encoding exact RSP path

Not a fact just because it was stated above.  You always have to resolve a next hop if you're a forwarder, regardless of the methodology that you learn (or maintain) the next hop.

[Linda] Yes, you can use "Source Routing" as developed by SPRING. But most of today deployed routers use pre-established "forwarding table" for next hop. 

 How "expensive" this is would be an implementation detail.  Further, it doesn't really appear as if the authors are offering an alternative, so these are (IMO) gratuitous statements that don't have a lot to do with the proposed framework.
[Linda] How about changing the wording to the following? 
" As mentioned in the previous section, encoding exact RSP path in every packet has the benefit and the issues of source routing. This approach may not be optimal when the RSP doesn't change very frequently, as in minutes or hours, or bandwidth is limited."

Why doesn't updating the classifier at the headend work for global restoration?
[Linda] Yes, one method is to escalate fault to the head end classifier node. Another method is regional repair, as MPLS's FRR. 

Further, the line "This method won't cause any contention issue among all the involved
  nodes." in section 6.1 is confusing.  What does it refer to?

[Linda] it means " Encoding the exact SFF-SF-sequence in every packet won't cause any contention issue among all the involved nodes when changes occur."

Section 6.2 is a boondoggle (we don't need another signaling protocol, IMHO), as is the idea of having coordinated RSP capabilities between the classifiers (see - we don't need another signaling protocol).  The SFFs can be updated without having to maintain their consistency through some head-end driven state machine.  Changing the SFP on the classifying node implicitly signals the new path.  Updating the SFFs is an orchestration/SDN problem.
[Linda] This section is NOT to introduce another signaling protocol. This section is to describe using MPLS RSVP to establish the RSP. We will improve the wording to reflect this. 

Section 6.3 is a solvable transaction problem - use NETCONF, use OF with barrier messages - is coordinated updates of the forwarders your ultimate concern here?  

BTW (same section), if you have a single NMS node, yeah, you have problems and restoration of service paths is just one of many.

Which leads us to 6.4, which I think is how most of us imagined that SFC was supposed to work, but I don't see the need for "until all the involved SFF nodes complete the installation of the new steering policy for the path."  Again, is the main point of this whole paper to beware of the transactional nature of updating the forwarders in the path?

[Linda] Glad to see that is "most of us imaged what SFC was supposed to work". The main point is to describe an approach with "Source routing" until all the SFF nodes nailed up the proper connections to SF nodes and next hop SFF node. 

You can completely lose the first paragraph of section 7.  I hope the authors are not still struggling with the concept of instance anonymity in load balancing (it seems like you had come to grips with that in your Local Repair section), because that concept (more than scale) makes it impossible for the head end to be aware of all instances.

[Linda] This is not about multiple same-function "instances" attached to one SFF node. Those SFICs can be handled by the SFF via local load balance as described in SFC-Arch. This section is to describe scenario of the Figure in Section 6. 

[Linda] How? 

Thank you very much. 

Linda

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Sat, 8 Nov 2014 14:41:01 +0000

Linda, I would suggest the authors rework from scratch under the
assumption that commentary on the efficacy of the SFC header in general be
made separately on the separate header draft and advocacy for the use of
the transport header also be contained therein.

In that light, we could discuss my doubts about the scalability of using
RSVP for pathing at host-host scale or even edge-edge scales and how
apparently ignorant that approach might be of the potential scale of host
involvement as head-end and encapsulator of the flow (and thus doing RSVP
signaling).  There too, we can discuss the potential limitations of using
SR in lieu of the SFP part of the header.

If they remove the conflation of their document with the extant header
document (ostensibly this is a draft about HA as the Abstract indicates)
and work from the assumption that the header exists and that the
transport, regardless of type has it's own HA ramifications that don't
need to be enumerated (in fact, they can use this sentence as a summary).
Thus they can potentially create an informative document that might
suggest mediation of the (obvious) global repair scenario of changing the
classifier-to-chain mapping at the headend of the service overlay (in
light of their concerns about it) or alternatives to anycast (if they have
any) as the alternative to (the obvious) anycast methods for local repair.

IMHO, both global and local repair of the service overlay should proceed
without the direct requirement of involvement of transport, since one of
the fundamental benefits of creating a service overlay (really ANY
overlay) is that it is decoupled from and indirectly benefits from changes
in the transport that provide HA (without having to be changed itself).
Since the current status quo is that we have no service overlay, and we
are ostensibly here to fill that gap, we need really take no action if we
want the transport header to subsume that role.

Fundamentally, it's time the AD(s) stepped in and decide how much longer
this "discussion" derails work in this WG.   What are we here for?  If you
want (and this is directed FAR beyond Linda personally) to keep horking
with transport ("transport overlay CAN BE service overlay, let's discuss")
to fill this role (service overlay), go to BESS or PALS, initiate your
effort there and be done with it (and I will happily argue the merits
THERE) - if the AD(s) support that!  We can waste time THERE.  I thought
that was the purpose of the re-organization.  Here we have another WG
being dragged into the hell of "MPLS is overlay" (NVO3 should have been a
learning experience - we should start from the premise of "yes, there is
MPLS, please see BESS/PALS - what if there isn't?" instead of constantly
"forking" anything that explores the world beyond).

On 11/4/14 6:47 PM, "Linda Dunbar" <[email-masked]> wrote:

>[Linda] Yes the wording needs some enhancement. The intent is to say if
>the forwarding nodes forward traffic based on the SFF-SF-sequence encoded
>in the packets, the "lookup" entry is the "SFF-SF-sequence" in the
>packet. Special consideration is needed.
>
> "The approach 1) above is basically "two dimensional" Source Routing,
>not only with explicit SFF nodes on the path, but also with exact SF
>sequence by each SFF node. For large flows, i.e. large number of packets
>in the flow, repeating the SFF-sequence/SFF-SF-sequence encoding in all
>packets can waste bandwidth, which is not suitable for environment where
>bandwidth is limited."
>
>
>Not a fact just because it was stated above.  You always have to resolve
>a next hop if you're a forwarder, regardless of the methodology that you
>learn (or maintain) the next hop.
>
>[Linda] Yes, you can use "Source Routing" as developed by SPRING. But
>most of today deployed routers use pre-established "forwarding table" for
>next hop. 
>
> How "expensive" this is would be an implementation detail.  Further, it
>doesn't really appear as if the authors are offering an alternative, so
>these are (IMO) gratuitous statements that don't have a lot to do with
>the proposed framework.
>" As mentioned in the previous section, encoding exact RSP path in every
>packet has the benefit and the issues of source routing. This approach
>may not be optimal when the RSP doesn't change very frequently, as in
>minutes or hours, or bandwidth is limited."
>
>
>[Linda] Yes, one method is to escalate fault to the head end classifier
>node. Another method is regional repair, as MPLS's FRR.
>
>
>[Linda] it means " Encoding the exact SFF-SF-sequence in every packet
>won't cause any contention issue among all the involved nodes when
>changes occur."
>
>[Linda] This section is NOT to introduce another signaling protocol. This
>section is to describe using MPLS RSVP to establish the RSP. We will
>improve the wording to reflect this.
>
>
>BTW (same section), if you have a single NMS node, yeah, you have
>problems and restoration of service paths is just one of many.
>
>was supposed to work, but I don't see the need for "until all the
>involved SFF nodes complete the installation of the new steering policy
>for the path."  Again, is the main point of this whole paper to beware of
>the transactional nature of updating the forwarders in the path?
>
>[Linda] Glad to see that is "most of us imaged what SFC was supposed to
>work". The main point is to describe an approach with "Source routing"
>until all the SFF nodes nailed up the proper connections to SF nodes and
>next hop SFF node.
>
>
>authors are not still struggling with the concept of instance anonymity
>in load balancing (it seems like you had come to grips with that in your
>[Linda] This is not about multiple same-function "instances" attached to
>one SFF node. Those SFICs can be handled by the SFF via local load
>balance as described in SFC-Arch. This section is to describe scenario of
>the Figure in Section 6.
>
>
>