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

From: [email-masked]
Date: Tue, 16 Nov 2010 17:28:53 +0800

hi,
i don't agree your advice. we should have a general solution to protect 
service on the ring regardless of multiple failure;
if each failure scene have different protection solution in the ring. the 
implement is very complex
and hard . it is not suitable for the ring protection requirement in RFC 
5654；

B.R.
Liu

"Huang Yong (Oliver)" <[email-masked]> 
2010-11-16 17:16

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked], 
[email-masked]
主题
RE: [mpls] [mpls-tp] Basic questions 
ondraft-huang-mpls-ring-signaling-extensions

Hello  Guoman,
 
       I  have just answered this question  in  another  email.   I  said 
that  the method in my draft now only  considered  one point of failure 
since I assume  multipoint  failures  at same time  will  take very little 
possibility  and can  be  an  optional  factor  when design the network.
 
Best Regards,
Oliver

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 16, 2010 3:44 PM
To: Huang Yong (Oliver)
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: [mpls] [mpls-tp] Basic questions 
ondraft-huang-mpls-ring-signaling-extensions

hi,huang and all 

i think the big problem is to not recovery service when there are  more 
than one failure in the ring. for example.in the following figure: 

one lsp is from node 1 to node 5 （working path: 1-2-3-4-5)。 
now the failure happened in link（1-2）and link (3-4). according to 
the solution in your draft, only node 3 know label mapping of link(1-2). 
but node 4 don't know it. just as the failure condition, how to protect 
the LSP? thank you. 

B.R. 
Liu 

"Huang Yong (Oliver)" <[email-masked]> 
发件人:  [email-masked] 
2010-11-16 14:54 

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

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

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?
[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

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

> 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
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.