Hi, Inline +++DK:
On 5/28/15 11:50 AM, "Darrel Lewis (darlewis)" <[email protected]> wrote: > >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. +++DK: Even in case of intra-subnet traffic we will go till Spine if customer creates their data center in multiple pods or domains. Eg:- Each PODs has 100 Leafs pair, and connectivity between POD for even briding traffic route is only at L3 Spine. Within POD path taken will not go till S1,s2, but for inter-POD it will reach S1. Also Traceroute or TTL expiry doesn't test the exact datapath in forwarding in spine, as real traffic will cover as ASIC treat outer layer TTL expiry different than looking at inner header, de-encap, encap changing vni and forwarding towards the leafs. Thanks, Deepak > >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
