Subject: [mpls-tp] Agenda for call on MPLS-TP Survivability Framework

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 6 Dec 2009 15:46:29 -0000

Hi,

Nurit and I have been going through the comments received from the ITU-T in 
their early review.

We have some specific issues with which we would like help and have 
constructed the attached agenda.

Speak to you on Tuesday.

Thanks,
Adrian

---

From: <[email-masked]>
Date: Sun, 6 Dec 2009 20:42:02 +0000

Adrian,

> constructed the attached agenda.

I won;t be on the call on Tuesday but thought I'd throw my 2p into the
ring...see below I have interspersed my comments with text from the document
you attached to your e-mail.

   Several of the comments from the ITU-T suggest that APS MUST NOT be
   termed an OAM mechanism.

I haven't really been party to the discussions but this seems a bit
"religious" to me. Maybe one person's OAM is another person's APS ;-)

   Yet there also appears to be requirements that:
   - APS MUST always be in-band
   - That the term "control plane" MUST NOT be associated with APS

I'm getting slightly more confused now. If APS is not part of OAM and it's
not part of the control plane what exactly is it part of? It's not
management plane. So the only thing left is data plane and protocols that
control data plane functionality are normally termed "control plane" are
they not?

   Question: Is PSC (APS) part of OAM or not?
   Proposal: The editors propose to dodge this issue in the document by
             describing it as an "in-band control protocol".

Good dodge :-) but does it adequately dodge the control plane issue above?

   Proposal: The editors propose that the liaison response asks the
             ITU-T for clarification of whether APS is an OAM mechanism.

It's probably sensible to ask, but I suspect if we're not careful we could
fall down a terminology rat hole. I think what's important is that
sufficient & correct functionality is delivered by the MPLS-TP project.
Making sure the "bucket" we throw it in is terminologically correct is
secondary IMO.

   APS seems to be used by some people to cover two concepts:
   - the OAM mechanism that detects a fault and triggers protection
     (such as used in ring protection)
   - the coordination of protection state
   Proposal: The editors feel it is helpful to split these concepts both
             from an architectural and an implementation point of view.

Agreed.

   Proposal: The editors feel that these specific mechanisms and
             triggers should be called simply "OAM" (i.e. are part of
             the wider OAM toolkit)

Fine with me but how does that align with your "dodge" above?.

   Proposal: To avoid confusion, the editors propose to use the term
             "PSC" for Protection State Coordination.

Will this not confuse with PSC == Packet Switch Capable in GMPLS (seeing as
the MPLS-TP control plane will be GMPLS based)?

   There are several survivability features that are either explicitly
   not requirements, or that are not mentioned in RFC 5654.

   Note that these are not state in RFC 5654 as "MUST NOT support".

Although we spent many months getting RFC5654 right I wouldn't like folks to
start making the assumption that something not being stated in RFC 5654
automatically means MPLS-TP MUST NOT support it. It probably does mean that
it's not critical to the functioning of a transport network though.

   Question: Is it OK for this document to describe survivablity
             features that are common to many networks (IP/MPLS or
             transport) but which are not required in RFC 5654.

Provided it doesn't distract from the focus of the document being a
survivability framework for those requirements articulated in RFC5654.
However what is the perceived benefit of describing such functions - purely
for informational purposes to state that other mechanisms are possible, just
not absolutely required in an MPLS-TP network?

   Proposal: The editors feel these should be treated on a case-by-case
             basis.

Agreed.

   Proposal: Each instance should be carefully caveated with text that
             points out that the feature is not required by RFC 5654.

OK.

   Proposal: We should allow the use of the management plane to effect
             restoration (even though this may be slower).

Agreed.

   4. RFC 5654 Requirement 104
   This states:
   104  The recovery mechanisms in a ring MUST support ways to
        distinguish administrative protection-switching from protection-
        switching initiated by other triggers.

   Question: How should we interpret this? To whom (which functional
             components) is the distinction being made?

   The editors have assumed that the distinction is made to the
   management system (and the operator).

I interpret the use of "administrative" in this context to mean management
plane or operations personnel triggered.

   6. Updates after review
   The ITU-T review contains somewhat more than 200 comments and
   questions. This requires significant updates.
   Question: How should we handle these updates?
   Proposal: The editors propose that they update the I-D according
             to the comments and post a new revision.
   Proposal: The editors propose that they do not justify each change
             to the working group, but rely on rfcdiff and the liaison
             response (see item 6).

Agreed, otherwise you'll spend more time justifying the updates than making
them in the first place!

7. Liaison response
   We need to generate a liaison response.
   Question: How shall we respond to the liaison?
   Proposal: The editors should draft a response.
             - include the updated I-D
             - no comments on the points we have addressed
             - requests for clarification where appropriate
             - rebuttals where appropriate

I would also (I guess you already have this in your mind and have just not
stated it explicitly) point to rfcdiff and possibly also attach a pre-diff'd
(HTML?) version to make comparison by ITU-T easier.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 07 Dec 2009 09:31:55 +0100

See inline.. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: zondag 6 december 2009 21:42
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Agenda for call on MPLS-TP Survivability Framework

Adrian,

On 06/12/2009 15:46, "Adrian Farrel" <[email-masked]> wrote:
> Nurit and I have been going through the comments received from the 
> ITU-T in their early review.
> 

[mv] There are different types of OAM/OH (see attached slide). All ITU-T
recommendations treat APS as part of their OAM/OH specifications. The same
is the case for DCC, MCC, SCC, GCC, COMMS and SSM. Those latter ones are
also treated as part of OAM/OH. 

[mv] The APS/PCC, DCC, MCC, SCC, COMMS, GCC and SSM OAM/OH provide
communication channels for protection switching, management, signalling and
synchronisation applications and differ as such from the pro-active and
on-demand OAM/OH which determine status and performance information of the
transport entity it self. 

[mv] As OAM stands for "Operation, Administration and Maintenance", APS/PCC,
DCC, MCC, SCC, GCC, COMMS and SSM are elements that support the operation
and administration parts of OAM. They are as such OAM elements, but not the
same type as the other OAM elements.

[mv] APS is part of OAM and provides a communication channel for protection
switching engines located in connection functions to synchronise their state
machines. The "control plane" contains the functions specified in G.8080,
and protection switching functions are not part of that.

[mv] Best is to describe that there are multiple classes of OAM (see
attached slide) and make APS, SCC, MCC part of the Communication Channel OAM
class.

Agreed.

[mv] APS never detects a fault; a fault is detected by the pro-active OAM
elements. APS is used to communicate the status of a protection process at
one end to the protection process at the other end in order to coordinate
the protection state.

[mv] I agree with the editors. APS is part of the OAM toolkit.

[mv] APS is a well known term in transport networks. Changing this will only
result in confusion... So a bad idea in my opinion.

Regards,
Maarten

Agreed.

OK.

Agreed.

   6. Updates after review

7. Liaison response

Ben

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