Hi Ron,
It is the 6man charter that precludes it from defining a new Source Routing
solution.
"It is not chartered to develop major changes or additions to the IPv6
specifications."
The RH work done in 6man (not ipng or ipv6) has been based on requirements from
other WGs where those solutions have been defined and which were chartered do
to that work. As such, 6man has simply designed those RHs and not their
respective Routing/Source Routing solutions.
"6man is the design authority for extensions and modifications to the IPv6
protocol."
So in which WG is this newly proposed IPv6 Source Routing solution going to be
architected in?
Regarding SPRING, the argument is that what you are claiming to be a new IPv6
Source Routing solution is in fact based on SPRING architecture. It seems
really unfortunate that significant work done by Spring WG group is re-used
without proper attribution. I am not surprised if people still thing this is
Segment Routing even after you have removed references, omitted text and
renamed terms.
Thanks,
Ketan
From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Ron Bonica
Sent: 21 May 2020 22:28
To: Chengli (Cheng Li) <c...@huawei.com>; Zafar Ali (zali) <z...@cisco.com>;
Robert Raszuk <rob...@raszuk.net>
Cc: spring@ietf.org; 6man <6...@ietf.org>
Subject: RE: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
Cheng,
Are you assuming that the SPRING charter precludes 6man from ever defining
another Routing header unless it originates in SPRING?
After all, every IPv6 Routing header facilitates source routing.....
Ron
Juniper Business Use Only
From: Chengli (Cheng Li) <c...@huawei.com<mailto:c...@huawei.com>>
Sent: Thursday, May 21, 2020 12:24 PM
To: Zafar Ali (zali) <z...@cisco.com<mailto:z...@cisco.com>>; Ron Bonica
<rbon...@juniper.net<mailto:rbon...@juniper.net>>; Robert Raszuk
<rob...@raszuk.net<mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6man
<6...@ietf.org<mailto:6...@ietf.org>>
Subject: RE: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
[External Email. Be cautious of content]
Well, when I read the latest revision, these terms are modified to other words,
but still feel similar.
Also, I still see the sentence in Introduction:
"
The CRH allows IPv6 source nodes to specify the path that a packet
takes to its destination.
"
To Ron,
is it a Source Packet Routing paradigm?
If yes, we should start from SPRING WG?
Things are going so fast and I don't understand why a reference deletion can
made such magic happen? :(
Best Regards,
Cheng
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Thursday, May 21, 2020 11:35 PM
To: Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>>;
Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6man
<6...@ietf.org<mailto:6...@ietf.org>>
Subject: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
Ron,
I sensed that you will propose that ... hence I already asked this question in
my last email,
Let me repeat. In rev 10 of the CRH document[1], the following SIDs with
normative reference to SRm6 were defined but removed in Feb. 2020:
"The following are valid segment types:
o Adjacency.
o Node.
o Binding.. "
Your proposed text is consistent on how CRH was positioned since inception till
Feb. 2020, i.e., for SPRING use-case.
However, the very premise of the current adoption call is use-case beyond
SPRING.
There is a clear need for documenting a genuine use-case & architecture for CRH
beyond SPRING, before adoption.
[1]
https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10*section-4__;Iw!!NEt6yMaO-gk!QAuA3Dl83zIeqeKCEhswwSXMzW48zN83GY5D6ZiwWA3VkPM6iOFJIwiYIWmNW_1A$>
Thanks
Regards ... Zafar
From: ipv6 <ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>> on behalf of
Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>>
Date: Thursday, May 21, 2020 at 10:19 AM
To: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Cc: 6man <6...@ietf.org<mailto:6...@ietf.org>>
Subject: RE: Size of CR in CRH
Robert,
It might makes sense for an operator to:
* Allocate identifiers that cause packets to traverse a least-cost path as
if they had domain-wide significance
* Allocate identifiers that cause packets to traverse specific links as
strictly node local
This concept also exists in SR-MPLS, where prefix SIDs have domain-wide scope
and adjacency SIDs have node-local scope.
I will make this more clear in the next draft version.
Ron
Juniper Business Use Only
From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: Thursday, May 21, 2020 4:34 AM
To: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>
Cc: 6man <6...@ietf.org<mailto:6...@ietf.org>>
Subject: Re: Size of CR in CRH
[External Email. Be cautious of content]
Ron,
> Now recall that identifiers have node local significance.
I was talking about case described in yr draft section 7:
"Applications can:
o Allocate SIDs so that they have domain-wide significance."
While not a must - it is an option. So I believe my observation stays valid
till draft either removes that option or describes scaling properties
differences between both domain wide and local significance of the SIDs.
Thx,
R.
On Thu, May 21, 2020 at 4:01 AM Ron Bonica
<rbon...@juniper.net<mailto:rbon...@juniper.net>> wrote:
Robert,
Consider the following network:
* Contains 65,000 routers
* Each router has 500 directly connected neighbors or fewer
* Uses 16-bit CRH
In this network, each node might have 65,499 CRH-FIB entries:
* 64,999 CRH-FIB entries cause packets to follow the least-cost path to
another node in the domain
* 500 CRH-FIB entries cause packets to traverse a specific link to a
specific neighbor.
As a mnemonic device, an operator might assign identifiers as follows:
* 0-65,000 identify CRH-FIB entries that cause packets to follow the
least-cost path to another node in the domain
* 65,001 - 65,565 identify CRH-FIB entries that that cause packets to
traverse a specific link to a specific neighbor.
Now recall that identifiers have node local significance. So, Node A and Node B
might both have a CRH-FIB entry that is identified by the value 65,001..
However:
* The CRH-FIB entry on Node A causes packets to traverse a particular link
towards Node X
* The CRH-FIB entry on Node B causes packets to traverse a different link
towards Node Y.
I think that this example refutes the premise of your argument, so there is not
further need to address the conclusion.
Ron
Juniper Business Use Only
From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: Wednesday, May 20, 2020 6:20 PM
To: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>
Cc: 6man <6...@ietf.org<mailto:6...@ietf.org>>
Subject: RE: Size of CR in CRH
[External Email. Be cautious of content]
HI,
So just to make sure I understand this analogy of 16 bit -- 2^16 = 65536 nodes.
I think this is only on paper.
Imagine I have 1000 routers so if I divide the 16 bit space by 1000 I get at
most 65 local node behaviours if anyone would like to embed such into the SID.
That means that if my router have more then 65 interfaces I am not able to
steer packets by src route out of my router ... I must always depend on the
lookup of next SID how to forward the packets.
That also means that if I want to apply any form of NP in segment endpoint I am
quite limited to the number of local functions I could use.
To conclude - Let me restate to what I and others already said - flat SID space
domain wide in mapping plane is a mistake. Yes this is like MPLS, but this does
not make it great again due to that legacy.
Many thx,
R.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
