Subject: Re: [mpls] [mpls-tp] Basic questions ondraft-huang-mpls-ring-signaling-extensions

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 15 Nov 2010 04:48:20 -0600

I share Yaacov's questions, and I have one more to add.  The wrapping
behaviors shown in sections 3.1.1 and 3.1.2 appear, to my mind, to look
exactly like bypass tunnels as defined in rfc4090 and as implemented in
many networks today.  I'm afraid I don't quite understand the text in
section 4 which defined what this signaling extension does, but the
sentence " The new label switching information can help node C to finish
the work described in section 3.1.2." makes me thing that the purpose of
the signaling extension is to deliver, not enhance, the behaviors
described in 3.1.1 and 3.1.2.  Can you clarify what the label stacks and
LSP paths look like when the extension in this draft is implemented?

Also, I see that the draft talks about an LDP extension.  This seems
like a useful idea by itself; especially in link protection, this is
straightforward to understand and implement.  There's nothing
ring-specific here, though; the extension you describe might be used in
LFA FRR, which is not restricted to just rings

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> Sent: Monday, November 15, 2010 3:38 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [mpls-tp] Basic questions ondraft-huang-mpls-ring-signaling-
> extensions
> 
> Hi all,
> 
> After hearing your presentation at IETF79, I have some questions about
the
> intention of this document:
> 
> 1. In addition to the signaling extensions that appear in the title of
> this document, you also seem to be defining ring-protection procedures
> based only on wrapping.  Is the intention of this draft to define ring
> protection?  Could you explain whether this is different from the
wrapping
> procedures already defined in the pre-existing I-D that address ring-
> protection?
> 
> 2. Is your draft addressing generic MPLS or MPLS-TP?  The title seems
to
> be directed at MPLS and not MPLS-TP, or is this my misinterpretation?
> 
> 3.  In continuation to the previous question - you seem to be
describing
> methods for unidirectional p2p LSPs, not sure how the signaling
extensions
> are intended for use with bidirectional LSP and in particular
co-routed
> bidirectional LSPs as defined for MPLS-TP.
> 
> 4.  Regarding your protection method using a SPME - is this SPME p2mp
or
> mp2mp?
> 
> Best regards,
> 
> 
> 
> Yaacov Weingarten
> 
> Industry Environment, Packet Transport
> 
> Nokia Siemens Networks
> 
> Hod Hasharon, Israel 45241
> 
> Tel: +972-9-775 1827
> 
> Mob: +972-54-220 0977

---

From: Giles Heron <[email-masked]>
Date: Mon, 15 Nov 2010 17:01:49 +0000

A few more issues with the draft:

The draft is rather "unusual" in that it proposes sending label mappings in
a notification message, and since the label mapping advertised in the
notification has no associated FEC.  Surely the label mapping message is a
better choice for sending label mappings?

There's also a mistake in section 4 I think - where it states that "Node C
sends a new message to Node C".  I believe the authors meant to say "Node B
sends a new message to Node C".

One major issue with the draft is that it appears to require a form of
upstream label allocation.  Specifically, the label mapping <L2-to-L4> at
node C is the result of a combination of local instantiation of the mapping
<L3-to-L4> by node C and upstream notification of the mapping <L2-to-L3> by
node B.  So you'd have a problem if node C had already allocated L2 itself -
unless of course the mapping <L2-to-L4> is only valid in the context of
protection label P4 (the authors fail to mention this point, so I suspect
they may have missed it).

So overall I think a better approach would be to use next next-hop labels
and to assign them using the label mapping message...

Giles

On 15/11/2010 10:48, "Eric Osborne (eosborne)" <[email-masked]> wrote:

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

---

From: [email-masked]
Date: Tue, 16 Nov 2010 11:16:35 +0800

some more questions needs authors'clarifications：

 1. If two links of the ring fails simultaneously,and the two links are 
not adjacent, for example, figure 2 in your draft, link A-B and link C-D 
occur failures at the same time, how can your scheme deal with such 
condition? if this is within the scope of your draft?

2. needs a closed protection lsp to protect all service lsps, and from 
your descriptions, working LSP is created via control plane, then how does 
the protection LSP be created? 

3. Abstract: 
This document describes a MPLS ring mechanism and some extensions on
   signaling protocol to facilitate the establishment of Label Switched
   Paths (LSPs) using Label Distribution Protocol [LDP] or RSVP-TE
   protocol [RSVP-TE] to achieve automated link and node protection.
my question is how can a node knows whether it's on a ring topology?

Best Regards

Giles Heron <[email-masked]> 
发件人:  [email-masked]
2010-11-16 01:01

收件人
"Eric Osborne (eosborne)" <[email-masked]>, "Weingarten, Yaacov (NSN - 
IL/Hod HaSharon)" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] [mpls] Basic questions 
ondraft-huang-mpls-ring-signaling-extensions

The draft is rather "unusual" in that it proposes sending label mappings 
in
a notification message, and since the label mapping advertised in the
notification has no associated FEC.  Surely the label mapping message is a
better choice for sending label mappings?

There's also a mistake in section 4 I think - where it states that "Node C
sends a new message to Node C".  I believe the authors meant to say "Node 
B
sends a new message to Node C".

One major issue with the draft is that it appears to require a form of
upstream label allocation.  Specifically, the label mapping <L2-to-L4> at
node C is the result of a combination of local instantiation of the 
mapping
<L3-to-L4> by node C and upstream notification of the mapping <L2-to-L3> 
by
node B.  So you'd have a problem if node C had already allocated L2 itself 
-
unless of course the mapping <L2-to-L4> is only valid in the context of
protection label P4 (the authors fail to mention this point, so I suspect
they may have missed it).

Giles

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

---

From: "Huang Yong (Oliver)" <[email-masked]>
Date: Tue, 16 Nov 2010 14:54:14 +0800

Hello Giles,

     My response is inline at below (marked with [Oliver]).
     Thanks for your comments and point out some mistake in the draft.

Best Regards,
Oliver

HuangYong  (English name: Oliver)
Huawei Technologies Co.,Ltd
Tel: +86 755 28971870
Fax: +86 755 28972352
Huawei Base,BanTian,Longgang,ShenZhen,
GuangDong, People's Republic of China

-----Original Message-----
From: Giles Heron [mailto:[email-masked]] 
Sent: Tuesday, November 16, 2010 1:02 AM
To: Eric Osborne (eosborne); Weingarten, Yaacov (NSN - IL/Hod HaSharon);
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] [mpls-tp] Basic questions
ondraft-huang-mpls-ring-signaling-extensions

The draft is rather "unusual" in that it proposes sending label mappings in
a notification message, and since the label mapping advertised in the
notification has no associated FEC.  Surely the label mapping message is a
better choice for sending label mappings?
[Oliver] Please notice that the purpose of sending label mapping information
is not to assign a label to a FEC. It is to inform a protecting node of the
label mapping information in order for protection. So I think FEC is not
needed here.

There's also a mistake in section 4 I think - where it states that "Node C
sends a new message to Node C".  I believe the authors meant to say "Node B
sends a new message to Node C".
[Oliver] Yes , you are right. Sorry for the mistake.  The correct sentence
is "At this point
   of time, Node B send a new message to Node C containing the local
   switching information <L2-to-L3>."
          Thank you for pointing out this mistake.

One major issue with the draft is that it appears to require a form of
upstream label allocation.  Specifically, the label mapping <L2-to-L4> at
node C is the result of a combination of local instantiation of the mapping
<L3-to-L4> by node C and upstream notification of the mapping <L2-to-L3> by
node B.  So you'd have a problem if node C had already allocated L2 itself -
unless of course the mapping <L2-to-L4> is only valid in the context of
protection label P4 (the authors fail to mention this point, so I suspect
they may have missed it).
[Oliver] It is good for talking about this. I have mentioned in section 4 as
 "Note that above mechanism needs to do some label planning work to
   avoid duplicate label for adjacent links (e.g.  link C-D and link B-C
   are adjacent links)."
    I think compare to the benefit of the solution, it is a small price.

So overall I think a better approach would be to use next next-hop labels
and to assign them using the label mapping message...
[Oliver] The draft is open for better signaling definition to achieve the
design goal. But As I mentioned above, I think notification message is OK to
do the job.
Giles

---

From: "Huang Yong (Oliver)" <[email-masked]>
Date: Tue, 16 Nov 2010 15:17:11 +0800

Hello Eric,
   
   The signaling extension is showed in section 4 and the label stacks can
be refer to section 3.1.1  and 3.1.2.  You can see figure 2 and figure 3 for
the protected path and related encapsulation.  I hope that is clear. If you
still not clear about the text and figure, please point out the points. I
will try to explain to you in email.

   I agree on your second point that the signaling extension may be used in
other scenarios. Even for statically provisioned LSP, the signaling can also
facilitate the provision work. For LFA FRR, we can study the applicability
of the signaling extension.

Best Regards,
Oliver

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Monday, November 15, 2010 6:48 PM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Basic questions
ondraft-huang-mpls-ring-signaling-extensions

eric

Behalf
the
wrapping
to
describing
extensions
co-routed
or

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 16 Nov 2010 08:54:41 -0600

Hi Oliver- one comment inline with EO#

> From: Huang Yong (Oliver) [mailto:[email-masked]]
> Sent: Tuesday, November 16, 2010 2:17 AM
> To: Eric Osborne (eosborne); 'Weingarten, Yaacov (NSN - IL/Hod
HaSharon)';
> Subject: RE: [mpls-tp] Basic questions
ondraft-huang-mpls-ring-signaling-
> be refer to section 3.1.1  and 3.1.2.  You can see figure 2 and figure
3
> for the protected path and related encapsulation.  I hope that is
clear.
> If you still not clear about the text and figure, please point out the
> points. I will try to explain to you in email.
> 

EO#  Let me rephrase my question.  Take section 3.1.1, for example.  In
this section, there is an LSP B-A-F-E-D-C which is used to deliver L3 to
C.  C receives L3, swaps it for L4, and forwards the packet to D.

As far as I can see, this is exactly the same behavior you would get
with a bypass tunnel as defined in rfc4090.  Is section 3.1.1 intended
to show how your solution works?  If so, I'm afraid I don't see the
benefit of defining a new signaling (or static config) behavior which
results in exactly the same label stack and protection performance as an
existing mechanism.

eric

>    I agree on your second point that the signaling extension may be
used
> in other scenarios. Even for statically provisioned LSP, the signaling
can
> also facilitate the provision work. For LFA FRR, we can study the
> applicability of the signaling extension.
> 
> 
> Best Regards,
> Oliver
> 
like
> a useful idea by itself; especially in link protection, this is
> straightforward to understand and implement.  There's nothing ring-
> specific here, though; the extension you describe might be used in LFA
> FRR, which is not restricted to just rings
> 
> 
> 
> 
> eric
> 
> 
>