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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Attila Takacs writes:
>  
> 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.


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.


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


That is a good point.  My comments are misdirected.


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


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.
>  
> Do you agree with this?


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.


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


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?


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

Thanks.

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


Thanks.  These referneces help.


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

Thanks.

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


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.


> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> > 
>