Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Huimin 

Documenting the 3 cases (and giving names) looks like a good idea, Huimin. That helps explain what an implementation supports and what it does not. 

I want to ensure that the group understand what can be done, and then we'll provide examples of how that is done. This is what I started with the cases.

I did not get much feedback. Should I assume that the group agrees the examples work?

Pascal 

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Huimin She (hushe)
> Sent: mercredi 9 décembre 2020 07:19
> To: [e-mail]
> Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions
> on P-DAO
> 
> Hi Pascal,
> 
> Non-storing P-DAO is a very good complement for non-storing RPL.
> One of the practical use case is to find the P2P path via the common ancestor in
> non-storing mode RPL.
> 
> For non-storing P-DAO, I think it's fine to live with Tracks without segments.
> 
> For the P-DAO draft, is it more reasonable to list three cases: non-storing,
> storing, and mixing?
> 
> Best regards,
> Huimin
> 
>     Message: 1
>     Date: Tue, 8 Dec 2020 07:29:37 +0000
>     From: "Pascal Thubert (pthubert)" <[e-mail]>
>     To: Routing Over Low power and Lossy networks <[e-mail]>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
>     	Questions on P-DAO
>     Message-ID:
> 
> 	<CO1PR11MB48819E978A4064D00E869A75D8CD0@CO1PR11MB48
> 81.namprd11.prod.outlook.com>
> 
>     Content-Type: text/plain; charset="iso-8859-1"
> 
>     Hello Li:
> 
>     > Yes. There is no segment in non-storing mode anymore... It seems that we
> either back to egress as root or accept this shortage?
> 
>     I have been bouncing between the 2. You can see that in the diffs in the
> 6TiSCH architecture. I did again when you suggested the change back to the
> ingress is root. We need to settle. The change was a lot of work
> (https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-15.txt). The
> reason why I accepted the change is that the RH reload that II explained at IETF
> 109 is far from accepted at 6MAN, and the history we have there with RH
> insertion does not leave much hope anyway. Which leaves us with:
> 
>     a) Tracks are non-storing  paths expressed in strict or loose source route.
> Simple implementations only do strict
>     b) Segments are storing mode paths, that stitch loose SRH paths. This applies
> to the main DODAG and to Tracks. That's the normal segment routing case 1.3
> below.
> 
>     What is also possible but more complex:
>     c) A path can be established by stitching segments without declaring a Track
> (that's case 1.1 below). The Track is implicit.
>     d) Instead of declaring a storing mode segment between 2 loose SRH hops, the
> path can be another Track in which case we need to encapsulate between the
> loose hops. That's the non-storing segment routing case 2.3 below.
> 
>     And then there can be tunneling of traffic beyond the egress, e.g., if the egress
> is a station with multiple devices in it.
> 
>     > Btw, I think mixed storing PDAO /non-storing PDAO/Stitched Segments is
> complex and maybe little bit hard to use in runtime deployment.
> 
> 
>     An implementation will not need to support all possible combinations. It is
> really a matter of what the industry standard -the like of Thread or Wi-Sun- that
> would use RPL P DAO needs. You see it today, most implementations of RPL do
> not support both storing and non-storing modes. But we have a consistent RPL
> RFC which can do both with most things in common.
> 
>     This is something we also observe with RFC 6282. The RFC has to propose all
> possibilities in a consistent fashion with a clear architecture that encompasses all
> cases. But you find that open source implementations, Thread or Wi-Sun did not
> necessarily support the same cases, and would not necessarily interoperate.
> Since those implementations face one another, that is not an issue.
> 
>     When an industry standard moves to P-DAO, it may support, say, only strict
> non-storing mode P-DAOs, if the problem is P2P/automation. It may create only
> one, or it may create more than one P2P path from ingress to egress. It may
> enable tunneling or not.
> 
>     Another standard may only care to shorten the SRH in the main DODAG, in
> which case it will not need the sibling information and the tracks, but just the
> storing mode P-DAO in the main DODAG.  Just like today we have storing mode
> only and non-storing mode only implementations. This is the original use of
> mixed P-DAO segments with loose SRH path. This use case makes a lot of sense
> and is the reason why the group originally adopted the draft.
> 
>     Because it proposes a consistent model, the draft allows a combination of
> tracks and segments. In that case, the SRH that defines a Track is loose, and
> storing mode segments join the dots, like they do in the main DODAG. I agree
> with you, that can be complex in current use cases. So I do not expect industry
> standards to pick it up day 1. But should we add text to say do not do it?
> 
>     It would be a lot worse if there were 10 RFCs that operate differently with no
> consistency and overall architecture!
> 
>     > The original requirement I want to get from pdao-draft is finding an
> available p2p path from PCE with lowest cost. Which means easy to get route
> entry from PCE and easy to maintain in node.
> 
>     > Because either rpl local instance or aodv-p2p mechanism will leverage more
> DIO/DAO/NS messages to maintain the route path.
> 
>     Yes, maybe you can live with non-storing strict SRH for that use case. Do you
> also need to compress the SRH in the main DODAG? I would suspect so.
> 
>     Keep safe;
> 
>     Pascal
> 
>     From: Roll <[e-mail]> On Behalf Of Li Zhao (liz3)
>     Sent: mardi 8 d?cembre 2020 02:07
>     To: Routing Over Low power and Lossy networks <[e-mail]>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
> 
>     Hello Pascal,
> 
>     Yes. There is no segment in non-storing mode anymore... It seems that we
> either back to egress as root or accept this shortage?
> 
> 
> 
>     More comments line...
> 
>     Btw, I think mixed storing PDAO /non-storing PDAO/Stitched Segments is
> complex and maybe little bit hard to use in runtime deployment.
>     The original requirement I want to get from pdao-draft is finding an available
> p2p path from PCE with lowest cost. Which means easy to get route entry from
> PCE and easy to maintain in node.
>     Because either rpl local instance or aodv-p2p mechanism will leverage more
> DIO/DAO/NS messages to maintain the route path.
> 
> 
>     Best regards,
>     Li
> 
> 
>     From: Roll <[e-mail]<mailto:[e-mail]>>
>     Date: Friday, November 27, 2020 at 19:52
>     To: Routing Over Low power and Lossy networks
> <[e-mail]<mailto:[e-mail]>>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
>     Dear all
> 
>     <hard thinking here, sorry, been scratching my head quite a bit, so please bear
> with me>
> 
>     On this thread we decided to change the Root from being the Track egress to
> being the ingress. That is cool for many reasons, but as i said that kills the
> possibility to "reload" the routing header in a multi-segment Track where the
> segments are expressed as non-storing P-DAOs. Why?
> 
>     The operation I presented at IETF 109 involves changing the packet source at
> the segment stitching point and still recognize the packet as being part of a
> Track. The change above makes the packet source is the Root of the Track, so
> the packet source now identifies the Track (together with the RPI). Non-storing
> P-DAOs require to add a routing header. If header insertion was allowed then
> that would not be an issue.
> 
>     But to add a RH cleanly at the segments stitching point, the connecting router
> needs to decapsulate the previous segment and encapsulate the next segment
> with the RH. The connecting router becomes the source, thus the root. Meaning
> that the segment is in fact a Track in its own right as opposed to a segment of the
> complex Track.
> 
>     Another way to say that there is no segment in non-storing mode anymore.
> There are only Tracks that can be further assembled into more complex graphs.
> That is, unless as I said we allow RH insertion despite the disputes we observe on
> the same subject at 6MAN about Segment Routing. Or the TrackID is taken from
> the Global Instance IDs name space. At the moment I'm ignoring those options
> which lead to either political issues or technical limitations.
> 
> 
>     A complex Track can still be expressed as a collection of loose source routing
> paths from a same Ingress == Root.
> 
>     Think of it as a Segment Routing Policy for those familiar with SR. The
> difference is that in SR the loose hops are ECMP path served by the IGP.
> 
>     Here we'll need either non-storing Tracks or storing mode segments, the
> difference being that the storing mode segments do not required re-
> encapsulation. Note that in either case, there can be multiple NECMP
> possibilities.
> 
> 
>     An example maybe?
> 
> 
>     Say we have
> 
>                                     ------ F
>     A------B------C------D------E <
>                                     ------ G
> 
> 
>     A is Track ingress, E is track Egress. C is stitching point. F and G are E's
> neighbors, "external" to the Track, and reachable from A over the Track A->E.
>     In a general manner we want:
> 
>       *   PDAO 1 signals A->B->C
>       *   PDAO 2 signals C->B->E
>       *   PDAO 3 signals F and G via the A->E Track
> 
>     PDAO 3 being loose, it can only be non-storing. Note that since the Root is
> always the ingress of a Track, and all SR-VIOs are now Track, the Root being
> signaled in the DAO base object can now be elided in the VIA list in SR-VIO. This
> enables the construction by the main root of the RFC 8138 optimized SRH-
> 6LoRH in the SR-VIO, to be placed as is in the packet by the Root.
> 
> 
>     1) Storing mode Segments
>     --------------------------------
> 
>     A->B->C and C->D->E are segments of a same Track.
>     Note that the storing mode signaling imposes strict continuity in a segment.
> This may also avoid weird loops.
> 
>     Case 1.1) Stitched Segments
> 
> 
>       1.  storing mode PDAO 1 is sent to E. It has Root = A, VIO = C, D, E, Track ID
> 129 from A's namespace, Target = E, F, G
>       2.  storing mode PDAO 2 is then sent to C. It has Root = A, VIO = A, B, C, Track
> ID 129 from A's namespace, Target = E, F, G
> 
>     E recognizes that it is egress because it is a Target and a segment endpoint.
> 
>     Packets along the Track have source= A, destination = E | F | G, and RPI = 129.
>     >From PDAO 2: A forwards to B and B forwards to C.
>     >From PDAO 1: C forwards to D and D forwards to E.
> 
> 
>     Case 1.2) External routes
> 
> 
>       1.  storing mode PDAO 1 is sent to E. It has Root = A, VIO = C, D, E, Track ID
> 129 from A's namespace, Target = E
>       2.  storing mode PDAO 2 is then sent to C. It has Root = A, VIO = A, B, C, Track
> ID 129 from A's namespace, Target = E
>       3.  non storing mode PDAO 3 is then sent to A. It has Root = A, SRVIO = E,
> Track ID 129 from A's namespace, Target = F, G
> 
>     >From PDAO 3: A encapsulates packets with dest =   F | G as below;
>     Packets along the Track have source= A, destination = E, and RPI = 129.
>     >From PDAO 2: A forwards to B and B forwards to C.
>     >From PDAO 1: C forwards to D and D forwards to E.
>     E decapsulates if encapsulated packet.
> 
> 
> 
>     Case 1.3) Segment Routing
> 
> 
>       1.  storing mode PDAO 1 is sent to E. It has Root = A, VIO = C, D, E, Track ID
> 129 from A's namespace, Target = E
>       2.  storing mode PDAO 2 is then sent to B. It has Root = A, VIO = A, B, Track
> ID 129 from A's namespace, Target = B, C
>       3.  non storing mode PDAO 3 is then sent to A. It has Root = A, SRVIO = C, E,
> Track ID 129 from A's namespace, Target = F, G
> 
> 
>     >From PDAO 3: A encapsulates packets with dest =   F | G as below;
>     Packets from A have source= A, destination = C, SRH = E, and RPI = 129.
>     >From PDAO 2: A forwards to B.
>     B forwards to C based on a sibling connected route; C consumes the RH and
> makes the destination E.
>     >From PDAO 1: C forwards to D and D forwards to E.
>     E decapsulates if encapsulated packet.
> 
> 
> 
>     2) Non Storing mode joining Tracks
>     ---------------------------------------------
> 
>     A->B->C and C->D->E are Tracks expressed as non-storing P-DAOs.
> 
>     Case 2.1 Stitched Tracks
> 
> 
>       1.  non storing mode PDAO 1 is sent to C. It has Root = C, VIO = D, E, Track ID
> 131 from C's namespace, Target = E, F, G
>       2.  non storing mode PDAO 2 is then sent to A. It has Root = A, VIO = B, C,
> Track ID 129 from A's namespace, Target = E, F, G
> 
>     >From PDAO 2: A encapsulates packets with dest =  E | F | G. The outer
> header has source = A, destination = B, SRH = C and RPI = 129.
>     Packets forwarded by B have source= A, destination = C , SRH =, and RPI =
> 129. C decapsulates.
>     >From PDAO 1: C  encapsulates packets with dest =  E | F | G. The outer
> header has source= C, destination = D, SRH = E and RPI = 131.
>     E decapsulates.
> 
> 
>     Case 2.2 External routes
> 
> 
>       1.  non storing mode PDAO 1 is sent to C. It has Root = C, VIO = D, E, Track ID
> 131 from C's namespace, Target = E
>       2.  non storing mode PDAO 2 is then sent to A. It has Root = A, VIO = B, C,
> Track ID 129 from A's namespace, Target = E
>       3.  non storing mode PDAO 3 is then sent to A. It has Root = A, SRVIO = E,
> Track ID 141 from A's namespace, Target = F, G
> 
> 
> 
>     >From PDAO 3: A encapsulates packets with dest =   F | G. The outer header
> has source = A, destination = E, and RPI = 141.
>     This may recurse with:
>     >From PDAO 2: A encapsulates packets with dest =  E. The outer header has
> source = A, destination = B, SRH = C and RPI = 129.
>     Packets forwarded by B have source= A, destination = C , SRH =, and RPI =
> 129. C decapsulates.
>     >From PDAO 1: C  encapsulates packets with dest =  E. The outer header has
> source= C, destination = D, SRH = E and RPI = 131.
>     E decapsulates if encapsulated.
> 
> 
>     Case 2.3 Segment Routing
> 
> 
>       1.  non storing mode PDAO 1 is sent to C. It has Root = C, VIO = D, E, Track ID
> 131 from C's namespace, Target = E
>       2.  non storing mode PDAO 2 is then sent to A. It has Root = A, VIO = B,  Track
> ID 129 from A's namespace, Target = C, E
>       3.  non storing mode PDAO 3 is then sent to A. It has Root = A, SRVIO = C, E,
> Track ID 141 from A's namespace, Target = F, G
> 
> 
>     >From PDAO 3: A encapsulates packets with dest =   F | G. The outer header
> has source = A, destination = C, SRH = E, and RPI = 141.
>     This may recurse with:
>     >From PDAO 2: A encapsulates packets with dest =  C | E . The outer header
> has source = A, destination = B, and RPI = 129.
>     B decapsulates forwards to C based on a sibling connected route; C consumes
> the RH and makes the destination E.
>     >From PDAO 1: C  encapsulates packets with dest =  E. The outer header has
> source= C, destination = D, SRH = E and RPI = 131.
>     E decapsulates, twice for dest =   F | G.
> 
> 
>     Does that work so far?
> 
>     Keep safe
> 
>     Pascal
> 
> 
>     From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf
> Of Pascal Thubert (pthubert)
>     Sent: jeudi 26 novembre 2020 11:47
>     To: Routing Over Low power and Lossy networks
> <[e-mail]<mailto:[e-mail]>>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
> 
>     Hello Li
> 
>     In the packet, there's a bit in the RPI to say if the root is the source or the
> destination. That's RFC 6550.
>     I guess the discussion is related to the PDR and P-DAO, not data packet,
> though it impacts the ICMP error reporting.
> 
>     In a packet along the P-Route, the idea was so far that the DODAG is a
> convergecast to the destination so the destination is the root. If we say that
> there's a single ingress and a single egress then the dodag is reversible and either
> can be the root. If we want to support multicast tracks in the future, then the
> ingress should be root.
> 
>     If the Track has a single ingress and a single egress, then the DODAG is
> reversible into another DODAG and it does not matter which is root, so we can
> make it bidir as Huimin asked.
>     The storing mode P DAO would look a lot more like a DAO, as you pointed
> out, if it goes towards the root. If we want to take that path, a node could learn
> both directions with a single storing mode P DAO. To be continued...
> 
>     For non-storing, making bidir is really hard. It seems easier to install a Track in
> both directions and couple them.
> 
>     As a summary of the proposed changes:
> 
>     General
>     - we make the root the ingress
>     - ICMP errors sent to the Root, using the main DODAG if the track is not
> reversible
> 
> 
>     Storing mode P DAO:
>     - we also make the root the ingress, P-DAO from egress to ingress are now
> more similar to RPL DAO operation
>     - the track could be made bi-directional, but that's more code; if so:
>       - the packet forwarding leverages the RPI to indicate the direction, from or to
> root
>       - ICMP errors sent to the Root, could be source or destination.
> 
>     Non storing mode P DAO:
>     - tracks remain directional, can be coupled, how is tbd
>     - the RPI is mostly useless since the intermediate nodes do not know the
> instance (they see neither the DIO nor the P-DAO); they have no idea of their
> Rank. Still, it is interesting to have is for error determination in an ICPMP error at
> eth root. It is also interesting if the SRH forwarding nodes have a state associated
> to the Track, e.g., reserved time slots or priority queues.
>     - the RPI is still a SHOULD when there's no compression and a MUST when
> there is. We need to clarify what to do, that's another of Huimin's questions,
> taken separately.
>     - ICMP errors forwarding packets are sent to the root which is now the
> ingress, aka the source of the packet, and the encapsulator field if the packet is
> encapsulated and compressed. This is common to any non-storing operation,
> whether it is a main Instance, local Instance, or Track. The RPI therein is useful to
> indicate the Track in Error. So for that matter the forwarder does not need to
> make a difference Track vs. other form of RPL local instance.
>     - this impacts the discussion in SRH reloading we had at IETF 109, when a  N-S
> mode loose track is forwarded along a segment that is also NS mode. We'll
> probably need to re-encapsulate now.  In case of re-encapsulation, the re-
> encapsulator becomes source and root of the segment, which now has to be
> considered as a serial Track; as tunnel headends do, it will have to decapsulate
> the tunneled packet to send the packet in error back to the ingress of the loose
> track
> 
> 
>     Doe that work?
> 
>     Pascal
> 
>     From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf
> Of Li Zhao (liz3)
>     Sent: jeudi 26 novembre 2020 03:45
>     To: Routing Over Low power and Lossy networks
> <[e-mail]<mailto:[e-mail]>>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
> 
>     Hello Pascal,
> 
>     If either source or destination can be root, it's better to identify when or in
> which case source or destination can be root. Otherwise, it's hard to interop
> between different implement even though they both follow RFC standard.
> 
>     E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-
> ACK after receiving PDR from source.
>     But if destination is root, PCE should also notify destination which trackid is
> used. Maybe we need bring new message for this notification?
> 
> 
>     Take care,
>     Li
> 
>     From: Roll <[e-mail]<mailto:[e-mail]>>
>     Date: Wednesday, November 25, 2020 at 21:54
>     To: Routing Over Low power and Lossy networks
> <[e-mail]<mailto:[e-mail]>>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
>     Hello Li;
> 
>     Well noted. This was the original intent. The change was made to egress
> because the idea was that the track could enable multiple sources to reach the
> egress, like a tree rooted at the egress that flows traverse going down. But the
> idea of a bidirectional track kinda blocks that idea and the other issues like the
> one you point out seem to get us back to the original view. I recently made the
> change from ingress to egress in the 6TiSCH architecture, waiting in RFC editor
> queue. I could reverse back, or maybe say "either source or destination" so it
> can be egress or egress and we are covered for bidirectional.
>     What do you think?
>     Or should a reversable Track be really a pair of tracks?
> 
>     Keep safe;
> 
>     Pascal
> 
>     From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf
> Of Li Zhao (liz3)
>     Sent: mercredi 25 novembre 2020 05:57
>     To: Routing Over Low power and Lossy networks
> <[e-mail]<mailto:[e-mail]>>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
> 
>     Hello Pascal,
> 
>     Ingress as Root looks better because
>     1.  It is consistent with the way RPL usually works. RPL Local instance, aodv-
> rpl, p2p-rpl all use ingress as root.
>     2.  For non-storing-mode P-DAO, currently ingress sends upward traffic to
> egress(root) with SR header. But in RPL, only downward traffic carries SR
> header.
>     3.  Only ingress can send PDR makes sense. Behavior of TrackId is similar as
> Local Instance ID. Ingress as root can propose TrackId from its namespace.
> 
> 
>     And for storing-mode P-DAO, if we make ingress as root and ingress sends
> PDR, can PCE send P-DAO to egress then egress forwards it towards predecessor
> to ingress?
>     Maybe it helps to make P-DAO looks like a DAO message.
> 
> 
>     Best regards,
>     Li
> 
> 
>     From: Roll <[e-mail]<mailto:[e-mail]>>
>     Date: Tuesday, November 24, 2020 at 21:39
>     To: Routing Over Low power and Lossy networks
> <[e-mail]<mailto:[e-mail]>>
>     Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions
> on P-DAO
>     Dear all
> 
>     Whether to make the P-DAO bidirectional is an intriguing question. It could be
> done, just like we can send packets DOWN a classical DODAG.
>     But if we take that path, we reopen the question of who is root and which
> direction the P-DAO flies.
> 
>     Could we make either the ingress OR the egress root? How does it matter?
> 
>     At the moment the Root is the egress and the storing-mode P-DAO flies from
> the Track egress to the track ingress, and the track egress is the root. This is not
> the way RPL usually works as the DAO flies towards the root. The reason was
> that we wanted a single egress for the Track, as we build unicast Track. If we
> wanted to build multicast Tracks the root should logically be the ingress. And for
> bidirectional Tracks it could be either.
> 
>     Up to -24 the 6TiSCH Architecture expected the ingress to be root. I changed
> in the latest to map we do here, that it is the egress; maybe a flag in the DAO
> would indicate which direction the flow, from root, to root, or both?
> 
>     Also if we build bidir Tracks in storing mode, the nodes that forward the DAO
> will have to build routes in both directions based on the P-DAO, both towards
> egress and ingress; but only the path from which the P-DAO comes has been
> validated by the P-DAO itself. Should we send a P-DAO to each end, each setting
> up one way?
> 
>     Please let me know your thoughts
> 
>     Pascal
> 
> 
>     From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf
> Of Pascal Thubert (pthubert)
>     Sent: mardi 24 novembre 2020 14:22
>     To: Routing Over Low power and Lossy networks
> <[e-mail]<mailto:[e-mail]>>
>     Subject: [Roll] IETF 109 open Questions on P-DAO
> 
>     Dear all
> 
>     The slides for the P-DAO discussion at IETF 109 are available here:
> 
>     https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/
> 
>     There are a number of open questions that we starting discussing, and would
> need to progress on the list.
>     Some of them were expressed on the list, e.g., from Huimin She. I'd like to
> progress on them all with individual threads.
>     The questions are:
> 
> 
>       1.  Lifetime Unit: could we use a different unit for P-DAO?
>       2.  How to differentiate a P-DAO from a normal DAO in a local instance; new
> flag?
>       3.  Make P-DAO bidirectional?
>       4.  Who sends the PDR? Does it have to be the ingress? If it was egress it
> could propose a TrackId from its namespace. Else could the ingress be the root?
>       5.  Maintaining the sibling state. Should we have text on using RFC 8505
> there?
>       6.  Whether ingress and egress are listed in NPO? Today they are both,
> ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH
> compression reference and egress to build the full SRH-6LoRH. Note that the
> ingress must consume the first entry and use it as source.
>       7.  Track in Track vs. SR Header reload models, see slides
> 
>     Let me open threads to follow up.
> 
>     Keep safe
> 
>     Pascal
> 
> 
> 
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll