Pablo,
Could you make this clear in the specification. Currently, Section 4.2 suggesst
that processing is the same as Section 4.1 except for the following
substitution:
"When N receives a packet destined to S and S is a local End.X SID, the line
S15 from the End processing is replaced by the following:
S15. Set the packet's egress adjacency to J"
Ron
Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[email protected]>
Sent: Monday, December 9, 2019 10:17 AM
To: Ron Bonica <[email protected]>; SPRING WG <[email protected]>
Subject: Re: [spring] SRv6 And ICMP Processing
Ron,
In the example you listed the SRv6 implementation does not reply sending an
ICMPv6 Parameter Problem message.
As you said, this would be a violation of RFC4443. I believe that RFC4443 is
very clear about this.
Thanks,
Pablo.
From: spring <[email protected]<mailto:[email protected]>> on
behalf of Ron Bonica
<[email protected]<mailto:[email protected]>>
Date: Monday, 25 November 2019 at 20:22
To: SPRING WG <[email protected]<mailto:[email protected]>>
Subject: [spring] SRv6 And ICMP Processing
Pablo,
Assume that an SRv6 implementation receives the following packet:
- IPv6 Header
o Destination Address is a locally instantiated END.DX4 SID
o Next Header is ICMPv6
- ICMPv6 Header
o Type is Parameter Problem
Section 4.5 of draft-ietf-spring-srv6-network-programming-05 suggests that the
implementation would respond by sending another ICMPv6 Parameter Problem
message. This would violate RFC 4443, Section 2.4.e.
You might want to add some text to the draft stating compliance with the rules
in Section 2.4 of RFC 4443.
ROn
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
