Subject: [CCAMP] draft-ietf-ccamp-oam-configuration-fwk-03

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Mar 2010 17:15:26 -0400

I have a few comments on draft-ietf-ccamp-oam-configuration-fwk-03

Most of my comments are general.

  1. The method suggested to change OAM parameters should be
     non-disruptive, and if possible including no loss of protection
     status.  The proposed mechanism seems to temporarily break the
     responsiveness of CC/CV during the transition period if a minor
     OAM parameter is changed.  Perhaps identifying OAM packets such
     as CC/CV according to an OAM configuration identifier would allow
     for the transition in a way that is similar to the transition of
     crypto keys where for an interim period two are recognized before
     the old is withdrawn.  For example, CC/CV at one rate with proper
     identification may allow working path to stay up.  CC/CV with a
     second rate make take over at any time, also identified and
     therefore at a known rate.  If either are being received the
     working path is assumed to be working.  The older of the OAM
     parameters can then be withdrawn leaving only the new parameters
     in place.  Management plane changes in particular take an
     eternity to perform compared to the restoration time
     requirements.

     This is either a missed OAM requirement, or not important (not
     missed, not a requirement), or accommodated by an alternate
     mechanism.

     Another way to accomplish the same thing would be creating a new
     LSP on the same path using make-before-break semantics.  If this
     is preferable, maybe it should be mentioned here.  OTOH -
     resignaling the LSP and in doing so coming up with a different
     LSP-id and set of labels is a lot of overhead for a parameter
     change.

     Another question - should a parameter change which is rejected
     take down the LSP?  As currently specified it does.

  2. Note: There does not seem to be any possibility of OAM leaking
     outside.  OAM is always received, evn if received and discarded
     and never forwarded.  Perhaps the paragraph describing this could
     be deleted or edited to reflect this.

  3. A requirement and framework document does not generally define
     the protocol mechanisms at the same time.  Either this document
     has to be edited to not claim to be a requirement and framework
     document, or the mechanism needs to be split off into another
     document.  If the WG goes with the former, then this document
     should be held to a higher standard as required by the IETF
     routing area (working code, interoperability).  The reason for
     this is a lot of problems are found in taking the step to working
     and interoperable code.  As it exists this is a base protocol
     specification, not a equirement and framework document.

  4. If a MIP is only desired at select points along the LSP, it would
     be better to extend the ERO.  If so, then this discussion of
     attribute flags bits goes away.  The ingress can elect to not use
     an LSP if the egress and appropriate set of midpoint LSR have
     filled in the RRO indicating that the OAM functionality is
     enabled.  The ERO would also have to be modified by MIP to
     indicate to the egress that they have been set up.

     The ERO/RRO might also be a better place to put this simple
     because SESSION_ATTRIBUTE bits and ADMIN_STATUS bits are in short
     supply and have limited potential semantics.

  5. A "reject object" containing a reason and the TLV being rejected
     would be preferable to a PathErr.  This is particularly true if
     resignaling a parameter.

  6. It might be better to put "lock" and "loopback" functionality in
     the control plane for PW and LSP or management plane rather than
     putting it in the data plane in the OAM packets.  We just had a
     brief discussion on setting loopback in the data plane using TTL
     to identify the node and having the TTL and data path change due
     to a segment protection status change (FRR being an example).

Minor:

@@ -760,6 +810,10 @@
              2                   Performance Monitoring/Loss (PM/Loss)
              3                   Performance Monitoring/Delay (PM/Delay)

+* The length is not specified.  As drawn this is a arbitrary length
+  integer containing one of the values 0..3.  A bitmap would be
+  preferable and that may be what was intended.

Last is a nit - there is a spelling error.

-   In general, two types of Maintenance Poits (MPs) can be
+   In general, two types of Maintenance Points (MPs) can be

Curtis

---

From: Attila Takacs <[email-masked]>
Date: Tue, 23 Mar 2010 18:29:52 +0100

Hi Curtis, 

Thank you for the comments!

>      eternity to perform compared to the restoration time

To allow two parameters to be recognised during reconfiguration is, I think, OAM technology and implementation dependant. If this is indeed supported by the underlying OAM technology then, re-signaling with the changed parameters without clearing the OAM Alarms Enabled flag would actually result in the desired operation you described above.

>      missed, not a requirement), or accommodated by an alternate

If this is a requirement, it must be addressed by the specific OAM technology and not in this document that deals with GMPLS CP aspects only.

>      take down the LSP?  As currently specified it does.

My intention was to say the following...I will need to elaborate on this in the text further, I admit.

Let us take as example the CC rate, now it is running at say 100ms. There are two cases:

1) the initiator wants to change to a higher rate say 3.3ms.
In this case the remote-end may chose not to accept the value and suggest 10ms instead. What should not be allowed trough is to suggest a lower rate than the 100ms that is used currently. So say suggesting 1s should result in an error and tear down.

2) the initiator wants to reduce the reate say to 1 sec. In this case I assume that the remote-end will have no problem to accept the new rate.

Do you agree with this?
 
>      be deleted or edited to reflect this.

Hmm, I would say that this may be technology specific too. In any case, calling out the setup of the sink function should not be an issue. In the case the "sink" function in implicit for a technology there is no harm calling that explicitly out.

>      specification, not a equirement and framework document.

Point taken, will discuss with the chairs.

>      supply and have limited potential semantics.

Discussion is going in the context of:
http://tools.ietf.org/html/draft-kern-ccamp-rsvpte-hop-attributes-00
http://tools.ietf.org/html/draft-kern-ccamp-intermediate-node-config-00

>      would be preferable to a PathErr.  This is particularly true if

Ok, will consider.

>      to a segment protection status change (FRR being an example).

Admin Status bits in the context of recovery signalling are defined in other documents for Lockout, Testing and Administratively Down that can be used here as well. 

> Minor:

Intension is to have a bitmap. Will clarify.

> +   In general, two types of Maintenance Points (MPs) can be

Thanks,
Attila

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Mar 2010 14:01:34 -0400

In message <[email-masked]>
Attila Takacs writes:
> To allow two parameters to be recognised during reconfiguration is, I
> think, OAM technology and implementation dependant. If this is indeed
> supported by the underlying OAM technology then, re-signaling with the
> changed parameters without clearing the OAM Alarms Enabled flag would
> actually result in the desired operation you described above.

If the underlying OAM is related to PW or LPS, then the capability is
what we define it to be.  Otherwise it is what IETF or ITU has defined
it to be for Etherent, SONET/SDH, OTN, etc.

> If this is a requirement, it must be addressed by the specific OAM technology and not in this document that deals with GMPLS CP aspects only.

That is a good point.  My comments are misdirected.

> In this case the remote-end may chose not to accept the value and suggest 10ms instead. What should not be allowed trough is to suggest a lower rate than the 100ms that is used currently. So say su…

A tear down is an unacceptable outcome.  That is why a suggested
make-before-break as a possibility.

> 2) the initiator wants to reduce the reate say to 1 sec. In this case I assume that the remote-end will have no problem to accept the new rate.

That is true.  This could be done without make-before-break but the
more general case would be make-before-break.  Either that or the idea
of two rates, where accepting one of the two is adequate to keep the
LSP from being rejected.

Having a window where protection is disabled is undesirable but the WG
may end up agreeing that this is acceptable.  If so, it should be
documented.

> Hmm, I would say that this may be technology specific too. In any case, calling out the setup of the sink function should not be an issue. In the case the "sink" function in implicit for a technolo…

Please explain how signaling in PATH and RESV messages could be
related to anything other than PW or LSP.  Or are you considering the
GELs case?

> Point taken, will discuss with the chairs.

Thanks.

> http://tools.ietf.org/html/draft-kern-ccamp-intermediate-node-config-00

Thanks.  These referneces help.

> >      would be preferable to a PathErr.  This is particularly true if

Thanks.

> Admin Status bits in the context of recovery signalling are defined in other documents for Lockout, Testing and Administratively Down that can be used here as well. 

I'm missing something.  Which I-D is this?

draft-kern-ccamp-intermediate-node-config-00 has:

  2.2.  OAM Configuration of Non-Intrusive Monitoring Entities

but lock and loopback are not non-intrusive and this section is not
very specific.  Good work though.