Subject: [Teas] P2MP message fragmentation : [Was WG Last Call on draft-ietf-teas-p2mp-loose-path-reopt]

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 Oct 2016 11:53:30 +0100

Thanks Rakesh,

Just cutting down to the discussion of fragmentation

>> I'm confused :-)
>> 4875 manages semantic fragmentation without the new S2L_SUB_LSP_FRAG
>> Object. It isn't clear in this document why reoptimisation (which is not
>> substantially different from LSP setup) needs this new function.
>
> Request for this addition came from Papadimitriou, Dimitri (author for RFC4875),
> who reviewed this document. Please see the attached email thread.  It seems
> this was thought of during RFC4875 but left as future work.

I think that the concern you are addressing is two-fold: forward path (i.e., Path message), and reverse path (i.e., PathErr mssage). In all cases, you're worried about what happens when there are so many sub-LSPs that the encoding of the message becomes too large.

In the forward direction, per 4875, semantic fragmentation "just works". There is no need to be worried about the sequence of Path messages, and no need to know whether all fragments have arrived. Each Path message simply overlays the others as and when if it received.

The reverse direction is what motivates you in this work. That is, an intermediate node wants to report the potential for re-optimising the part of the LSP to a large number of leaf nodes. If there are so many nodes that the PathErr must be fragmented, then you want to make sure that all fragments are received at the root before the new Path message is sent so that the re-optimisation is accurate.

Now, let's suppose that there is some branch node that is aware that re-optimisation is possible for some of the downstream leaf nodes. The branch node is, of course, unaware of re-optimisation that is available on other branches. So the branch node builds a re-optimisation PathErr for all of the leaf nodes for which it wants the root to signal a new Path message. 

My question is that, considering that
- the root node knows which leaf nodes are downstream of the branch
- the branch knows which leaf nodes can be re-optimised
couldn't a single PathErr from the branch be sent saying "all parts of the tree downstream of this branch node"?

That would remove all need for sending multiple PathErr fragment.

Anyway, thanks for making all of the other changes.

Cheers,
Adrian

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 25 Oct 2016 02:17:05 +0000

Hi Adrian,

Please see inline with <RG> ..

>couldn't a single PathErr from the branch be sent saying "all parts of the tree downstream of this branch node"?

<RG>  Provisions to do this by sending a single notification to re-optimize the tree is already in the draft (Preferable P2MP-TE Tree Exists Path Error Sub-code).

Let’s take an example. Looking at the Figure 1 from the draft.

https://tools.ietf.org/html/draft-ietf-teas-p2mp-loose-path-reopt-07#section-3.1

Let’s say there are 100s of S2L destinations behind node R10 and there is a need to re-optimize those destinations only, without affecting the rest of the P2MP-TE tree.

Only way to do this is using Sub-group-based re-optimization method and the head-end sending path queries (with S2L list) for those destinations to ABR3. If ABR3 knows the candidate S2L list for re-evaluation, it can evaluate that portion of the tree accurately in its domain. If there are large number of such destinations, the Path message may get fragmented and may not yield the desired result at ABR3.

Similarly, ABR3 needs to notify the head-end about only those destinations towards ABR7 (past R10) if there is a preferred path in its domain. ABR3 does not evaluate destinations towards ABR8 in this case. If there is a preferred path for those destinations towards ABR7, ABR3 needs to send PathErr messages with those S2Ls in the list (and it can not use PathErr for the tree here). This PathErr may get fragmented before reaching the head-end and not achieve desired results.

>Anyway, thanks for making all of the other changes.

<RG> Thanks for the thorough review and many useful feedbacks.

Regards,
Rakesh (for all authors)

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Oct 2016 08:58:44 +0100

OK, I'm not going to push this further than adding some words to what you said...

> Only way to do this AT THE MOMENT is using Sub-group-based re-optimization
> method and the head-end sending path queries (with S2L list) for those 
> destinations to ABR3.

My observation is that in a new report type, the branch node could report "Re-optimisation is available for leaf nodes downstream of this branch node". And the root could then either signal Path messages as usual or could use a new Path message to "Trigger re-optimisation for all leaf nodes downstream of the branch".

And now I'll move on. I don't have and do not intend to have an implementation of this function so I my concern is academic (to do the right thing and not over-complicate the protocol).

Cheers,
Adrian

> -----Original Message-----
> From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
> Sent: 25 October 2016 03:17
> To: [email-masked]; 'Vishnu Pavan Beeram'
> Cc: 'TEAS WG Chairs'; [email-masked]; draft-ietf-teas-p2mp-loose-path-
> [email-masked]
> Subject: Re: P2MP message fragmentation : [Was WG Last Call on draft-ietf-teas-
> p2mp-loose-path-reopt]
> 
> Hi Adrian,
> 
> >I think that the concern you are addressing is two-fold: forward path (i.e., Path
> message), and reverse path (i.e., PathErr mssage). In all cases, you're worried
> about what happens when there are so many sub-LSPs that the encoding of the
> message becomes too large.
> >
> >In the forward direction, per 4875, semantic fragmentation "just works". There
> is no need to be worried about the sequence of Path messages, and no need to
> know whether all fragments have arrived. Each Path message simply overlays the
> others as and when if it received.
> >
> >The reverse direction is what motivates you in this work. That is, an
> intermediate node wants to report the potential for re-optimising the part of the
> LSP to a large number of leaf nodes. If there are so many nodes that the PathErr
> must be fragmented, then you want to make sure that all fragments are received
> at the root before the new Path message is sent so that the re-optimisation is
> accurate.
> >
> >Now, let's suppose that there is some branch node that is aware that re-
> optimisation is possible for some of the downstream leaf nodes. The branch
> node is, of course, unaware of re-optimisation that is available on other
> branches. So the branch node builds a re-optimisation PathErr for all of the leaf
> nodes for which it wants the root to signal a new Path message.
> >
> <RG>  Provisions to do this by sending a single notification to re-optimize the tree
> is already in the draft (Preferable P2MP-TE Tree Exists Path Error Sub-code).
> 
> Let’s say there are 100s of S2L destinations behind node R10 and there is a need
> to re-optimize those destinations only, without affecting the rest of the P2MP-TE
> tree.
> 
> Only way to do this is using Sub-group-based re-optimization method and the
> head-end sending path queries (with S2L list) for those destinations to ABR3. If
> ABR3 knows the candidate S2L list for re-evaluation, it can evaluate that portion
> of the tree accurately in its domain. If there are large number of such
> destinations, the Path message may get fragmented and may not yield the
> desired result at ABR3.
> 
> Similarly, ABR3 needs to notify the head-end about only those destinations
> towards ABR7 (past R10) if there is a preferred path in its domain. ABR3 does not
> evaluate destinations towards ABR8 in this case. If there is a preferred path for
> those destinations towards ABR7, ABR3 needs to send PathErr messages with
> those S2Ls in the list (and it can not use PathErr for the tree here). This PathErr
> may get fragmented before reaching the head-end and not achieve desired
> results.
> 
> 
> 
> >

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 26 Oct 2016 19:18:21 +0000

Hi Adrian,

Yes, happy to move on:) Many thanks for the thorough review and discussions.

Thanks,
Rakesh (for all authors)