On May 27, 2015, at 10:35 AM, Erik Nordmark <[email protected]> wrote:
> 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. This approach seems reasonable to me. Its certainly what we’ve attempted to do with the LISP overlay. I think the problem space is complex enough without trying to bold the ocean. The good thing about this incremental approach is that if operational experience proofs a need, it can be addressed then. -=Darrel > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
