Re: [mpls] draft-ietf-mpls-p2mp-sig-requirement-00.txt

On Dec 21, 2004, at 4:52 PM, Adrian Farrel wrote:

> Tom,
>
> Maybe I have flu and I'm not thinking straight.
>
>>> But, in another email you commit to doing the work to making sure 
>>> that
>>> P2MP OAM requirements are covered, so perhaps you'd like to propose
>>> some text for discussion.
>>
>> I personally have none nor have I received any to-date,
>> which is why they didn't go into the MPLS OAM draft. *)
>> In any event, why is it unreasonable to request that these be given
>> by the editors of the MPLS OAM Requirements draft in the near
>> future?  I can't speak for Dave, but I personally
>> am willing to wait a couple of weeks to a month
>> to add these so that the draft is complete.  Can we agree
>> that if we don't get any say by January 15, then there
>> will be none?
>
> That's daft.
>
> The fact that no-one supplies any OAM requirements for P2MP before 
> January
> 15 doesn't mean there aren't any. It means that no-one has supplied 
> them.

	Well, you have to draw a line in the sand at some time,
don't you?

> If the P2MP Sig Req draft is to refer to the MPLS OAM draft (as you
> desire) then it must clearly be done only because the MPLS OAM draft
> contains an adequate statement of the requirements. The choice is:
> a. Do everything necessary to ensure that the MPLS OAM draft includes 
> the
>     P2MP OAM requirements
> b. Put the P2MP OAM requirements in a separate draft.
>
>>> Can you point up what your objections to the text are. For reference,
>>> here is the text...
>>>
>>> 4.18 P2MP MPLS OAM
>>>
>>>    Management of P2MP LSPs is as important as the management of P2P
>>>    LSPs.
>>>
>>>    The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE
>>>    LSP management.
>>>
>>>    In order to facilitate correct management, P2MP TE LSPs MUST have
>>>    unique identifiers.
>>
>> I don't see why the second or third sentences need to be a MUST,
>> especially since they have no corresponding justification.
>
> So, if we supply a justification we're in the clear?
> The justification for the former is simple - the routing area requires
> that MIB modules are prepared for all signaling protocols and 
> extensions.
> The second point is also simple; for how can you manage something if 
> you
> cannot identify it uniquely?
>
> Nevertheless, these paragraphs could happily be subsumed into another
> document describing the requirements for P2MP OAM.
>
>>>    OAM facilities will have special demands in P2MP environments
>>>    especially within the context of tracing the paths and 
>>> connectivity
>>>    of P2MP TE LSPs. The precise requirements and mechanisms for OAM
> are
>>>    out of the scope of this document. It is expected that a separate
>>>    document will cover these requirements.
>>
>> This sentence seems to indicate that precise OAM requirements
>> are out of the scope of this document -- so why then do the preceding
>> two sentences provide requirements for OAM for p2mp TE LSPs?! Based
>> on this, the preceding two sentences should be removed from this
>> document and put into a place where there are in the scope of the
>> document (i.e.: MPLS OAM Requirements). :P
>
> So put them in the MPLS OAM Requirements and then Seisho can remove 
> them
> from here.

	I am okay with that as long as we don't delay the OAM
requirements draft any longer than is necessary to capture
the p2mp requirements.

	--Tom

>
> A
>

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls