Subject: [spring] About the upper layer header processing in RFC8754(SRH)

From: "Aijun Wang" <[email-masked]>
Date: Mon, 15 Jun 2020 10:13:57 +0800

Hi, Folks:

RFC8754(SRH) section
4.3.1.2(https://tools.ietf.org/html/rfc8754#section-4.3.1.2) 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-pro
gramming-15#section-9.1), 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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 15 Jun 2020 02:29:18 +0000

Hi Aijun,
Very good catch!
I think the 4.3.1.2 need to be updated !
I would like to propose some text (maybe later today) for RFC8754 4.3.1.2, as well as some other text in SRv6-PGM section 4.1 (and some related sections) I have observed  about the Upper-layer processing for further discussion.

Thanks
Jingrong

From: ipv6 [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: [email-masked]; [email-masked]
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) 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), 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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jun 2020 13:54:23 +0000

Aijun, Jingrong,

Could the upper-layer header also be ICMP, as in a ICMP Echo message?

                                                    Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Xiejingrong (Jingrong)
Sent: Sunday, June 14, 2020 10:29 PM
To: Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: About the upper layer header processing in RFC8754(SRH)

[External Email. Be cautious of content]

Hi Aijun,
Very good catch!

Thanks
Jingrong

From: ipv6 [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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!TQj3lWlbJi1xnhmD0skSC1Qbp_vkkYT77iE2zA_6hLItZqr8eZxbW1IoKhFgaBkD$>) 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!TQj3lWlbJi1xnhmD0skSC1Qbp_vkkYT77iE2zA_6hLItZqr8eZxbW1IoKiVOq5HR$>), one new Ethernet Next Header Type(143) is proposed.

Best Regards

Aijun Wang
China Telecom

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 15 Jun 2020 15:10:21 +0000

Hi Ron,
Agreed ICMP is an upper-layer header that should be consistent with the SRv6-OAM draft [1], and I guess you may have also noticed the same.
Please see the proposed text I have just posted.

Regards,
Jingrong

[1] https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-05

From: Ron Bonica [mailto:[email-masked]]
Sent: Monday, June 15, 2020 9:54 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Aijun, Jingrong,

                                                    Ron

Juniper Business Use Only
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Xiejingrong (Jingrong)
Sent: Sunday, June 14, 2020 10:29 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Hi Aijun,
Very good catch!

Thanks
Jingrong

Hi, Folks:

Best Regards

Aijun Wang
China Telecom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jun 2020 15:25:56 +0000

Hi Jingrong,

Where did you post the text?

                             Ron

Juniper Business Use Only
From: Xiejingrong (Jingrong) <[email-masked]>
Sent: Monday, June 15, 2020 11:10 AM
To: Ron Bonica <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Hi Ron,

Regards,
Jingrong

From: Ron Bonica [mailto:[email-masked]]
Sent: Monday, June 15, 2020 9:54 PM
To: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Aijun, Jingrong,

                                                    Ron

Hi Aijun,
Very good catch!

Thanks
Jingrong

Hi, Folks:

Best Regards

Aijun Wang
China Telecom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jun 2020 15:38:29 +0000

Hi Jingrong,

I have found the text. (It was in my SPRING mailbox).

A much shorter update may suffice. Does the following work for you?

OLD>

<OLD

NEW> IF (Upper-layer Header is IPv4 or IPv6 or Ethernet or ICMP) and
       local configuration permits {
     Perform IPv6 decapsulation
     Submit the newly exposed payload to the appropriate processing module
   }
   ELSE {
   ......
}

<NEW

Hi Ron,

Regards,
Jingrong

Aijun, Jingrong,

                                                    Ron

Hi Aijun,
Very good catch!

Thanks
Jingrong

Hi, Folks:

Best Regards

Aijun Wang
China Telecom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 15 Jun 2020 16:20:55 +0000

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-masked]> on behalf of Aijun Wang <[email-masked]>
Sent: Sunday, June 14, 2020 10:15 PM
To: [email-masked]; [email-masked]
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
   ……

Best Regards

Aijun Wang
China Telecom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jun 2020 19:08:12 +0000

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-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Monday, June 15, 2020 12:21 PM
To: Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: About the upper layer header processing in RFC8754(SRH)

Hello Aijun.

section 4.3.1 says:

Thanks
  Darren
  (Written on mobile)

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Aijun Wang <[email-masked]<mailto:[email-masked]>>

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.

Best Regards

Aijun Wang
China Telecom

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Jun 2020 21:32:45 +0200

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 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=
[email-masked]> wrote:

> Darren,
>
>
>
> Does the SID described in RFC 8754 represent any of the SIDs in the
> Network Programming Draft? In any other document?
>
>
>
>
> Ron
>
>
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Darren Dukes (ddukes)
> *Sent:* Monday, June 15, 2020 12:21 PM
> *To:* Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
> *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:
>
> ------------------------------
>
> *From:* ipv6 <[email-masked]> on behalf of Aijun Wang <
> [email-masked]>
> *Sent:* Sunday, June 14, 2020 10:15 PM
> *To:* [email-masked]; [email-masked]
> *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:
>
> 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.
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jun 2020 21:26:35 +0000

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-masked]>
Sent: Monday, June 15, 2020 3:33 PM
To: Ron Bonica <[email-masked]>
Cc: Darren Dukes (ddukes) <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: About the upper layer header processing in RFC8754(SRH)

Hi Ron,

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=[email-masked]<mailto:[email-masked]>> wrote:
Darren,

                                                                              Ron

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Darren Dukes (ddukes)

Hello Aijun.

section 4.3.1 says:

Thanks
  Darren
  (Written on mobile)

Hi, Folks:

Best Regards

Aijun Wang
China Telecom

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VpA2yHsqImwMGaAtR4SPjzF6Ek2NKqm6gF4497TQ2fOFK-RBSZLDVLBl5gomzxK4$>
--------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Jun 2020 23:30:32 +0200

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 <[email-masked]> wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Monday, June 15, 2020 3:33 PM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* Darren Dukes (ddukes) <[email-masked]>; Aijun Wang <
> [email-masked]>; [email-masked]; [email-masked]
> 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
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!VpA2yHsqImwMGaAtR4SPjzF6Ek2NKqm6gF4497TQ2fOFK-RBSZLDVLBl5gomzxK4$>

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Jun 2020 07:51:41 +1000

On Tue, 16 Jun 2020 at 07:31, Robert Raszuk <[email-masked]> wrote:
>
> 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.
>

The IPv6 addressing model is 25 years old, going by the publication
date of RFC 1881 (1995).

IPv6 is like a 25 year old house. The purpose of some rooms is
flexible or somewhat flexible - a bedroom can be turned into a study,
or, depending on where it is located, a lounge room can be used as a
bedroom.

Other rooms in the house are fixed purpose and either are impossible
to change, or cannot be changed without a massive expense. It is
almost impossible to effectively change a kitchen into a bedroom, or a
bathroom into a kitchen.

At some point the house can't effectively be changed, and it is better
to design a new house. IPv6 isn't a house that is on the drawing board
any more, or is a house that is early in its construction such that
rooms' functions can be easily changed with minimal consequences.

If SPRING want a new forwarding architecture and a new addressing
architecture, then a new house needs to be designed.

Regards,
Mark.

>> Do we think that https://tools.ietf.org/html/rfc4291 section 2.5 still holds ? Do we need to keep stretching notion of interface to logical interfaces mapped to functions ?
>>
>>
>>
>> On Mon, Jun 15, 2020 at 9:08 PM Ron Bonica <rbonica=[email-masked]> wrote:
>>
>> Darren,
>>
>>
>>
>> RFC8754(SRH) section 4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4.3.1.2) describes the process of upper layer header as the followings:
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 16 Jun 2020 00:03:32 +0200

Hey Mark,

Thank you for presenting your house architectural perspective.

Mine is much simpler ... I compare IPv6 128 bits of address to a train.

First 64 bits is a locomotive and undercarriage which we better leave
alone.

However what goes into the remaining 64 bits are passengers travelling
along. As such some may be just tourists, some may be monks having
completely different missions in life. Yet another set may be gold miners
etc ... I really do not see a need to redo the train in general just to
accommodate different types of passengers to travel along. IMHO there is a
room there for all of the above.

Sure changing ethertype and designing new tracks is a very attractive
option. So is shortening the train engine to reduce the overhead - and I do
like those (in fact proposed some of this already both publicly and
privately), but Ron's mail is a bit shooting in between.

Anyhow I will leave it at that here,

Best,
R.

On Mon, Jun 15, 2020 at 11:52 PM Mark Smith <[email-masked]> wrote:

> > 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.
> >
>
> >> Cc: Darren Dukes (ddukes) <[email-masked]>; Aijun Wang <
> >> 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.
> >>
> >>
> >>
> >> No update to rfc8754 is necessary. Rfc8754 was written so new sids can
> be defined in other documents independently.
> >>
> >>
> >>
> >> section 4.3.1 says:
> >>
> >> RFC8754(SRH) section 4.3.1.2(https://tools..
> ietf.org/html/rfc8754#section-4.3.1.2) describes the process of upper
> layer header as the followings:
> >>
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1),
> >> 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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 15 Jun 2020 18:54:41 -0400

Hi Jingrong and Arjun

I believe what Daren is pointing out is that section 4.3.1 is referencing
RFC 8200 for next header processing.  Since that is stated in the beginning
of section 4 and pertains to all sub sections I believe  that would
suffice.  For SRv6 PGM draft I agree section 4 needs updating.  I think
that got clipped in Darens post.

4.3.1 <https://tools.ietf.org/html/rfc8754#section-4.3.1>.  FIB Entry
Is a Locally Instantiated SRv6 SID

   If the FIB entry represents a locally instantiated SRv6 SID, process
   the next header chain of the IPv6 header as defined in Section 4 of
   [RFC8200] <https://tools.ietf.org/html/rfc8200#section-4>.  Section
4.3.1.1 <https://tools.ietf.org/html/rfc8754#section-4.3.1.1>
describes how to process an SRH;
   Section 4.3.1.2
<https://tools.ietf.org/html/rfc8754#section-4.3.1.2> describes how to
process an upper-layer header or the
   absence of a Next Header.

Kind Regards

Gyan

On Mon, Jun 15, 2020 at 12:21 PM Darren Dukes (ddukes) <ddukes=
[email-masked]> wrote:

> <https://tools.ietf.org/html/rfc8754#section-4.3.1.2>) describes the
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 15 Jun 2020 19:08:49 -0400

Question regarding the IANA request for ethernet protocol number for SRV6.

https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

143 Ethernet Ethernet (TEMPORARY - registered 2020-01-31, expires
2021-01-31)

The ethernet protocol number request does seem odd as the protocol number
or next header is usually the upper layer protocol and not lower link
layer.

Is this for the 6in6 encapsulation that occurs on the SR source node ?

The next header would be IPv6 not ethernet I would think.

Gyan

On Mon, Jun 15, 2020 at 6:54 PM Gyan Mishra <[email-masked]> wrote:

> 4.3.1 <https://tools.ietf.org/html/rfc8754#section-4.3.1>.  FIB Entry Is a Locally Instantiated SRv6 SID
>
>    [RFC8200] <https://tools.ietf.org/html/rfc8200#section-4>.  Section 4.3.1.1 <https://tools.ietf.org/html/rfc8754#section-4.3.1.1> describes how to process an SRH;
>    Section 4.3.1.2 <https://tools.ietf.org/html/rfc8754#section-4.3.1.2> describes how to process an upper-layer header or the

*Gyan Mishra*

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jun 2020 23:38:06 +0000

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

Sent: Monday, June 15, 2020 5:31 PM

Hi Ron,

True !

Best,
Robert.

On Mon, Jun 15, 2020 at 11:26 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                   Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 15, 2020 3:33 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: About the upper layer header processing in RFC8754(SRH)

Hi Ron,

Best,
R.

                                                                              Ron

Hello Aijun.

section 4.3.1 says:

Thanks
  Darren
  (Written on mobile)

Hi, Folks:

Best Regards

Aijun Wang
China Telecom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jun 2020 23:43:26 +0000

Mark, Robert,

I will be in the club car of that train, enjoying a few shots of fernet branca.

                                                                        😉
                                                                         Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Monday, June 15, 2020 6:04 PM
To: Mark Smith <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: About the upper layer header processing in RFC8754(SRH)

Hey Mark,

First 64 bits is a locomotive and undercarriage which we better leave alone.

However what goes into the remaining 64 bits are passengers travelling along. As such some may be just tourists, some may be monks having completely different missions in life. Yet another set may be gold miners etc ... I really do not see a need to redo the train in general just to accommodate different types of passengers to travel along. IMHO there is a room there for all of the above.

Sure changing ethertype and designing new tracks is a very attractive option. So is shortening the train engine to reduce the overhead - and I do like those (in fact proposed some of this already both publicly and privately), but Ron's mail is a bit shooting in between.

Best,
R.

On Mon, Jun 15, 2020 at 11:52 PM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Mark.

>> Do we think that https://tools.ietf.org/html/rfc4291<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291__;!!NEt6yMaO-gk!TKMsiLjjiwnzhuK-tBniesZkFsQzOmCfv3ExPdLu6NasbfoHaWlPxGV6tAuWwMLF$> section 2.5 still holds ? Do we need to keep stretching notion of interface to logical interfaces mapped to functions ?
>>
>>
>>
>> RFC8754(SRH) section 4.3.1.2(https://tools.<https://urldefense.com/v3/__https:/tools.__;!!NEt6yMaO-gk!TKMsiLjjiwnzhuK-tBniesZkFsQzOmCfv3ExPdLu6NasbfoHaWlPxGV6tPejmhKs$>.ietf.org/html/rfc8754#section-4.3.1.2<https://urldefense.com/v3/__http:/ietf.org/html/rfc8754*section-4.3.1.2__;Iw!!NEt6yMaO-gk!TKMsiLjjiwnzhuK-tBniesZkFsQzOmCfv3ExPdLu6NasbfoHaWlPxGV6tNDQ73Ds$>) describes the process of upper layer header as the followings:
>>
>> 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!TKMsiLjjiwnzhuK-tBniesZkFsQzOmCfv3ExPdLu6NasbfoHaWlPxGV6tFUWCVJZ$>), one new Ethernet Next Header Type(143) is proposed.
>>
>>
>>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TKMsiLjjiwnzhuK-tBniesZkFsQzOmCfv3ExPdLu6NasbfoHaWlPxGV6tJgtyfti$>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TKMsiLjjiwnzhuK-tBniesZkFsQzOmCfv3ExPdLu6NasbfoHaWlPxGV6tJgtyfti$>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 16 Jun 2020 02:17:27 +0000

Hi Ron.

The SID described in RFC8754 is fully described there.

The SIDs in draft-ietf-spring-SRv6-network-programming are fully defined in that document.

Darren

________________________________
From: Ron Bonica <rbonica=[email-masked]>
Sent: Monday, June 15, 2020 3:08:12 PM
To: Darren Dukes (ddukes) <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Darren,

                                                                              Ron

Hello Aijun.

section 4.3.1 says:

Thanks

  Darren

  (Written on mobile)

Hi, Folks:

   }

   ELSE {

   ……

}

Best Regards

Aijun Wang

China Telecom

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 16 Jun 2020 15:39:52 +0800

Hi, Darren:

RFC8754 should defines the general processing rule for the SRH, not defining
any kind of SID. 

Different kinds of SID behavior should be defined in other documents, for
example, the network programming draft etc.

I think https://tools.ietf.org/html/rfc8754#section-4.3.1.1( for SRH) covers
all the processing rules that defined in
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-14. 

The description in  https://tools.ietf.org/html/rfc8754#section-4.3.1.2
(for Upper Layer)should also cover all the situations that defined in
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-14,
and the situations defined in any other related drafts.

And, if your statement is true, what kind of SID behavior is defined in this
section then? What is its relationship with the different SID behaviors
described in the network program draft?

Best Regards

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Darren
Dukes (ddukes)
发送时间: 2020年6月16日 10:17
收件人: Ron Bonica <rbonica=[email-masked]>; Aijun Wang
<[email-masked]>; [email-masked]; [email-masked]
主题: Re: About the upper layer header processing in RFC8754(SRH)

Hi Ron.

The SIDs in draft-ietf-spring-SRv6-network-programming are fully defined in
that document. 

Darren

  _____  

From: Ron Bonica <rbonica=[email-masked]
<mailto:rbonica=[email-masked]> >
Sent: Monday, June 15, 2020 3:08:12 PM
To: Darren Dukes (ddukes) <[email-masked] <mailto:[email-masked]> >;
Aijun Wang <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]>
>; [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >
Subject: RE: About the upper layer header processing in RFC8754(SRH) 

Darren,

Does the SID described in RFC 8754 represent any of the SIDs in the Network
Programming Draft? In any other document?

Ron

From: ipv6 <[email-masked] <mailto:[email-masked]> > On Behalf
Of Darren Dukes (ddukes)
Sent: Monday, June 15, 2020 12:21 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Subject: Re: About the upper layer header processing in RFC8754(SRH)

Hello Aijun. 

section 4.3.1 says:

 

Thanks

  Darren

  (Written on mobile)

  _____  

From: ipv6 <[email-masked] <mailto:[email-masked]> > on behalf
of Aijun Wang <[email-masked] <mailto:[email-masked]> >
Sent: Sunday, June 14, 2020 10:15 PM
To: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
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-5j3jjAVQJ
YjvxKIgrBz$> ) describes the process of upper layer header as the
followings:

   }

   ELSE {

   ……

}

And in network programming draft section
9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-pro
gramming-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_ZbJ6Iap
hycWPj08UYd8k9IPlcBP_h6HEasypDyifP-5j3jjAVQJYjv0iiulaO$> ), one new Ethernet
Next Header Type(143) is proposed.

Best Regards

Aijun Wang

China Telecom

---

From: Ron Bonica <[email-masked]>
Date: Tue, 16 Jun 2020 19:22:47 +0000

Darren,

Will the SID defined in RFC 8754 appear in the IANA SRv6 Endpoint Behavior Sub-registry? If not, can it be implemented?

                                                                                                   Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Monday, June 15, 2020 10:17 PM
To: Ron Bonica <[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: About the upper layer header processing in RFC8754(SRH)

Hi Ron.

Darren

________________________________
From: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Sent: Monday, June 15, 2020 3:08:12 PM
To: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Darren,

                                                                              Ron

Hello Aijun.

section 4.3.1 says:

Thanks

  Darren

  (Written on mobile)

Hi, Folks:

   }

   ELSE {

   ......

}

Best Regards

Aijun Wang

China Telecom