Subject: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Tue, 8 Mar 2022 01:58:00 +0000

Hi,

I just posted a draft that specifies a framework and some more detail of the idea for provisioning of underlay services (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using SRv6.

https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-overlay

Please comment and send any feedback.

I would like to discuss this document over e-mail/mail-list.

Best Regards,

Jingrong Xie

---

From: Tom Hill <[email-masked]>
Date: Wed, 9 Mar 2022 14:43:13 +0000

Hi Jinrong,

On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote:
> I just posted a draft that specifies a framework and some more detail of 
> the idea for provisioning of underlay services 
> (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using SRv6.
> 
> <https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-overlay>
> 

I'm concerned that this draft is explicitly violating the concept of 
SRv6 as a protocol that operates within a Limited Domain.

As per Section 3.2 of this draft, "... the network operator of AN, TN 
and Internet can be different from each other."

Further, "In some scenarios, the AN can be an Internet exchange provider 
(IXP) independent of ISP and NSP. In some other scenarios, the AN can be 
an ISP that running Internet backbone as well."

This would read to me that the proposal is explicitly intended to be 
inter-domain, and not at all limited to any one administrative domain. 
Additionally, I cannot determine if the draft implicitly requires the 
use of SIDs across the public Internet?

Could I ask for some clarification on the scope of the draft, with 
respect to Limited Domains, and also the use of SIDs over the public 
Internet?

Kind regards,

-- 
Tom

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 10 Mar 2022 06:40:27 +0000

Hi Tom,

Thanks for reading the draft and raise discussions.

In the proposal the SRv6 domain is the overlay network, belonging to one administrative domain -- the overlay network operator(say ONO). 

For your concern about use of SIDs "across" the public Internet. Let me try to explain using following figure (hope it works):

    CPE1                CPE2                 CPE3
     +                  +  +                  +
     |    +--------+    |  |   +----------+   |
     +---[1] TN1  [1]---+  +---+ Internet |---+
          +--------+           +----------+ 

In the perspective of the ONO, it has the following SIDs:
SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO.
SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, marked [1] in the figure).
The ONO can use these SIDs, and I would think they are all "in the overlay network", and are running "Over the Internet". 

You mentioned in the last sentence "the use of SIDs over the public Internet". That is what I am modeling above.

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: [email-masked]
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Jinrong,

On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote:
> I just posted a draft that specifies a framework and some more detail 
> of the idea for provisioning of underlay services

As per Section 3.2 of this draft, "... the network operator of AN, TN and Internet can be different from each other."

Further, "In some scenarios, the AN can be an Internet exchange provider
(IXP) independent of ISP and NSP. In some other scenarios, the AN can be an ISP that running Internet backbone as well."

This would read to me that the proposal is explicitly intended to be inter-domain, and not at all limited to any one administrative domain. 
Additionally, I cannot determine if the draft implicitly requires the use of SIDs across the public Internet?

Could I ask for some clarification on the scope of the draft, with respect to Limited Domains, and also the use of SIDs over the public Internet?

Kind regards,

--
Tom

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: Andrew Alston - IETF <[email-masked]>
Date: Thu, 10 Mar 2022 14:58:56 +0000

Hi Jingrong,

I'm struggling to entirely understand this.  I think the question for me is - if you are sending packets with SID's over the open internet - are you encapsulating those packets and is this encapsulation cryptographically protected - I.E the SID's are not visible outside of the encapsulation, to preserve the limited domain.

Limited domains are typically extended via tunnel mechanisms, very often with cryptographic protection, hence the question

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, March 10, 2022 9:40 AM
To: Tom Hill <[email-masked]>; [email-masked]
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Tom,

CPE1 CPE2 CPE3
+ + + +

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Jinrong,

On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote:
> https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov<https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov>
> erlay
> <https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-o<https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-o>
> verlay>
>

Kind regards,

--
Tom

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Mar 2022 19:26:29 -0500

Hi Jingrong

I reads the draft and was trying to understand the problem statement as
well as the solution.

So I believe the problem statement is how to interconnect desperate sites
over the internet using a managed IPSEC VPN or SDWAN solution or managed
MPLS and complexity of provisioning CE attachment.

The solution is an automated solution using SRv6 over the internet using
BSID.  This involves running SRv6 over the internet, however SRv6 is
limited to closed domains.  It appears an E2E pseudowire is used in
provisioning the service.  Have you though of using NG L2 VPN EVPN all or
single active multi home over SRv6.

Does all the provisioning use a PCE / SDN controller?

Thanks

Gyan

On Thu, Mar 10, 2022 at 9:59 AM Andrew Alston - IETF <andrew-ietf=
[email-masked]> wrote:

> Hi Jingrong,
>
>
>
> I’m struggling to entirely understand this.  I think the question for me
> is – if you are sending packets with SID’s over the open internet – are you
> encapsulating those packets and is this encapsulation cryptographically
> protected – I.E the SID’s are not visible outside of the encapsulation, to
> preserve the limited domain.
>
>
>
> Limited domains are typically extended via tunnel mechanisms, very often
> with cryptographic protection, hence the question
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Xiejingrong
> (Jingrong)
> *Sent:* Thursday, March 10, 2022 9:40 AM
> *To:* Tom Hill <[email-masked]>; [email-masked]
> *Subject:* Re: [spring] Network Programming Interface for Provisioning of
> Underlay Services to Overlay Networks Using SRv6
> (draft-xie-spring-srv6-npi-for-overlay)
>
>
>
> Hi Tom,
>
> In the proposal the SRv6 domain is the overlay network, belonging to one
> administrative domain -- the overlay network operator(say ONO).
>
> For your concern about use of SIDs "across" the public Internet. Let me
> try to explain using following figure (hope it works):
>
> CPE1 CPE2 CPE3
> + + + +
> The ONO can use these SIDs, and I would think they are all "in the overlay
> network", and are running "Over the Internet".
>
> You mentioned in the last sentence "the use of SIDs over the public
> Internet". That is what I am modeling above.
>
> Thanks
> Jingrong
>
>
> From: spring [mailto:[email-masked] <[email-masked]>]
> On Behalf Of Tom Hill
> Subject: Re: [spring] Network Programming Interface for Provisioning of
> Underlay Services to Overlay Networks Using SRv6
> (draft-xie-spring-srv6-npi-for-overlay)
>
> Hi Jinrong,
>
> As per Section 3.2 of this draft, "... the network operator of AN, TN and
> Internet can be different from each other."
>
> Could I ask for some clarification on the scope of the draft, with respect
> to Limited Domains, and also the use of SIDs over the public Internet?
>
> Kind regards,
>
> --
> Tom
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 14 Mar 2022 07:16:19 +0000

Hi,

I think I now understand better the concern about "the use of SIDs over the public Internet".
In my previous mail, the SID2/SID3 used between CPE2-Internet-CPE3 is to explain the layering model (over vs across), but it is not the proposal of the draft.
The draft is talking about the interface (name NPI) that overlay networks use to access the underlying network in the last mile.
There may be an Access Network (AN) in the last mile, and the AN may also connect to Internet backbone and/or multiple underlying networks, but it is distinct from the "open Internet".
Make more sense if the AN can enhance (if no way to enforce) not to leak the SRv6 BSID to Internet backbone or other TNs ?

For the control plane, it is still not clear if a controller is required, but one thing I considered is to use an IETF standard protocol because the PE need to implement the NPI.

Regards,
Jingrong

From: Gyan Mishra [mailto:[email-masked]]
Sent: Sunday, March 13, 2022 8:26 AM
To: Andrew Alston - IETF <[email-masked]>
Cc: Tom Hill <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Jingrong

I reads the draft and was trying to understand the problem statement as well as the solution.

So I believe the problem statement is how to interconnect desperate sites over the internet using a managed IPSEC VPN or SDWAN solution or managed MPLS and complexity of provisioning CE attachment.

The solution is an automated solution using SRv6 over the internet using BSID.  This involves running SRv6 over the internet, however SRv6 is limited to closed domains.  It appears an E2E pseudowire is used in provisioning the service.  Have you though of using NG L2 VPN EVPN all or single active multi home over SRv6.

Thanks

Gyan

On Thu, Mar 10, 2022 at 9:59 AM Andrew Alston - IETF <andrew-ietf=[email-masked]<mailto:[email-masked]>> wrote:
Hi Jingrong,

I’m struggling to entirely understand this.  I think the question for me is – if you are sending packets with SID’s over the open internet – are you encapsulating those packets and is this encapsulation cryptographically protected – I.E the SID’s are not visible outside of the encapsulation, to preserve the limited domain.

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, March 10, 2022 9:40 AM
To: Tom Hill <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Tom,

CPE1 CPE2 CPE3
+ + + +

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Jinrong,

Kind regards,

--
Tom

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Andrew Alston - IETF <[email-masked]>
Date: Mon, 14 Mar 2022 15:16:26 +0000

Jingrong,

Limited Domain (in my view) refers to a domain where all points are under single administrative control.  I.E the source, destination and anything in the middle must fall under the same administrative control, otherwise, you are not within the limited domain.  This can be extended using encapsulation (tunneling) where the packet is encapsulated and preferably cryptographically protected, such that any intermediate networks outside of the same administrative control cannot, either by error or deliberate action, act on the information contained within the routing headers.

Anything else would run into issues with section 8.2 of RFC8402.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Xiejingrong (Jingrong)
Sent: Monday, March 14, 2022 10:16 AM
To: Gyan Mishra <[email-masked]>; Andrew Alston - IETF <[email-masked]>
Cc: [email-masked]; Tom Hill <[email-masked]>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi,

Regards,
Jingrong

From: Gyan Mishra [mailto:[email-masked]]
Sent: Sunday, March 13, 2022 8:26 AM
To: Andrew Alston - IETF <[email-masked]<mailto:[email-masked]>>
Cc: Tom Hill <[email-masked]<mailto:[email-masked]>>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Jingrong

Thanks

Gyan

Thanks

Andrew

Hi Tom,

CPE1 CPE2 CPE3
+ + + +

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Jinrong,

Kind regards,

--
Tom

Gyan Mishra

M 301 502-1347

---

From: Eduard Metz <[email-masked]>
Date: Tue, 15 Mar 2022 14:02:27 +0100

Hello Jingrong,

I haven't read your draft in detail yet, but the question of how to expose
SRv6 based transport service / capabilities for consumption by overlay
networks I think is an interesting one.

I'm not sure whether the reference figure (5) already conflicts with
"limited domain", assuming one would expose such services only to a
controlled set of CPE I would say it doesn't. I have to agree with others
who commented that the scope of the draft is not fully clear though. It
suggests to aim to solve "interdomain" cases, while in the solution part
the focus seems to be again on the question of how to expose services.

It would help if the scope is clarified.
By the way, I interpreted the scope as described in the first sentence
above, is this correct?

cheers,
  Eduard

On Mon, Mar 14, 2022 at 4:17 PM Andrew Alston - IETF <andrew-ietf=
[email-masked]> wrote:

> Jingrong,
>
>
>
> Limited Domain (in my view) refers to a domain where all points are under
> single administrative control.  I.E the source, destination and anything in
> the middle must fall under the same administrative control, otherwise, you
> are not within the limited domain.  This can be extended using
> encapsulation (tunneling) where the packet is encapsulated and preferably
> cryptographically protected, such that any intermediate networks outside of
> the same administrative control cannot, either by error or deliberate
> action, act on the information contained within the routing headers.
>
>
>
> *Sent:* Monday, March 14, 2022 10:16 AM
> *To:* Gyan Mishra <[email-masked]>; Andrew Alston - IETF
> <[email-masked]>
> *Cc:* [email-masked]; Tom Hill <[email-masked]>
> In my previous mail, the SID2/SID3 used between CPE2-Internet-CPE3 is to
> explain the layering model (over vs across), but it is not the proposal of
> the draft.
>
> The draft is talking about the interface (name NPI) that overlay networks
> use to access the underlying network in the last mile.
>
> There may be an Access Network (AN) in the last mile, and the AN may also
> connect to Internet backbone and/or multiple underlying networks, but it is
> distinct from the "open Internet".
>
> Make more sense if the AN can enhance (if no way to enforce) not to leak
> the SRv6 BSID to Internet backbone or other TNs ?
>
>
>
> For the control plane, it is still not clear if a controller is required,
> but one thing I considered is to use an IETF standard protocol because the
> PE need to implement the NPI.
>
>
>
> Regards,
>
> Jingrong
>
>
>
> *From:* Gyan Mishra [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Sunday, March 13, 2022 8:26 AM
> *To:* Andrew Alston - IETF <[email-masked]>
> *Cc:* Tom Hill <[email-masked]>; Xiejingrong (Jingrong) <
> [email-masked]>; [email-masked]
> is – if you are sending packets with SID’s over the open internet – are
> you encapsulating those packets and is this encapsulation cryptographically
> protected – I.E the SID’s are not visible outside of the encapsulation,
> to preserve the limited domain.
>
>
>
> *Network Solutions Architect *
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 16 Mar 2022 07:31:06 +0000

Hello Eduard,

Thank you for reading and the positive feedback on this draft.
Your interpretation in the first sentence is basically correct but incomplete.
This draft is about how to expose transport service / capabilities for consumption by overlay networks, and this point is very precisely caught(twice) in your mail.
The exposing of the transport service to overlay network outside is abstracted as an "Interface", and is proposed to use SRv6 in this draft.
However, the transport service is not limited to SRv6-based transport service, but can be implemented independently of the Interface spec, for example, can be implemented using SRv6 or MPLS.

For the suggestion to clarify the scope, I would think about how to clarify, and send the proposed text to mailing-list for discussion.

Before this, I would like to share my points and hope it useful to understand the draft for you all.

1) Currently SRv6 SIDs are mainly used inside a TN, and hence the "Net-PGM Instruction" is an appropriate description, and it is easy to understand as the limited-domain is TN.

2) The draft is describing an "Net-PGM Interface" that is exposed outside a TN. Once exposed, the use of the SRv6 SID is in the "Overlay network", and hence the limited-domain is the Overlay network.

3) The Overlay network is an administrative domain, and the SRv6 domain is only part of the Overlay network.
   For example, in the figure in https://mailarchive.ietf.org/arch/msg/spring/Y21yvJO-I2ex-8VNSjoDbWA9qCk/ , the CPE1, CPE2 and the exposed Interface of TN1 is an SRv6 domain, but CPE3 is not the SRv6 domain.

4) An Overlay network may uses N Transport-Networks, and there could be N SRv6 domains, each surrounding a TN.

Regards,
Jingrong

From: Eduard Metz [mailto:[email-masked]]
Sent: Tuesday, March 15, 2022 9:02 PM
To: Andrew Alston - IETF <[email-masked]>
Cc: Xiejingrong (Jingrong) <[email-masked]>; Gyan Mishra <[email-masked]>; Andrew Alston - IETF <[email-masked]>; [email-masked]; Tom Hill <[email-masked]>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hello Jingrong,

I haven't read your draft in detail yet, but the question of how to expose SRv6 based transport service / capabilities for consumption by overlay networks I think is an interesting one.

I'm not sure whether the reference figure (5) already conflicts with "limited domain", assuming one would expose such services only to a controlled set of CPE I would say it doesn't. I have to agree with others who commented that the scope of the draft is not fully clear though. It suggests to aim to solve "interdomain" cases, while in the solution part the focus seems to be again on the question of how to expose services.

It would help if the scope is clarified.
By the way, I interpreted the scope as described in the first sentence above, is this correct?

cheers,
  Eduard

On Mon, Mar 14, 2022 at 4:17 PM Andrew Alston - IETF <andrew-ietf=[email-masked]<mailto:[email-masked]>> wrote:
Jingrong,

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Xiejingrong (Jingrong)
Sent: Monday, March 14, 2022 10:16 AM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Andrew Alston - IETF <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Tom Hill <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi,

Regards,
Jingrong

Hi Jingrong

Thanks

Gyan

Thanks

Andrew

Hi Tom,

CPE1 CPE2 CPE3
+ + + +

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay)

Hi Jinrong,

Kind regards,

--
Tom

Gyan Mishra

M 301 502-1347