Removing a header from an IPv6 packet (without removing the whole IPv6
header) is a violation of RFC 8200.
As such, it should be removed from the base network programming draft.
If you really want it, put it in the new insertion draft. And justify it.
With regard to the example of off-load, the usual practice has been to
avoid standardizing off-load behaviors in the IETF. the NIC vendors
come up with all sorts of ways to improve performance that violate the
specifications. We do not endorse that, and leave the need for
consenting devices engaging in proprietary communication to them.
Yours,
Joel
On 10/17/2019 5:41 AM, Pablo Camarillo (pcamaril) wrote:
Li,
Node1's
Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy <B:3:C4::,
B:8:D100::>.
When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks
up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8. As a
consequence, 1 pushes an outer header with SA=A:1::, DA=B:3:C4::,
NH=SRH followed by SRH (B:8:D100::, B:3:C4::; SL=1; NH=4). 1 then
forwards the resulting packet on the interface to 2.
2 forwards to 3 along the path to B:3::/32.
When 3 receives the packet, 3 matches the DA in its "My SID Table"
and finds the bound function End.X to neighbor 4. 3 notes the PSP
capability of the SID B:3:C4::. 3 sets the DA to the next SID
B:8:D100::. As 3 is the penultimate segment hop, it performs PSP and
pops the SRH. 3 forwards the resulting packet to 4.
4, 6 and 7 forwards along the path to B:8::/32.
When 8 receives the packet, 8 matches the DA in its "My SID Table"
and finds the bound function End.DT(100). As a result, 8 decaps the
outer header, looks up the inner IPv4 DA (20.20.20.20) in tenant-100
IPv4 table, and forward the (inner) IPv4 packet towards CE-B.
Node 3 receives the packet SA=A:1::, DA=B:3:C4::,NH=SRH followed by SRH
(B:8:D100::, B:3:C4::; SL=1; NH=4)
The SID B:3:C4:: is associated with the End.X behavior with PSP support.
Node 3 is going to decrement SL, copy the segment B:8:D100:: into the
IPv6 DA and set the packet’s egress adjacency to J (adjacency associated
with that SID instance). Additionally, (PSP) it will check what is the
SL value in the SRH. If the SL=0 it will remove the SRH from the packet.
The segment B:3:C4:: is the penultimate SID in the segment list
<B:3:C4::, B:8:D100::>. Note that the PSP behavior is not related to IP
hops.
Cheers,
Pablo.
*From: *li zhenqiang <[email protected]>
*Date: *Thursday, 17 October 2019 at 06:11
*To: *"Pablo Camarillo (pcamaril)" <[email protected]>, Ron Bonica
<[email protected]>, "[email protected]" <[email protected]>
*Cc: *draft-ietf-spring-srv6-network-programming
<[email protected]>
*Subject: *Re: Re: [spring] draft-ietf-spring-srv6-network-programming:
Section 4.16
Hi Pablo,
I am still confused by the example in section 2.8.1. Node 3 is the
destionation of SID B:3:C4::, why should it behave PSP for this SID?
While for SID B:8:D100::, it is an END.DT4, the PSP behavior is not
defined for this kind of SIDs. Node 3 should not behave PSP for SID
B:8:D100::, neither. Would you please explain node 3 is the penultimate
segment hop of which node or which segment? Suppose the behavior is
correct, may I know the benifit you gain in this example?
Many Thanks,
Zhenqiang Li
------------------------------------------------------------------------
[email protected]
*From:*Pablo Camarillo (pcamaril) <mailto:[email protected]>
*Date:* 2019-10-16 00:45
*To:*li zhenqiang <mailto:[email protected]>; Ron Bonica
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*CC:*draft-ietf-spring-srv6-network-programming
<mailto:[email protected]>
*Subject:* Re: [spring] draft-ietf-spring-srv6-network-programming:
Section 4.16
Li,
I have replied the technical questions regarding PSP and USP in the
email thread from one week ago.
You have not provided any technical concern.
> “Further, the example for PSP in the companion doc
srv6-net-pgm-illustration is wrong. PSP is used for END.DT4 in the companion doc
while flavors are only defined for END, END.X and END.T in
srv6-network-programming.”
The illustration in section 2.8.1 is correct. Please re-read it. PSP
is used at node 3 together with the End.X behavior.
Regards,
Pablo.
Replies from one week ago:
https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c
https://mailarchive.ietf.org/arch/msg/spring/WrYzRZC0HKVgBYaYMCQVcTWrfak
*From: *li zhenqiang <[email protected]>
*Date: *Tuesday, 15 October 2019 at 09:32
*To: *Ron Bonica <[email protected]>,
"[email protected]" <[email protected]>
*Cc: *draft-ietf-spring-srv6-network-programming
<[email protected]>
*Subject: *Re: [spring] draft-ietf-spring-srv6-network-programming:
Section 4.16
*Resent from: *<[email protected]>
*Resent to: *<[email protected]>, <[email protected]>, <[email protected]>,
<[email protected]>, <[email protected]>,
<[email protected]>
*Resent date: *Tuesday, 15 October 2019 at 09:32
I suggest this section be removed from this version until the
community reaches rough consensus.
Further, the example for PSP in the companion doc
srv6-net-pgm-illustration is wrong. PSP is used for END.DT4 in the
companion doc while flavors are only defined for END, END.X and
END.T in srv6-network-programming.
Best Regards,
Zhenqiang Li
------------------------------------------------------------------------
[email protected]
*From:*Ron Bonica <mailto:[email protected]>
*Date:* 2019-10-15 02:42
*To:*SPRING WG List <mailto:[email protected]>
*Subject:* [spring] draft-ietf-spring-srv6-network-programming:
Section 4.16
Authors,
Lacking the B.INSERT and T.INSERT functions, can you describe a
use-case for the PSP and USP flavors of the END, END.X and END.T
functions?
Ron
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
