Re: [spring] Comments on draft-filsfils-spring-srv6-net-pgm-illustration-00

[<[e-mail]>]

Hi Zhuangshunwan,

Thank you for reviewing drafts and providing comments. This is the way we improve and progress documents.


Ø  Again, I think this draft is very useful, it can help us understand and implement SRv6 network programming faster.
If the SRv6 network programming draft is not clear/easy to understand enough, please provides comments on the network programming draft in order to improve it. Because in the end, in case of misunderstanding leading to interop issues, this is the normative text which matters, not illustrations.

Thank you,
Best regards,
Bruno
From: Zhuangshunwan [mailto:[e-mail]]
Sent: Thursday, July 11, 2019 8:06 AM
To: [e-mail]
Cc: [e-mail]
Subject: Comments on draft-filsfils-spring-srv6-net-pgm-illustration-00

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

_________________________________________________________________________________________________________________________

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.