Robert,
While this is an interesting question, it is orthogonal to the question that I
posed to Darren.
Ron
Juniper Business Use Only
From: Robert Raszuk <[email protected]>
Sent: Monday, June 15, 2020 3:33 PM
To: Ron Bonica <[email protected]>
Cc: Darren Dukes (ddukes) <[email protected]>; Aijun Wang
<[email protected]>; [email protected]; [email protected]
Subject: Re: About the upper layer header processing in RFC8754(SRH)
[External Email. Be cautious of content]
Hi Ron,
I think this is not the question of RFC 8754.
To me (and trust me I am not alone) this is much more of the question what IPv6
address means. How flexible we can use all bits regardless if we are talking
SRv6 or not.
Do we think that
https://tools.ietf.org/html/rfc4291<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291__;!!NEt6yMaO-gk!VpA2yHsqImwMGaAtR4SPjzF6Ek2NKqm6gF4497TQ2fOFK-RBSZLDVLBl5ltmCnmb$>
section 2.5 still holds ? Do we need to keep stretching notion of interface to
logical interfaces mapped to functions ?
Then take projects completely unrelated to segment routing ... don't we see
evident that we can encode a lot of useful information in the lowest
significant bits of the IPv6 address without each time proposing new RH ?
Best,
R.
On Mon, Jun 15, 2020 at 9:08 PM Ron Bonica
<[email protected]<mailto:[email protected]>>
wrote:
Darren,
Does the SID described in RFC 8754 represent any of the SIDs in the Network
Programming Draft? In any other document?
Ron
Juniper Business Use Only
From: ipv6 <[email protected]<mailto:[email protected]>> On Behalf Of
Darren Dukes (ddukes)
Sent: Monday, June 15, 2020 12:21 PM
To: Aijun Wang <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Re: About the upper layer header processing in RFC8754(SRH)
[External Email. Be cautious of content]
Hello Aijun.
No update to rfc8754 is necessary. Rfc8754 was written so new sids can be
defined in other documents independently.
section 4.3.1 says:
This document and section define a single SRv6 SID. Future documents
may define additional SRv6 SIDs. In such a case, the entire content
of this section will be defined in that document.
Thanks
Darren
(Written on mobile)
________________________________
From: ipv6 <[email protected]<mailto:[email protected]>> on behalf of
Aijun Wang <[email protected]<mailto:[email protected]>>
Sent: Sunday, June 14, 2020 10:15 PM
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: About the upper layer header processing in RFC8754(SRH)
Hi, Folks:
RFC8754(SRH) section
4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4..3.1.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8754*section-4.3.1.2__;Iw!!NEt6yMaO-gk!W4_ZbJ6IaphycWPj08UYd8k9IPlcBP_h6HEasypDyifP-5j3jjAVQJYjvxKIgrBz$>)
describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
local configuration permits {
Perform IPv6 decapsulation
Resubmit the decapsulated packet to the IPv4 or IPv6 module
}
ELSE {
......
}
And in network programming draft section
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15*section-9.1__;Iw!!NEt6yMaO-gk!W4_ZbJ6IaphycWPj08UYd8k9IPlcBP_h6HEasypDyifP-5j3jjAVQJYjv0iiulaO$>),
one new Ethernet Next Header Type(143) is proposed.
Although the detail process of this new next header are described in the
network program draft, does it need to update the section 4.3.1.2 of RFC8754
to reflect the process of new header type(143)?
Best Regards
Aijun Wang
China Telecom
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]<mailto:[email protected]>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VpA2yHsqImwMGaAtR4SPjzF6Ek2NKqm6gF4497TQ2fOFK-RBSZLDVLBl5gomzxK4$>
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
