Subject: Re: [mpls-tp] poll on making draft-sprecher-mpls-tp-survive-fwk-01.txta working group document?

From: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Thu, 12 Mar 2009 09:25:48 +0800

I support to make the document an mpls working group document.

Follows are several minor comments:

1, in section 3 for restoration:
>   - Must support soft re-routing (Make-before-break).
>   - May support hard LSP restoration (break-before-make).
   I think soft re-routing means these is no fault in network, re-routing is triggered mannully, it's beacause that maybe the operator just want change the route of a path. And hard re-routing means these is fault in network and it is fault triggerd the re-routing.
   Make-before-break and break-before-make have no direct relation with soft re-routing and hard re-routing. Of course, soft re-routing should apply Make-before-break to reduce the effect to triffic.

2, In section 3 for protection:
>   - Must support protection ration of 100%.
This is impossible for 1:N protection when more than 1 working path need protect.

3, In section 4.2.1 for span recovery, can CP support section restoration?

Sincerely Yours
Xueqin Wei (Shuetsing Wei)

Development & Planning Department,
Fiberhome Telecommunication Technologies Co.,Ltd.,
No.88 Youkeyuan Road,Hongshan Dist.,Wuhan,Hubei,P.R.China,430074
Email:  [email-masked]
2009-03-12  09:11:13

==================== Following is your email=====================
Subject:[mpls-tp] poll on making draft-sprecher-mpls-tp-survive-fwk-01.txta working group document?
Sent：2009-02-27 02:25:55
From:Loa Andersson
To:mpls-tp; mpls; ITU-T ad hoc team on MPLS-TP; ccamp; pwe3
CC to:

>All,
>
>we have received a request from the editors/authors of
>draft-sprecher-mpls-tp-survive-fwk-01.txt to make the
>document an mpls working group document.
>
>Please send your comments to the mpls-tp mailing list.
>
>This poll ends eob Thu Mar 12, 2009.
>
>/Loa
>
>-- 
>
>
>Loa Andersson
>
>Sr Strategy and Standards Manager
>Ericsson ///                          phone:  +46 8 632 77 14
>
>                                       email:  [email-masked]
>                                               [email-masked]
>                                               [email-masked]
>
>
>_______________________________________________
>mpls-tp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls-tp
>

=================================================================

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 12 Mar 2009 10:16:01 +0100

Ni hao Xueqin,

You wrote:

> Make-before-break and break-before-make have no direct
> relation with soft re-routing and hard re-routing. Of course, soft
> re-routing should apply 
> Make-before-break to reduce the effect to triffic.

Make-b4-break requires merging which is not supported.

Also make-b4-break may cause PDU duplication which
cannot be detected.

> This is impossible for 1:N protection when more than 1 working path

The one (1) protection entity must be possiible to protect 100% one
of the N working entities. This means that if the N working entities
have different bandwidth, the protection entity MUST have the
capability to protect the largest bandwidth in the N working entities

Cheers, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Fri, 13 Mar 2009 08:32:39 +0800

Huub:

>Make-b4-break requires merging which is not supported.
The merging is not supported in MPLS-TP, but this didn't affect Make-b4-break 
because we use selector at the detination end.

>Also make-b4-break may cause PDU duplication which
I agree with you and I think duplicaiton problem is more important! Make-b4-break
 will cause bridge at the source end, and this will cause duplicaton. So we cann't 
support make-b4-break in a packet network (MPLS-TP) .

>capability to protect the largest bandwidth in the N working entities
1:N protection means N work path share the bandwidth of 1 protection path. 
If 1 of N working path failed, then this working path will be 100% protected.
But when more than 1 working path failed, then only 1 of N working path will be 
protected and the rest failed working path will still failed. IMO, the second one 
can't be called 100% protection.

Sincerely Yours

Tel:    +86 27 87691310
Fax:    +86 27 87694362
2009-03-13  08:21:55

==================== Following is your email=====================
Subject:Re: [mpls-tp] poll on making	draft-sprecher-mpls-tp-survive-fwk-01.txtaworking group document?
Sent：2009-03-13 08:12:58
From:Huub van Helvoort
To:xqwei
CC to:MPLS-TP

---

From: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Fri, 13 Mar 2009 09:09:30 +0800

Huub:

Sorry updated, so I send again.

>Make-b4-break requires merging which is not supported.
I agree with you! In packet network, protection need merging at the destination end.

Sincerely Yours

---

From: [email-masked]
Date: Fri, 13 Mar 2009 09:36:47 +0800

xueqin and Huub:
  1 IMO, make-b4-break means pre-planed path to protected working path. 
but when the working path have not any fault, there isn't any traffic of 
working path to be  transported through protected path, it means it isn't 
necessary to duplicate in the source node.
only the working path is wrong or fault, the traffic will be transported 
through the protection path.

  2 for 1:N protection,maybe 100%  is considered from the bandwidth of 
every working path. IMO, even if the working path that need the most 
bandwidth among N working path  is failed, the protection path also ensure 
to provide the same bandwidth and QOS for the working traffic. It may not 
mean all traffic of all failed working path must be restored when more one 
working paths are failed.
 
  thank you 
   liu 

"Xueqin WEI (Shuetsing WEI)" <[email-masked]> 
发件人:  [email-masked]
2009-03-13 09:09
请答复 给
[email-masked]

收件人
"hhelvoort" <[email-masked]>
抄送
MPLS-TPSG15 <[email-masked]>, MPLS-TP <[email-masked]>
主题
Re: [mpls-tp] poll on   making 
draft-sprecher-mpls-tp-survive-fwk-01.txtaworking       group document?

Huub:

>Make-b4-break requires merging which is not supported.
I agree with you! In packet network, protection need merging at the 
destination end.

>Also make-b4-break may cause PDU duplication which
I agree with you and I think duplicaiton problem is more important! 
Make-b4-break
 will cause bridge at the source end, and this will cause duplicaton. So 
we cann't 
support make-b4-break in a packet network (MPLS-TP) .

If 1 of N working path failed, then this working path will be 100% 
protected.
But when more than 1 working path failed, then only 1 of N working path 
will be 
protected and the rest failed working path will still failed. IMO, the 
second one 
can't be called 100% protection.

Sincerely Yours

==================== Following is your email=====================
Subject:Re: [mpls-tp] poll on making 
draft-sprecher-mpls-tp-survive-fwk-01.txtaworking group document?
Sent：2009-03-13 08:12:58
From:Huub van Helvoort
To:xqwei
CC to:MPLS-TP

--------------------------------------------------------
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.

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 13 Mar 2009 09:05:27 +0100

Hello, Liu,

You replied:

> working path to be  transported through protected path, it means it 
> isn't necessary to duplicate in the source node.

You removed too much text, the make-b4-break is applicable when
performing a manual switch MS or forced switch FS. Not for the case there
is a signal fail. For MS and FS both working and protection entity are
intact. Make-b4-break requires in case of 1:1 (and 1:N) protection that the
source sends traffic on both working and protection and THEN the sink
will switch (preferably after confirmation from the source). It is still
possible
that in this case PDUs are lost.
If merging is used at the sink side, duplication of PDUs is possible.

> bandwidth among N working path  is failed, the protection path also 
> ensure to provide the same bandwidth and QOS for the working traffic. It 
> may not mean all traffic of all failed working path must be restored 
> when more one working paths are failed.

This means that the requiremnt should be reworded: 100% of the first
failed path shall be protected (even though it is illogical to require that
100% of the N entities is protected by a single entity).

Xie xie, Huub.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Mar 2009 11:46:04 -0000

Hi,

Sorry for some delay in replying (I know you have had an exchange with Huub, 
but I want to cut back to your original mail).

> I think soft re-routing means these is no fault in
> network, re-routing is triggered mannully, it's
> beacause that maybe the operator just want change
> the route of a path.

That is often the reason for mb4b, but it is not the case in this draft. 
After all, it is a survivability framework, so we are talking about fault 
conditions.

We *are* talking about restoration, however.

Consider the case of the simple network...

A---B---C-x-D
     \     /
      E---F

Have an LSP ABCD. Fail the link CD.
Want to restore the LSP to ABEFD

If we do break-before-make we release the resources (buffers) on link AB and 
they might be grabbed by another LSP meaning that the restoration LSP can't 
be set up.

Make-before-break allows the resources to be held for the restoration LSP 
sing resource sharing.

IMHO it is spurious to talk about make-before-break requiring "merging" as 
there will only ever be one traffic flow active on one of the paths. 
Further, one of the paths is broken.

> And hard re-routing means these is fault in network
> and it is fault triggerd the re-routing.
> relation with soft re-routing and hard re-routing. Of
> course, soft re-routing should apply Make-before-break
> to reduce the effect to traffic.

I think you have simply redefined the terms "soft re-routing" and "hard 
re-routing" and then you are complaining that our definitions are not 
consistent with yours.

>> than 1 working path need protect.

No, you misunderstand the language.
Must support does not mean that every situation must provide 100% protection 
ratio. It means that there must be a mechanism to provide 100% protection 
ratio if requested.

Obviously, if the operator selects to contradicting deployment switches 
something will go wrong.

Our objective in the requirements is simply to state that it must be 
possible to configure the boxes to provide this feature.

Actually, I would argue that the protection ratio applies to the case where 
protection is activated. When a working LSP is switched over to the 
pretection LSP, this requirement is saying that it must be possible for the 
protection LSP to carry all of the traffic that was on the working LSP. (You 
might note that there is an implicit suggestion that also supporting ratios 
of less than 100% may be desirable, and this is often used where there are 
different taffic classes.)

Anyway, if you have any objections to requirements listed in this document, 
please discuss them in the context of the requirements I-D. This document 
can only repeat the requirements that have been expressed in that document 
(and most of which came from the ITU-T).

> 3, In section 4.2.1 for span recovery, can CP support

Interesting question.
What is a "section"?
The requirements I-D says...
  Section: A section is a server layer (which may be MPLS-TP or a
  different technology) which provides for encapsulation and OAM of a
  MPLS-TP transport path client layer.  A section layer may provide for
  aggregation of multiple MPLS-TP clients.  Note that G.805
  [ITU.G805.2000] defines the section layer as one of the two layer
  networks in a transmission media layer network.  The other layer
  network is the physical media layer network.

So your question appears to be "Can the control plane support the recovery 
of a server layer network?"

And I'm afraid I don't understand the question.

Thanks,
Adrian

---

From: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Fri, 13 Mar 2009 21:29:18 +0800

Adrian:

Thanks for you response. 

1, For the soft re-rotuing and hard re-routing, I think I get what  you
said and it's OK for restoration when working path failed. But if it is
signal deradation at the working path, I think we still have risk receive
duplicated packet at the destination. So here it should state that we
must not bridge triffic at the souce when mb4b (only for survivability).

2, For comment 2, I think what said in draft means protection path
can 100% protect anyone of N working path if it fails. Thanks for you 
explanation. If it is convenience, I think it's better to make it more clear.

3, Let me explain my question. I am not clear with "span recovery"(title
of section 4.2.1), is it means segment recovery? What the relationship 
between "span recovery", "segment recovery" and "end to end recovery"?  
(I just find the definition of section has been deleted in MPLS-TP Requirements, 
sorry for confusion I made.)  

Sincerely Yours

2009-03-13  20:26:05

==================== Following is your email=====================
Subject:Re: [mpls-tp] poll on makingdraft-sprecher-mpls-tp-survive-fwk-01.txta working group document?
Sent：2009-03-13 19:55:06
From:Adrian Farrel
To:[email-masked]
CC to:MPLS-TP

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Mar 2009 14:48:42 -0000

Hi,

> 1, For the soft re-rotuing and hard re-routing, I
> think I get what  you said and it's OK for
> restoration when working path failed. But if it
> is signal deradation at the working path, I think
> we still have risk receive duplicated packet at
> the destination. So here it should state that we

Fine to make this statement.
It applies to *all* uses of make-before-break, by definition.

> 2, For comment 2, I think what said in draft means
> protection path can 100% protect anyone of N working
> path if it fails. Thanks for you explanation. If it
> is convenience, I think it's better to make it more
> clear.

Certainly. If the authors were not understood, they need to make it more 
clear!

> 3, Let me explain my question. I am not clear with
> "span recovery"(title of section 4.2.1), is it means
> segment recovery? What the relationship between
> "span recovery", "segment recovery" and "end to end
> recovery"?
> (I just find the definition of section has been deleted
> in MPLS-TP Requirements, sorry for confusion I made.)

Yeah, we've been having a lot of fun with terminology :-)

The draft "...uses the recovery terminology defined in [RFC4427]"

4427 says that a span is a link.

We have expanded that slightly to say:
"A span is a single hop between neighboring MPLS-TP LSRs in the same network 
layer."
We did this because sometimes there is confusion about what a "link" is when 
an LSP tunnel provides a link.

Although draft-ietf-mpls-tp-requirements-04.txt gives a good definition of 
link that should make everything clear.
Link: A physical or logical connection between a pair of LSRs that
   are adjacent at the (sub)layer network under consideration.  A link
   may carry zero, one or more LSPs or PWs.  A packet entering a link
   will emerge with the same label stack entry values.

Finally (!) draft-ietf-mpls-tp-requirements-04.txt has made two definitions 
for "segment" and "concatenated segment". Both of these definitions, are 
talking about a piece of an LSP.

So this gives us:
- end-to-end protection
  Protecting a whole LSP from the ingress to the egress
- segment protection
  Protecting one or more hops of a single LSP
- span protection
  Protecting a link

In the first two cases, the thing that is protected is an LSP.
In the third case, the thing that is protected is a link.

OK?

Adrian