Re: [spring] [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt

[Greg Mirsky]

Hi Ahmed and the Authors,
thank you for sharing this information. I've read the draft and have
several questions and comments:

   - It is not clear if you propose a new active measurement protocol or
   view it as a hybrid method (based on RFC 7799 classification). On one hand,
   packets are referred to as probes, but I don't see why the new Hb H option
   cannot be applied to a data packet.
   - Resemblance with IOAM is very strong and it seems that the only
   advantage of PT over IOAM seems in the introduction of a Truncated
   Timestamp IE  for a Midpoint node. If the same IE is added in IOAM, what do
   you see as the benefit of using PT compared to IOAM?
   - In the draft you describe how to use PT to collect timestamps along a
   path. T64 is recorded in PTP 64 bit-long format. What is the format used to
   record a Truncated Timestamp? Also, I couldn't find an explanation why PT
   uses only one timestamp format and, for example, does not allow using NTP
   64 bit-long timestamp format.
   - Furthermore, one-way delay measurement requires clock synchronization.
   OIj the draft you use two use cases for PT, intercontinental and DC, what
   should be the accuracy of the clock synchronization in the domain to ensure
   the PT produces useful measurement data?
   - As I understand the process of collecting truncated timestamps at a
   midpoint system, it records the value into the HbH IPv6 EH. You suggest
   that the time value is "the time at which the packet egress the router".
   But since a new value is written in the packet, should the checksum be
   re-calculated? And if that is the case, would that cause a variable delay
   that affects the accuracy of the measurement provided by the PT method?
   - Related to the above mentioned scenario, I find that IOAM has an
   advantage compared with the PT method as a process of generating telemetry
   data can be separated from transporting that telemetry information for
   processing. For example, using IOAM Direct Export or Hybrid Two-Step
   mechanisms. Such separation allows for more accurate measurements and also
   can be conducted out-of-band relative to the monitored data flow.

I greatly appreciate your kind consideration of my comments and questions
and looking forward to an interesting discussion.

Regards,
Greg

On Wed, Mar 9, 2022 at 6:14 AM Ahmed Abdelsalam (ahabdels)  wrote:

> Dear SPRING WG,  IPPM WG,
>
>
>
> We have submitted a new I-D for Path Tracing in SRv6 networks (
> https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing)
> to SPRING WG.
>
>
>
> We are looking for your feedback and comments.
>
>
>
> Path Tracing provides a record of the packet path as a sequence of
> interface ids. In addition, it provides a record of end-to-end delay,
> per-hop delay, and load on each egress interface along the packet delivery
> path to facilitate operation of SR networks.
>
>
>
> Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop
> extension header.
>
>
>
> We will present Path Tracing to the SPRING WG at next IETF (
> https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt)
>
>
>
>
> Thanks,
>
> Ahmed
>
>
>
> *From: *internet-dra...@ietf.org 
> *Date: *Friday, 4 March 2022 at 16:48
> *To: *Ahmed Abdelsalam (ahabdels) , cf(mailer list) <
> c...@cisco.com>, Mark Yufit , Pablo Camarillo
> (pcamaril) , Pablo Camarillo (pcamaril) <
> pcama...@cisco.com>, Satoru Matsushima ,
> Thomas.Graf , Yuanchao Su <
> yitai@alibaba-inc.com>
> *Subject: *New Version Notification for
> draft-filsfils-spring-path-tracing-00.txt
>
>
> A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
> has been successfully submitted by Pablo Camarillo Garvia and posted to the
> IETF repository.
>
> Name:   draft-filsfils-spring-path-tracing
> Revision:   00
> Title:  Path Tracing in SRv6 networks
> Document date:  2022-03-04
> Group:  Individual Submission
> Pages:  15
> URL:
> https://www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing
>
>
> Abstract:
>Path Tracing provides a record of the packet path as a sequence of
>interface ids.  In addition, it provides a record of end-to-end
>delay, per-hop delay, and load on each egress interface along the
>packet delivery path.
>
>Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop-
>by-Hop extension header.
>
>Path Tracing supports fine grained timestamp.  It has been designed
>for linerate hardware implementation in the base pipeline.
>
>
>
>
>
> The IETF Secretariat
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
___
spring mailing list
spring@ietf.org

[spring] SPRING Chairs observation on WG calls for consensus

[Joel M. Halpern]

In discussion with chairs of other routing working groups, it was noted 
that there is sometimes confusion or misunderstanding about what is 
sought when the chairs conduct adoption calls and WG last calls.


The top line is that we are looking for working group support and review.

In the case of adoption we are looking for whether the working group 
considers the document a good starting point for the problem, whether 
working group participants want to work on the problem, and whether 
there is enough active participation to support and review the work.

This is also why we find "+1" response to be unhelpful in judging this.

For working group last call, we are looking for whether the working 
group thinks the document is in good enough shape to be sent to the IESG 
and the IETF community.


In particular, we assume that the authors of a document are in support 
of it.  What is of interest to us when we issue these calls is about the 
opinion of the rest of the working group.  Working group adoption and 
completion requires that more than just the author team supports the 
work.  It needs broad working group support and review.


Yours,
Bruno, Jim, and Joel

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] WG adoption for draft-boutros-spring-elan-services-over-sr-00

[Boutros, Sami]

Dear WG Chairs,

The authors would like to request a WG adoption for this draft, the draft was 
presented at last IETF.

We could present the draft at this IETF too, if you folks like.

Thanks,

Sami
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Andrew Alston - IETF]

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  On Behalf Of Xiejingrong (Jingrong)
Sent: Monday, March 14, 2022 10:16 AM
To: Gyan Mishra ; Andrew Alston - IETF 

Cc: spring@ietf.org; 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,

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:hayabusa...@gmail.com]
Sent: Sunday, March 13, 2022 8:26 AM
To: Andrew Alston - IETF 
mailto:andrew-i...@liquid.tech>>
Cc: Tom Hill mailto:t...@ninjabadger.net>>; Xiejingrong 
(Jingrong) mailto:xiejingr...@huawei.com>>; 
spring@ietf.org
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.

Does all the provisioning use a PCE / SDN controller?


Thanks

Gyan

On Thu, Mar 10, 2022 at 9:59 AM Andrew Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>> 
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 mailto:spring-boun...@ietf.org>> On 
Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, March 10, 2022 9:40 AM
To: Tom Hill mailto:t...@ninjabadger.net>>; 
spring@ietf.org
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,

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 

Re: [spring] New Version Notification for draft-filsfils-spring-path-tracing-00.txt

[Andrew Alston - IETF]

Hi There,

Speaking entirely as a working group participant,

I have two substantial concerns with this document at first skim read.

Firstly - the 12 bits for an interface ID - I have serious concerns that this 
will be far from sufficient.  Keep in mind you have interface specific VLAN's 
(that alone can eat 12 bits), you have PWHE terminated interfaces - and I know 
of several cases where those are used for termination of logical circuits that 
would be doing this type of traffic, etc etc, and in effect, you can very 
easily exceed the 4096 interface ID's on a single router.

Secondly, in the security considerations section of the document, last 
paragraph of section 11.  It states "The HBH-PT option MUST be processed at 
line rate." I think the wording here probably needs work.  Could we not say 
that "A router that cannot process the HBH-PT option in fast path must ignore 
said option" Because "line rate" does not actually refer to packets that avoid 
punt to the CPU - all it means is that the CPU's are fast enough to not slow 
other things down while processing it.

Thanks

Andrew




From: spring  On Behalf Of Ahmed Abdelsalam (ahabdels)
Sent: Wednesday, March 9, 2022 5:13 PM
To: spring@ietf.org; spring-cha...@ietf.org; i...@ietf.org
Subject: [spring] FW: New Version Notification for 
draft-filsfils-spring-path-tracing-00.txt

Dear SPRING WG,  IPPM WG,

We have submitted a new I-D for Path Tracing in SRv6 networks 
(https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing)
 to SPRING WG.

We are looking for your feedback and comments.

Path Tracing provides a record of the packet path as a sequence of interface 
ids. In addition, it provides a record of end-to-end delay, per-hop delay, and 
load on each egress interface along the packet delivery path to facilitate 
operation of SR networks.

Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop 
extension header.

We will present Path Tracing to the SPRING WG at next IETF 
(https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt)

Thanks,
Ahmed

From: internet-dra...@ietf.org 
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) , cf(mailer list) 
, Mark Yufit , Pablo Camarillo 
(pcamaril) , Pablo Camarillo (pcamaril) 
, Satoru Matsushima , 
Thomas.Graf , Yuanchao Su 
Subject: New Version Notification for draft-filsfils-spring-path-tracing-00.txt

A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
has been successfully submitted by Pablo Camarillo Garvia and posted to the
IETF repository.

Name:   draft-filsfils-spring-path-tracing
Revision:   00
Title:  Path Tracing in SRv6 networks
Document date:  2022-03-04
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing


Abstract:
   Path Tracing provides a record of the packet path as a sequence of
   interface ids.  In addition, it provides a record of end-to-end
   delay, per-hop delay, and load on each egress interface along the
   packet delivery path.

   Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop-
   by-Hop extension header.

   Path Tracing supports fine grained timestamp.  It has been designed
   for linerate hardware implementation in the base pipeline.




The IETF Secretariat
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Xiejingrong (Jingrong)]

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:hayabusa...@gmail.com]
Sent: Sunday, March 13, 2022 8:26 AM
To: Andrew Alston - IETF 
Cc: Tom Hill ; Xiejingrong (Jingrong) 
; spring@ietf.org
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.

Does all the provisioning use a PCE / SDN controller?


Thanks

Gyan

On Thu, Mar 10, 2022 at 9:59 AM Andrew Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>> 
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 mailto:spring-boun...@ietf.org>> On 
Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, March 10, 2022 9:40 AM
To: Tom Hill mailto:t...@ninjabadger.net>>; 
spring@ietf.org
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,

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:spring-boun...@ietf.org] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: spring@ietf.org
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
> (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-ov
> erlay
>  verlay>
>
> Please comment and send any feedback.
>
> I would like to discuss this document over e-mail/mail-list.


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