Re: [Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Dhruv

Your proposed text is even better like it is.

No hard feeling for the TLV name, I will defer to Erik Kline (the ONLINK name 
was suggested when there were 2 addresses and made sense for 2 addresses)

-éric

-Original Message-
From: Dhruv Dhody 
Date: Friday, 26 February 2021 at 08:25
To: Eric Vyncke 
Cc: "Pengshuping (Peng Shuping)" , Erik Kline 
, Julien Meuric , "pce@ietf.org" 
, The IESG , pce-chairs , 
"draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org" 

Subject: Re: Éric Vyncke's Discuss on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

Hi Eric,

On Fri, Feb 26, 2021 at 12:45 PM Eric Vyncke (evyncke)
 wrote:
>
> Shuping,
>
> The text is much better but may I still suggest the following:
>
> --- Proposed text by the authors --
>  Further, this document specify a new TLV called 
ONLINK-IPV6-ADDRESS
>to describe an IPv6 unnumbered adjacency for a link that does 
not
>have an IPv6 address assigned.
>
>  Proposed text by Éric Vyncke 
>  Further, this document specify a new TLV called 
LINKLOCAL-IPV6-ADDRESS
>to describe an IPv6 unnumbered adjacency for an interface that 
does not
>have a global IPv6 address assigned.
> -
> As a side note, I find " IPv6 unnumbered adjacency" a very strange 
wording as an IPv6 always has a 'number' in the sense that link-local address 
is always there.
>

Maybe we could say -

   Further, this document specifies a new TLV called
LINKLOCAL-IPV6-ADDRESS
   to describe an IPv6 adjacency for an interface that does not
   have a global IPv6 address assigned.

Erik suggested using ONLINK instead of LINKLOCAL for the TLV name. I
am not sure, to me using LINKLOCAL to match with RFC 8664 seems to be
okay. Any thoughts on that?

Thanks!
Dhruv



> Once the revised I-D is posted, then I am clearing my DISCUSS point 
(please send me an email when the revised I-D is posted)
>
> -éric
>
> -Original Message-
> From: "Pengshuping (Peng Shuping)" 
> Date: Friday, 26 February 2021 at 04:43
> To: Erik Kline , Dhruv Dhody 
> Cc: Eric Vyncke , Julien Meuric 
, "pce@ietf.org" , The IESG 
, pce-chairs , 
"draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org" 

> Subject: RE: Éric Vyncke's Discuss on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)
>
> Hi Erik,
>
> Thank you for your comments! Please find the diff including the 
updates based on your comments. Thank you!
>
> Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt
>
> Best regards,
> Shuping
>
>
>
> -Original Message-
> From: Erik Kline [mailto:ek.i...@gmail.com]
> Sent: Thursday, February 25, 2021 11:57 PM
> To: Dhruv Dhody 
> Cc: Éric Vyncke ; Julien Meuric 
; pce@ietf.org; The IESG ; pce-chairs 
; draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
> Subject: Re: Éric Vyncke's Discuss on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)
>
> Dhruv,
>
> Thanks for this.
>
> >From my previous review, for reference only:
>
> """
> * Saying that the LINKLOCAL-IPV6-ID-ADDRESS TLV holds a pair of 
global IPv6
>   addresses seems confusing to me.
>
>   If the pair of global IPv6 addresses is to be considered "on link" 
in the
>   sense that IPv6 ND can be successfully be performed on the link for 
both
>   of these addresses, then "ONLINK" might be better than LINKLOCAL.
>
> * Also, why are two interface IDs required?  I would have expected 
that only
>   the outgoing interface name/ID would be of relevance to the 
recipient of
>   a message with TLV in it?
> """
>
> Just for your consideration, in case "ONLINK" seems like it might be 
useful naming.
>
> One more thing of note: I am terrible at naming!
>
> On Thu, Feb 25, 2021 at 7:46 AM Dhruv Dhody  
wrote:
> >
> > Hi Eric,
> >
> > I discussed this offline with one of the authors, who confirmed that
> > while NAI in RFC 8664 uses a pair, in this case, the pair is not
> > needed for the next-hop information and it can be updated as 
suggested
> > by you.
> >
> > Thanks!
> > Dhruv
> >
> > On Thu, Feb 25, 2021 at 8:50 PM Dhruv Dhody  
wrote:
> > >
> > > Hi Eric,
> > >
> > > On Thu, Feb 25, 2021 at 

Re: [Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Dhruv Dhody]

Hi Eric,

On Fri, Feb 26, 2021 at 12:45 PM Eric Vyncke (evyncke)
 wrote:
>
> Shuping,
>
> The text is much better but may I still suggest the following:
>
> --- Proposed text by the authors --
>  Further, this document specify a new TLV called 
> ONLINK-IPV6-ADDRESS
>to describe an IPv6 unnumbered adjacency for a link that does not
>have an IPv6 address assigned.
>
>  Proposed text by Éric Vyncke 
>  Further, this document specify a new TLV called 
> LINKLOCAL-IPV6-ADDRESS
>to describe an IPv6 unnumbered adjacency for an interface that 
> does not
>have a global IPv6 address assigned.
> -
> As a side note, I find " IPv6 unnumbered adjacency" a very strange wording as 
> an IPv6 always has a 'number' in the sense that link-local address is always 
> there.
>

Maybe we could say -

   Further, this document specifies a new TLV called
LINKLOCAL-IPV6-ADDRESS
   to describe an IPv6 adjacency for an interface that does not
   have a global IPv6 address assigned.

Erik suggested using ONLINK instead of LINKLOCAL for the TLV name. I
am not sure, to me using LINKLOCAL to match with RFC 8664 seems to be
okay. Any thoughts on that?

Thanks!
Dhruv



> Once the revised I-D is posted, then I am clearing my DISCUSS point (please 
> send me an email when the revised I-D is posted)
>
> -éric
>
> -Original Message-
> From: "Pengshuping (Peng Shuping)" 
> Date: Friday, 26 February 2021 at 04:43
> To: Erik Kline , Dhruv Dhody 
> Cc: Eric Vyncke , Julien Meuric 
> , "pce@ietf.org" , The IESG 
> , pce-chairs , 
> "draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org" 
> 
> Subject: RE: Éric Vyncke's Discuss on 
> draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and 
> COMMENT)
>
> Hi Erik,
>
> Thank you for your comments! Please find the diff including the updates 
> based on your comments. Thank you!
>
> Diff: 
> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt
>
> Best regards,
> Shuping
>
>
>
> -Original Message-
> From: Erik Kline [mailto:ek.i...@gmail.com]
> Sent: Thursday, February 25, 2021 11:57 PM
> To: Dhruv Dhody 
> Cc: Éric Vyncke ; Julien Meuric 
> ; pce@ietf.org; The IESG ; 
> pce-chairs ; 
> draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
> Subject: Re: Éric Vyncke's Discuss on 
> draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and 
> COMMENT)
>
> Dhruv,
>
> Thanks for this.
>
> >From my previous review, for reference only:
>
> """
> * Saying that the LINKLOCAL-IPV6-ID-ADDRESS TLV holds a pair of global 
> IPv6
>   addresses seems confusing to me.
>
>   If the pair of global IPv6 addresses is to be considered "on link" in 
> the
>   sense that IPv6 ND can be successfully be performed on the link for both
>   of these addresses, then "ONLINK" might be better than LINKLOCAL.
>
> * Also, why are two interface IDs required?  I would have expected that 
> only
>   the outgoing interface name/ID would be of relevance to the recipient of
>   a message with TLV in it?
> """
>
> Just for your consideration, in case "ONLINK" seems like it might be 
> useful naming.
>
> One more thing of note: I am terrible at naming!
>
> On Thu, Feb 25, 2021 at 7:46 AM Dhruv Dhody  wrote:
> >
> > Hi Eric,
> >
> > I discussed this offline with one of the authors, who confirmed that
> > while NAI in RFC 8664 uses a pair, in this case, the pair is not
> > needed for the next-hop information and it can be updated as suggested
> > by you.
> >
> > Thanks!
> > Dhruv
> >
> > On Thu, Feb 25, 2021 at 8:50 PM Dhruv Dhody  wrote:
> > >
> > > Hi Eric,
> > >
> > > On Thu, Feb 25, 2021 at 8:35 PM Éric Vyncke via Datatracker
> > >  wrote:
> > > >
> > > > Éric Vyncke has entered the following ballot position for
> > > > draft-ietf-pce-pcep-extension-for-pce-controller-12: Discuss
> > > >
> > > > When responding, please keep the subject line intact and reply to
> > > > all email addresses included in the To and CC lines. (Feel free to
> > > > cut this introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to
> > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for
> > > > -pce-controller/
> > > >
> > > >
> > > >
> > > > --
>   

Re: [Pce] new draft on segment routing approach to TSN

[Jakob Heitz (jheitz)]

i'm talking about point to point

Regards,
Jakob.


On Feb 25, 2021, at 10:08 PM, Yaakov Stein  wrote:


And I forgot to mention the real way this is handled in sophisticated wireless 
systems.

There shouldn’t be any idle time!

If there are less bits to be transmitted then the modulation order is reduced
increasing the margin and reducing the probability of error!

Even for NRZ Ethernet transmitting random frames that happen to the next in a 
cyclic buffer
is in general not the best option.
Not only does it not guarantee retransmission of a bad packet (unless is really 
very little to transmit),
it wastes a lot of energy on transmitting packets that have already been 
received.
If there is so little to transmit you should be powering down your transmitter 
(802.3az).

Y(J)S

From: Jakob Heitz (jheitz) 
Sent: 26/02/2021 07:56
To: Yaakov Stein ; Pascal Thubert (pthubert) 

Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Lots of ways. Another:
Use a circular buffer. As you transmit a packet put it into the buffer.
As it is acknowledged, remove it.
Just keep transmitting the buffer circularly.
If one is NACKed, retransmit it immediately.
The receiver can keep track of received sequence numbers.
They should be in order. Ack the latest sequence whenever there is a chance.
If the receiver sees a hole in the received sequence, NACK it.

Regards,
Jakob.

From: Yaakov Stein mailto:yaako...@rad.com>>
Sent: Thursday, February 25, 2021 9:48 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Jakob

I forgot to address your first sentence.

Retransmission without NACK is an interesting idea, but I am not sure it really 
helps.

If there is nothing to be transmitted then you could go into a loop and 
retransmit packets over and over,
but I assume that this usually won’t happen.
So assume that you have a short idle window – which packet are you going to 
retransmit?
Without knowing which packet was not received correctly you have no idea.

So let’s assume that you reserve a full 50% of your BW and retransmit every 
packet.
Some packets received twice will differ – which one is correct? You can’t know 
without a FEC.
And if you are using a FEC it is more efficient to use a strong one then 
retransmit the whole packet!

So, let’s assume that you don’t use a FEC (maybe you don’t want the hassle of 
implementing one in hardware).
Then you need to send each packet at least 3 times to be able to do a majority 
decision.
So, you have reduced your BW efficiency to 33%.

I’m not saying that this is never justified. Lots of messages are sent 3 times 
for redundancy.
Going back to cellular, triple redundancy is used for critical control messages 
(in addition to other error correction means)/
But only for them. It is really suboptimal for everything else.

Y(J)S




From: Yaakov Stein
Sent: 26/02/2021 07:38
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

My point regarding HARQ was that this kind of retransmission can be more 
efficiently handled
at layers lower than where you see packets.
4G/5G has actually two mechanisms precisely of the type you suggest at two 
different layers,
but the magic happens on the physical signals (HARQ) or the SDUs (PDCP 
retransmission)
and is completely transparent to the user packets.

True, high speed Ethernet links are no longer physical broadcast domains
and one could insert sequence numbers into the frames and perform local 
retransmission.
This has been done in the past (I personally have a patent on such a method, 
although it also gives an alternative to numbering).
But if you are already numbering it might be even better to go all the way and 
use RFER.
(Or maybe even combine ACK/NACK retransmission and replication.)

Y(J)S


From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 07:00
To: Yaakov Stein mailto:yaako...@rad.com>>; Pascal Thubert 
(pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Suppose you're sending packets out an interface and all the queues are empty. 
You got nothing to send.
What are you going to do with the dead air? Send idle patterns?
No.
Retransmit

Re: [Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Shuping,

The text is much better but may I still suggest the following:

--- Proposed text by the authors --
 Further, this document specify a new TLV called 
ONLINK-IPV6-ADDRESS
   to describe an IPv6 unnumbered adjacency for a link that does not
   have an IPv6 address assigned.

 Proposed text by Éric Vyncke 
 Further, this document specify a new TLV called 
LINKLOCAL-IPV6-ADDRESS 
   to describe an IPv6 unnumbered adjacency for an interface that does 
not  
   have a global IPv6 address assigned.
-
As a side note, I find " IPv6 unnumbered adjacency" a very strange wording as 
an IPv6 always has a 'number' in the sense that link-local address is always 
there.

Once the revised I-D is posted, then I am clearing my DISCUSS point (please 
send me an email when the revised I-D is posted)

-éric

-Original Message-
From: "Pengshuping (Peng Shuping)" 
Date: Friday, 26 February 2021 at 04:43
To: Erik Kline , Dhruv Dhody 
Cc: Eric Vyncke , Julien Meuric , 
"pce@ietf.org" , The IESG , pce-chairs 
, 
"draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org" 

Subject: RE: Éric Vyncke's Discuss on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

Hi Erik, 

Thank you for your comments! Please find the diff including the updates 
based on your comments. Thank you!

Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt

Best regards, 
Shuping 



-Original Message-
From: Erik Kline [mailto:ek.i...@gmail.com] 
Sent: Thursday, February 25, 2021 11:57 PM
To: Dhruv Dhody 
Cc: Éric Vyncke ; Julien Meuric 
; pce@ietf.org; The IESG ; pce-chairs 
; draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
Subject: Re: Éric Vyncke's Discuss on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

Dhruv,

Thanks for this.

>From my previous review, for reference only:

"""
* Saying that the LINKLOCAL-IPV6-ID-ADDRESS TLV holds a pair of global IPv6
  addresses seems confusing to me.

  If the pair of global IPv6 addresses is to be considered "on link" in the
  sense that IPv6 ND can be successfully be performed on the link for both
  of these addresses, then "ONLINK" might be better than LINKLOCAL.

* Also, why are two interface IDs required?  I would have expected that only
  the outgoing interface name/ID would be of relevance to the recipient of
  a message with TLV in it?
"""

Just for your consideration, in case "ONLINK" seems like it might be useful 
naming.

One more thing of note: I am terrible at naming!

On Thu, Feb 25, 2021 at 7:46 AM Dhruv Dhody  wrote:
>
> Hi Eric,
>
> I discussed this offline with one of the authors, who confirmed that 
> while NAI in RFC 8664 uses a pair, in this case, the pair is not 
> needed for the next-hop information and it can be updated as suggested 
> by you.
>
> Thanks!
> Dhruv
>
> On Thu, Feb 25, 2021 at 8:50 PM Dhruv Dhody  wrote:
> >
> > Hi Eric,
> >
> > On Thu, Feb 25, 2021 at 8:35 PM Éric Vyncke via Datatracker 
> >  wrote:
> > >
> > > Éric Vyncke has entered the following ballot position for
> > > draft-ietf-pce-pcep-extension-for-pce-controller-12: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to 
> > > all email addresses included in the To and CC lines. (Feel free to 
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to 
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for
> > > -pce-controller/
> > >
> > >
> > >
> > > --
> > > 
> > > DISCUSS:
> > > --
> > > 
> > >
> > > Thank you for the work put into this document. I have not had time 
> > > to review in details though :( but I appreciated the detailed 
> > > description as well as the useful time diagrams.
> > >
> > > Please find below one blocking DISCUSS point (which may be my bad 
> > > understanding), some non-blocking COMMENT points (but replies 
> > > would be appreciated).
> > >
> > > I hope that this helps to improve the document,
> > >
> > > Regards,
> > >
> > > -éric
> > >
> > > == DISCUSS ==
> > >

Re: [Pce] new draft on segment routing approach to TSN

[Pascal Thubert (pthubert)]

Hello Yaakov

Short term could you ask the RAW chairs for 15mn at the next IETF?

Wherever your work finally progresses that is a good start...

Take care,

Pascal

Le 26 févr. 2021 à 05:32, Yaakov Stein  a écrit :


Pascal,

Please accept my apologies for having misunderstood your intention regarding 
“green waves”.

I originally read it as two separate statements, namely

  1.  people won’t understand the “green wave” analogy
  2.  people in general think that TSN is magic and no packet ever waits
while I now understand that you intended one statement

  1.  people will misunderstand the analogy to green waves and believe that I 
am implying that no packet ever waits.

My reply to your true intention is that even in those places where traffic 
lights are coordinated
it doesn’t mean that every car is first to go through every light or that you 
don’t have to slow down before lights.
It merely implies that there is high correlation between car arrival times and 
green light periods.
This is what Qbv and calendaring are supposed to accomplish,
and if people will be misled then perhaps I need to find another analogy.

Perhaps something with bus arrival times is more appropriate where people queue 
up to enter the bus.
The reason I wanted to avoid that one is that buses don’t stick to schedule.
Since they wait longer when there happen to be more passengers getting on,
they then meet even more passengers at the next stop, while the following bus 
meets fewer, resulting in bunching.

Y(J)S

From: Pascal Thubert (pthubert) 
Sent: 25/02/2021 23:27
To: Yaakov Stein 
Cc: Tianran Zhou ; det...@ietf.org; spr...@ietf.org; 
pce@ietf.org
Subject: Re: new draft on segment routing approach to TSN

Hello Yaakov

Please see below:



Le 25 févr. 2021 à 21:33, Yaakov Stein 
mailto:yaako...@rad.com>> a écrit :

Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

Indeed; the questions that this raises are:

- which WG, so I added RAW to the candidate list in this thread

- how to package the complementary proposals in how many draft

Your excellent work focuses on SR signaling in the forwarding plane with strict 
intermediate latencies at each stage. It would be grand to neatly insert this 
in a SRv6 together with other information that the RAW PSE processes in its 
forwarding/scheduling decision.

There are multiple dimensions in which the scope of your work could be 
enlarged; one of them would be to use a similar signaling but with a best 
effort objective, which is what I discussed. This could easily be combined if 
we decide to, so the same signaling serves both use cases. And maybe more, to 
be discussed.



I was going to add a section on how to reproduce Qbv behavior using a stack of 
deadlines (the argument is a bit tricky, but straightforward).
I don’t necessarily think that is a good idea, but it should be there to 
counter claims that SRTSN only reduces the expectation
but can’t provide an absolute upper bound on latency (when based on EDF).

Very cool;



I like to use the term latency, but sometimes use delay to avoid overusing it.

Your decision, at least as long as it is personal submission ; but having a 
clear terminology is useful. Literature value is of lesser importance here I 
guess. Latency is what we use in DetNet and RAW. Delay often refers to extra, 
possibly unwanted time, like a queueing delay. At least you’d make my reader 
life easier by defining your terminology and sticking to it quite strictly : )



I thought that “green wave” would be understood by those who drive cars in 
cities where traffic light coordination is common.

Yes, and I think you were clear enough; but then only a few deterministic flows 
really operate like that. Another flow that use the same outgoing port will 
have to suffer some delay in a time-triggered queue till the port is free, the 
delay being taken from the end to end latency budget. My suggestion was to 
reconsider the text to avoid giving the impression that all flows benefit from 
that green wave.



I attempted to describe a data structure for EDF to be used instead of a queue,

Neat


but never implied that “queueing” (meaning packets waiting to be transmitted) 
doesn’t occur.
If that were the case there would not be a need for any data structure at all.

Cool


(Another thing I didn’t get into was the trade-offs among the different options,
 from worst case complexity and difficulty to implement in hardware PoVs.)

I’d love to read that too



I took a quick look at US 9602420 and will study it further.

It’s not as deep as an academic paper but a good hint at how you can turn 
schedule into QoS or another technique to reorder the set of packets that 
compete for the port.


However the purpose of this draft is not to mandate any specific scheduling 
mechanism,
rather to show how such mechanisms can be integra

Re: [Pce] new draft on segment routing approach to TSN

[Yaakov Stein]

And I forgot to mention the real way this is handled in sophisticated wireless 
systems.

There shouldn’t be any idle time!

If there are less bits to be transmitted then the modulation order is reduced
increasing the margin and reducing the probability of error!

Even for NRZ Ethernet transmitting random frames that happen to the next in a 
cyclic buffer
is in general not the best option.
Not only does it not guarantee retransmission of a bad packet (unless is really 
very little to transmit),
it wastes a lot of energy on transmitting packets that have already been 
received.
If there is so little to transmit you should be powering down your transmitter 
(802.3az).

Y(J)S

From: Jakob Heitz (jheitz) 
Sent: 26/02/2021 07:56
To: Yaakov Stein ; Pascal Thubert (pthubert) 

Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Lots of ways. Another:
Use a circular buffer. As you transmit a packet put it into the buffer.
As it is acknowledged, remove it.
Just keep transmitting the buffer circularly.
If one is NACKed, retransmit it immediately.
The receiver can keep track of received sequence numbers.
They should be in order. Ack the latest sequence whenever there is a chance.
If the receiver sees a hole in the received sequence, NACK it.

Regards,
Jakob.

From: Yaakov Stein mailto:yaako...@rad.com>>
Sent: Thursday, February 25, 2021 9:48 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Jakob

I forgot to address your first sentence.

Retransmission without NACK is an interesting idea, but I am not sure it really 
helps.

If there is nothing to be transmitted then you could go into a loop and 
retransmit packets over and over,
but I assume that this usually won’t happen.
So assume that you have a short idle window – which packet are you going to 
retransmit?
Without knowing which packet was not received correctly you have no idea.

So let’s assume that you reserve a full 50% of your BW and retransmit every 
packet.
Some packets received twice will differ – which one is correct? You can’t know 
without a FEC.
And if you are using a FEC it is more efficient to use a strong one then 
retransmit the whole packet!

So, let’s assume that you don’t use a FEC (maybe you don’t want the hassle of 
implementing one in hardware).
Then you need to send each packet at least 3 times to be able to do a majority 
decision.
So, you have reduced your BW efficiency to 33%.

I’m not saying that this is never justified. Lots of messages are sent 3 times 
for redundancy.
Going back to cellular, triple redundancy is used for critical control messages 
(in addition to other error correction means)/
But only for them. It is really suboptimal for everything else.

Y(J)S




From: Yaakov Stein
Sent: 26/02/2021 07:38
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

My point regarding HARQ was that this kind of retransmission can be more 
efficiently handled
at layers lower than where you see packets.
4G/5G has actually two mechanisms precisely of the type you suggest at two 
different layers,
but the magic happens on the physical signals (HARQ) or the SDUs (PDCP 
retransmission)
and is completely transparent to the user packets.

True, high speed Ethernet links are no longer physical broadcast domains
and one could insert sequence numbers into the frames and perform local 
retransmission.
This has been done in the past (I personally have a patent on such a method, 
although it also gives an alternative to numbering).
But if you are already numbering it might be even better to go all the way and 
use RFER.
(Or maybe even combine ACK/NACK retransmission and replication.)

Y(J)S


From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 07:00
To: Yaakov Stein mailto:yaako...@rad.com>>; Pascal Thubert 
(pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Suppose you're sending packets out an interface and all the queues are empty. 
You got nothing to send.
What are you going to do with the dead air? Send idle patterns?
No.
Retransmit your previous queues. Just in case something got lost the preemptive 
retransmission will fix it quicker.

Re: [Pce] new draft on segment routing approach to TSN

[Jakob Heitz (jheitz)]

Lots of ways. Another:
Use a circular buffer. As you transmit a packet put it into the buffer.
As it is acknowledged, remove it.
Just keep transmitting the buffer circularly.
If one is NACKed, retransmit it immediately.
The receiver can keep track of received sequence numbers.
They should be in order. Ack the latest sequence whenever there is a chance.
If the receiver sees a hole in the received sequence, NACK it.

Regards,
Jakob.

From: Yaakov Stein 
Sent: Thursday, February 25, 2021 9:48 PM
To: Jakob Heitz (jheitz) ; Pascal Thubert (pthubert) 

Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Jakob

I forgot to address your first sentence.

Retransmission without NACK is an interesting idea, but I am not sure it really 
helps.

If there is nothing to be transmitted then you could go into a loop and 
retransmit packets over and over,
but I assume that this usually won’t happen.
So assume that you have a short idle window – which packet are you going to 
retransmit?
Without knowing which packet was not received correctly you have no idea.

So let’s assume that you reserve a full 50% of your BW and retransmit every 
packet.
Some packets received twice will differ – which one is correct? You can’t know 
without a FEC.
And if you are using a FEC it is more efficient to use a strong one then 
retransmit the whole packet!

So, let’s assume that you don’t use a FEC (maybe you don’t want the hassle of 
implementing one in hardware).
Then you need to send each packet at least 3 times to be able to do a majority 
decision.
So, you have reduced your BW efficiency to 33%.

I’m not saying that this is never justified. Lots of messages are sent 3 times 
for redundancy.
Going back to cellular, triple redundancy is used for critical control messages 
(in addition to other error correction means)/
But only for them. It is really suboptimal for everything else.

Y(J)S




From: Yaakov Stein
Sent: 26/02/2021 07:38
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

My point regarding HARQ was that this kind of retransmission can be more 
efficiently handled
at layers lower than where you see packets.
4G/5G has actually two mechanisms precisely of the type you suggest at two 
different layers,
but the magic happens on the physical signals (HARQ) or the SDUs (PDCP 
retransmission)
and is completely transparent to the user packets.

True, high speed Ethernet links are no longer physical broadcast domains
and one could insert sequence numbers into the frames and perform local 
retransmission.
This has been done in the past (I personally have a patent on such a method, 
although it also gives an alternative to numbering).
But if you are already numbering it might be even better to go all the way and 
use RFER.
(Or maybe even combine ACK/NACK retransmission and replication.)

Y(J)S


From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 07:00
To: Yaakov Stein mailto:yaako...@rad.com>>; Pascal Thubert 
(pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Suppose you're sending packets out an interface and all the queues are empty. 
You got nothing to send.
What are you going to do with the dead air? Send idle patterns?
No.
Retransmit your previous queues. Just in case something got lost the preemptive 
retransmission will fix it quicker.
Then put a link layer sequence number and ACK and NACK numbers so you can 
manage what you retransmit.
This will only work on point-to-point. Ethernet's not broadcast on the physical 
layer anymore, is it?

Regards,
Jakob.

From: Yaakov Stein mailto:yaako...@rad.com>>
Sent: Thursday, February 25, 2021 8:56 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Of course they are common in wireless.
Cellular HARQ works just like that – if the FEC fixes the problem then fine, if 
not then the information is retransmitted.
And HARQ not only causes timing problems when there are errors, the HARQ SAW 
(Stop and Wait) process adds delay to all information transmitted.

However, I was mostly thinking about wireline cases.
Pascal pointed to the work being done in RAW, which is where this question 
n

Re: [Pce] new draft on segment routing approach to TSN

[Yaakov Stein]

Jakob

I forgot to address your first sentence.

Retransmission without NACK is an interesting idea, but I am not sure it really 
helps.

If there is nothing to be transmitted then you could go into a loop and 
retransmit packets over and over,
but I assume that this usually won’t happen.
So assume that you have a short idle window – which packet are you going to 
retransmit?
Without knowing which packet was not received correctly you have no idea.

So let’s assume that you reserve a full 50% of your BW and retransmit every 
packet.
Some packets received twice will differ – which one is correct? You can’t know 
without a FEC.
And if you are using a FEC it is more efficient to use a strong one then 
retransmit the whole packet!

So, let’s assume that you don’t use a FEC (maybe you don’t want the hassle of 
implementing one in hardware).
Then you need to send each packet at least 3 times to be able to do a majority 
decision.
So, you have reduced your BW efficiency to 33%.

I’m not saying that this is never justified. Lots of messages are sent 3 times 
for redundancy.
Going back to cellular, triple redundancy is used for critical control messages 
(in addition to other error correction means)/
But only for them. It is really suboptimal for everything else.

Y(J)S




From: Yaakov Stein
Sent: 26/02/2021 07:38
To: Jakob Heitz (jheitz) ; Pascal Thubert (pthubert) 

Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

My point regarding HARQ was that this kind of retransmission can be more 
efficiently handled
at layers lower than where you see packets.
4G/5G has actually two mechanisms precisely of the type you suggest at two 
different layers,
but the magic happens on the physical signals (HARQ) or the SDUs (PDCP 
retransmission)
and is completely transparent to the user packets.

True, high speed Ethernet links are no longer physical broadcast domains
and one could insert sequence numbers into the frames and perform local 
retransmission.
This has been done in the past (I personally have a patent on such a method, 
although it also gives an alternative to numbering).
But if you are already numbering it might be even better to go all the way and 
use RFER.
(Or maybe even combine ACK/NACK retransmission and replication.)

Y(J)S


From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 07:00
To: Yaakov Stein mailto:yaako...@rad.com>>; Pascal Thubert 
(pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Suppose you're sending packets out an interface and all the queues are empty. 
You got nothing to send.
What are you going to do with the dead air? Send idle patterns?
No.
Retransmit your previous queues. Just in case something got lost the preemptive 
retransmission will fix it quicker.
Then put a link layer sequence number and ACK and NACK numbers so you can 
manage what you retransmit.
This will only work on point-to-point. Ethernet's not broadcast on the physical 
layer anymore, is it?

Regards,
Jakob.

From: Yaakov Stein mailto:yaako...@rad.com>>
Sent: Thursday, February 25, 2021 8:56 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Of course they are common in wireless.
Cellular HARQ works just like that – if the FEC fixes the problem then fine, if 
not then the information is retransmitted.
And HARQ not only causes timing problems when there are errors, the HARQ SAW 
(Stop and Wait) process adds delay to all information transmitted.

However, I was mostly thinking about wireline cases.
Pascal pointed to the work being done in RAW, which is where this question 
needs to be addressed.

Y(J)S

From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 06:47
To: Yaakov Stein mailto:yaako...@rad.com>>; Pascal Thubert 
(pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Are they rare in wireless transmission? I believe some wireless protocols have 
lower layers that retransmit to provide reliability, but I don't know much 
about them.
My point is if you are going to provide a guarantee of time for delivery, you 
need to consider all factors that influence that time.

Also, what happens if you can't meet the deadline? Do you drop the packet or 
deliver with best e

Re: [Pce] new draft on segment routing approach to TSN

[Yaakov Stein]

My point regarding HARQ was that this kind of retransmission can be more 
efficiently handled
at layers lower than where you see packets.
4G/5G has actually two mechanisms precisely of the type you suggest at two 
different layers,
but the magic happens on the physical signals (HARQ) or the SDUs (PDCP 
retransmission)
and is completely transparent to the user packets.

True, high speed Ethernet links are no longer physical broadcast domains
and one could insert sequence numbers into the frames and perform local 
retransmission.
This has been done in the past (I personally have a patent on such a method, 
although it also gives an alternative to numbering).
But if you are already numbering it might be even better to go all the way and 
use RFER.
(Or maybe even combine ACK/NACK retransmission and replication.)

Y(J)S


From: Jakob Heitz (jheitz) 
Sent: 26/02/2021 07:00
To: Yaakov Stein ; Pascal Thubert (pthubert) 

Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Suppose you're sending packets out an interface and all the queues are empty. 
You got nothing to send.
What are you going to do with the dead air? Send idle patterns?
No.
Retransmit your previous queues. Just in case something got lost the preemptive 
retransmission will fix it quicker.
Then put a link layer sequence number and ACK and NACK numbers so you can 
manage what you retransmit.
This will only work on point-to-point. Ethernet's not broadcast on the physical 
layer anymore, is it?

Regards,
Jakob.

From: Yaakov Stein mailto:yaako...@rad.com>>
Sent: Thursday, February 25, 2021 8:56 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Of course they are common in wireless.
Cellular HARQ works just like that – if the FEC fixes the problem then fine, if 
not then the information is retransmitted.
And HARQ not only causes timing problems when there are errors, the HARQ SAW 
(Stop and Wait) process adds delay to all information transmitted.

However, I was mostly thinking about wireline cases.
Pascal pointed to the work being done in RAW, which is where this question 
needs to be addressed.

Y(J)S

From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 06:47
To: Yaakov Stein mailto:yaako...@rad.com>>; Pascal Thubert 
(pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Are they rare in wireless transmission? I believe some wireless protocols have 
lower layers that retransmit to provide reliability, but I don't know much 
about them.
My point is if you are going to provide a guarantee of time for delivery, you 
need to consider all factors that influence that time.

Also, what happens if you can't meet the deadline? Do you drop the packet or 
deliver with best effort?

Regards,
Jakob.

From: Yaakov Stein mailto:yaako...@rad.com>>
Sent: Thursday, February 25, 2021 8:40 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Jakob

Yes, one always needs to consider bit errors (even if they are very rare in 
wireline nowadays).

I’m just not sure where you want to hang this on the present discussion.

A local retransmission mechanism such as the one you suggest
would obviously thwart any calendaring mechanism that attempts to coordinate 
scheduling based on traffic timing
(unless the detection, signaling, and retransmission takes place much faster 
than an opening time).
LIS could be made to work by retransmitting with the original timestamp, and 
EDF would work just fine.

Y(J)S

From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 01:36
To: Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>;
 Yaakov Stein mailto:yaako...@rad.com>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Another thing to consider is packets dropped due to bit errors.
Possibilities: Link level acknowledgement and preemptive retransmission
if the link would otherwise be idle. I.e. "just in case" retransmission.

Regards,
Jakob.

From: spring mailto:spring-b

Re: [Pce] new draft on segment routing approach to TSN

[Yaakov Stein]

Tianran,

For some reason I didn’t see your email and thus never responded to it. My 
apologies.


1.   I believe that I address this question at the beginning of my draft.

Using a single deadline per packet at is suboptimal at any particular switch.

For example, say two packets arrive at a switch, one with only 20 microseconds 
left on its deadline

and one with 50. The switch would naturally schedule the 10 microsecond one 
first.

But what the switch doesn’t know is that it is the last hop for the 10 
microsecond one

and there are only 2 microseconds from it to destination,

while the 50 microsecond packet still has 45 microseconds of physical time 
ahead of it!

  1.  I gave a specific algorithm in the draft and pointed to Andrews and Zhang 
who give another one.
  2.  I don’t think a service needs to support EDF, but perhaps a switch does.

I haven’t seen EDF support since the ATM days, but am proposing that perhaps 
the time has come to re-evaluate it.

However, I am not advocating for EDF in this draft, just for the stack.

I mention a variant of EDF which I believe is better, and am working on another 
variant which is even better.

They can all be built into hardware, although admitted are more complex than a 
simple queue.

But they may be simpler than a set of queues with time schedules like Qbv

and are much much simpler than monstrosities like MEF 10.3 token bucket with 
cross-color/cross-CoS sharing and coupling.
Y(J)S



From: detnet mailto:detnet-boun...@ietf.org>> On 
Behalf Of Tianran Zhou
Sent: jeudi 25 février 2021 9:14
To: Yaakov Stein mailto:yaako...@rad.com>>; 
det...@ietf.org; 
spr...@ietf.org; pce@ietf.org
Subject: Re: [Detnet] new draft on segment routing approach to TSN

Hi Yaakov,

This is an interesting topic.
After a quick review, there are several questions as follows:
1. It’s clear to me to have a deadline for each packet. So that router can 
schedule the packet based on the urgency. But what’s the motivation to split 
the end to end deadline to several local ones?
2. How to divide an end to end deadline into several local deadlines? Is there 
any example algorithm that could be used by the controller?
3. As far as I know, most devices do not support edf. I am not sure whether 
your proposal based on edf could really be useful.

Cheers,
Tianran


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Yaakov Stein
Sent: Tuesday, February 23, 2021 9:14 PM
To: det...@ietf.org; 
spr...@ietf.org; pce@ietf.org
Subject: [Pce] new draft on segment routing approach to TSN

All,

I would like to call your attention to a new ID 
https://www.ietf.org/archive/id/draft-stein-srtsn-00.txt
which describes using a stack-based approach (similar to segment routing) to 
time sensitive networking.
It furthermore proposes combining segment routing with this approach to TSN
resulting in a unified approach to forwarding and scheduling.

The draft is information at this point, since it discusses the concepts and 
does not yet pin down the precise formats.

Apologies for simultaneously sending to 3 lists,
but I am not sure which WG is the most appropriate for discussions of this 
topic.

  *   DetNet is most relevant since the whole point is to control end-to-end 
latency of a time-sensitive flow.
  *   Spring is also directly relevant due to the use of a stack in the header 
and the combined approach just mentioned.
  *   PCE is relevant to the case of a central server jointly computing an 
optimal path and local deadline stack.
I’ll let the chairs decide where discussions should be held.

Y(J)S

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

Re: [Pce] new draft on segment routing approach to TSN

[Jakob Heitz (jheitz)]

Suppose you're sending packets out an interface and all the queues are empty. 
You got nothing to send.
What are you going to do with the dead air? Send idle patterns?
No.
Retransmit your previous queues. Just in case something got lost the preemptive 
retransmission will fix it quicker.
Then put a link layer sequence number and ACK and NACK numbers so you can 
manage what you retransmit.
This will only work on point-to-point. Ethernet's not broadcast on the physical 
layer anymore, is it?

Regards,
Jakob.

From: Yaakov Stein 
Sent: Thursday, February 25, 2021 8:56 PM
To: Jakob Heitz (jheitz) ; Pascal Thubert (pthubert) 

Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Of course they are common in wireless.
Cellular HARQ works just like that – if the FEC fixes the problem then fine, if 
not then the information is retransmitted.
And HARQ not only causes timing problems when there are errors, the HARQ SAW 
(Stop and Wait) process adds delay to all information transmitted.

However, I was mostly thinking about wireline cases.
Pascal pointed to the work being done in RAW, which is where this question 
needs to be addressed.

Y(J)S

From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 06:47
To: Yaakov Stein mailto:yaako...@rad.com>>; Pascal Thubert 
(pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Are they rare in wireless transmission? I believe some wireless protocols have 
lower layers that retransmit to provide reliability, but I don't know much 
about them.
My point is if you are going to provide a guarantee of time for delivery, you 
need to consider all factors that influence that time.

Also, what happens if you can't meet the deadline? Do you drop the packet or 
deliver with best effort?

Regards,
Jakob.

From: Yaakov Stein mailto:yaako...@rad.com>>
Sent: Thursday, February 25, 2021 8:40 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Jakob

Yes, one always needs to consider bit errors (even if they are very rare in 
wireline nowadays).

I’m just not sure where you want to hang this on the present discussion.

A local retransmission mechanism such as the one you suggest
would obviously thwart any calendaring mechanism that attempts to coordinate 
scheduling based on traffic timing
(unless the detection, signaling, and retransmission takes place much faster 
than an opening time).
LIS could be made to work by retransmitting with the original timestamp, and 
EDF would work just fine.

Y(J)S

From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 01:36
To: Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>;
 Yaakov Stein mailto:yaako...@rad.com>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Another thing to consider is packets dropped due to bit errors.
Possibilities: Link level acknowledgement and preemptive retransmission
if the link would otherwise be idle. I.e. "just in case" retransmission.

Regards,
Jakob.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, February 25, 2021 1:27 PM
To: Yaakov Stein mailto:yaako...@rad.com>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: Re: [spring] new draft on segment routing approach to TSN

Hello Yaakov

Please see below:


Le 25 févr. 2021 à 21:33, Yaakov Stein 
mailto:yaako...@rad.com>> a écrit :

Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

Indeed; the questions that this raises are:

- which WG, so I added RAW to the candidate list in this thread

- how to package the complementary proposals in how many draft

Your excellent work focuses on SR signaling in the forwarding plane with strict 
intermediate latencies at each stage. It would be grand to neatly insert this 
in a SRv6 together with other information that the RAW PSE processes in its 
forwarding/scheduling decision.

There are multiple dimensions in which the scope of your work could be 
enlarged; one of them would be to use a

Re: [Pce] new draft on segment routing approach to TSN

[Yaakov Stein]

Of course they are common in wireless.
Cellular HARQ works just like that – if the FEC fixes the problem then fine, if 
not then the information is retransmitted.
And HARQ not only causes timing problems when there are errors, the HARQ SAW 
(Stop and Wait) process adds delay to all information transmitted.

However, I was mostly thinking about wireline cases.
Pascal pointed to the work being done in RAW, which is where this question 
needs to be addressed.

Y(J)S

From: Jakob Heitz (jheitz) 
Sent: 26/02/2021 06:47
To: Yaakov Stein ; Pascal Thubert (pthubert) 

Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Are they rare in wireless transmission? I believe some wireless protocols have 
lower layers that retransmit to provide reliability, but I don't know much 
about them.
My point is if you are going to provide a guarantee of time for delivery, you 
need to consider all factors that influence that time.

Also, what happens if you can't meet the deadline? Do you drop the packet or 
deliver with best effort?

Regards,
Jakob.

From: Yaakov Stein mailto:yaako...@rad.com>>
Sent: Thursday, February 25, 2021 8:40 PM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Pascal 
Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Jakob

Yes, one always needs to consider bit errors (even if they are very rare in 
wireline nowadays).

I’m just not sure where you want to hang this on the present discussion.

A local retransmission mechanism such as the one you suggest
would obviously thwart any calendaring mechanism that attempts to coordinate 
scheduling based on traffic timing
(unless the detection, signaling, and retransmission takes place much faster 
than an opening time).
LIS could be made to work by retransmitting with the original timestamp, and 
EDF would work just fine.

Y(J)S

From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 01:36
To: Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>;
 Yaakov Stein mailto:yaako...@rad.com>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Another thing to consider is packets dropped due to bit errors.
Possibilities: Link level acknowledgement and preemptive retransmission
if the link would otherwise be idle. I.e. "just in case" retransmission.

Regards,
Jakob.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, February 25, 2021 1:27 PM
To: Yaakov Stein mailto:yaako...@rad.com>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: Re: [spring] new draft on segment routing approach to TSN

Hello Yaakov

Please see below:


Le 25 févr. 2021 à 21:33, Yaakov Stein 
mailto:yaako...@rad.com>> a écrit :

Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

Indeed; the questions that this raises are:

- which WG, so I added RAW to the candidate list in this thread

- how to package the complementary proposals in how many draft

Your excellent work focuses on SR signaling in the forwarding plane with strict 
intermediate latencies at each stage. It would be grand to neatly insert this 
in a SRv6 together with other information that the RAW PSE processes in its 
forwarding/scheduling decision.

There are multiple dimensions in which the scope of your work could be 
enlarged; one of them would be to use a similar signaling but with a best 
effort objective, which is what I discussed. This could easily be combined if 
we decide to, so the same signaling serves both use cases. And maybe more, to 
be discussed.


I was going to add a section on how to reproduce Qbv behavior using a stack of 
deadlines (the argument is a bit tricky, but straightforward).
I don’t necessarily think that is a good idea, but it should be there to 
counter claims that SRTSN only reduces the expectation
but can’t provide an absolute upper bound on latency (when based on EDF).

Very cool;


I like to use the term latency, but sometimes use delay to avoid overusing it.

Your decision, at least as long as it is personal submission ; but having a 
clear terminology is useful. Literature value is of lesser importance here I 
guess. Latency is what we use in DetNet and RAW. Delay often refers to extra, 
possibly unwanted time, like a queueing delay. At least you’d make m

Re: [Pce] new draft on segment routing approach to TSN

[Jakob Heitz (jheitz)]

Are they rare in wireless transmission? I believe some wireless protocols have 
lower layers that retransmit to provide reliability, but I don't know much 
about them.
My point is if you are going to provide a guarantee of time for delivery, you 
need to consider all factors that influence that time.

Also, what happens if you can't meet the deadline? Do you drop the packet or 
deliver with best effort?

Regards,
Jakob.

From: Yaakov Stein 
Sent: Thursday, February 25, 2021 8:40 PM
To: Jakob Heitz (jheitz) ; Pascal Thubert (pthubert) 

Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Jakob

Yes, one always needs to consider bit errors (even if they are very rare in 
wireline nowadays).

I’m just not sure where you want to hang this on the present discussion.

A local retransmission mechanism such as the one you suggest
would obviously thwart any calendaring mechanism that attempts to coordinate 
scheduling based on traffic timing
(unless the detection, signaling, and retransmission takes place much faster 
than an opening time).
LIS could be made to work by retransmitting with the original timestamp, and 
EDF would work just fine.

Y(J)S

From: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Sent: 26/02/2021 01:36
To: Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>;
 Yaakov Stein mailto:yaako...@rad.com>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Another thing to consider is packets dropped due to bit errors.
Possibilities: Link level acknowledgement and preemptive retransmission
if the link would otherwise be idle. I.e. "just in case" retransmission.

Regards,
Jakob.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, February 25, 2021 1:27 PM
To: Yaakov Stein mailto:yaako...@rad.com>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: Re: [spring] new draft on segment routing approach to TSN

Hello Yaakov

Please see below:


Le 25 févr. 2021 à 21:33, Yaakov Stein 
mailto:yaako...@rad.com>> a écrit :

Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

Indeed; the questions that this raises are:

- which WG, so I added RAW to the candidate list in this thread

- how to package the complementary proposals in how many draft

Your excellent work focuses on SR signaling in the forwarding plane with strict 
intermediate latencies at each stage. It would be grand to neatly insert this 
in a SRv6 together with other information that the RAW PSE processes in its 
forwarding/scheduling decision.

There are multiple dimensions in which the scope of your work could be 
enlarged; one of them would be to use a similar signaling but with a best 
effort objective, which is what I discussed. This could easily be combined if 
we decide to, so the same signaling serves both use cases. And maybe more, to 
be discussed.


I was going to add a section on how to reproduce Qbv behavior using a stack of 
deadlines (the argument is a bit tricky, but straightforward).
I don’t necessarily think that is a good idea, but it should be there to 
counter claims that SRTSN only reduces the expectation
but can’t provide an absolute upper bound on latency (when based on EDF).

Very cool;


I like to use the term latency, but sometimes use delay to avoid overusing it.

Your decision, at least as long as it is personal submission ; but having a 
clear terminology is useful. Literature value is of lesser importance here I 
guess. Latency is what we use in DetNet and RAW. Delay often refers to extra, 
possibly unwanted time, like a queueing delay. At least you’d make my reader 
life easier by defining your terminology and sticking to it quite strictly : )


I thought that “green wave” would be understood by those who drive cars in 
cities where traffic light coordination is common.

Yes, and I think you were clear enough; but then only a few deterministic flows 
really operate like that. Another flow that use the same outgoing port will 
have to suffer some delay in a time-triggered queue till the port is free, the 
delay being taken from the end to end latency budget. My suggestion was to 
reconsider the text to avoid giving the impression that all flows benefit from 
that green wave.


I attempted to describe a data structure for EDF to be used instead of a queue,

Neat

but never implied that “queueing” (meaning packets waiting to be transmitted) 
doesn’t occur.
If that were the case there would not be a need for any data structure at al

Re: [Pce] new draft on segment routing approach to TSN

[Yaakov Stein]

Jakob

Yes, one always needs to consider bit errors (even if they are very rare in 
wireline nowadays).

I’m just not sure where you want to hang this on the present discussion.

A local retransmission mechanism such as the one you suggest
would obviously thwart any calendaring mechanism that attempts to coordinate 
scheduling based on traffic timing
(unless the detection, signaling, and retransmission takes place much faster 
than an opening time).
LIS could be made to work by retransmitting with the original timestamp, and 
EDF would work just fine.

Y(J)S

From: Jakob Heitz (jheitz) 
Sent: 26/02/2021 01:36
To: Pascal Thubert (pthubert) ; Yaakov 
Stein 
Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Another thing to consider is packets dropped due to bit errors.
Possibilities: Link level acknowledgement and preemptive retransmission
if the link would otherwise be idle. I.e. "just in case" retransmission.

Regards,
Jakob.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, February 25, 2021 1:27 PM
To: Yaakov Stein mailto:yaako...@rad.com>>
Cc: det...@ietf.org; Tianran Zhou 
mailto:zhoutian...@huawei.com>>; 
pce@ietf.org; spr...@ietf.org
Subject: Re: [spring] new draft on segment routing approach to TSN

Hello Yaakov

Please see below:


Le 25 févr. 2021 à 21:33, Yaakov Stein 
mailto:yaako...@rad.com>> a écrit :

Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

Indeed; the questions that this raises are:

- which WG, so I added RAW to the candidate list in this thread

- how to package the complementary proposals in how many draft

Your excellent work focuses on SR signaling in the forwarding plane with strict 
intermediate latencies at each stage. It would be grand to neatly insert this 
in a SRv6 together with other information that the RAW PSE processes in its 
forwarding/scheduling decision.

There are multiple dimensions in which the scope of your work could be 
enlarged; one of them would be to use a similar signaling but with a best 
effort objective, which is what I discussed. This could easily be combined if 
we decide to, so the same signaling serves both use cases. And maybe more, to 
be discussed.


I was going to add a section on how to reproduce Qbv behavior using a stack of 
deadlines (the argument is a bit tricky, but straightforward).
I don’t necessarily think that is a good idea, but it should be there to 
counter claims that SRTSN only reduces the expectation
but can’t provide an absolute upper bound on latency (when based on EDF).

Very cool;


I like to use the term latency, but sometimes use delay to avoid overusing it.

Your decision, at least as long as it is personal submission ; but having a 
clear terminology is useful. Literature value is of lesser importance here I 
guess. Latency is what we use in DetNet and RAW. Delay often refers to extra, 
possibly unwanted time, like a queueing delay. At least you’d make my reader 
life easier by defining your terminology and sticking to it quite strictly : )


I thought that “green wave” would be understood by those who drive cars in 
cities where traffic light coordination is common.

Yes, and I think you were clear enough; but then only a few deterministic flows 
really operate like that. Another flow that use the same outgoing port will 
have to suffer some delay in a time-triggered queue till the port is free, the 
delay being taken from the end to end latency budget. My suggestion was to 
reconsider the text to avoid giving the impression that all flows benefit from 
that green wave.


I attempted to describe a data structure for EDF to be used instead of a queue,

Neat

but never implied that “queueing” (meaning packets waiting to be transmitted) 
doesn’t occur.
If that were the case there would not be a need for any data structure at all.

Cool

(Another thing I didn’t get into was the trade-offs among the different options,
 from worst case complexity and difficulty to implement in hardware PoVs.)

I’d love to read that too


I took a quick look at US 9602420 and will study it further.

It’s not as deep as an academic paper but a good hint at how you can turn 
schedule into QoS or another technique to reorder the set of packets that 
compete for the port.

However the purpose of this draft is not to mandate any specific scheduling 
mechanism,
rather to show how such mechanisms can be integrated and hopefully more readily 
distributed.

Usually you’re expected to provide the meaning of the signaling and the visible 
behavior of the node; the way the node implements the does not need to be spec 
but some hints on how that can be achieved are welcome, possibly in annex.

Incidentally I

Re: [Pce] Implementation option of draft-ietf-pce-stateful-interdomain-01.txt

[Dhruv Dhody]

Hi Olivier,

Thanks for starting this thread.

As a WG participant...

On Tue, Feb 23, 2021 at 12:05 AM  wrote:

> Dear all,
>
> According to the remark about implementation we got during the WG call
> for adoption, we would start a new thread to discuss this point.
> The goal isto prepare the discussion for next IETF meeting and reach a
> consensusin order to edit revision 2 of the draft.
>
> The stitching label principle requires at least a certain number of
> modifications in the current PCEP version:
>
>  a) A new PCE Capability to announce the inter-domain behaviour
>  b) A new PCE Association Group to associate the local paths identifier
> to the inter-domain identifier
>  c) new PCEP Errors to manage the Stitching Label exchange
>  d) A mechanism to convey the Stitching Label
>
> If there is no other choice than to reuse existing PCEP Objects by
> allocating new code points for modifications a-c,there is several
> options for point d, which we have tried to list below:
>
>  d1) Use ERO and RRO in conjunction to new Path Setup code points as
>  described in version 01 of the draft. It is the simplest
>  implementation but as mention by Dhruv, each time a new path
>  enforcement appear, a new PST code point must be allocated.
>  For example, when Segment Routing v6 will be standardized, we must
>  allocate a new Stitching label PST code point for SRv6.
>  d2) Use ERO and ERO in conjunction to a new flag in LSP. Simple as for d1,
>  but need to use the LSP Extended Flag draft as all LSP flags have
> been
>  already allocated.
>  d3) Same as d2 but find another place for the flag e.g. SRP or LSPA
> Object.
>  d4) Define a new PCEP sub-Objet TLV within the LSP Object to convey the
>  stitching label. This is more independent but need extra parsing from
>  an implementation point of view.
>
>
My preference would for d2 or d3 (in that order).
LSP Extended Flag is adopted by the WG and is ready for prime-time use --
let's use it :)
Authors of LSP Extended Flag are waiting for the draft blockade to be
lifted to post the -00 WG I-D.

Thanks!
Dhruv


> Please, give us your opinion about these different options and don't
> hesitate
> to propose others.
>
> Regards
>
> Olivier on be-half of co-author's
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] new draft on segment routing approach to TSN

[Yaakov Stein]

Pascal,

Please accept my apologies for having misunderstood your intention regarding 
“green waves”.

I originally read it as two separate statements, namely

  1.  people won’t understand the “green wave” analogy
  2.  people in general think that TSN is magic and no packet ever waits
while I now understand that you intended one statement

  1.  people will misunderstand the analogy to green waves and believe that I 
am implying that no packet ever waits.

My reply to your true intention is that even in those places where traffic 
lights are coordinated
it doesn’t mean that every car is first to go through every light or that you 
don’t have to slow down before lights.
It merely implies that there is high correlation between car arrival times and 
green light periods.
This is what Qbv and calendaring are supposed to accomplish,
and if people will be misled then perhaps I need to find another analogy.

Perhaps something with bus arrival times is more appropriate where people queue 
up to enter the bus.
The reason I wanted to avoid that one is that buses don’t stick to schedule.
Since they wait longer when there happen to be more passengers getting on,
they then meet even more passengers at the next stop, while the following bus 
meets fewer, resulting in bunching.

Y(J)S

From: Pascal Thubert (pthubert) 
Sent: 25/02/2021 23:27
To: Yaakov Stein 
Cc: Tianran Zhou ; det...@ietf.org; spr...@ietf.org; 
pce@ietf.org
Subject: Re: new draft on segment routing approach to TSN

Hello Yaakov

Please see below:



Le 25 févr. 2021 à 21:33, Yaakov Stein 
mailto:yaako...@rad.com>> a écrit :

Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

Indeed; the questions that this raises are:

- which WG, so I added RAW to the candidate list in this thread

- how to package the complementary proposals in how many draft

Your excellent work focuses on SR signaling in the forwarding plane with strict 
intermediate latencies at each stage. It would be grand to neatly insert this 
in a SRv6 together with other information that the RAW PSE processes in its 
forwarding/scheduling decision.

There are multiple dimensions in which the scope of your work could be 
enlarged; one of them would be to use a similar signaling but with a best 
effort objective, which is what I discussed. This could easily be combined if 
we decide to, so the same signaling serves both use cases. And maybe more, to 
be discussed.



I was going to add a section on how to reproduce Qbv behavior using a stack of 
deadlines (the argument is a bit tricky, but straightforward).
I don’t necessarily think that is a good idea, but it should be there to 
counter claims that SRTSN only reduces the expectation
but can’t provide an absolute upper bound on latency (when based on EDF).

Very cool;



I like to use the term latency, but sometimes use delay to avoid overusing it.

Your decision, at least as long as it is personal submission ; but having a 
clear terminology is useful. Literature value is of lesser importance here I 
guess. Latency is what we use in DetNet and RAW. Delay often refers to extra, 
possibly unwanted time, like a queueing delay. At least you’d make my reader 
life easier by defining your terminology and sticking to it quite strictly : )



I thought that “green wave” would be understood by those who drive cars in 
cities where traffic light coordination is common.

Yes, and I think you were clear enough; but then only a few deterministic flows 
really operate like that. Another flow that use the same outgoing port will 
have to suffer some delay in a time-triggered queue till the port is free, the 
delay being taken from the end to end latency budget. My suggestion was to 
reconsider the text to avoid giving the impression that all flows benefit from 
that green wave.



I attempted to describe a data structure for EDF to be used instead of a queue,

Neat


but never implied that “queueing” (meaning packets waiting to be transmitted) 
doesn’t occur.
If that were the case there would not be a need for any data structure at all.

Cool


(Another thing I didn’t get into was the trade-offs among the different options,
 from worst case complexity and difficulty to implement in hardware PoVs.)

I’d love to read that too



I took a quick look at US 9602420 and will study it further.

It’s not as deep as an academic paper but a good hint at how you can turn 
schedule into QoS or another technique to reorder the set of packets that 
compete for the port.


However the purpose of this draft is not to mandate any specific scheduling 
mechanism,
rather to show how such mechanisms can be integrated and hopefully more readily 
distributed.

Usually you’re expected to provide the meaning of the signaling and the visible 
behavior of the node; the way the node implements the does not need to be spec 
but some hi

Re: [Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Pengshuping (Peng Shuping)]

Hi Erik, 

Thank you for your comments! Please find the diff including the updates based 
on your comments. Thank you!

Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt

Best regards, 
Shuping 



-Original Message-
From: Erik Kline [mailto:ek.i...@gmail.com] 
Sent: Thursday, February 25, 2021 11:57 PM
To: Dhruv Dhody 
Cc: Éric Vyncke ; Julien Meuric ; 
pce@ietf.org; The IESG ; pce-chairs ; 
draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
Subject: Re: Éric Vyncke's Discuss on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

Dhruv,

Thanks for this.

>From my previous review, for reference only:

"""
* Saying that the LINKLOCAL-IPV6-ID-ADDRESS TLV holds a pair of global IPv6
  addresses seems confusing to me.

  If the pair of global IPv6 addresses is to be considered "on link" in the
  sense that IPv6 ND can be successfully be performed on the link for both
  of these addresses, then "ONLINK" might be better than LINKLOCAL.

* Also, why are two interface IDs required?  I would have expected that only
  the outgoing interface name/ID would be of relevance to the recipient of
  a message with TLV in it?
"""

Just for your consideration, in case "ONLINK" seems like it might be useful 
naming.

One more thing of note: I am terrible at naming!

On Thu, Feb 25, 2021 at 7:46 AM Dhruv Dhody  wrote:
>
> Hi Eric,
>
> I discussed this offline with one of the authors, who confirmed that 
> while NAI in RFC 8664 uses a pair, in this case, the pair is not 
> needed for the next-hop information and it can be updated as suggested 
> by you.
>
> Thanks!
> Dhruv
>
> On Thu, Feb 25, 2021 at 8:50 PM Dhruv Dhody  wrote:
> >
> > Hi Eric,
> >
> > On Thu, Feb 25, 2021 at 8:35 PM Éric Vyncke via Datatracker 
> >  wrote:
> > >
> > > Éric Vyncke has entered the following ballot position for
> > > draft-ietf-pce-pcep-extension-for-pce-controller-12: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to 
> > > all email addresses included in the To and CC lines. (Feel free to 
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to 
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for
> > > -pce-controller/
> > >
> > >
> > >
> > > --
> > > 
> > > DISCUSS:
> > > --
> > > 
> > >
> > > Thank you for the work put into this document. I have not had time 
> > > to review in details though :( but I appreciated the detailed 
> > > description as well as the useful time diagrams.
> > >
> > > Please find below one blocking DISCUSS point (which may be my bad 
> > > understanding), some non-blocking COMMENT points (but replies 
> > > would be appreciated).
> > >
> > > I hope that this helps to improve the document,
> > >
> > > Regards,
> > >
> > > -éric
> > >
> > > == DISCUSS ==
> > >
> > > -- Section 7.3.1 --
> > > LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are 
> > > two addresses in this TLV while others have one one ? Also is 
> > > 'local' and 'remote' really global addresses ?
> > >
> > >
> >
> > Erik Kline had the same comment.
> >
> > The text and encoding is inspired by RFC 8664
> > https://www.rfc-editor.org/rfc/rfc8664.html#section-4.3.2
> >
> > which says -
> >
> > IPv6 Link-Local Adjacency:
> > Specified as a pair of (global IPv6 address, interface ID) tuples. 
> > It is used to describe an IPv6 adjacency for a link that uses only 
> > link-local IPv6 addresses. Each global IPv6 address is configured on 
> > a specific router, so together they identify a pair of adjacent routers.
> > The interface IDs identify the link that the adjacency is formed over.
> >
> > A reference to RFC8664 and more description can be added.
> >
> > Thanks!
> > Dhruv
> >
> > > --
> > > 
> > > COMMENT:
> > > --
> > > 
> > >
> > > == COMMENTS ==
> > >
> > > A minor comment: the abstract is clear but probably a little too 
> > > long for an abstract.
> > >
> > > -- Section 7.3 --
> > > Just wonder why  LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this 
> > > section but well in the next one ?
> > >
> > >
> > >
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Roman Danyliw's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Roman, 

Thank you for your comments! Please find the diff and the responses in line 
below. Thank you!

Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt


-Original Message-
From: Roman Danyliw via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 25, 2021 2:58 AM
To: The IESG 
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; Julien Meuric ; 
julien.meu...@orange.com
Subject: Roman Danyliw's No Objection on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

Thank you to Yaron Sheffer for the SECDIR review and the updates made as a 
result to improve the Security Considerations.  I endorse the revised text that 
minimally RECOMMENDs the use of “mutually-authenticated and encrypted 
sessions.”  My question is why can’t we go even further and require (use MUST) 
this crucial provisioning channel always be protected.  When would we NOT want 
to use TLS?  I appreciate that mandating the use of security primitives in 
routing is challenging due to a long tail of legacy investment.  However, this 
extension seems like a near "green field" focused on a modern, SDN architecture 
which seems unlikely to have less capable legacy elements.


Shuping> This is a case of blending elements of SDN into the existing 
distributed control plane and devices without necessarily completely replacing 
it and enhancing PCEP as an SBI. It is true that the central control 
instructions allows greater control to label allocation but it is not far from 
what is already done for segment routing label stack (which uses 'RECOMMEND').

Best Regards, 
Shuping 
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Robert Wilton's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Robert, 

Thank you for your comments! Please find the diff and the responses in line 
below. Thank you!

Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt


-Original Message-
From: Robert Wilton via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 25, 2021 8:26 PM
To: The IESG 
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; Julien Meuric ; 
julien.meu...@orange.com
Subject: Robert Wilton's No Objection on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Robert Wilton has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

Hi,

Thanks for the document, I have not had time to review in detail.

The length of the abstract does stand out to me, and it might be helpful if it 
could be shortened.  E.g. I suspect that the first two paragraphs are probably 
not required in the abstract and are best covered in the introduction.

Shuping> Updated.

On section 10:

   A PCE or PCC implementation SHOULD allow to configure to enable/
   disable PCECC capability as a global configuration.   =>
   A PCE or PCC implementation SHOULD allow the PCECC capability
   to be enabled/disabled as part of the global configuration.

Also probably change "is enabled on the PCEP session" to "is enabled on a PCEP 
session"?

Shuping> Ack

Best Regards, 
Shuping 


Regards,
Rob



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

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Benjamin, 

Thank you for your comments! Please find the diff and the responses in line 
below. Thank you!

Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt


-Original Message-
From: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 25, 2021 2:59 PM
To: The IESG 
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; Julien Meuric ; 
julien.meu...@orange.com
Subject: Benjamin Kaduk's No Objection on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

I agree with Roman about the prospects for ensuring a solid security baseline 
with what is essentially greenfield deployment.

Shuping> As mentioned to Roman, this is a case of blending elements of SDN into 
the existing distributed control plane and devices without necessarily 
completely replacing it. 

(throughout) Is the TLV LSP-IDENTIFIER or LSP-IDENTIFIERS (with final 'S')?

Shuping> Updated to LSP-IDENTIFIERS (as per RFC 8231)

Thanks to Yaron Sheffer for the secdir reviews, and to the authors for updating 
in light of that review.

I note in a few places in the section-by-section comments that the figures seem 
to indicate a 'D' flag in PCInitiate and PCUpd messages, and the only D flag I 
see mentioned in the prose is the Delegate flag in a PCRpt.  This seems 
particularly important to check and get right (though I admit that I could just 
be missing something).

Shuping> Yes, D flag is the Delegate flag. Changed the text so that it is 
applicable for other PCEP messages as well - "The ingress PCC and PCE MUST also 
set D (Delegate) flag (see [RFC8231]) and C (Create) flag (see [RFC8281]) in 
the LSP object in the initial exchange."

Section 1

   A PCE-based Central Controller (PCECC) can simplify the processing of
   a distributed control plane by blending it with elements of SDN and
   without necessarily completely replacing it.  Thus, the LSP can be
   calculated/setup/initiated and the label forwarding entries can also
   be downloaded through a centralized PCE server to each network
   devices along the path while leveraging the existing PCE technologies
   as much as possible.

nit: "each network device" singular.

Shuping> Ack

Section 2

   The terminology used in this document is the same as that described
   in the draft [RFC8283].

"That RFC doesn't look like a draft to me"

Shuping> removed


Section 3

   This document also allows a case where the label space is maintained
   by the PCC itself, and the labels are allocated by the PCC, in this
   case, the PCE should request the allocation from PCC as described in
   Section 5.5.8.

nit: comma splice.

Shuping> Ack

Section 4

   4.  PCEP procedures need to provide a mean to update (or clean up)
   the label-download entry to the PCC.

   5.  PCEP procedures need to provide a mean to synchronize the labels
   between the PCE and the PCC via PCEP messages.

nits: "provide a means" plural (twice); s/the label-download entry/label 
entries downloaded/ (I think)

Shuping> Ack

Section 5.4

   A legacy PCEP speaker (that does not recognize the PCECC Capability
   sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and
   [RFC5440].  As per [RFC8408], the legacy PCEP speaker (that does not
   support PST), it will:

Sending a PCErr for an unrecognized PST in the PATH-SETUP-TYPE-CAPABILITY would 
break extensibility; the 21/1 error type/value pair is only used in RFC 8408 
when a PST is attempted to be used in a PCRpt, PCInitiate, or PCUpd.  I think 
we should just say that it ignores the PST in the PATH-SETUP-TYPE-CAPABILITY 
TLV.

Shuping> Changed to "As per [RFC8408], the legacy PCEP speaker on receipt of an 
unsupported PST in RP/SRP Object will:" to make it clear.


Section 5.5.1

   An LSP-IDENTIFIER TLV MUST be included for PCECC LSPs, the tuple
   uniquely identifies the LSP in the network.  [...]

Which tuple?

Shuping> Removed.

Also, RFC 8231 says that the LSP-IDENTIFIERS TLV (note final 'S') must be used 
for RSVP-signaled LSPs, but PCECC is

Re: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Pengshuping (Peng Shuping)]

Hi Murray,

Thank you for your comments! Please find the diff and the responses in line 
below. Thank you!

Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt
 


-Original Message-
From: Murray Kucherawy via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, February 25, 2021 3:42 PM
To: The IESG 
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org; pce@ietf.org; Julien Meuric 
Subject: Murray Kucherawy's No Objection on 
draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

In Section 2, RFC 8283 isn't a "draft".

Shuping> Removed!

In Section 5.5.1:

   Once the label operations are completed, the PCE SHOULD send a PCUpd
   message to the ingress PCC.

Why "SHOULD"?  Is there another option?   Why might an implementer do something 
else?

Shuping> Changed to MUST. Thanks for spotting this!

The SHOULDs elsewhere in Section 5 are probably worth a second look too.

Shuping> Ack

Best Regards, 
Shuping 

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

Re: [Pce] new draft on segment routing approach to TSN

[Jakob Heitz (jheitz)]

Another thing to consider is packets dropped due to bit errors.
Possibilities: Link level acknowledgement and preemptive retransmission
if the link would otherwise be idle. I.e. "just in case" retransmission.

Regards,
Jakob.

From: spring  On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, February 25, 2021 1:27 PM
To: Yaakov Stein 
Cc: det...@ietf.org; Tianran Zhou ; pce@ietf.org; 
spr...@ietf.org
Subject: Re: [spring] new draft on segment routing approach to TSN

Hello Yaakov

Please see below:



Le 25 févr. 2021 à 21:33, Yaakov Stein 
mailto:yaako...@rad.com>> a écrit :

Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

Indeed; the questions that this raises are:

- which WG, so I added RAW to the candidate list in this thread

- how to package the complementary proposals in how many draft

Your excellent work focuses on SR signaling in the forwarding plane with strict 
intermediate latencies at each stage. It would be grand to neatly insert this 
in a SRv6 together with other information that the RAW PSE processes in its 
forwarding/scheduling decision.

There are multiple dimensions in which the scope of your work could be 
enlarged; one of them would be to use a similar signaling but with a best 
effort objective, which is what I discussed. This could easily be combined if 
we decide to, so the same signaling serves both use cases. And maybe more, to 
be discussed.



I was going to add a section on how to reproduce Qbv behavior using a stack of 
deadlines (the argument is a bit tricky, but straightforward).
I don’t necessarily think that is a good idea, but it should be there to 
counter claims that SRTSN only reduces the expectation
but can’t provide an absolute upper bound on latency (when based on EDF).

Very cool;



I like to use the term latency, but sometimes use delay to avoid overusing it.

Your decision, at least as long as it is personal submission ; but having a 
clear terminology is useful. Literature value is of lesser importance here I 
guess. Latency is what we use in DetNet and RAW. Delay often refers to extra, 
possibly unwanted time, like a queueing delay. At least you’d make my reader 
life easier by defining your terminology and sticking to it quite strictly : )



I thought that “green wave” would be understood by those who drive cars in 
cities where traffic light coordination is common.

Yes, and I think you were clear enough; but then only a few deterministic flows 
really operate like that. Another flow that use the same outgoing port will 
have to suffer some delay in a time-triggered queue till the port is free, the 
delay being taken from the end to end latency budget. My suggestion was to 
reconsider the text to avoid giving the impression that all flows benefit from 
that green wave.



I attempted to describe a data structure for EDF to be used instead of a queue,

Neat


but never implied that “queueing” (meaning packets waiting to be transmitted) 
doesn’t occur.
If that were the case there would not be a need for any data structure at all.

Cool


(Another thing I didn’t get into was the trade-offs among the different options,
 from worst case complexity and difficulty to implement in hardware PoVs.)

I’d love to read that too



I took a quick look at US 9602420 and will study it further.

It’s not as deep as an academic paper but a good hint at how you can turn 
schedule into QoS or another technique to reorder the set of packets that 
compete for the port.


However the purpose of this draft is not to mandate any specific scheduling 
mechanism,
rather to show how such mechanisms can be integrated and hopefully more readily 
distributed.

Usually you’re expected to provide the meaning of the signaling and the visible 
behavior of the node; the way the node implements the does not need to be spec 
but some hints on how that can be achieved are welcome, possibly in annex.


Incidentally I am working on a joint path+deadline optimization algorithm which 
only requires partial information.


I’d love to chat in this; missing the face to face meetings! Could it be that 
we do SF in summer?


Proofs of absolute upper bounds on latency are nice, but generally come at the 
price of either

This is exactly why we did what we did; it also comes at the cost of gathering 
very specific info on the flows and not all flows can do that, think CBR.




  1.  significantly reduced bandwidth efficiency (like TDM, or equivalently 
time gating as in Qbv or FlexE),
  2.  unscalable computation
  3.  relatively loose deadlines to being with (like Andrews Zhang)

I need to read it, sorry I was not aware enough of that line of work.



  1.
  2.  assumptions that aren’t necessarily obeyed in real life (like a lot of 
the network calculus proofs).
I would be happy to discuss your variant to see in which class it falls.


Same here!

Re: [Pce] new draft on segment routing approach to TSN

[Pascal Thubert (pthubert)]

Hello Yaakov

Please see below:


Le 25 févr. 2021 à 21:33, Yaakov Stein  a écrit :


Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

Indeed; the questions that this raises are:

- which WG, so I added RAW to the candidate list in this thread

- how to package the complementary proposals in how many draft

Your excellent work focuses on SR signaling in the forwarding plane with strict 
intermediate latencies at each stage. It would be grand to neatly insert this 
in a SRv6 together with other information that the RAW PSE processes in its 
forwarding/scheduling decision.

There are multiple dimensions in which the scope of your work could be 
enlarged; one of them would be to use a similar signaling but with a best 
effort objective, which is what I discussed. This could easily be combined if 
we decide to, so the same signaling serves both use cases. And maybe more, to 
be discussed.


I was going to add a section on how to reproduce Qbv behavior using a stack of 
deadlines (the argument is a bit tricky, but straightforward).
I don’t necessarily think that is a good idea, but it should be there to 
counter claims that SRTSN only reduces the expectation
but can’t provide an absolute upper bound on latency (when based on EDF).

Very cool;


I like to use the term latency, but sometimes use delay to avoid overusing it.

Your decision, at least as long as it is personal submission ; but having a 
clear terminology is useful. Literature value is of lesser importance here I 
guess. Latency is what we use in DetNet and RAW. Delay often refers to extra, 
possibly unwanted time, like a queueing delay. At least you’d make my reader 
life easier by defining your terminology and sticking to it quite strictly : )


I thought that “green wave” would be understood by those who drive cars in 
cities where traffic light coordination is common.

Yes, and I think you were clear enough; but then only a few deterministic flows 
really operate like that. Another flow that use the same outgoing port will 
have to suffer some delay in a time-triggered queue till the port is free, the 
delay being taken from the end to end latency budget. My suggestion was to 
reconsider the text to avoid giving the impression that all flows benefit from 
that green wave.


I attempted to describe a data structure for EDF to be used instead of a queue,

Neat

but never implied that “queueing” (meaning packets waiting to be transmitted) 
doesn’t occur.
If that were the case there would not be a need for any data structure at all.

Cool

(Another thing I didn’t get into was the trade-offs among the different options,
 from worst case complexity and difficulty to implement in hardware PoVs.)

I’d love to read that too


I took a quick look at US 9602420 and will study it further.

It’s not as deep as an academic paper but a good hint at how you can turn 
schedule into QoS or another technique to reorder the set of packets that 
compete for the port.

However the purpose of this draft is not to mandate any specific scheduling 
mechanism,
rather to show how such mechanisms can be integrated and hopefully more readily 
distributed.

Usually you’re expected to provide the meaning of the signaling and the visible 
behavior of the node; the way the node implements the does not need to be spec 
but some hints on how that can be achieved are welcome, possibly in annex.

Incidentally I am working on a joint path+deadline optimization algorithm which 
only requires partial information.


I’d love to chat in this; missing the face to face meetings! Could it be that 
we do SF in summer?

Proofs of absolute upper bounds on latency are nice, but generally come at the 
price of either

This is exactly why we did what we did; it also comes at the cost of gathering 
very specific info on the flows and not all flows can do that, think CBR.



  1.  significantly reduced bandwidth efficiency (like TDM, or equivalently 
time gating as in Qbv or FlexE),
  2.  unscalable computation
  3.  relatively loose deadlines to being with (like Andrews Zhang)

I need to read it, sorry I was not aware enough of that line of work.


  1.
  2.  assumptions that aren’t necessarily obeyed in real life (like a lot of 
the network calculus proofs).
I would be happy to discuss your variant to see in which class it falls.


Same here!

Pascal

Y(J)S


From: Pascal Thubert (pthubert) 
Sent: 25/02/2021 19:40
To: Tianran Zhou ; Yaakov Stein ; 
det...@ietf.org; spr...@ietf.org; pce@ietf.org
Subject: RE: new draft on segment routing approach to TSN


CAUTION: External sender. Do not click links or open attachments unless you 
know the content is safe.
Hi Yaakov and all:

Whereever Yaakov decides to place it I’ll be there supporting the work. The 
draft itself is incredibly well-written and information-rich.
Note that there’s also work in RAW 

Re: [Pce] new draft on segment routing approach to TSN

[Yaakov Stein]

Pascal,

Wow, there is a lot to respond to.

Thanks for the pointers. I was not aware of this work.
However, I believe this proposal is both different and can be complementary to 
the ones you mention.

I was going to add a section on how to reproduce Qbv behavior using a stack of 
deadlines (the argument is a bit tricky, but straightforward).
I don't necessarily think that is a good idea, but it should be there to 
counter claims that SRTSN only reduces the expectation
but can't provide an absolute upper bound on latency (when based on EDF).

I like to use the term latency, but sometimes use delay to avoid overusing it.

I thought that "green wave" would be understood by those who drive cars in 
cities where traffic light coordination is common.

I attempted to describe a data structure for EDF to be used instead of a queue,
but never implied that "queueing" (meaning packets waiting to be transmitted) 
doesn't occur.
If that were the case there would not be a need for any data structure at all.
(Another thing I didn't get into was the trade-offs among the different options,
 from worst case complexity and difficulty to implement in hardware PoVs.)

I took a quick look at US 9602420 and will study it further.
However the purpose of this draft is not to mandate any specific scheduling 
mechanism,
rather to show how such mechanisms can be integrated and hopefully more readily 
distributed.
Incidentally I am working on a joint path+deadline optimization algorithm which 
only requires partial information.

Proofs of absolute upper bounds on latency are nice, but generally come at the 
price of either

  1.  significantly reduced bandwidth efficiency (like TDM, or equivalently 
time gating as in Qbv or FlexE),
  2.  unscalable computation
  3.  relatively loose deadlines to being with (like Andrews Zhang)
  4.  assumptions that aren't necessarily obeyed in real life (like a lot of 
the network calculus proofs).
I would be happy to discuss your variant to see in which class it falls.

Y(J)S


From: Pascal Thubert (pthubert) 
Sent: 25/02/2021 19:40
To: Tianran Zhou ; Yaakov Stein ; 
det...@ietf.org; spr...@ietf.org; pce@ietf.org
Subject: RE: new draft on segment routing approach to TSN


CAUTION: External sender. Do not click links or open attachments unless you 
know the content is safe.
Hi Yaakov and all:

Whereever Yaakov decides to place it I'll be there supporting the work. The 
draft itself is incredibly well-written and information-rich.
Note that there's also work in RAW that mentions SR operation DetNet related 
operations 
(draft-pthubert-raw-architecture).
 RAW has vested interest in intelligent forwarding decision, that would be the 
trademark vs. DetNet. With this draft, the forwarding is not based on Qbv 
schedule but the forwarder has some latitude as long as it matches the hop 
deadline. So RAW may be a good place.
And then there's 
draft-chen-detnet-sr-based-bounded-latency.
 Ideally all these related items would progress in the same room.

Also a few notes on the draft itself:
- maybe use latency instead of delay; it would be nice to maybe define delay as 
something else, e.g., the delay representing the time the packet spends queued 
in one hop vs. the latency that is end to end?
- not sure the term green wave is well understood by the public here; the draft 
gives the impression that the TSN path is faster than the best effort and 
involves no queueing. For the most part that is untrue; the latency is bounded 
but for most flows it is longer than best effort. Best effort can be really 
fast with passthrough in an empty network. The problem is the long tail and 
possibly congestion loss. For TSN, there can be very special flows that will 
traverse the city with all the lights green, but usually there'll be queuing. 
The difference is that the queueing latency is constant and the overall latency 
is withing bounds.
- Time triggered is not the only TSN operation. I wonder what the draft would 
become with asynchronous shaper in mind. We designed (and as I must announce, 
patented as 
US9602420

Re: [Pce] new draft on segment routing approach to TSN

[Pascal Thubert (pthubert)]

Hi Yaakov and all:

Whereever Yaakov decides to place it I'll be there supporting the work. The 
draft itself is incredibly well-written and information-rich.
Note that there's also work in RAW that mentions SR operation DetNet related 
operations 
(draft-pthubert-raw-architecture).
 RAW has vested interest in intelligent forwarding decision, that would be the 
trademark vs. DetNet. With this draft, the forwarding is not based on Qbv 
schedule but the forwarder has some latitude as long as it matches the hop 
deadline. So RAW may be a good place.
And then there's 
draft-chen-detnet-sr-based-bounded-latency.
 Ideally all these related items would progress in the same room.

Also a few notes on the draft itself:
- maybe use latency instead of delay; it would be nice to maybe define delay as 
something else, e.g., the delay representing the time the packet spends queued 
in one hop vs. the latency that is end to end?
- not sure the term green wave is well understood by the public here; the draft 
gives the impression that the TSN path is faster than the best effort and 
involves no queueing. For the most part that is untrue; the latency is bounded 
but for most flows it is longer than best effort. Best effort can be really 
fast with passthrough in an empty network. The problem is the long tail and 
possibly congestion loss. For TSN, there can be very special flows that will 
traverse the city with all the lights green, but usually there'll be queuing. 
The difference is that the queueing latency is constant and the overall latency 
is withing bounds.
- Time triggered is not the only TSN operation. I wonder what the draft would 
become with asynchronous shaper in mind. We designed (and as I must announce, 
patented as US9602420) a system 
very similar to the one proposed in the draft, but that is designed to adapt 
QoS depending on whether the packet is early or late vs. its schedule, and not 
tagging the schedule in the since the latency is considered end to end not hop 
by hop. The use case is slightly different since we apply this without a global 
controller and a provable guarantees all flows will meet the deadline - so not 
really detnet-, but more like a best effort that all flows meet their deadline 
in a stochastic environment. If Yaakov is interested, we can contribute on that 
aspect.

Good luck with the draft,

Pascal


From: detnet  On Behalf Of Tianran Zhou
Sent: jeudi 25 février 2021 9:14
To: Yaakov Stein ; det...@ietf.org; spr...@ietf.org; 
pce@ietf.org
Subject: Re: [Detnet] new draft on segment routing approach to TSN

Hi Yaakov,

This is an interesting topic.
After a quick review, there are several questions as follows:
1. It's clear to me to have a deadline for each packet. So that router can 
schedule the packet based on the urgency. But what's the motivation to split 
the end to end deadline to several local ones?
2. How to divide an end to end deadline into several local deadlines? Is there 
any example algorithm that could be used by the controller?
3. As far as I know, most devices do not support edf. I am not sure whether 
your proposal based on edf could really be useful.

Cheers,
Tianran


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Yaakov Stein
Sent: Tuesday, February 23, 2021 9:14 PM
To: det...@ietf.org; 
spr...@ietf.org; pce@ietf.org
Subject: [Pce] new draft on segment routing approach to TSN

All,

I would like to call your attention to a new ID 
https://www.ietf.org/archive/id/draft-stein-srtsn-00.txt
which describes using a stack-based approach (similar to segment routing) to 
time sensitive networking.
It furthermore proposes combining segment routing with this approach to TSN
resulting in a unified approach to forwarding and scheduling.

The draft is information at this point, since it discusses the concepts and 
does not yet pin down the precise formats.

Apologies for simultaneously sending to 3 lists,
but I am not sure which WG is the most appropriate for discussions of this 
topic.

  *   DetNet is most relevant since the whole point is to control end-to-end 
latency of a time-sensitive flow.
  *   Spring is also directly relevant due to the use of a stack in the header 
and the combined approach just mentioned.
  *   PCE is relevant to the case of a central server jointly computing an 
optimal path and local deadline stack.
I'll let the chairs decide where discussions should be held.

Y(J)S

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

[Pce] PCE WG Agenda for IETF 110

[Dhruv Dhody]

Hi WG,

The agenda for the PCE WG session during IETF 110 is posted -
https://datatracker.ietf.org/meeting/110/materials/agenda-110-pce/

Presenters, please send your slides to pce-cha...@ietf.org by Sunday
7th March, earlier is much better!

Some useful information:
https://www.ietf.org/how/meetings/110/session-participant-guide/

Thanks!
Dhruv, Julien & Hari.

ICS:https://datatracker.ietf.org/meeting/110/sessions/pce.ics
Timezone: 
https://www.timeanddate.com/worldclock/converter.html?iso=20210310T12&p1=1440&p2=tz_cet

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

Re: [Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Erik Kline]

Dhruv,

Thanks for this.

>From my previous review, for reference only:

"""
* Saying that the LINKLOCAL-IPV6-ID-ADDRESS TLV holds a pair of global IPv6
  addresses seems confusing to me.

  If the pair of global IPv6 addresses is to be considered "on link" in the
  sense that IPv6 ND can be successfully be performed on the link for both
  of these addresses, then "ONLINK" might be better than LINKLOCAL.

* Also, why are two interface IDs required?  I would have expected that only
  the outgoing interface name/ID would be of relevance to the recipient of
  a message with TLV in it?
"""

Just for your consideration, in case "ONLINK" seems like it might be
useful naming.

One more thing of note: I am terrible at naming!

On Thu, Feb 25, 2021 at 7:46 AM Dhruv Dhody  wrote:
>
> Hi Eric,
>
> I discussed this offline with one of the authors, who confirmed that
> while NAI in RFC 8664 uses a pair, in this case, the pair is not
> needed for the next-hop information and it can be updated as suggested
> by you.
>
> Thanks!
> Dhruv
>
> On Thu, Feb 25, 2021 at 8:50 PM Dhruv Dhody  wrote:
> >
> > Hi Eric,
> >
> > On Thu, Feb 25, 2021 at 8:35 PM Éric Vyncke via Datatracker
> >  wrote:
> > >
> > > Éric Vyncke has entered the following ballot position for
> > > draft-ietf-pce-pcep-extension-for-pce-controller-12: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
> > >
> > >
> > >
> > > --
> > > DISCUSS:
> > > --
> > >
> > > Thank you for the work put into this document. I have not had time to 
> > > review in
> > > details though :( but I appreciated the detailed description as well as 
> > > the
> > > useful time diagrams.
> > >
> > > Please find below one blocking DISCUSS point (which may be my bad
> > > understanding), some non-blocking COMMENT points (but replies would be
> > > appreciated).
> > >
> > > I hope that this helps to improve the document,
> > >
> > > Regards,
> > >
> > > -éric
> > >
> > > == DISCUSS ==
> > >
> > > -- Section 7.3.1 --
> > > LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are two 
> > > addresses
> > > in this TLV while others have one one ? Also is 'local' and 'remote' 
> > > really
> > > global addresses ?
> > >
> > >
> >
> > Erik Kline had the same comment.
> >
> > The text and encoding is inspired by RFC 8664
> > https://www.rfc-editor.org/rfc/rfc8664.html#section-4.3.2
> >
> > which says -
> >
> > IPv6 Link-Local Adjacency:
> > Specified as a pair of (global IPv6 address, interface ID) tuples. It
> > is used to describe an IPv6 adjacency for a link that uses only
> > link-local IPv6 addresses. Each global IPv6 address is configured on a
> > specific router, so together they identify a pair of adjacent routers.
> > The interface IDs identify the link that the adjacency is formed over.
> >
> > A reference to RFC8664 and more description can be added.
> >
> > Thanks!
> > Dhruv
> >
> > > --
> > > COMMENT:
> > > --
> > >
> > > == COMMENTS ==
> > >
> > > A minor comment: the abstract is clear but probably a little too long for 
> > > an
> > > abstract.
> > >
> > > -- Section 7.3 --
> > > Just wonder why  LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this 
> > > section but
> > > well in the next one ?
> > >
> > >
> > >
>

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

Re: [Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Dhruv Dhody]

Hi Eric,

I discussed this offline with one of the authors, who confirmed that
while NAI in RFC 8664 uses a pair, in this case, the pair is not
needed for the next-hop information and it can be updated as suggested
by you.

Thanks!
Dhruv

On Thu, Feb 25, 2021 at 8:50 PM Dhruv Dhody  wrote:
>
> Hi Eric,
>
> On Thu, Feb 25, 2021 at 8:35 PM Éric Vyncke via Datatracker
>  wrote:
> >
> > Éric Vyncke has entered the following ballot position for
> > draft-ietf-pce-pcep-extension-for-pce-controller-12: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > Thank you for the work put into this document. I have not had time to 
> > review in
> > details though :( but I appreciated the detailed description as well as the
> > useful time diagrams.
> >
> > Please find below one blocking DISCUSS point (which may be my bad
> > understanding), some non-blocking COMMENT points (but replies would be
> > appreciated).
> >
> > I hope that this helps to improve the document,
> >
> > Regards,
> >
> > -éric
> >
> > == DISCUSS ==
> >
> > -- Section 7.3.1 --
> > LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are two 
> > addresses
> > in this TLV while others have one one ? Also is 'local' and 'remote' really
> > global addresses ?
> >
> >
>
> Erik Kline had the same comment.
>
> The text and encoding is inspired by RFC 8664
> https://www.rfc-editor.org/rfc/rfc8664.html#section-4.3.2
>
> which says -
>
> IPv6 Link-Local Adjacency:
> Specified as a pair of (global IPv6 address, interface ID) tuples. It
> is used to describe an IPv6 adjacency for a link that uses only
> link-local IPv6 addresses. Each global IPv6 address is configured on a
> specific router, so together they identify a pair of adjacent routers.
> The interface IDs identify the link that the adjacency is formed over.
>
> A reference to RFC8664 and more description can be added.
>
> Thanks!
> Dhruv
>
> > --
> > COMMENT:
> > --
> >
> > == COMMENTS ==
> >
> > A minor comment: the abstract is clear but probably a little too long for an
> > abstract.
> >
> > -- Section 7.3 --
> > Just wonder why  LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this section 
> > but
> > well in the next one ?
> >
> >
> >

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

Re: [Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Dhruv Dhody]

Hi Eric,

On Thu, Feb 25, 2021 at 8:35 PM Éric Vyncke via Datatracker
 wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-pce-pcep-extension-for-pce-controller-12: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for the work put into this document. I have not had time to review 
> in
> details though :( but I appreciated the detailed description as well as the
> useful time diagrams.
>
> Please find below one blocking DISCUSS point (which may be my bad
> understanding), some non-blocking COMMENT points (but replies would be
> appreciated).
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> -- Section 7.3.1 --
> LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are two 
> addresses
> in this TLV while others have one one ? Also is 'local' and 'remote' really
> global addresses ?
>
>

Erik Kline had the same comment.

The text and encoding is inspired by RFC 8664
https://www.rfc-editor.org/rfc/rfc8664.html#section-4.3.2

which says -

IPv6 Link-Local Adjacency:
Specified as a pair of (global IPv6 address, interface ID) tuples. It
is used to describe an IPv6 adjacency for a link that uses only
link-local IPv6 addresses. Each global IPv6 address is configured on a
specific router, so together they identify a pair of adjacent routers.
The interface IDs identify the link that the adjacency is formed over.

A reference to RFC8664 and more description can be added.

Thanks!
Dhruv

> --
> COMMENT:
> --
>
> == COMMENTS ==
>
> A minor comment: the abstract is clear but probably a little too long for an
> abstract.
>
> -- Section 7.3 --
> Just wonder why  LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this section but
> well in the next one ?
>
>
>

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

[Pce] Éric Vyncke's Discuss on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
DISCUSS:
--

Thank you for the work put into this document. I have not had time to review in
details though :( but I appreciated the detailed description as well as the
useful time diagrams.

Please find below one blocking DISCUSS point (which may be my bad
understanding), some non-blocking COMMENT points (but replies would be
appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 7.3.1 --
LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are two addresses
in this TLV while others have one one ? Also is 'local' and 'remote' really
global addresses ?


--
COMMENT:
--

== COMMENTS ==

A minor comment: the abstract is clear but probably a little too long for an
abstract.

-- Section 7.3 --
Just wonder why  LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this section but
well in the next one ?



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

[Pce] Robert Wilton's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

Hi,

Thanks for the document, I have not had time to review in detail.

The length of the abstract does stand out to me, and it might be helpful if it
could be shortened.  E.g. I suspect that the first two paragraphs are probably
not required in the abstract and are best covered in the introduction.

On section 10:

   A PCE or PCC implementation SHOULD allow to configure to enable/
   disable PCECC capability as a global configuration.   =>
   A PCE or PCC implementation SHOULD allow the PCECC capability
   to be enabled/disabled as part of the global configuration.

Also probably change "is enabled on the PCEP session" to "is enabled on a PCEP
session"?

Regards,
Rob



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

Re: [Pce] new draft on segment routing approach to TSN

[Tianran Zhou]

Hi Yaakov,

This is an interesting topic.
After a quick review, there are several questions as follows:
1. It's clear to me to have a deadline for each packet. So that router can 
schedule the packet based on the urgency. But what's the motivation to split 
the end to end deadline to several local ones?
2. How to divide an end to end deadline into several local deadlines? Is there 
any example algorithm that could be used by the controller?
3. As far as I know, most devices do not support edf. I am not sure whether 
your proposal based on edf could really be useful.

Cheers,
Tianran


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Yaakov Stein
Sent: Tuesday, February 23, 2021 9:14 PM
To: det...@ietf.org; spr...@ietf.org; pce@ietf.org
Subject: [Pce] new draft on segment routing approach to TSN

All,

I would like to call your attention to a new ID 
https://www.ietf.org/archive/id/draft-stein-srtsn-00.txt
which describes using a stack-based approach (similar to segment routing) to 
time sensitive networking.
It furthermore proposes combining segment routing with this approach to TSN
resulting in a unified approach to forwarding and scheduling.

The draft is information at this point, since it discusses the concepts and 
does not yet pin down the precise formats.

Apologies for simultaneously sending to 3 lists,
but I am not sure which WG is the most appropriate for discussions of this 
topic.

  *   DetNet is most relevant since the whole point is to control end-to-end 
latency of a time-sensitive flow.
  *   Spring is also directly relevant due to the use of a stack in the header 
and the combined approach just mentioned.
  *   PCE is relevant to the case of a central server jointly computing an 
optimal path and local deadline stack.
I'll let the chairs decide where discussions should be held.

Y(J)S

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