Subject: [mpls] draft-deshmukh-rsvp-rmr-extension

From: Abhishek Deshmukh <[email-masked]>
Date: Mon, 6 Mar 2017 22:52:33 +0000

Hi All,

During IETF96 & IETF97, we received some feedback on the following draft:
https://www.ietf.org/id/draft-deshmukh-rsvp-rmr-extension-01.txt
The purpose of this email just to clarify on the PATH sender-template merging process as described in the draft.

Every ring lsp originates & terminated at the same node i.e. the ingress & egress for the ring LSP is same.
Also, ring LSPs are MP2P in nature. It means every non-egress node is also an ingress and a merge-point for the LSP.
R0---->R1---->R2---->R3---->R4---->R0

To establish an MP2P LSP, when node R2 receives a PATH message from R0, R2 adds it’s own SENDER_TEMPLATE in the outgoing PATH message.
The outgoing PATH message at R0 will have the following SENDER_TEMPLATES:
         ----------------------------------------------------------------------------------------
         |SENDER_TEMPLATE_0 : SENDER_ADDRESS = R0, LSP_ID = 1 |
         ----------------------------------------------------------------------------------------
         |SENDER_TEMPLATE_1 : SENDER_ADDRESS = R1, LSP_ID = 1 |
         ----------------------------------------------------------------------------------------
         |SENDER_TEMPLATE_2 : SENDER_ADDRESS = R2, LSP_ID = 1 |
         ----------------------------------------------------------------------------------------

Similarly, each node in the ring will insert it’s own SENDER_TEMPLATE.
The RESV message will have multiple FILTER_SPEC objects corresponding to the SENDER_TEMPLATES.

Further, this process of SENDER_TEMPLATE merging can also be used for bandwidth management as described in section 4.5 of the draft.
I will be presenting this draft at the upcoming IETF 98. Please let us know, if there are any additional questions/feedback on this.

Thanks,
Abhishek and co-author(s)