Subject: [mpls-tp] OAM configuration via the control plane - four drafts that needs to coordinated

From: Loa Andersson <[email-masked]>
Date: Fri, 27 Nov 2009 11:50:03 +0100

All,

There are four diferent drafts that have been brought to ccamp on using 
a control plane to configure OAM:

draft-ietf-ccamp-oam-configuration-fwk-02
draft-ietf-ccamp-rsvp-te-eth-oam-ext-02
draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03

All these draft address issues around extending RSVP-TE to configure
OAM for different forwarding planes.

This is good and something we need to resolve fairly quickly,
we need to discuss this in several contexts with IETF, e.g.
CCAMP, the MPLS-TP project and possibly also in the Operation and
Management Area.

I see a few problems that I would like to see resolved, that has
mostly to do with the relationship between raft-ietf-ccamp-oam-
configuration-fwk and the technology specific documents. All
drafts is to a certain extent unclear and miss  some necessary
information, e.g. the exact relationship between the flag field
in the OAM Configuration TLV and tool specific sub-TLVs.
This is reflected in that it hard to write the technology specific
oam-configuration documents in a clear and consistent way.

There are a few issues that needs to be resolved.

1. We need to understand how generic it is possible to capture
    the OAM functions in the OAM Functions Flag Field in the OAM
    Configuration TLV.
    One idea with the flag field is that if you use default values for
    a OAM flagged in the flag field you don't need further sub-TLVs.
    However there seems to be different needs depending on the forwarding
    planes, e.g. it seems that the Ethernet draft makes the assumption
    that cc and cv is always run together at the same time, while in
    mpls-tp context we see that cc without cv is possible, and cc is
    implicit in proactive cv.
    Now with the current "Connectivity Monitoring flag" it is perfectly
    possible to take correct actions based on the default values for
    Ethernet, but for mpls(-tp) you be required to add some extra
    information. We can do this with using a mpls(-tp) specific sub-TLV,
    there is no real problem in that, but we loses some of the power of
    very simple trigger we have in the flag field. Or we could add a CC
    flag to the flag field, and let the "Connectivity Monitoring flag"
    represent th case where we use CC and CV in combination.
    Again that is not a problem, but I concerned that if this is
    recurring we would very quickly run out of in flags in the rather
    small OAM Functions Flag Field. Extending the field would be one way
    to resolve this.

2. Specifying and describing TLVs. In order to make RFCs easy to read
    and understand the TLV specifications need to be precise and to the
    point, I think there is a lot to be learned from e.g RFC5036, there
    Bob create an art of clearly specifying e.g. TLVs. There is e.g a
    clear and exactly matching list of explanations for each field in
    in the TLV

    In the four OAM Configuration drafts this is less clear. I'm not
    picking on any draft or author here, yes requesting that we sue a
    model that is as clear as in RFC5036.

    Again looking at the OAM Configuration TLV (but I'm not picking on
    that one in particular, this is recurring)
    - the Type field contains the value we want IANA to assign, this very
      quickly becomes hard to track since IANA will assign may Type (2)
      e.g. one each as sub-TLV for different TLVs. The type field should
      contain the name of the TLV.
    - what follows the TLV picture is a mix of defining what goes into
      the and what behavior that is expected in some cases.
      The list after should only indicates what goes into the TLV field
    - E.g. under OAM type it says that an "error" should be generated if
      the OAM type is not supported, I think this os an example of what
      indicated where we find the error codes.
    - names in the TLV picture and the list defining what goes into the
      field should be the same.

I realize that having said this it will be necessary to start sending
text to the authors of the different drafts, will do so as soon as I
can.

In order finally come up with a good control of OAM in gmpls we need to
fix all four drafts. This does not in anyway require that we stop
working on the technology specif draft, but fixes and clarifications in
the framework needs to be reflected in the technology specific drafts.
 From an MPLS-TP project view it is also necessary to progress the
mpls-tp specific drafts early, at least in parallel with the other
drafts.

/Loa
-- 

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: "Attila Takacs" <[email-masked]>
Date: Mon, 30 Nov 2009 14:25:34 +0100

Hi Loa, 

Thanks for your review and comments!

>     small OAM Functions Flag Field. Extending the field would 

This is a point we discussed off-line in Hiroshima between Elisa, you
and myself. The reason to progress the framewrok togeather with a set of
technology specific documents is exactly to see what and how would fit
into the framework and what needs to be technology specific.

Up until now, having 3 flags seemed to be enough, there may indeed be a
need to separate CC and CV as we see MPLS-TP OAM unfold. Also we need to
see how other TP OAM functions will fit into the configuration fwk
and/or if they are specific to the MPLS-TP OAM configuration document.

In any case, one way to extend the flags field would be to have a
dedicated flag at the end that would extend the field with an additional
32 flags. In paralell it would also be possible to define the flags to
be scoped under technology specific documents. These two were Loa's
proposal in Hiroshima.

An alternative would be to remove the flags and let the OAM function
specific sub-TLVs self represent the need of and trigger the
establishment of the corresponding OAM function. This would, probably
simplify the structure but would require more data to configure default
OAM functions. 

I think both alternatives are viable.

>     model that is as clear as in RFC5036.

Since the darfts are still work in progress and are a result of
continous evolution there is for sure room to improve the text. 

>       field should be the same.

I could not decode the issue here, could you please clarify?

Thanks,
Attila

> I realize that having said this it will be necessary to start 
> sending text to the authors of the different drafts, will do 
> so as soon as I can.
> 
> 
> In order finally come up with a good control of OAM in gmpls 
> we need to fix all four drafts. This does not in anyway 
> require that we stop working on the technology specif draft, 
> but fixes and clarifications in the framework needs to be 
> reflected in the technology specific drafts.
>  From an MPLS-TP project view it is also necessary to 
> progress the mpls-tp specific drafts early, at least in 
> parallel with the other drafts.
> 
> /Loa
> -- 
> 
> 
> Loa Andersson                         email: 
>                                               +46 767 72 92 
> 13 _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Attila Takacs" <[email-masked]>
Date: Tue, 1 Dec 2009 07:20:49 +0100

Hi Deborah, Lou, all,

Given the interest in the new technology specific OAM configuration documents and the proposed update of the framework itself, the authors of draft-kern and draft-bellagamba would like to work together updating their documents, in parallel with an update of the framework document, before asking to become WG documents. 

Hence, I would like to ask the CCAMP chairs to suspend the call of draft-kern, and reinitiate it once the updates took place.

Thanks,
Attila

> -----Original Message-----
> From: Andrew G. Malis [mailto:[email-masked]] 
> Sent: Monday, November 30, 2009 6:43 PM
> To: Attila Takacs
> Cc: Loa Andersson; [email-masked]; [email-masked]
> Subject: Re: [CCAMP] [mpls-tp] OAM configuration via the 
> control plane - four drafts that needs to coordinated
> 
> Attila and Loa,
> 
> I certainly agree that the four drafts in question need to be 
> consistent and should be worked in parallel to keep them that way.
> Also, Loa's request to follow Bob's precedent in RFC 5036 for 
> TLV specification is certainly reasonable. Also, the first 
> alternative in Attila's email (adding an additional 32 flag 
> bits) seems the simpler choice.
> 
> Cheers,
> Andy
> 
> On Mon, Nov 30, 2009 at 2:25 PM, Attila Takacs 
> <[email-masked]> wrote:
> > Hi Loa,
> >
> >>     there is no real problem in that, but we loses some of 
> the power 
> >> of
> >>     very simple trigger we have in the flag field. Or we 
> could add a 
> >> CC
> >>     small OAM Functions Flag Field. Extending the field 
> would be one 
> >> way
> >>     to resolve this.
> >
> > and myself. The reason to progress the framewrok togeather 
> with a set 
> > of technology specific documents is exactly to see what and 
> how would 
> > fit into the framework and what needs to be technology specific.
> >
> > Up until now, having 3 flags seemed to be enough, there may 
> indeed be 
> > a need to separate CC and CV as we see MPLS-TP OAM unfold. Also we 
> > need to see how other TP OAM functions will fit into the 
> configuration 
> > fwk and/or if they are specific to the MPLS-TP OAM 
> configuration document.
> >
> > simplify the structure but would require more data to configure 
> > default OAM functions.
> >
> >>     and understand the TLV specifications need to be 
> precise and to 
> >> the
> >>     Again looking at the OAM Configuration TLV (but I'm 
> not picking 
> >> on
> >>     - the Type field contains the value we want IANA to 
> assign, this 
> >> very
> >>       quickly becomes hard to track since IANA will assign 
> may Type 
> >> (2)
> >>     - E.g. under OAM type it says that an "error" should 
> be generated 
> >> if
> >>     - names in the TLV picture and the list defining what 
> goes into 
> >> the
> >> In order finally come up with a good control of OAM in 
> gmpls we need 
> >> to fix all four drafts. This does not in anyway require 
> that we stop 
> >> working on the technology specif draft, but fixes and 
> clarifications 
> >> in the framework needs to be reflected in the technology specific 
> >> drafts.
> > _______________________________________________
> > CCAMP mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ccamp
> >
>