Weibin,
Your analysis is absolutely correct. If you believe that node segments provide
point-to-point connectivity, node SIDs have local significance only. If you
believe that node segments provide multipoint-to-point connectivity, node SIDs
have global significance.
This distinction is sufficiently subtle that it confuses most readers. So, in
the next draft version, I *will not* say that all SIDs have local significance
only. Instead, I will say:
- Adjacency SIDs have node-local significance
- In order to simplify network operations, node SIDs are assigned in a manner
that gives them global significance. Namely, all segments terminating at the
same node are identified by the same SID.
Does this work for you?
Ron
Juniper Public
-----Original Message-----
From: Wang, Weibin (NSB - CN/Shanghai) <[email protected]>
Sent: Monday, September 2, 2019 11:31 PM
To: Ron Bonica <[email protected]>; SPRING WG <[email protected]>; IPv6 List
<[email protected]>
Subject: RE: New Version Notification for draft-bonica-spring-srv6-plus-05.txt
Hi Ron:
Thank u for your explanation in detail, I fully agreed on what you said from
SID's different perspective. You have offered new idea for Segment.
The key reason why I previously raised the different opinion to your Node-local
significance of all type of SID is my understanding of segment. It only based
on my understanding and I am sure it may not wrong.
Though it is NOT important in your SRv6+ work, but I still have to describe my
understanding to Segment, May be wrong.
If only consider the Node segment (i.e. corresponding to prefix SID), I think
it only represent one Node itself, like loopback@ (/32) advertisement in
standard IGP flooding procedure, loopback@ represent router itself, (such as
OSPF, carried in router LSA), every other router receiving the router LSA will
calculate the least cost path to advertising router, we are consistent that
saying the loopback@ is unique and global significance, it should not be
thought as Node-local significance from every receiving router perspective;
back to SR context, so every other router receiving the IGP extension
advertisement with Node SID TLV also calculate the least cost path to
advertising router, in fact, from the two flooding procedure perspective, the
behavior of all receiving routers are same, that is computing the path to Node
which is represented by loopback@ or Node SID.
So in your case, 25 segments (B-A/.../Z-A) in fact only represent a path to
Node A respectively, the same segment SID represent B-A ... or Z-A, I think the
way of saying is not full precise, the node SID only represent the Node itself,
the specific action or behavior at every Node is up to every other node, so in
my understanding, the meaning of Node SID equal loopback@, Like Loopback@ (/32)
only represent Node A itself, it doesn't itself identify path between other
Node to Node A. and I think it is easy to understand in normal SRv6 context, it
is full clear that the format of Node SID equal IPv6@ in normal SRv6 context,
so easy acceptable that the Node-SID is domain-wide significance, because the
IPv6@ is domain-wide unicast.
Thanks
--------------------------------------
Thank you !
WANG Weibin
i
-----Original Message-----
From: spring <[email protected]> On Behalf Of Ron Bonica
Sent: 2019年8月30日 23:23
To: Wang, Weibin (NSB - CN/Shanghai) <[email protected]>; SPRING WG
<[email protected]>; IPv6 List <[email protected]>
Subject: Re: [spring] New Version Notification for
draft-bonica-spring-srv6-plus-05.txt
Hi Wang,
I think that we are in agreement about how thing actually work. For example,
assume the following:
- An SRv6+ domain contains Nodes A-Z
- On Node A, an network operator configures a node segment endpoint and
associates the node segment endpoint with SID A
- IS-IS floods the node segment endpoint and SID throughout the IGP domain
- Node B builds Node Segment B-A and associates SID A with that segment
- Node C builds Node Segment C-A and associates SID A with that segment
- And so on until Node Z builds Node Segment Z-A and associates SID A with that
segment
I think that our disagreement is whether SID A, above, is a global SID or a
node local SID.
If you think that a SID identifies a segment, then it is node-local. This is
because a single SID (i.e., A) identifies 25 different segments (i.e., Segments
B-A through Z-A).
If you think that a SID identifies an instruction that a) can be instantiated
on multiple nodes and b) forwards a packet from the node upon which it is
instantiated to Node A, then t is global.
Whether we call the SID local or global is really secondary, so long as we
agree on how things work. If the text confuses the WG, I would be happy to
change it.
Ron
Juniper Public
-----Original Message-----
From: Wang, Weibin (NSB - CN/Shanghai) <[email protected]>
Sent: Friday, August 30, 2019 10:23 AM
To: Ron Bonica <[email protected]>; SPRING WG <[email protected]>; IPv6 List
<[email protected]>
Subject: RE: New Version Notification for draft-bonica-spring-srv6-plus-05.txt
Ron:
I still feel that all SID (including adj SID as well as Node SID) is node-local
significance in your SRv6+ draft May be a problem, even if you has explained it
previously.
>From my understanding, the Node SID (for loopback@) must be global
>significance in SR-enabled domain, so that every Node within SRv6 domain can
>find the least cost path to the other Node which advertising its Node segment
>in IGP extension, every Node has its Node-segment and adj-segments for itself,
>these SIDs must be assigned by Node itself, not by other Nodes within
>SR-enabled domain.
>From example described in section "5.1 Range" in your draft, I deduced, within
>SR domain, each node must assign independently a unique SID or more for other
>every Node from its perspective, for example, for Node 100, Node 1 can assign
>Node SID#11 to the Node 100, and Node 3 can assign Node SID#13 to Node 100, it
>means that Node 1 is segment ingress node for SID 11 whose instruction
>correspond to going to Node 100 via least cost path, Node 3 is segment ingress
>node for SID 13 to Node 100, following this way, How the ingress PE node
>calculate the E2E SR path within domain, because the ingress PE must know all
>different Segment SIDs assigned by every Node from its perspective, that is to
>say, in your case, one Node must receive 4999*4999 Node SIDs, 4999 for each
>Node, in order to achieve this goal, every Node must advertise all other
>Nodes' Node segments assigned by itself from its perspective, but it may be
>not possible, because each node has to advertise lots of SIDs in IGP extension
, it is complex.
Although a good SIDs assigning way described in section "5.3 Assigning SIDs to
Node segments", but meaning of this way in fact is not same as your essential
meaning of your section 5.1. in fact you have used the global significance of
SID, and each Node assign SID to itself and in further advertising it in IGP
extension.
--------------------------------------
Thank you !
WANG Weibin
-----Original Message-----
From: spring <[email protected]> On Behalf Of Ron Bonica
Sent: 2019年8月28日 23:38
To: SPRING WG <[email protected]>; IPv6 List <[email protected]>
Subject: [spring] FW: New Version Notification for
draft-bonica-spring-srv6-plus-05.txt
FYI
Juniper Public
-----Original Message-----
From: [email protected] <[email protected]>
Sent: Wednesday, August 28, 2019 11:31 AM
To: Ron Bonica <[email protected]>; Shraddha Hegde <[email protected]>;
Andrew Alston <[email protected]>; Gang Chen <[email protected]>;
Joel Halpern <[email protected]>; Andrew Alston
<[email protected]>; Daniam Henriques
<[email protected]>; Jen Linkova <[email protected]>; Yuji
Kamite <[email protected]>
Subject: New Version Notification for draft-bonica-spring-srv6-plus-05.txt
A new version of I-D, draft-bonica-spring-srv6-plus-05.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.
Name: draft-bonica-spring-srv6-plus
Revision: 05
Title: IPv6 Support for Segment Routing: SRv6+
Document date: 2019-08-28
Group: Individual Submission
Pages: 23
Abstract:
This document describes SRv6+. SRv6+ is a Segment Routing (SR)
solution that leverages IPv6. It supports a wide variety of use-
cases while remaining in strict compliance with IPv6 specifications.
SRv6+ is optimized for ASIC-based forwarding devices that operate at
high data rates.
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
_______________________________________________
spring mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwIGoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=Y7tg_WdE6dDTbLTNP7fA4mmVNhGtWb9D_1Q0A228DOE&s=fDRQpSgY2T772Uheoj6CZ-n_K2TdcHCoa9_Mtz2GHGY&e=
_______________________________________________
spring mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwIGoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JmHER-UU7JwsLRYG26SYPfYLuC96QfLcNm2JoW0yecQ&s=IhcG7iCxBD1__lhlXruSQCfi_ueg0oNDHimr2q_a5G4&e=
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
