Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps

From: Francesco Fondelli <[email-masked]>
Date: Mon, 1 Apr 2013 18:19:33 +0200

quoting item 15, from www.ietf.org/proceedings/86/minutes/minutes-86-ccamp

Lou Berger: I think you misunderstood my comment from the last meeting. You
should look at leveraging the OAM configuration work which came after the
earlier versions of your draft.
Zafar Ali: this is applicable to multiple technologies.
Lou Berger: yes, the OAM configuration framework is also applicable to
multiple technologies. You need a strong reason not to follow the WG in
this area. Please look at the OAM configuration document
[draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state why
your work is justified in not following the existing WG solution in this
area.

---

Hi all,

  the OAM configuration framework [1] is about OAM.  Therefore, it is used in
order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], CC/CV
TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about *protection
switching*.  HOFF, WTR and SNC sub-type are protection switching parameters.

  I believe HOFF, WTR and SNC sub-type are outside of the OAM configuration
framework scope and should be signaled as any other protection switching
params (i.e. via PROTECTION object).

  I hope this answer Lou question reported above (item 15, IETF 86 ccamp
minutes).  Authors of [4] would like to understand WG's view about this point
and are soliciting for comments.

thank you
ciao
FF

[1]
http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09

[2]
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11

[3]
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05

[4]
http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Mon, 1 Apr 2013 18:06:19 +0000

Hi Francesco,

While these may be protection switching parameters, this draft is about configuration of these parameters. Protection switching provisioning has always been treated as a common equipment management functionality - same as performance management and fault management (refer to G.7710 section 8). So it is in scope of OAM configuration. CCAMP's OAM configuration work has been focused on PM and FM but it is generally applicable (hopefully) to any equipment management configuration.

Lou's comment is that the WG has chosen the approach used in the OAM framework document for configuration. Instead of updating the protection object at this time as your draft proposes, the question is have you considered using the OAM configuration TLV? First, we need to understand why you have chosen to not use this approach. Then we can discuss pros and cons.

BR-
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francesco Fondelli
Sent: Monday, April 01, 2013 12:20 PM
To: [email-masked]
Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps

---

Hi all,

thank you
ciao
FF

[1]

[2]

[3]

[4]
http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Francesco Fondelli <[email-masked]>
Date: Tue, 2 Apr 2013 11:22:24 +0200

> Hi Francesco,

Hi Deborah,

> While these may be protection switching parameters, this draft is about configuration of these parameters. Protection switching provisioning has always been treated as a common equipment management…

  Puzzled.  If we follow this reasoning (i.e. common equipment management
functionalities => should use OAM framework) then almost any aspect of
networking can be applicable to OAM and so any operation should exploit
the OAM framework draft.

  For example, G.7710 section 8.6.1 describes the provisioning
of cross-connections but this does not imply that we are going to use the
OAM framework to establish label binding in the next GMPLS controlled
technology, I guess we will continue to use LABEL_REQUEST/LABEL objects
(plus any other relevant info).

> Lou's comment is that the WG has chosen the approach used in the OAM framework document for configuration. Instead of updating the protection object at this time as your draft proposes, the questio…

  Well, at the beginning we did not take it into consideration
because [4] predate [1].  Later we did not take [1] into consideration
simply because we thought [4] was out of OAM framework scope.

  Having said that, I have no problem rewriting [4] using OAM
configuration TLV.  It's just weird to me but I can live with it.

> Deborah

thank you
ciao
fra

---

From: Francesco Fondelli <[email-masked]>
Date: Wed, 3 Apr 2013 18:59:19 +0200

Hi Deborah, all,

> configuration TLV.  It's just weird to me but I can live with it.

  sorry, I changed my mind, I cannot use the OAM TLV.  The more I read
about OAM in IETF the more I think protection switching provisioning
is completely out-of-scope.

  I spent some hours looking for the OAM definition within the
IETF context(s).  The most recent and enlightening (to me at least)
documents I found are [A] and [B].  As far as I understand, [1] is
perfectly aligned with them.  At the same time I cannot find any
support of your statement:

> Protection switching provisioning has always been treated as a
> common equipment management functionality [cut]. So it is in scope
> of OAM configuration.

  Maybe I'm just missing something big (?) Can someone shed some light on
this?

thank you
ciao
fra

[A]
http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08

[B]
http://tools.ietf.org/html/rfc6291

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 3 Apr 2013 17:28:01 +0000

Hi all- 

In addition, I see draft-takacs-ccamp-revertive-ps something that was not
addressed by 4872 but very much in-line with the rest of the mechanics of
4872. Even if we can define something using a different object, I feel use
of protection object is more in-line with the spirit of this draft.

Thanks

Regards Š Zafar

-----Original Message-----
From: Francesco Fondelli <[email-masked]>
Date: Wednesday, April 3, 2013 12:59 PM
To: "BRUNGARD, DEBORAH A" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps

>>> While these may be protection switching parameters, this draft is
>>>about configuration of these parameters. Protection switching
>>>provisioning has always been treated as a common equipment management
>>>functionality - same as performance management and fault management
>>>(refer to G.7710 section 8). So it is in scope of OAM configuration.
>>>CCAMP's OAM configuration work has been focused on PM and FM but it is
>>>generally applicable (hopefully) to any equipment management
>>>configuration.
>>
>>> Lou's comment is that the WG has chosen the approach used in the OAM
>>>framework document for configuration. Instead of updating the
>>>protection object at this time as your draft proposes, the question is
>>>have you considered using the OAM configuration TLV? First, we need to
>>>understand why you have chosen to not use this approach. Then we can
>>>discuss pros and cons.
>>
>>> quoting item 15, from
>>>www.ietf.org/proceedings/86/minutes/minutes-86-ccamp
>>>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 4 Apr 2013 14:49:31 +0000

Hi Francesco,

That was a fast analysis:-)

Suggest you first expand on the requirements that you want to support vs. solution. When you detail aspects of SNC/N, SNC/I, and SNC/S, you will find that you also need OAM configuration to support (N/I/S configuration (e.g. DEG, TTI)) and you will need to configure which defects contribute to a "failure". This will all need to be coordinated with the LSP OAM configuration.

Also on SNC/N, SNC/I, and SNC/S, is this for a segment or e-2-e? The draft needs more detail and alignment with GMPLS protection terminology and mechanisms.

After having a better scope of the requirements, we can discuss the solution tradeoffs. There are always multiple ways to solve, first we need to understand what is needed.

Thanks,
Deborah

-----Original Message-----
From: Francesco Fondelli [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2013 12:59 PM
To: BRUNGARD, DEBORAH A
Cc: [email-masked]
Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps

Hi Deborah, all,

thank you
ciao
fra

[A]

[B]

---

From: Francesco Fondelli <[email-masked]>
Date: Fri, 5 Apr 2013 00:00:49 +0200

Hi Deborah,

> Suggest you first expand on the requirements that you want to support vs. solution. When you detail aspects of SNC/N, SNC/I, and SNC/S, you will find that you also need OAM configuration to support…

  SNC sub-type has been introduced only recently in [4] and is a
Zafar Ali's contribution; I think he can expand/elaborate this
topic here on the list or in the next draft version.  In my emails
I was referring exclusively to hold off and wtr ([4] is about hold off
and wtr since day zero: July, 2008), sorry if this was not clear.

> Also on SNC/N, SNC/I, and SNC/S, is this for a segment or e-2-e? The draft needs more detail and alignment with GMPLS protection terminology and mechanisms.

  I think [4] addresses both e2e and segment (note: I'm talking about
hold off and wtr).

> After having a better scope of the requirements, we can discuss the solution tradeoffs. There are always multiple ways to solve, first we need to understand what is needed.

  The requirement is straightforward: in order to set up protection
switching you need hold off and wtr.  Either you use default values
for any LSP on a given network (which is what is happening today) or
you signal these values (hoff and wtr) on a per LSP basis.  The draft
tries to provide support for the latter.

> Deborah

thank you
Ciao
Fra

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 12 Apr 2013 19:19:16 +0000

Hi Deborah/ Francesco:

I don't want SNC changes to become a stopper for this draft. I will be ok
to take them out. 

Thanks

Regards Š Zafar

-----Original Message-----
From: Francesco Fondelli <[email-masked]>
Date: Thursday, April 4, 2013 6:00 PM
To: "BRUNGARD, DEBORAH A" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps

>> Suggest you first expand on the requirements that you want to support
>>vs. solution. When you detail aspects of SNC/N, SNC/I, and SNC/S, you
>>will find that you also need OAM configuration to support (N/I/S
>>configuration (e.g. DEG, TTI)) and you will need to configure which
>>defects contribute to a "failure". This will all need to be coordinated
>>with the LSP OAM configuration.
>
>> Also on SNC/N, SNC/I, and SNC/S, is this for a segment or e-2-e? The
>>draft needs more detail and alignment with GMPLS protection terminology
>>and mechanisms.
>
>> After having a better scope of the requirements, we can discuss the
>>solution tradeoffs. There are always multiple ways to solve, first we
>>need to understand what is needed.
>