Subject: [sfc] draft-quinn-sfc-nsh-05 RSP_ID Role

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 4 Feb 2015 17:24:54 +0000

We have this discussion on RSP_ID, and as I review the NSH(5) proposal  I see:

Since the SPI is an representation of the service path, the lookup
may return more than one possible next-hop within a service path for
a given SF, essentially a series of weighted (equally or otherwise)
overlay links to be used (for load distribution, redundancy or
policy),..

The table example is then :

     +----------------------------------+

     | SPI | SI |   NH        |  Metric |

     +----------------------------------+

     | 10  |  3 | 10.1.1.1    |  1      |

     |     |    | 10.1.1.2    |  1      |

     |     |    |             |         |

     | 20  | 12 | 192.168.1.1 |  1      |

     |     |    | 10.2.2.2    |  1      |

     |     |    |             |         |

     | 30  |  7 | 10.2.2.3    |  10     |

     |     |    | 10.3.3.3    |  5      |

     +----------------------------------+

     (encap type omitted for formatting)

This shows clearly that an SFF can take local forwarding decision based on SPI /SI and its routing table.

However, there is an limitation in proceeding like that when provisioning a chain this way. How can you have 2 SFF
take a coordinated decision for some traffic:  SSFx  forwards to SFx(1) when SFFy forwards to SFy(1) ?

It is not necessarily a load balancing decision here. It can be a decision based some criteria known to the Classifier
(think of the number of information available about a subscriber in a GI LAN).

I can see how an RSP_ID could help here, if we allow such a parameter to be part of the routing table as well.

Nicolas

This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous avez re?u ce message par erreur, merci d'en informer imm?diatement son ?metteur par courrier ?lectronique et d'effacer ce message de votre syst?me. Dans cette hypoth?se, vous n'?tes pas autoris? ? utiliser, copier ce message et/ou en divulguer le contenu ? un tiers. Tout message ?lectronique est susceptible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? au titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?.

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Feb 2015 17:47:39 +0000

Nicolas,

I agree with your analysis that RSP ID is fundamental to the hop-by-hop forwarding and will ultimately be part of a classifier's and SFF's forwarding table.    There are 2 use cases I can foresee, here.   In the first, the fully concrete RSP's are calculated by some sort of central orchestrator.   In this case, it would be necessary for the encapsulation to carry only the RSP ID (the SFP ID, which is not necessarily concrete, is not necessary at all) - in practice, you simply rename the current "SFP ID" to be "RSP ID".

In a second use case, the fully concrete path is nailed up on a hop-by-hop "trail-blazed" basis (i.e., classifier makes a decision as to which is the first SFF, first SFF decides upon local SF instance invocation and/or second SFF, etc.).   In this case, the encapsulation would be required to carry both the SFP ID and the RSP ID.

I believe that both use cases are covered by the architecture and that both are entirely valid.

Thanks.

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 4, 2015 12:25 PM
To: [email-masked]'
Subject: [sfc] draft-quinn-sfc-nsh-05 RSP_ID Role

     |     |    | 10.1.1.2    |  1      |

     |     |    |             |         |

     |     |    | 10.2.2.2    |  1      |

     |     |    |             |         |

     |     |    | 10.3.3.3    |  5      |

Nicolas

Ce message et toutes ses pièces jointes (ci-après le "message")sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, merci d'en informer immédiatement son émetteur par courrier électronique et d'effacer ce message de votre système. Dans cette hypothèse, vous n'êtes pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.