Subject: [CCAMP] Comments to draft-ietf-ccamp-oam-configuration-framework-04

From: Greg Mirsky <[email-masked]>
Date: Mon, 1 Nov 2010 17:26:57 -0700

Dear Authors,
please find my comments to the document below:

   - Introduction uses Operations and Management as interpretation of OAM
   acronym. According to The OAM Acronym <http://goog_660573193>
<http://goog_660573193>
   Soup<http://tools.ietf.org/html/draft-ietf-opsawg-mpls-tp-oam-def-02#page-6>Operations,
Administration, Maintenance is more commonly interpretation of
   the acronym.
   - Section Requirements p.5 lists requirement specific to MPLS-TP "The
   MPLS-TP control plane MUST support ..." I think that requirements for OAM
   should not refer to any specific data plane technology. Perhaps MPLS-TP can
   be omitted to make "The Control Plane MUST support ..."
   - Requirements p.6 in "It MUST be possible to explicitly request ..."
   refers to OAM entities. I couldn't find explicit list of OAM
   objects/entities that are require control by GMPLS. I think that such list
   might be useful. On another note, this requirement seems as more generic
   than preceding requirement on p.5 (it would be helpful to enumerate
   requirements in the document)
   - Section 3.1 second paragraph. I think that your observation that OAM
   can be configured at the time of LSP setup as well as at any time after the
   LSP became operational. I couldn't find explicit corresponding requirement.
   - I couldn't find requirement that would state that setup and maintenance
   of ME and MPs should not affect client services.
   - Section 3.1 p.8 "When the Path message arrives at the receiver ..." I
   think that this reference is too specific for the framework document.
   Perhaps this can be used instead "When a control message arrives at the
   receiver ..."
   - "When the initiating side receives the Resv message ..." same as above
   comment
   - I think that Section 4 offers solution to formulated requirements. The
   framework, requirements could be separate Informational document with
   solution provided in a Standard Track document.

Regards,
Greg

---

From: Loa Andersson <[email-masked]>
Date: Tue, 02 Nov 2010 11:01:24 +0100

Greg,

actually the soup draft says:

    OAM - Operations, Administration, and Maintenance

    O&M - OAM and Management

so it depends of what they want to say, but we should follow
the guidelinnes in the draft.

/Loa

On 2010-11-02 01:26, Greg Mirsky wrote:
>     * Introduction uses Operations and Management as interpretation of
>       OAM acronym. According to The OAM Acronym
>       <http://goog_660573193><http://goog_660573193>Soup
>       <http://tools.ietf.org/html/draft-ietf-opsawg-mpls-tp-oam-def-02#page-6>Operations,
>       Administration, Maintenance is more commonly interpretation of the
>       acronym.
>     * Section Requirements p.5 lists requirement specific to MPLS-TP
>       "The MPLS-TP control plane MUST support ..." I think that
>       requirements for OAM should not refer to any specific data plane
>       technology. Perhaps MPLS-TP can be omitted to make "The Control
>       Plane MUST support ..."
>     * Requirements p.6 in "It MUST be possible to explicitly request
>       ..." refers to OAM entities. I couldn't find explicit list of OAM
>       objects/entities that are require control by GMPLS. I think that
>       such list might be useful. On another note, this requirement seems
>       as more generic than preceding requirement on p.5 (it would be
>       helpful to enumerate requirements in the document)
>     * Section 3.1 second paragraph. I think that your observation that
>       OAM can be configured at the time of LSP setup as well as at any
>       time after the LSP became operational. I couldn't find explicit
>       corresponding requirement.
>     * I couldn't find requirement that would state that setup and
>       maintenance of ME and MPs should not affect client services.
>     * Section 3.1 p.8 "When the Path message arrives at the receiver
>       ..." I think that this reference is too specific for the framework
>       document. Perhaps this can be used instead "When a control message
>       arrives at the receiver ..."
>     * "When the initiating side receives the Resv message ..." same as
>       above comment
>     * I think that Section 4 offers solution to formulated requirements.
>       The framework, requirements could be separate Informational
>       document with solution provided in a Standard Track document.
>
> Regards,
> Greg
>
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Loa Andersson <[email-masked]>
Date: Tue, 02 Nov 2010 17:31:09 +0100

Authors,

your introduction section starts:

    GMPLS is designed as an out-of-band control plane supporting dynamic
    connection provisioning for any suitable data plane technology;

I think the right thing to say would be:

    "GMPLS is control plane that is always *capable* of running
    out-of band supporting dynamic connection provisioning for
    any suitable data plane technology;"

/Loa

--

---

From: "t.petch" <[email-masked]>
Date: Wed, 3 Nov 2010 12:58:00 +0100

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: "Greg Mirsky" <[email-masked]>
Cc: <[email-masked]>; "Attila Takacs" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, November 02, 2010 11:01 AM
> the guidelinnes in the draft.

And the AD responsible says

"The IESG felt that the current document text attempts to strongly
influence the IETF-wide behavior while being an Informational document that
describes the use of the acronym in the MPLS-TP project"

so we should not follow the guidelines in the draft until this issue is
resolved,
and certainly not for a document that is not an MPLS-TP one.

Tom Petch

> >       <http://goog_660573193><http://goog_660573193>Soup
<http://tools.ietf.org/html/draft-ietf-opsawg-mpls-tp-oam-def-02#page-6>Operatio
ns,