Robert,
I wasn't aware that I was shooting. But, since it is 19:39 in my time zone, I
might take a shot of Fernet Branca.
Ron
Juniper Business Use Only
From: Robert Raszuk <rob...@raszuk.net>
Sent: Monday, June 15, 2020 5:31 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: Darren Dukes (ddukes) <ddu...@cisco.com>; Aijun Wang
<wang...@chinatelecom.cn>; i...@ietf.org; spring@ietf.org
Subject: Re: About the upper layer header processing in RFC8754(SRH)
[External Email. Be cautious of content]
Hi Ron,
True !
But pls do not take my response as an attempt to derail your shot. It was
rather a delicate attempt to put it on the right tracks towards the truth
target.
Best,
Robert.
On Mon, Jun 15, 2020 at 11:26 PM Ron Bonica
<rbon...@juniper.net<mailto:rbon...@juniper.net>> wrote:
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 <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: Monday, June 15, 2020 3:33 PM
To: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>
Cc: Darren Dukes (ddukes) <ddu...@cisco.com<mailto:ddu...@cisco.com>>; Aijun
Wang <wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>;
i...@ietf..org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
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
<rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>
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 <ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>> On Behalf Of
Darren Dukes (ddukes)
Sent: Monday, June 15, 2020 12:21 PM
To: Aijun Wang <wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>;
i...@ietf.org<mailto:i...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
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 <ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>> on behalf of
Aijun Wang <wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>
Sent: Sunday, June 14, 2020 10:15 PM
To: i...@ietf.org<mailto:i...@ietf.org>;
spring@ietf.org<mailto:spr...@ietf..org>
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
i...@ietf.org<mailto:i...@ietf.org>
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
