Hi all,
Thanks to the authors for introducing this very useful draft.
I have read draft-filsfils-spring-srv6-net-pgm-illustration-00 and may have
found some minor questions.
#1
2.1. Simplified SID allocation
....
Node k has a classic IPv6 loopback address A:k::/128 which is
advertised in the IGP
[Shunwan] Maybe "A:k::/128" here would be A:k::/32?
#2
2.4. SR-L3VPN
....
The reader can easily infer all the other SR-IPVPN instantiations:
+---------------------------------+----------------------------------+
| Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8)|
+---------------------------------+----------------------------------+
| IPv4 tenant route with egress | End.DT4 function bound to |
| tenant table lookup | IPv4-tenant-100 table |
+---------------------------------+----------------------------------+
| IPv4 tenant route without egress| End.DX4 function bound to |
| tenant table lookup | CE-C (IPv4) |
+---------------------------------+----------------------------------+
| IPv6 tenant route with egress | End.DT6 function bound to |
| tenant table lookup | IPv6-tenant-100 table |
+---------------------------------+----------------------------------+
| IPv6 tenant route without egress| End.DX6 function bound to |
| tenant table lookup | CE-C (IPv6) |
+---------------------------------+----------------------------------+
[Shunwan] May we add an End.DT46 case here?
#3
2.7.1. EVPN Bridging
....
Nodes 1, 4 and 8 are going to exchange the End.DT2M SIDs via BGP-
based EVPN Type-3 route. Upon reception of the EVPN Type-3 routes,
each node build its own replication list per L2 table that will be
used for ingress BUM traffic replication. The replication lists are
the following:
[Shunwan]"Nodes 1, 4 and 8"here should be "Nodes 1, 3 and 8 ..."
#4
2.7.4. EVPN Integrated Routing Bridging (IRB)
....
When node 1 receives a packet P from CE-A destined to 20.20.20.20
from a host (10.10.10.11), P looks up its L2 table T1 MAC-DA lookup
to find the associated SID. It pushes an outer IPv6 header with
SA=A:1::, DA=B:8:D2C:: and NH=59. Note that no additional header is
pushed. Node 8 then forwards the resulting packet on the shortest
path to B:8::/32. EVPN intra-subnet forwarding is then achieved.
[Shunwan] Should "from a host (10.10.10.11)" be "from a host (20.20.20.11), "
here?.
Or any other address belongs the same network segment as the destination
address.
#5
2.8.2. SR policy at a midpoint
....
Let us consider P2 when it is received by node 2 and let us assume
that node 2 is configured to steer B:7::/32 in a T.Insert behavior
associated with SR policy <B:3:C4::, B:5:1::>.
In such a case, node 2 would send the following modified packet P2 on
the link to 4:
[Shunwan] Should "the link to 4" be "the link to 3" here?
#6
2.9. End-to-End policy with intermediate BSID
....
B:3:C4:: realizes the low-latency path from the ingress PE to the
egress PE. This is the underlay optimization part of the
intermediate policy.
B:9:A1:: and B:6:A2:: represent two SR-aware NFV applications
residing in containers respectively connected to node 9 and 6.
[Shunwan]
Should "B:3:C4:: realizes the low-latency path ..."here be "B:2:B1:: realizes
the low-latency path ..."?
AND we see only 2 reference topologies in page 4 & 9, but cannot find node 9
within them, maybe need another reference topology here?
Again, I think this draft is very useful, it can help us understand and
implement SRv6 network programming faster.
I think it should be adopted by the WG.
Thanks,
Shunwan
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
