Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10

From: "Lizhong Jin" <[email-masked]>
Date: Fri, 7 Feb 2014 23:41:04 +0800

Hi authors,
I review this draft, and I think the problem the draft tries to solve is a
real problem in operational networks. 
But from the technical point of view, whether RSVP-TE is the right signaling
protocol between primary and backup ingress node needs to be discussed in
the WG list.
This document uses RSVP-TE as a pure signaling protocol between primary
ingress and backup ingress node, to exchange necessary protection
information. Then the behavior of RSVP-TE signaling on backup ingress node
will only exchange control information, but will not create any forwarding
status (for off-path case).  Such kind of behavior is different with
traditional RSVP-TE protocol. 
1. This new behavior changes RSVP-TE fundamentally, and RSVP-TE becomes a
pure signaling protocol, not a path setup protocol between primary and
backup node.
2. RSVP is a hop-by-hop protocol, and requires logical direct connection
between primary ingress and backup ingress node, which is an additional
burden for network operation. 
Then I don't think RSVP-TE is a good candidate for the mechanism described
in this draft. Some TCP based signaling protocol maybe more suitable, e.g,
ICCP.

The above personal concern is the technical direction of this draft, and I
think the WG should get consensus before adoption.

Regards
Lizhong

> -----Original Message-----
> From: Ross Callon [mailto:[email-masked]]
> Sent: 2014年1月23日 0:19
> To: Eric Gray; Tarek Saad (tsaad); Lizhong Jin
> Cc: [email-masked]; draft-chen-mpls-p2mp-ingress-
> [email-masked]; Martin Vigoureux
> Subject: MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10
> 
> Eric, Tarek, Lizhong;
> 
> You have been selected as MPLS Review team reviewers for draft-chen-
> mpls-p2mp-ingress-protection-10.
> 
> Note to authors: You have been CC'd on this email so that you can know
that
> this review is going on. However, please do not review your own document.
> 
> Reviews should comment on whether the document is coherent, is it useful
> (ie, is it likely to be actually useful in operational networks), and is
the
> document technically sound?  Also, is the text and grammar understandable
> (it doesn't need to be perfect at this point, but should be reasonably
clear).
> We are interested in knowing whether the document is ready to be
> considered for WG adoption (ie, it doesn't have to be perfect at this
point,
> but should be a good start).
> 
> Reviews should be sent to the document authors, WG co-chairs and WG
> secretary, and CC'd to the MPLS WG email list. If necessary, Comments may
> be sent privately to only the WG chairs.
> 
> Are you able to review this draft by February 6, 2014?
> 
> Thanks, Ross
> (as MPLS WG chair)
> 
>

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 7 Feb 2014 22:48:44 +0000

Hi Lizhong,

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

Best Regards,
Huaimo
-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Friday, February 07, 2014 10:41 AM
To: 'Ross Callon'; 'Eric Gray'; 'Tarek Saad (tsaad)'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-p2mp-ingress-protection-10

Hi authors,
I review this draft, and I think the problem the draft tries to solve is a real problem in operational networks.
But from the technical point of view, whether RSVP-TE is the right signaling protocol between primary and backup ingress node needs to be discussed in the WG list.
This document uses RSVP-TE as a pure signaling protocol between primary ingress and backup ingress node, to exchange necessary protection information. Then the behavior of RSVP-TE signaling on backup ingress node will only exchange control information, but will not create any forwarding status (for off-path case).  Such kind of behavior is different with traditional RSVP-TE protocol.
1. This new behavior changes RSVP-TE fundamentally, and RSVP-TE becomes a pure signaling protocol, not a path setup protocol between primary and backup node.
2. RSVP is a hop-by-hop protocol, and requires logical direct connection between primary ingress and backup ingress node, which is an additional burden for network operation.
Then I don't think RSVP-TE is a good candidate for the mechanism described in this draft. Some TCP based signaling protocol maybe more suitable, e.g, ICCP.

[Huaimo (start)]:
We considered to use other protocols such as OSPF as a signaling protocol between a primary and a backup ingress node. In some early versions of the draft, there is a section about this. It seems that it is more complicated for us to use another protocol (e.g., OSPF/ICCP/BGP) as the signaling protocol.
If another protocol (e.g., OSPF/ICCP/BGP) is used, then two protocols need to be changed and changed more. At first, the other protocol (e.g., OSPF/ICCP/BGP) needs to be extended for transporting/exchanging the necessary protection information between the primary ingress and backup ingress node.
Secondly, this protocol component (e.g., OSPF/ICCP/BGP process/thread) has to dynamically obtain the necessary protection information from protocol RSVP-TE component on the primary ingress, and give the information to protocol RSVP-TE on the backup ingress node, and vise versa.
Thirdly, RSVP-TE component (process/thread) is required to be extended for receiving the protection information from another protocol component (e.g., OSPF/ICCP/BGP process/thread) and also providing the protection information to another protocol component.
Moreover, RSVP-TE protocol needs to be extended for creating a backup LSP and its corresponding states according to the protection information received from another protocol. And so on.

Using just one protocol RSVP-TE is simpler. A couple of new objects need to be added to the existing RSVP-TE messages and used for transporting/exchanging the necessary protection information between the primary and backup ingress. On the backup ingress, RSVP-TE creates a backup LSP and its corresponding states according to the protection information in the RSVP-TE messages received from the primary ingress.
[Huaimo (end)]

The above personal concern is the technical direction of this draft, and I think the WG should get consensus before adoption.

Regards
Lizhong

> Cc: [email-masked]<mailto:[email-masked]>; draft-chen-mpls-p2mp-ingress-
> [email-masked]<mailto:[email-masked]>; Martin Vigoureux
that
> Reviews should comment on whether the document is coherent, is it
> useful (ie, is it likely to be actually useful in operational
> networks), and is
the
> document technically sound?  Also, is the text and grammar
> understandable (it doesn't need to be perfect at this point, but
> should be reasonably
clear).
point,
> secretary, and CC'd to the MPLS WG email list. If necessary, Comments
> may be sent privately to only the WG chairs.
>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Lizhong Jin" <[email-masked]>
Date: Sun, 9 Feb 2014 14:50:29 +0800

Hi Huaimo,

Thank you for the explanations. But I will consider the signaling protocol
selection from another perspective.

In many metro network cases, the primary and backup ingress are service
router, and not directly connected. And the only requirement for the
signaling protocol is to exchange necessary protection information. The TCP
based signaling protocol will surely provide more reliable connection than
RSVP-TE which is a hop-by-hop IP protocol. TCP has its own flow control
mechanism, and could provide more reliable connection.

Since TCP based ICCP (http://tools.ietf.org/html/draft-ietf-pwe3-iccp-13)
has already been defined by IETF to do node protection, I personally prefer
ICCP to do ingress node protection for RSVP-TE tunnel. Hope to see more
views from the list.

Regards

Lizhong

From: Huaimo Chen [mailto:[email-masked]] 
Sent: 2014年2月8日 6:49
To: Lizhong Jin; 'Ross Callon'; 'Eric Gray'; 'Tarek Saad (tsaad)'
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [mpls] MPLS-RT review of
draft-chen-mpls-p2mp-ingress-protection-10

Hi Lizhong,

Best Regards,

Huaimo

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Friday, February 07, 2014 10:41 AM
To: 'Ross Callon'; 'Eric Gray'; 'Tarek Saad (tsaad)'
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] MPLS-RT review of
draft-chen-mpls-p2mp-ingress-protection-10

Hi authors,

[Huaimo (start)]: 

We considered to use other protocols such as OSPF as a signaling protocol
between a primary and a backup ingress node. In some early versions of the
draft, there is a section about this. It seems that it is more complicated
for us to use another protocol (e.g., OSPF/ICCP/BGP) as the signaling
protocol. 

If another protocol (e.g., OSPF/ICCP/BGP) is used, then two protocols need
to be changed and changed more. At first, the other protocol (e.g.,
OSPF/ICCP/BGP) needs to be extended for transporting/exchanging the
necessary protection information between the primary ingress and backup
ingress node. 

Secondly, this protocol component (e.g., OSPF/ICCP/BGP process/thread) has
to dynamically obtain the necessary protection information from protocol
RSVP-TE component on the primary ingress, and give the information to
protocol RSVP-TE on the backup ingress node, and vise versa. 

Thirdly, RSVP-TE component (process/thread) is required to be extended for
receiving the protection information from another protocol component (e.g.,
OSPF/ICCP/BGP process/thread) and also providing the protection information
to another protocol component. 

Moreover, RSVP-TE protocol needs to be extended for creating a backup LSP
and its corresponding states according to the protection information
received from another protocol. And so on.

Using just one protocol RSVP-TE is simpler. A couple of new objects need to
be added to the existing RSVP-TE messages and used for
transporting/exchanging the necessary protection information between the
primary and backup ingress. On the backup ingress, RSVP-TE creates a backup
LSP and its corresponding states according to the protection information in
the RSVP-TE messages received from the primary ingress.

[Huaimo (end)]

Regards

Lizhong

that

the

clear).

point,

 

mpls mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/mpls>
https://www.ietf.org/mailman/listinfo/mpls