Re: [mpls] mplxs Digest, Vol 105, Issue 46

[dhany19 <[e-mail]>]

Xxvubnivx
Sent from Meizu M9


-------- Original Message --------
From：[e-mail]
Time：1/22/2013 03:01
To：[e-mail]
Subject：mpls Digest, Vol 105, Issue 46

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

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

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send mpls mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/mpls
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mpls digest..."


Today's Topics:

   1. Re: I-D Action: draft-ietf-mpls-tp-rosetta-stone-08.txt (t.petch)
   2. Re: working group last call (Luyuan Fang (lufang))


----------------------------------------------------------------------

Message: 1
Date: Mon, 21 Jan 2013 14:35:43 +0000
From: t.petch <[e-mail]>
To: <[e-mail]>
Cc: [e-mail]
Subject: Re: [mpls] I-D Action:
	draft-ietf-mpls-tp-rosetta-stone-08.txt
Message-ID: <018801cdf7e4$e70b6420$[e-mail]>
Content-Type: text/plain; charset="UTF-8"

----- Original Message -----
From: "Huub van Helvoort" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: <[e-mail]>
Sent: Sunday, January 20, 2013 8:49 PM

Hello Tom,

Sorry for that.

I have uploaded draft-ietf-mpls-tp-rosetta-stone-09 to fix
these issues after double checking and unscrewing.

<tp>
Huub

Thanks for that - definitely not so kinky.

My big comment is that I would like all the entries in section 3 in
alphabetic order.  Technically, it makes no difference but to the user,
I think it would be a big improvement.  At the moment, it is like
turning to an English dictionary that is divided into sections and
needing to know whether a word derives from Greek or Arabic, Sanskrit or
Chinese, in order to know which section it is in.  The fact that the
first half is in alphabetic order just makes it harder to use - if the
ordering were seemingly random, it would be less of a problem!

Lesser comments.

PST and SPME have made it into significant MPLS-TP RFC and will be there
for ever.  I would like (deprecated) entries for these in this.

3.12 CE is not expanded anywhere

3.16 spurious period after the reference

3.43 an MEG???

3.43 et seq.  The various ME entries lack any references; since ME seems
to me to have been the most troublesome aspect of MPLS-TP and one that
still leads to errors, such as the erroneous expansion of MEP, I think
that these entries above all need references.

3.45  This is a comprehensive entry and yet ...  TCM is not expanded
anywhere - I think it deserves an entry of its own.  Statements like
"A MEP terminates all the OAM packets that it receives"
makes me think 'from where?' do I really understand this?
while
"MPLS-TP MEP notifies a fault indication"
seems odd in highlighting just one aspect of a MEP's functionality;
again, why that?

5 Operations and Management (OAM)
I love it - could we push for this usage to be adopted across the
IETF:-)

I would like a reference for this section - there are a number of OAM
RFC to choose from, e.g. framework, analysis, requirements.

6 I would like a reference for this section, perhaps the just-WGLC'd
draft-ietf-mpls-tp-security-framework

9 I do like alphabetic order, for references as well (a comment I saw
recently from a GenArt reviewer).

Overall, it remains an impressive piece of work.

Tom Petch


Regards, Huub.

========================
> Um; I am still seeing
>
>     [RFC....].
>
>     <<TBA>>
>
> Error! Reference source not found., Error!
>     Reference source not found., and Error! Reference source not
found..
>     ITU-T Recommendation Error! Reference source not found
>
> which suggests to me that a little more unscrewing is in order.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Huub van Helvoort" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, January 15, 2013 12:54 PM
> Subject: Re: [mpls] I-D Action:
draft-ietf-mpls-tp-rosetta-stone-08.txt
>
>
>> Sorry,
>>
>> I had to re-spin. MS messed up the references.
>>
>> Regards, Huub.
>>
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>>>    This draft is a work item of the Multiprotocol Label Switching
> Working Group of the IETF.
>>>
>>> Title           : A Thesaurus for the Terminology used in
> Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs
> and ITU-T's Transport Network Recommendations.
>>> Author(s)       : Huub van Helvoort
>>>                             Loa Andersson
>>>                             Nurit Sprecher
>>> Filename        : draft-ietf-mpls-tp-rosetta-stone-08.txt
>>> Pages           : 18
>>> Date            : 2013-01-15
>>>
>>> Abstract:
>>>      MPLS-TP is based on a profile of the MPLS and PW procedures as
>>>      specified in the MPLS-TE and (MS-)PW architectures developed by
> the
>>>      IETF.  The ITU-T has specified a Transport Network
architecture.
>>>
>>>      This document provides a thesaurus for the interpretation of
> MPLS-TP
>>>      terminology within the context of the ITU-T Transport Network
>>>      recommendations.
>>>
>>>      It is important to note that MPLS-TP is applicable in a wider
> set of
>>>      contexts than just Transport Networks.  The definitions
> presented in
>>>      this document do not provide exclusive nor complete
> interpretations
>>>      of MPLS-TP concepts.  This document simply allows the MPLS-TP
> terms
>>>      to be applied within the Transport Network context.
>>>
>
>


--
*****************************************************************
               ??????????????????????




------------------------------

Message: 2
Date: Mon, 21 Jan 2013 17:29:09 +0000
From: "Luyuan Fang (lufang)" <[e-mail]>
To: "t.petch" <[e-mail]>, "[e-mail]"
	<[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>,	"[e-mail]"
	<[e-mail]>,
	"[e-mail]"
	<[e-mail]>
Subject: Re: [mpls] working group last call
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset="us-ascii"

Hi Tom,

Thank you for your review, comments, and suggestions.

Please see in-line.


-----Original Message-----
From: "t.petch" <[e-mail]>
Date: Thursday, January 17, 2013 12:58 PM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
<[e-mail]>,
"[e-mail]"
<[e-mail]>
Subject: Re: [mpls] working group last call

>----- Original Message -----
>From: "Huub van Helvoort" <[e-mail]>
>To: <[e-mail]>
>Cc: <[e-mail]>; <[e-mail]>;
><[e-mail]>
>Sent: Wednesday, January 16, 2013 2:39 PM
>
>> Editors,
>>
>> You need to fix the acronym expansion for MEP and MIP:
>>
>> MEP   Maintenance Entity Group End Point
>> MIP   Maintenance Entity Group Intermediate Point
>
>and, at the same time, that other hoary old chestnut
>OAM  Operations, Administration and Maintenance

[luyuan] Yes, good point, will use the suggested text.


>
>On a slightly different tack, if Security Considerations calls out
>[RFC5920] as
>Normative (rightly so, IMO), then I think that  [MPLS-TP Sec FW]  must
>also
>be Normative.

[luyuan] I'm OK with that, will check with Adrian and Loa too.

>
>And, while I am on, there are still a fair number of places where the
>English
>reads oddly.  My sense was that Adrian, in August, provided a list of
>some of the
>instances where he saw that corrections would be beneficial but I think
>that
>his list was never meant to be inclusive.

[luyuan] We actually made major effort in 03 to improve the 'entire'
document 
after Adrian made his comments on 02 version. You can check the diff
between 03 and 02.


>
>For example, to take a paragraph at random, there is currently

[luyuan] This paragraph was added in 05 just before the last call based on
an operator's input.
We can improve the text per your comments.


>
>OLD
>   Some operators are using the similar model as in 2G and 3G Mobile
>   Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static
>   provisioning through NMS in aggregation and access. The reasoning is
>   the following: X2 traffic load in LTE network is currently a very
>   small percentage, e.g., some large mobile operator observed less than
>   one percent of total S1 traffic. Therefore, optimizing X2 traffic is
>   not the design objective, X2 traffic can be carried through the same
>   static tunnels together with S1 traffic in the aggregation and access
>   networks, and further forwarded accross IP/MPLS core. In addition,
>   Mesh protection may be more efficient in regard of bandwidth
>   utilization, but linear protection and ring protection are considered
>   simpler by some operators from operation maintenance and trouble
>   shooting point of view, therefore widely deployed. In general, using
>   MPLS-TP with NMS model for LTE backhaul is a viable approach. The
>   design objective of using this approach is to keep the operation
>   simple and with unified model for mobile backhaul.
>
>which, editing just the English and not the meaning, might produce,
>with an asterisk(*) indicating a change
>
>NEW
>   Some operators are using the *same model as in 2G and 3G Mobile
>   Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static
>   provisioning *(through NMS*)  in aggregation and access. The
>reasoning is
>   *as follows: *the X2 traffic load in LTE *networks is currently a
>very
>   small percentage, e.g., some large mobile *operators *observe less
>than
>   one percent of total S1 traffic. Therefore, optimizing X2 traffic is
>   not *a design objective*, X2 traffic can be carried through the same
>   static tunnels *as S1 traffic in the aggregation and access
>   networks, and forwarded *across *the IP/MPLS core. In
>addition,
>   Mesh protection may be more efficient *with regard *to bandwidth
>   utilization, but linear protection and ring protection are considered
>   simpler by some operators from the *point of view of operation*,
>maintenance and trouble
>   shooting *and so are widely deployed. In general, using
>   MPLS-TP with *static provisioning *(through NMS) for LTE backhaul is
>a viable approach. The
>   design objective of using this approach is to keep the operation
>   simple and *use a *common model for mobile backhaul.
>
>Um; quite a few changes (or we could leave it to the RFC Editor).

[luyuan] Thanks for your detailed suggestions and your discussion with me.
Below is the proposed new text, which you are OK with.

Some operators are using the same model as in 2G and 3G Mobile
   Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static
   provisioning (through NMS) in aggregation and access. The reasoning is
   as follows: the X2 traffic load in LTE networks currently may be a very
   small percentage of the total traffic, e.g., a large mobile operator
observed the X2 traffic was less than one percent of the total S1 traffic.
Therefore, optimizing the X2 traffic may not the design objective in this
case, 
The X2 traffic can be carried through the same static tunnels together with
the S1 traffic in the aggregation and access networks, and further
forwarded 
across the IP/MPLS core. In addition, mesh protection may be more
efficient with
regard to bandwidth utilization, but linear protection and ring protection
are 
often considered simpler by some operators from the point of view of
operation
maintenance and trouble shooting, and so are widely deployed. In general,
using MPLS-TP with static provisioning for LTE backhaul is a viable option.
The design objective of using this approach is to keep the operation
simple and 
use a common model for mobile backhaul, especially during the transition
period.


Thanks,
Luyuan
>
>Tom Petch
>
>> Regards, Huub.
>>
>> ======
>>
>> > this is to start a two week Working Group last call on
>> > draft-ietf-mpls-tp-use-cases-and-design.
>> >
>> > This is the second time we working group last call this
>> > draft, it has been updated after comments during the
>> > ADE-review. The changes are such that we have decided to
>> > do a full two week wglc.
>> >
>> > Please send your comments to the mpls working group
>> > mailing list ([e-mail]).
>> >
>> > Please send both technical comments, and if you are happy
>> > with the document as is also indications of support.
>> >
>> > There are no IPR claims against this draft.
>> >
>> > All the co-authors has stated that they are not aware
>> > of any IPRs.
>> >
>> > This working group last call will end on January 25, 2013.
>> >
>> > /Loa
>> > for the wg co-chairs
>> >
>>
>
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls



------------------------------

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


End of mpls Digest, Vol 105, Issue 46
*************************************