Hi
I do not quite get the same warm and fuzzy from the definition when
thinking about multicast…..
The mapping of the binding SID to local policy is still IMO per path
state. For a simple p2p path it is pretty straightforward as the
mapping can be to a common policy abstraction at every node (send to
‘x’) .
In the case of multicast, the mapping would be unique at every node
that had state for the binding SID (send copy to ‘a’ and ‘b’, send
copy to ‘m’ and ‘q’ etc.) . So some means of disseminating the
mappings is required, and correlating them with the SID. So the
difference between a binding SID and a global SID for multicast IMO is
choice of terminology.
So you have to decide if the whole “avoiding per path state”
discussion is simply a desirable goal, or a strict admonition. A bulk
overprovisioning model to eliminate per path state will not work for
multicast.
Cheers
Dave
*From:*spring <spring-boun...@ietf.org> *On Behalf Of *Alexander
Vainshtein
*Sent:* Tuesday, June 19, 2018 6:38 AM
*To:* bruno.decra...@orange.com; Stewart Bryant <stewart.bry...@gmail.com>
*Cc:* SPRING WG List <spring@ietf.org>; Rob Shakir
<robjs=40google....@dmarc.ietf.org>
*Subject:* Re: [spring] Updating the SPRING WG Charter
Bruno, Stewart and all,
I have looked up Section 5 “*/Binding Segment/*” of the Segment
Routing Architecture
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15>draft,
and it says:
In order to provide greater scalability, network opacity, and service
independence, SR utilizes a Binding SID (BSID). The BSID is bound to
an SR policy, instantiation of which may involve a list of SIDs. Any
packets received with active segment = BSID are steered onto the
bound SR Policy.
A BSID may either be a local or a global SID. If local, a BSID
SHOULD be allocated from the SRLB. If global, a BSID MUST be
allocated from the SRGB.
Use of a BSID allows the instantiation of the policy (the SID list)
to be stored only on the node(s) which need to impose the policy.
Direction of traffic to a node supporting the policy then only
requires imposition of the BSID. If the policy changes, this also
means that only the nodes imposing the policy need to be updated.
Users of the policy are not impacted.
From my POV this definition is fully aligned both with the Bruno’s
last email and with my earlier argument why a BSID does not add a
*/per-path state/* in the transit nodes.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@ecitele.com
<mailto:alexander.vainsht...@ecitele.com>
*From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of
*bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
*Sent:* Tuesday, June 19, 2018 3:38 PM
*To:* Stewart Bryant <stewart.bry...@gmail.com
<mailto:stewart.bry...@gmail.com>>
*Cc:* SPRING WG List <spring@ietf.org <mailto:spring@ietf.org>>; Rob
Shakir <robjs=40google....@dmarc.ietf.org
<mailto:robjs=40google....@dmarc.ietf.org>>
*Subject:* Re: [spring] Updating the SPRING WG Charter
Hi Stewart,
Speaking as individual contributor, please see inline [Bruno]
*From:*spring [mailto:spring-boun...@ietf.org] *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. ”
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.
--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.
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains
information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this
transmission in error, please inform us by e-mail, phone or fax, and
then delete the original
and all copies thereof.
___________________________________________________________________________