Re: [spring] Updating the SPRING WG Charter

[Stewart Bryant <[e-mail]>]

On 19/06/2018 13:38, [e-mail] wrote:
>
> Hi Stewart,
>
> Speaking as individual contributor, please see inline [Bruno]
>
> *From:*spring [mailto:[e-mail]] *On Behalf Of *Stewart 
> Bryant
> *Sent:* Tuesday, June 19, 2018 1:19 PM
>
> On 01/06/2018 17:05, Rob Shakir wrote:
>
>     The SPRING WG defines procedures that allow a node to steer a
>     packet through an
>
>     SR Policy instantiated as an ordered list of instructions called
>     segments and
>
>     without the need for per-path state information to be held at
>     transit nodes.
>
>
> I am not sure where the line gets drawn with the per-path state 
> statement. If I introduce a
> binding-SID to allow the creation of a path, have I introduced 
> per-path state or not? In practise
> a management entity will choose between the infinity of possible 
> binding-SIDs by considering
> the need to create specific paths and I would imagine that many will 
> be instantiated just-in-time.
>
> I think that the key point is that the ingress creates the path by 
> using SIDs to create
> a concatenation of paths, policies and resources.
>
> [Bruno] Agreed. And it can be argued that this creates a state on the 
> ingress. An “outgoing” state, very roughly comparable to Next Hop 
> Label Forwarding Entry (NHLFE))
>
> However it could be argued that
> as soon as we introduced Binding SIDs we introduced per-path state.
>
> [Bruno] Adding a Binding SID to this SR policy introduces an 
> “incoming” state, very roughly comparable to Incoming Label Map (ILM). 
> But this gets additional benefit as it allows others SR nodes to use 
> this state/SR policy.
>
> I’m not sure that in such high level text, we need to make such 
> distinction.
>
> I think we might
> be best served by deleting the text I have highlighted.
>
> [Bruno] This text is mostly a copy/past from existing charter so is 
> not really new:
> “allow a node to steer a packet along an explicit
>
>   route using information attached to the packet and
>
>   without the need for per-path state information to be
>
>   held at transit nodes. ”
>

The text of course is a direct derivative of the original charter text:

The SPRING working group will define procedures that will allow
a node to steer a packet between any source and destination through
a SPRING region on any path without requiring state to be
maintained by transited nodes, but rather at the source device.


However that pre-dates the introduction of binding SIDs which although 
can be considered a type of shared link are non-the-less state usually 
introduced to overcome a specific limitation in the SR hardware, since 
they achieve nothing that base SR cannot achieve without them.


> At high level, I believe that this is a key distinction of 
> spring/segment routing hence worth keeping in the high level 
> introduction of the WG.
>
> Now do we need to add text about more specific details, such as BSID? 
> I’d rather not, as I don’t see what this would bring. I also don’t 
> think that this sentence prohibits the creation of states when 
> required/useful.
>
I suppose if you replaced:

and without the need for per-path state information to be held at 
transit nodes.

with

with minimum path state introduced at the transit nodes.

that would be closer to the design we have.

- Stewart


> --Bruno
>
>
> - Stewart
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.