Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection

From: "Doolan, Paul (NSN - US/Irving)" <[email-masked]>
Date: Wed, 3 Oct 2012 05:36:58 +0800

Hello Alessandro,

Nurit claimed that you (and others) did not "provide any indication nor
technical justification which requirements are not addressed and why do
you think they are not addressed....."
'Pointing out R100 of RFC5654' I guess counts as an 'indication' but
certainly does not provide justification or indicate how the requirement
is not addressed. So to be productive here you  need to be more
specific.

Since you provide the example please indicate precisely how you think
this proposed draft violates R100 of RFC5654 (inline below for those
unfamiliar).

Recovery techniques in a ring SHOULD be identical (or as similar
as possible) to those in general transport networks to simplify
implementation and operations.  However, this MUST NOT override
 any other requirement.

You might also want to look at RFC2119.

best regards,
pd

Paul Doolan

---

From: Elton huang <[email-masked]>
Date: Wed, 17 Oct 2012 02:11:59 +0000

Dear Paul,
     A lot of requirements indicated in ITU-T lianson, and inputs form TI and CMCC are not satisfied in this drafts, could you read past emails carefully? That's why the draft is not supported.
B.R.
hffellow

Date: Wed, 3 Oct 2012 05:36:58 +0800
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
Subject: [mpls] R: Working group last call on draft-ietf-mpls-tp-ring-protection

Hello Alessandro,

Nurit claimed that you (and others) did not “provide any indication nor technical justification which requirements are not addressed and why do you think they are not addressed…..”
‘Pointing out R100 of RFC5654’ I guess counts as an ‘indication’ but certainly does not provide justification or indicate how the requirement is not addressed. So to be productive here you  need to be more specific.

Since you provide the example please indicate precisely how you think this proposed draft violates R100 of RFC5654 (inline below for those unfamiliar).

Paul Doolan

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

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 17 Oct 2012 08:42:26 +0200

Hi,

After careful reading of the LS received from the ITU-T, I did not see "a
lot of requirements" - there were exactly three, two of which were new
requirements, apparently put together in order to fit a particular
solution, that define a new concept in ring protection - "shared ring
protection switching".  Aside from that the LS presents a "problem" with
the draft for multiple faults that, IMHO, is based on a questionable
interpretation or implementation of the protection mechanism and a
"comparison" between three mechanisms one of which is not available to the
working group and is laced with subjective scales of comparison (i.e.
harder vs easier).

Regarding the emails from TI and CMCC - the authors are analyzing them and
will provide feedback in the near future.

BR,
yaacov

Still looking for new opportunity

On Wed, Oct 17, 2012 at 4:11 AM, Elton huang <[email-masked]> wrote:

>  Dear Paul,
>      A lot of requirements indicated in ITU-T lianson, and inputs form TI
> and CMCC are not satisfied in this drafts, could you read past emails
> carefully? That's why the draft is not supported.
> B.R.
> hffellow
>
>
>  ------------------------------
> CC: [email-masked]; [email-masked];
> [email-masked]
> Nurit claimed that you (and others) did not “provide any indication nor
> you think they are not addressed…..”
>
> ‘Pointing out R100 of RFC5654’ I guess counts as an ‘indication’ but
> is not addressed. So to be productive here you  need to be mor e specific.
>
> _______________________________________________ mpls mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>