Subject: Re: [mpls] RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 19 Sep 2014 21:22:22 +0000

Hi Dimitri,

Thank you for your review comments.

Gist of your comments is that there is a way in RFC4875 to bulk the requests for queries via a path message and also add a list of S2Ls in a PathErr message.
This method can be used for re-optimizing a group of S2Ls without incrementing the LSP-ID as Tarek mentioned.

As you hinted below, proposed draft provides a signalling extension to re-optimize entire P2MP LSP/tree similar to P2P [RFC4736] by incrementing the LSP-ID.

If you agree with above understanding, we can clarify in the draft accordingly.

Thanks,
Rakesh

From: <Papadimitriou>, "Dimitri (Dimitri)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 19 September, 2014 10:49 AM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello Rakesh,

See below for my answers:

From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
Sent: Saturday, September 06, 2014 2:39 AM
To: Tarek Saad (tsaad); Papadimitriou, Dimitri (Dimitri); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hi WG,

Forwarding following reply from Tarek to the MPLS mailing list.

Thanks Tarek and Dimitri.

Regards,
Rakesh

From: "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 5 September, 2014 1:42 PM
To: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]<mailto:[email-masked]>>, DEBORAH BRUNGARD <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Martin Vigoureux <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hi Dimitri,

Thanks much for reviewing the draft and for your feedback. Please see inline..

From: <Papadimitriou>, "Dimitri (Dimitri)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 25, 2014 at 8:45 AM
To: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "VIGOUREUX, MARTIN (MARTIN)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Jonathan Hardwick ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc
Hello,

Here is my review of this document:

The statement "notification of preferred path exists for a single S2L sub-LSP only." and what comes in Section 3 of this document is questionable

i) there is a mode of operation already included in RFC 4875 which allows such reorganization by sub-group ID cf. Section 14.2. "Sub-Group-Based Re-Optimization." It looks as an over-reading to state this method is limited on per-sub-LSP basis, that section states clearly

"14.2.  Sub-Group-Based Re-Optimization

   Any node may initiate re-optimization of a set of S2L sub-LSPs by
   using incremental state update and then, optionally, combining
   multiple path messages."

[TS]: the draft is in agreement of the above statement from rfc4875 and this is called out in the draft (below) with the shortcoming mentioned in section 14.2 for duplication of traffic in certain cases.
"The ingress LSR that receives (un)solicited PathErr notification(s)
   for individual S2L sub-LSP(s), may prematurely start re-optimizing
   the sub-set of S2L sub-LSPs.  However, as mentioned in [RFC4875]
   Section 14.2, such re-optimization procedure may result in data duplication
"
The make-before-break reoptimization method as described in rfc4875 section 14.1 avoids the former duplication problem by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there’s no explicit way for a mid-LSR to notify the ingress to trigger this specific mode of reoptimization-- short of possibly re-using the PERR code/subcode for “preferable path exists” as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. when a single message may not be large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L sub-LSPs in each and would require additional logic to infer all S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by (example) waiting for some time to aggregate all possible PERR messages before taking action.
We also believe having a sub-set of S2L sub-LSPs in the descriptor list in the PERR sent by a mid-LSR is useful to explicitly trigger the sub-group based reoptimization mode described in section 14.2.

In other cases, a PATH message that is intended to carry the “path re-evaluation” flag — as defined defined in rfc4736—with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and only a subset of the S2L sub-LSPs that are routed over same next-hop will be propagated in the descriptor list of the PATH message propagated to downstream mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can unambiguously use it to distinguish which LSP mode of reoptimization to invoke.

[DP2] It is the requestor (initiator of the PathErr) which expands the ERO (right ?) and sequence their signaling (thus any remerging between old and new sub-LSP follows the remerging (following Section 18), why would request to have such control taken by the root of the tree ?

The protocol format chain can be found here below to see possibility for generating such request via notification:

   <notify session list>       ::= [ <notify session list> ]
                                   <upstream notify session> |
                                   <downstream notify session>

   <upstream notify session>   ::= <SESSION> [ <ADMIN_STATUS> ]
                                   [<POLICY_DATA>...]
                                   <sender descriptor>

   <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
                                    [ <ADSPEC> ]

   With:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Sub-Group Originator ID                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |            Sub-Group ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I read behind this draft that this new mode of operation (the fact subpaths "are loose or abstract hop expanded" doesn't change the general comment) means some would prefer alignment with P2P re-optimization and operate outside incremental state update --introduced for scaling reasons. In any case, the justification/motivation for this mode of operation is missing in the document.

ii) with PathErr as defined in RFC 4875 it includes a [ <S2L sub-LSP descriptor list> ]
thus, it is even less clear why one would like to move with or more generally signaling it differently ("Request flags" instead of an "code") would prevent as mentioned in [RFC4875] Section 14.2, that sub-Group-based re-optimization may result in transient data
duplication as the new Path messages for a set of S2L sub-LSPs may
transit one or more nodes with the old Path state for the same set of
S2L sub-LSPs.”
[TS]: Please see reply above for the first one.

[DP2] I am not sure you have captured this comment, and would reformulate it as follows: under which conditions the number of sub-LSPs is so large that i) the receiver triggers re-signalling without having received the full sequence of sub-LSP, ii) the initiator has no mean to sequence the resulting Path messages such as to avoid situation of Section 14.2, iii) assuming this would be the case, why the procedure of Section 18 is not sufficient ? In more general terms why signal to the root a procedure than can be performed by the requestor itself ?

[DP2] On the other hand, there is a wide question, why do you consider only the case with loose ERO’s ? I mean the fragmentation problem is only one cause of occurrence of duplication (which could happen from any transient event during establishment of P2MP LSP), in that case, the question of introducing a more general procedure with an EOL (end of list bit) would certainly be more appropriate as it would solve two problems at once.

Regards,
Tarek

The proposed draft doesn’t solve cases where this would occur, and on the other, the cases it covers are already by RFC 4875 (re-optimize a loose set from a single branching point is already covered).

Many thanks,
-dimitri.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Mon, 22 Sep 2014 11:25:14 +0000

Hi,

Beside this gist, there is a point that would be worth discussing

message fragmentation is one possible cause of initiating re-signaling before the full list is being known to the root but this is decorrelated from loose or strict ERO; in that case, the question of introducing a more general procedure with an EOL (end of list bit) could be more appropriate as it would solve two problems at once.

+ including a compatibility section somewhere in this document would certainly help.

PS: in the longer term, I anticipate the need to collect practices and production of a BCP.

Thanks,
-dimitri.

From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
Sent: Friday, September 19, 2014 11:22 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); [email-masked]
Cc: [email-masked]
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

The make-before-break reoptimization method as described in rfc4875 section 14.1 avoids the former duplication problem by resignaling all the S2L sub-LSPs with a different LSP-ID. Currently, there's no explicit way for a mid-LSR to notify the ingress to trigger this specific mode of reoptimization-- short of possibly re-using the PERR code/subcode for "preferable path exists" as defined in rfc4736 and including the *full* list of S2Ls in the S2L sub-LSPs descriptor in the PERR sent back to the ingress. However, as mentioned in rfc4875, an LSR may fragment such signalled messages (e.g. when a single message may not be large enough to fit all S2L sub-LSPs).. In this case, the ingress LSR may receive multiple PERR(s) with sub-sets of S2L sub-LSPs in each and would require additional logic to infer all S2L sub-LSPs are to be resigned (e..g. using section 14.1 method) by (example) waiting for some time to aggregate all possible PERR messages before taking action.

In other cases, a PATH message that is intended to carry the "path re-evaluation" flag - as defined defined in rfc4736-with a full list of S2L sub-LSPs in S2L sub-LSPs descriptor list will be decomposed at branching LSRs, and only a subset of the S2L sub-LSPs that are routed over same next-hop will be propagated in the descriptor list of the PATH message propagated to downstream mid-LSRs.. Consequently, when a preferable path exists at such mid-LSRs, the PERR can only include the sub-set of S2L sub-LSPs traversing it.. The ingress LSR in this case can unambiguously use it to distinguish which LSP mode of reoptimization to invoke.

   With:

       0                   1                   2                   3

S2L sub-LSPs."

[DP2] On the other hand, there is a wide question, why do you consider only the case with loose ERO's ? I mean the fragmentation problem is only one cause of occurrence of duplication (which could happen from any transient event during establishment of P2MP LSP), in that case, the question of introducing a more general procedure with an EOL (end of list bit) would certainly be more appropriate as it would solve two problems at once.

Regards,
Tarek

The proposed draft doesn't solve cases where this would occur, and on the other, the cases it covers are already by RFC 4875 (re-optimize a loose set from a single branching point is already covered).

Many thanks,
-dimitri.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 22 Sep 2014 12:31:26 +0000

Thanks Dimitri.

Please see inline .. <RG> ..

Date: Monday, 22 September, 2014 7:25 AM

Hi,

<RG> Great, we will update the draft with the gist information.

<RG> We can solve the fragmentation issue (using EOL) for the RSVP messages containing S2L list. However, solving that does not solve the re-optimization [RFC4736] issue this draft is addressing.  Please see an example below.

A --------B ------ D, E,F,G,H,I,J
   --------C ------- K,L,M,N,O,P,Q,R

In above case, the mid-point node B may send a PathErr with S2L list (D,E,F,G,H,I, J) using an EOL bit. However, this can not be interpreted that the node B is requesting to repot the whole LSP tree since part of the LSP that traverse node C do not go via node B.

<RG> Ok, we can expand section 5.

Thanks,
Rakesh

Thanks,
-dimitri.

To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); [email-masked]<mailto:[email-masked]>

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Mon, 22 Sep 2014 16:30:59 +0000

Hi Dimitri,

I discussed with Rakesh. We see the value of having the EOL marker (for S2L list) to trigger sub-group reoptimization as in stated rfc4875/section 14.2.
As it's more generic mechanism that can potentially be used in all signalling messages that contain the S2L sub-LSP descriptor list, we’re not sure if best to integrate in current document or tracked with its own draft. Any preference?
For triggering make-before-break reoptimization (rfc4875/section 14.1), we still think the explicit notification back to the root is preferable.

Regards,
Tarek

From: "Rakesh Gandhi (rgandhi)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 22, 2014 at 8:31 AM
To: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]<mailto:[email-masked]>>, Tarek Saad <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Thanks Dimitri.

Hi,

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Mon, 22 Sep 2014 16:41:30 +0000

Hello,

From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
Sent: Monday, September 22, 2014 2:31 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); [email-masked]
Cc: [email-masked]
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Thanks Dimitri.

Hi,

[DP] there are two cases. Case n°1: sub-trees are topologically independent (disjoint), thus operations can remain independent, and if C or B needs it, the process here above solves the problem. Case n°2: sub-trees are not topologically independent, then one needs an additional step, in this example A needs after EOL to ensure that C will cooperate in the global rearrangement (otherwise, C could after B request completes initiate its own rearrangement); if you get this then answer from C would solve the problem.

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Mon, 22 Sep 2014 17:43:07 +0000

Hello, as you ask the question, my preference is a single document; we managed so far to keep a reduced set of documents for P2MP and willing to continue along this track. This doesn't prevent combining different elements altogether (this is how RFC 4875 came in)

Thanks,
-dimitri.

From: Tarek Saad (tsaad) [mailto:[email-masked]]
Sent: Monday, September 22, 2014 6:31 PM
To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); [email-masked]
Cc: [email-masked]
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hi Dimitri,

I discussed with Rakesh. We see the value of having the EOL marker (for S2L list) to trigger sub-group reoptimization as in stated rfc4875/section 14.2.
As it's more generic mechanism that can potentially be used in all signalling messages that contain the S2L sub-LSP descriptor list, we're not sure if best to integrate in current document or tracked with its own draft. Any preference?
For triggering make-before-break reoptimization (rfc4875/section 14.1), we still think the explicit notification back to the root is preferable.

Regards,
Tarek

Thanks Dimitri.

Hi,

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 23 Sep 2014 18:42:41 +0000

Hi Dimitri,

Agree on the behaviour. We can add this in the draft along with the EOL marker.

Thanks,
Rakesh

From: <Papadimitriou>, "Dimitri (Dimitri)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, 22 September, 2014 12:41 PM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Zafar Ali <[email-masked]<mailto:[email-masked]>>
Resent-Date: Monday, 22 September, 2014 12:41 PM

Hello,

Thanks Dimitri.

Hi,

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 23 Sep 2014 18:43:37 +0000

Hi Dimitri, Tarek,

Ack, thanks.

Regards,
Rakesh

From: <Papadimitriou>, "Dimitri (Dimitri)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, 22 September, 2014 1:43 PM
To: "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hello, as you ask the question, my preference is a single document; we managed so far to keep a reduced set of documents for P2MP and willing to continue along this track. This doesn’t prevent combining different elements altogether (this is how RFC 4875 came in)

Thanks,
-dimitri.

To: Rakesh Gandhi (rgandhi); Papadimitriou, Dimitri (Dimitri); [email-masked]<mailto:[email-masked]>

Hi Dimitri,

Regards,
Tarek

Thanks Dimitri.

Hi,

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 24 Sep 2014 12:44:39 +0000

Hi Dimitri, Tarek, WG,

I had a look at RFC4875 and there is one way to add begin and end for the S2L list as follows (using new C-types). Please let me know your thoughts.

Existing C-type defines
-------------------------------
  <S2L sub-LSP descriptor list> ::= <S2L_SUB_LSP>  [ <S2L sub-LSP descriptor list> ]

19.3. S2L_SUB_LSP Object
    An S2L_SUB_LSP object identifies a particular S2L sub-LSP belonging to the P2MP LSP.

19.3.1. S2L_SUB_LSP IPv4 Object
    S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4 C-Type = 1

19.3.2. S2L_SUB_LSP IPv6 Object
    S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6 C-Type = 2

Define new C-types as follows:
--------------------------------------
Begin of IPv4 S2L List.
    S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4_BOL C-Type = 3

End of IPv4 S2L List.
    S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv4_EOL C-Type = 4

Begin of IPv6 S2L List.
    S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6_BOL C-Type = 5

End of IPv6 S2L List.
    S2L_SUB_LSP Class = 50, S2L_SUB_LSP_IPv6_EOL C-Type = 6

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Regards,
Tarek

Thanks Dimitri.

Hi,

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 24 Sep 2014 14:12:46 +0000

Hello,

There is another mean define special values e.g. 0x0...0 (BOL) and 0xF...F (EOL) but leave it to the list to decide about format and encoding.

Thanks,
-dimitri.

From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 2:45 PM
To: Papadimitriou, Dimitri (Dimitri); Tarek Saad (tsaad); [email-masked]
Cc: [email-masked]
Subject: Re: RTG-DIR review requested - Fwd: poll to see if we have support to make draft-tsaad-mpls-p2mp-loose-path-reopt an mpls wg doc

Hi Dimitri, Tarek, WG,

Existing C-type defines

19.3. S2L_SUB_LSP Object

End of IPv4 S2L List.

Begin of IPv6 S2L List.

End of IPv6 S2L List.

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Regards,
Tarek

Thanks Dimitri.

Hi,

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 26 Sep 2014 18:30:49 +0000

Hi Dimitri, WG,

Thanks Dimitri for your comments.

Tarek and I were thinking that adding new C-types for BEGIN and END objects may be preferred for compatibility reasons, as nodes not supporting can simply ignore them.

We also do not need separate IPV4/IPv6 specific markers.

Separate C-types for BEGIN and END allow smallest object size (length 4 bytes).

    S2L_SUB_LSP Class = 50 (S2L_SUB_LSP),   S2L_SUB_LSP_MARKER_BEGIN    C-Type = 3 (TBA)
    S2L_SUB_LSP Class = 50 (S2L_SUB_LSP) ,  S2L_SUB_LSP_MARKER_END        C-Type = 4 (TBA)

Another option is to define one C-type for object S2L_SUB_LSP_MARKER and have BEGIN and END as parameter although that increases the length of the object to 8 bytes so may be less preferred.

Thanks,
Rakesh

Date: Wednesday, 24 September, 2014 10:12 AM

Hello,

There is another mean define special values e.g. 0x0…0 (BOL) and 0xF…F (EOL) but leave it to the list to decide about format and encoding.

Thanks,
-dimitri.

Hi Dimitri, Tarek, WG,

Existing C-type defines

19.3. S2L_SUB_LSP Object

End of IPv4 S2L List.

Begin of IPv6 S2L List.

End of IPv6 S2L List.

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Regards,
Tarek

Thanks Dimitri.

Hi,

Thanks,
Rakesh

Thanks,
-dimitri.

Hi Dimitri,

Thanks,
Rakesh

Hello Rakesh,

Hi WG,

Regards,
Rakesh

Hi Dimitri,

   With:

       0                   1                   2                   3

Regards,
Tarek

Many thanks,
-dimitri.