On 19/06/2018 13:38, [email protected] wrote:
Hi Stewart,
Speaking as individual contributor, please see inline [Bruno]
*From:*spring [mailto:[email protected]] *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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
