Tom, inline. [PC2]
Thanks, Pablo. On 18/07/2018, 18:57, "Tom Herbert" <[email protected]> wrote: > >In summary if you could address: > > > >1. Section 5.1 Traditional mode (Tom’s comment on terminology and >IP-in-IP with no relation to SR?) > > > >PC1: Tom, please read >https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05#section-3 > Pablo, I'm not sure that's relevant to discussion on an encapsulation dataplane. PC2: A node may receive a packet with an SRv6 SID in the DA without an SRH. In such case the packet should still be processed by the Segment Routing engine. PC2: This is relevant understanding how the encapsulation dataplane operates IMO. SIDs are 128 bit values that are in the IPv6 address space, and if a SID is place in a destination IPv6 address then it must be routable to a node in the network. Wrt encapsulation, if it's any more complex than that, then I'm missing something fundamental about segment routing. >PC1: It might be IP-in-IP as long as the inner header is not Ethernet or >Unstructured PDUs (3GPP PDU types). > If it's not IP-IP, then what is it? The draft states that in traditional mode: PC2: If it is Ethernet or Unstructured, I strongly believe this is not IP-in-IP. "gNB only adds an outer IPv6 header with IPv6 DA U1::1." This implies that foo over IP can be used if there is a protocol number for it (e.g. IPv[46]/IPv6, GRE/IPv6, MPLS/IPv6, etc.). But what does this mean in the case of unstructured PDUs? How are those encapsulated? PC2: Unstructured PDUs uses T.Encaps.L2 and End.DX2 functions. IPv6/SRH(if more than one SID)/byte_stream. If its traditional mode -one SID- then IPv6/byte_stream. Please clarify, or provide the reference to the exact format of encapsulation protocols being used with SR. PC2: The encapsulation protocol being used with SRv6 is defined in draft-ietf-6man-segment-routing-header which of course requires RFC8200. PC2: The encapsulation/decapsulation procedures used in dmm-srv6-mobile-uplane are defined in draft-filsfils-srv6-network-programming. >PC1: When its IP-in-IP the destination address is an SRv6 SID and is >processed differently at the destination than an interface address. See >4.8-4.12 of draft-filsfils-srv6-network-programming. > Okay, but I don't see how the protocol is processed changes the fact (at least that I think is a fact) that the solution is using IP-IP, or maybe foo-over-IP in some cases as above, as the encapsulation and that is the on-the-wire protocol in use. PC2: It depends how you understand what is an encapsulation. To me this is the on-the-wire byte-codification and its processing. PC2: In this particular case of Traditional mode with IP PDUs and encapsulation, the on-the-wire codification is IPinIP, since the SRH is not needed, while the processing is SRv6. If the UPF does not support SRv6, then it will not be able to work. Because of this, referring to it as IPinIP is misleading. PC2: Let me try to give you an analogy. A external packet arrives to an ILA network. The original IPv6 DA is translated as per ILA. What is the packet? Is it an IP packet or is it an ILA packet? To me this is an ILA packet, because if the source and destination UPFs are not ILA capable the overlay does not work. PC2: For this reason, I would not call the above SRv6 example IPinIP. It needs SRv6 on the UPFs, hence calling it IPinIP does not reflect the requirement of running SRv6 on the destination UPF -which in my opinion is considerable to highlight-. Tom
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
