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

Hi Curtis, 

Thank you for the comments!

> 
> 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.
>

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.

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

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.

> 
>      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.
>

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?

>   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.
> 

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.

>   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.

Point taken, will discuss with the chairs.

> 
>   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.
> 

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

>   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.

Ok, will consider.

> 
>   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).
> 

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:
> 
> @@ -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.
> 

Intension is to have a bitmap. Will clarify.

> 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

Thanks,
Attila

> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> 