Subject: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10

From: Gregory Mirsky <[email-masked]>
Date: Wed, 5 Feb 2014 21:46:14 +0000

Dear Authors, et. al,
please find my comments to the latest version below:
•       Introduction. " The main disadvantage of this approach is that more network resources such as double bandwidths may be used." I believe that can be easily avoided if Shared explicit filterspec used signaling working and protecting LSPs so that both could share BW resources of common links. If that is the main motivation for the proposed extensions, I don't see it as sufficiently strong case.
•       Section 1.1 “The failure of a primary egress (e.g., L1 in the figure) MAY be detected by its upstream node (e.g., R3 in the figure) through a BFD session between the upstream node and the egress in MPLS networks.” If monitored path is limited to segment between R3 and L1, then failure of L1 to forward traffic to CE1 or CE1 to receive from L1 would not be detected. Is such limited scope really useful?

   Regards,
        Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 5 Feb 2014 22:20:52 +0000

Dear All,
I’d like to add to my comment on use case presented in the document.
Proposal is based on assumption that detected loss of continuity (LoC) between R3 and L1 is because of L1 failure.  But that may be not the case and LoC fault may be because R3 or path problem, or problem of particular port on L1. All that can cause LoC fault while L1 is functionally sound. And RFC 4090 based FRR would handle these failure scenarios thus making new extensions and additional complexity unnecessary. I think that if the goal is protection of an egress node, then there must be more determinism in detecting its failure to support the use case.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Wednesday, February 05, 2014 1:46 PM
To: [email-masked]; [email-masked]
Subject: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10

Dear Authors, et. al,
please find my comments to the latest version below:
·         Introduction. " The main disadvantage of this approach is that more network resources such as double bandwidths may be used." I believe that can be easily avoided if Shared explicit filterspec used signaling working and protecting LSPs so that both could share BW resources of common links. If that is the main motivation for the proposed extensions, I don't see it as sufficiently strong case.
·         Section 1.1 “The failure of a primary egress (e.g., L1 in the figure) MAY be detected by its upstream node (e.g., R3 in the figure) through a BFD session between the upstream node and the egress in MPLS networks.” If monitored path is limited to segment between R3 and L1, then failure of L1 to forward traffic to CE1 or CE1 to receive from L1 would not be detected. Is such limited scope really useful?

Regards,
        Greg

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 6 Feb 2014 04:38:53 +0000

Dear Greg,

Thanks for your comments!
My answers/explanations are inline below.

Best Regards,
Huaimo
From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Wednesday, February 05, 2014 4:46 PM
To: [email-masked]; [email-masked]
Subject: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10

Dear Authors, et. al,
please find my comments to the latest version below:
·         Introduction. " The main disadvantage of this approach is that more network resources such as double bandwidths may be used." I believe that can be easily avoided if Shared explicit filterspec used signaling working and protecting LSPs so that both could share BW resources of common links. If that is the main motivation for the proposed extensions, I don't see it as sufficiently strong case.
Huaimo: In the case that the primary LSP is from an ingress node A to a number of egress nodes and the standby LSP is from a backup ingress node B (note that A is different from B), it seems that the shared explicit RSVP reservation style does not work in this case.  The primary LSP can not share its bandwidth with the standby LSP since they are two different LSP tunnels starting from two different ingress nodes.
·         Section 1.1 “The failure of a primary egress (e.g., L1 in the figure) MAY be detected by its upstream node (e.g., R3 in the figure) through a BFD session between the upstream node and the egress in MPLS networks.” If monitored path is limited to segment between R3 and L1, then failure of L1 to forward traffic to CE1 or CE1 to receive from L1 would not be detected. Is such limited scope really useful?
Huaimo: In addition to detecting the failure of a primary egress such as L1 in the figure, we talked about detecting/monitoring the other parts such as those you mentioned above in IETF MPLS working group meetings. Detecting/monitoring these parts can be decided locally by operators. It seems that there is no impact on the MPLS protocols.

Regards,
        Greg

---

From: Francesco Fondelli <[email-masked]>
Date: Thu, 6 Feb 2014 12:02:59 +0100

Hi,

> Dear Greg,

[cut]

> Huaimo: In the case that the primary LSP is from an ingress node A to a
> number of egress nodes and the standby LSP is from a backup ingress node B
> (note that A is different from B), it seems that the shared explicit RSVP
> reservation style does not work in this case.  The primary LSP can not share
> its bandwidth with the standby LSP since they are two different LSP tunnels
> starting from two different ingress nodes.

Oh, this is in my still-have-to-be-understood-queue since a while...

SE-style reservation creates a single reservation shared by selected
upstream sender*s* (I do not think they have to be be on the same
node) within a given session [RFC2205].  In a p2mp scenario a session
is identified by the tuple (P2MP ID, Tunnel ID, Extended Tunnel ID)
[RFC4875].  If ingress nodes A and B use the same P2MP ID *and* the
same Tunnel ID *and* 0 as Extended Tunnel ID (it is normally set to a
value != 0 by ingress nodes that wish to *narrow* the scope of a
session to the ingress-egress pair [RFC3209], though in this case we
want the opposite) primary and standby LSPs will share the same
resources along common links/nodes.  How nodes A and B shares P2MP ID
and Tunnel ID is outside the scope of this email :-), I guess manual
configuration might be a possibility.

This is my understanding.  ACK/NACK would be much appreciated (not
sure all I said is 100% correct or I missed something).

thank you
ciao
fra

PS
this possibility for the p2p case is mentioned in RFC3209 section
2.4.3 "SE style reservations can be provided using multipoint-to-point
label-switched-path or LSP per sender..."

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 6 Feb 2014 17:34:33 +0000

Hi Huaimo,
many thanks for the most expedient response and thorough consideration of my comments. Please find couple notes in-lined and tagged by GIM>>.

                Regards,
                                Greg

From: Huaimo Chen [mailto:[email-masked]]
Sent: Wednesday, February 05, 2014 8:39 PM
To: Gregory Mirsky; [email-masked]; [email-masked]
Subject: RE: Comments to draft-chen-mpls-p2mp-egress-protection-10

Dear Greg,

Best Regards,
Huaimo
From: mpls [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Wednesday, February 05, 2014 4:46 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10

Dear Authors, et. al,
please find my comments to the latest version below:
·         Introduction. " The main disadvantage of this approach is that more network resources such as double bandwidths may be used." I believe that can be easily avoided if Shared explicit filterspec used signaling working and protecting LSPs so that both could share BW resources of common links. If that is the main motivation for the proposed extensions, I don't see it as sufficiently strong case.
Huaimo: In the case that the primary LSP is from an ingress node A to a number of egress nodes and the standby LSP is from a backup ingress node B (note that A is different from B), it seems that the shared explicit RSVP reservation style does not work in this case.  The primary LSP can not share its bandwidth with the standby LSP since they are two different LSP tunnels starting from two different ingress nodes.
GIM>> That may be valid case but I don’t see what type of coordination is required then. And more questions to this use case:

·         where is PLR that monitors egress’ well-being

·         if network is tightly controlled, wildcard reservation may be BW conservation measure
·         Section 1.1 “The failure of a primary egress (e.g., L1 in the figure) MAY be detected by its upstream node (e.g., R3 in the figure) through a BFD session between the upstream node and the egress in MPLS networks.” If monitored path is limited to segment between R3 and L1, then failure of L1 to forward traffic to CE1 or CE1 to receive from L1 would not be detected. Is such limited scope really useful?
Huaimo: In addition to detecting the failure of a primary egress such as L1 in the figure, we talked about detecting/monitoring the other parts such as those you mentioned above in IETF MPLS working group meetings. Detecting/monitoring these parts can be decided locally by operators. It seems that there is no impact on the MPLS protocols.
GIM>> We’ve discussed issues related to monitoring continuity between R1 and CE1 over L1. True, it would address more failure scenarios but, IMO, would introduce several problems of its own:

·         security – CPE device must have connectivity well into provider’s domain;

·         ensuring that OAM follows CE1-L1-R1 path in both directions.
Because of these issues, I still believe that it is better to split protection task in two domains:

·         LSP protection – e2e or local

·         access link protection – multi-homing, MC-LAG

Regards,
        Greg

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 6 Feb 2014 19:10:24 +0000

There are a number of conditions for two or more LSPs to share some bandwidths of a link. The conditions include:
1) They (these LSPs) belong to a same tunnel, and
2) They share the same link, and
3) Only one of them sends data traffic to that link at any time.

For two LSPs starting from different ingress nodes such as node A and node B, it is very hard to make them belong to a same tunnel. 
A tunnel is identified by <P2MP ID/Destination, Tunnel ID, Extended Tunnel ID>. Setting Extended Tunnel ID to 0 in the session object on node A and node B for two LSPs respectively to make them belong to the same tunnel seems not work. See the top part of page 13 in RFC 3209. 

Basically, a node in the network needs to identify a tunnel uniquely for two or more LSPs under the same tunnel to share the bandwidth of a link. If Extended Tunnel ID is set to 0, <P2MP ID/Destination, Tunnel ID, 0 for Extended Tunnel ID> seems not enough to identify a tunnel uniquely unless some items such as 16-bit tunnel ID are made globally unique.  

Best Regards,
Huaimo
-----Original Message-----
From: Francesco Fondelli [mailto:[email-masked]] 
Sent: Thursday, February 06, 2014 6:03 AM
To: Huaimo Chen
Cc: Gregory Mirsky; [email-masked]; [email-masked]
Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-egress-protection-10

Hi,

[cut]

> Huaimo: In the case that the primary LSP is from an ingress node A to 
> a number of egress nodes and the standby LSP is from a backup ingress 
> node B (note that A is different from B), it seems that the shared 
> explicit RSVP reservation style does not work in this case.  The 
> primary LSP can not share its bandwidth with the standby LSP since 
> they are two different LSP tunnels starting from two different ingress nodes.

SE-style reservation creates a single reservation shared by selected upstream sender*s* (I do not think they have to be be on the same
node) within a given session [RFC2205].  In a p2mp scenario a session is identified by the tuple (P2MP ID, Tunnel ID, Extended Tunnel ID) [RFC4875].  If ingress nodes A and B use the same P2MP ID *and* the same Tunnel ID *and* 0 as Extended Tunnel ID (it is normally set to a value != 0 by ingress nodes that wish to *narrow* the scope of a session to the ingress-egress pair [RFC3209], though in this case we want the opposite) primary and standby LSPs will share the same resources along common links/nodes.  How nodes A and B shares P2MP ID and Tunnel ID is outside the scope of this email :-), I guess manual configuration might be a possibility.

This is my understanding.  ACK/NACK would be much appreciated (not sure all I said is 100% correct or I missed something).

thank you
ciao
fra

PS
this possibility for the p2p case is mentioned in RFC3209 section
2.4.3 "SE style reservations can be provided using multipoint-to-point label-switched-path or LSP per sender..."

---

From: Francesco Fondelli <[email-masked]>
Date: Fri, 7 Feb 2014 09:42:51 +0100

Hi Huaimo,

On Thu, Feb 6, 2014 at 8:10 PM, Huaimo Chen <[email-masked]> wrote:
[cut]
> A tunnel is identified by <P2MP ID/Destination, Tunnel ID, Extended Tunnel ID>. Setting Extended Tunnel ID to 0 in the session object on node A and node B for two LSPs respectively to make them belong to the same tunnel seems not work.

I agree, I said "If ingress nodes A and B use the same P2MP ID *and*
the same Tunnel ID *and* 0 as Extended Tunnel ID...".  I highlighted
'and' to emphasize the fact that all conditions must be met.

> Basically, a node in the network needs to identify a tunnel uniquely for two or more LSPs under the same tunnel to share the bandwidth of a link. If Extended Tunnel ID is set to 0, <P2MP ID/Destina…

Some implementations let the user specify the Tunnel ID, I guess is
possible to do the same for the P2MP ID and the Extended Tunnel ID.
Operator would have explicit network-wise control of this mp2mp
construct.

So basically, we agree.

thanks
ciao
fra