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

From: Lou Berger <[email-masked]>
Date: Tue, 01 Dec 2009 06:55:47 -0500

Attila,
	While unusual, I see no real issues with suspending the poll.

All,
	Please keep in mind that becoming a WG document does not mean that the 
technical details of a document are frozen.  It does mean that the 
working group become the authoritative body for technical content, i.e., 
WG consensus drives a WG document while author consensus drives an 
individual document.

Lou

On 12/1/2009 1:20 AM, Attila Takacs wrote:
> 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,
>>>
>>> Thanks for your review and comments!
>>>
>>>> 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.
>>>
>>> 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.
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> Since the darfts are still work in progress and are a result of
>>> continous evolution there is for sure room to improve the text.
>>>
>>>>      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 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:
>>>> [email-masked]
>>>> Sr Strategy and Standards Manager            [email-masked]
>> Ericsson Inc
>>>> phone: +46 10 717 52 13
>>>>                                                +46 767 72 92
>>>> 13 _______________________________________________
>>>> mpls-tp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>
>
>
>