On 5/22/15 1:28 PM, Deepak Kumar (dekumar) wrote:
Hi Erik,
Agreed we don't ned 96 bytes of customer data in all scenario for intra-DC
but it will required in few scenarios and need to be use judiciously by
user.
Deepak,
As I understand your example below it is about testing inter-subnet
traffic i.e. a case where you have overlay routers which forward packets
based on the original/inner IP header.
That seems like a case were one could be using existing IP tools (ping,
traceroute) in the overlay, and perhaps extending the information
returned in ICMP errors following the approach used for MPLS (RFC4884
and RFC4950). Perhaps we should consider those RFCs more in NVO3 since
it means less need for new tools and new training - many ping and
traceroute implementations already print the extensions.
Do you see a need for the 96 bits of customer data when there is no NVO3
overlay routers in the path?
Thanks,
Erik
Network Diagram (Tried my best I will do better diagram in the draft)
/ S1 \ / S2 \ (L3 VTEP)
/ \ / \ (full mesh in east/west, x1<->s1,s2,
x2<->s1,s2, ...)
/ \ / \
X1 X2 X3 X4 ...
/ \ / |
/ \ / | full mesh in east/west l1<->x1, x2, x3, x4,
l2 <-> x1,x2,x3,x4, l3 ..)
/ \ / |
L1 L2 L3 L4 Š (L2 VTEP)
| |
H1 H2 ŠŠ
Now H1 is host, L1 is Switch, X1 is switch in underlay, S1 is switch with
l3 gateway functionality.
All switches are connected in East West fully connected with multiple way
ecmp.
Customer want to test L1 - Lx scenario providing Host information (H1, and
Hx)
For example: H1 and Hx are in inter subnet and across mobility domain or
any scenario where traffic will reach till L3 VTEP.
L3 VTEP will do de-encap of outer header, vxlan header and do again
re-encap of packet towards Lx.
Now to forward packet toward Lx Inner payload should be same as customer
information so right hashing is choosen as it's done for real data packet.
Thanks,
Deepak
On 5/22/15 8:31 AM, "Erik Nordmark" <[email protected]> wrote:
Deepak,
Didn't have time to go into this on the call, but the draft and your
slides refer to "96 bits of customer data"
I understand why that was needed for TRILL - basically the entropy for
ECMP/LAG is calculated at each hop in TRILL so it needs to look at the
inner Ethernet, IP, and TCP/UDP headers.
But for NVO3 the thinking is to use a UDP header where the source UDP
port is set (in the ingress NVE) to some hash of those inner addresses
and ports.
If that is the source of entropy, why do we need to also carry 96 bits
of the inner packet in the OAM frames?
Regards,
Erik
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
