Subject: Re: [mpls-tp] working grouplastcallondraft-ietf-mpls-tp-requirements-08.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 02 Jun 2009 15:18:48 +0100

Was this discussed in Sophia? What was the consensus? Ben

On 21/05/2009 18:05, "Adrian Farrel" <[email-masked]> wrote:

> I think this is good material for discussion in Sophia Antipolis.
AFAIK, the
> precise wording came from the ITU-T meeting in Geneva.
We should, therefore,
> get signoff from ITU-T folk when we change it.

A

> ----- Original Message -----
> 
From: <[email-masked]>
To: "Weingarten, Yaacov (NSN - IL/Hod
> HaSharon)" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday,
> May 21, 2009 11:09 AM
Subject: Re: [mpls-tp] working
grouplastcallondraft-ietf-mpls-tp-requirements-08.txt

> hi,all
> I think
> everyone's explaining maybe be  true and have a few good reasons.
> but
> IMO.there are not two different describles :
>   1 MPLS-TP MUST support rings
> of at least 16 nodes. IMO . there should
> be 16 and more than 16 nodes in the
> ring.
>   2 MPLS-TP should support rings of more than 16 nodes. IMO, there
> should
> be more than 16 nodes in the ring.
> so I advise there should be the
> same describles.
>
>  in additions, according to yaacov and sasha's email. I
> think the
> requirement should be revise to "no more than 16 nodes", it may be
> easy
> for other people to understand the requirements.
>
> regards
>
> liu
>
>
>
>
>
>
>
> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
> <[email-masked]>
> 发件人:  [email-masked]
> 2009-05-21
> 17:17
>
> 收件人
> "ext Alexander Vainshtein" <[email-masked]>,
> "Adrian
> Farrel" <[email-masked]>
> 抄送
> [email-masked]
> 主题
> Re:
> [mpls-tp] working group
>
> lastcallondraft-ietf-mpls-tp-requirements-08.txt
>
>
>
>
>
>
> Sasha, hi
>
> I
> understand the limitation of up-to 16 nodes is also related to the
> famous
> 50ms switching time requirement - where the base ring size is
> up-to 16 nodes
> and up-to 1200km.
>
> But I know that in G.8032 (Ethernet Ring Protection) the
> language that
> is used to describe this behavior is: "... with less than 1200
> km of
> ring fibre circumference, and fewer than 16 nodes, the switch
> completion
> time ... shall be less than 50 ms."
>
> Therefore, I suggest that
> the language be changed to: "MUST ... up to 16
> nodes..."
>
> Thanx and BR
>
> yaacov
>
> -----Original Message-----
> From: ext Alexander Vainshtein
> [mailto:[email-masked]]
>
> Sent: Thursday, May 21, 2009
> 10:37
> To: Adrian Farrel; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> Cc:
> [email-masked]
> Subject: RE: [mpls-tp] working group
>
> lastcallondraft-ietf-mpls-tp-requirements-08.txt
>
> Adrian, Yaakov and all,
>
> On top of highly problematic English:
> The original limit on up to 16 NEs in
> a SONET/SDH ring is a side effect
> of having just 4 bits for NE ID in the
> BLSR/MS-SPRing protocol
> that used K1/K2 octets in the Line/MS overhead.
>
>
> Unless we plan to reuse the same protocol in MPLS-TP or consider an
> upgrade
> of SONET/SDH muxes into MPLS-TP switches,
> the limit of 16 MPLS-TP nodes in a
> ring looks artificial to me.
>
> My 2c,
>     Sasha
>
>> -----Original
> Message-----
>> From: [email-masked]
>>
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
>> Sent:
> Wednesday, May 20, 2009 4:57 PM
>> To: Weingarten, Yaacov (NSN - IL/Hod
> HaSharon)
>> Cc: [email-masked]
>> Subject: Re: [mpls-tp] working group
> last
>> callondraft-ietf-mpls-tp-requirements-08.txt
>>
>> Yaacov,
>>
>> > I
> have some comments on this document that can be seen more
>> > as questions
> for clarification:
>> >
>> > 1. Req 27-C: MPLS-TP MUST support rings of at
> least 16
>> > nodes...MPLS-TP SHOULD support rings with more than
>> > 16
> nodes.
>> >
>> > So is it a MUST or a SHOULD?  Isn't "at least 16" and
> "more
>> > than 16" almost equivalent (except for exactly 16)?
>>
>> Right
>>
> MUST support 0-16
>> SHOULD support 17...
>>
>> That is what the text
> says.
>>
>> > 2. In Req 100 & 102 - What is the difference between
> "Recovery
>> > mechanisms" and "Recovery techniques"? Why is the first a
> MUST
>> > and the second a SHOULD?
>>
>> Good catch.
>> Only one of the two
> requirements should remain.
>> But which?
>>
>> > Finally, just a little
> spelling note: in Req 32-A: change
>> "bellow" to
>> > "below".
>>
>>
> Cheers,
>> Adrian
>>
>> _______________________________________________
>>
> mpls-tp mailing list
>> [email-masked]
>>
> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>
> _______________________________________________
> mpls-tp mailing list
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/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.
>

------------------------------------------------------------------
> --------------

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

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

---

From: Loa Andersson <[email-masked]>
Date: Tue, 02 Jun 2009 16:23:29 +0200

Ben,

yes it was discussed in Sophia, it was decided that ITU-T/SG15 did not
require any changes to the current text.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13

                                      email:  [email-masked]
                                              [email-masked]