Subject: Re: [Mpls-interop] FW: Comment on MPLS-TP OAM Reqs document

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Apr 2009 23:53:46 +0100

Yaacov,

Apologies for not responding sooner.

I think we are debating semantics to some extent but in my opinion there is
a slight difference.

What I am saying is essentially:

If IP routing or forwarding is present they MUST be used
If they are not present then other mechanisms can be used

Which I view as slightly stronger than just saying SHOULD NOT preclude IP
routing & forwarding being used.

Ben

On 07/04/2009 06:07, "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
<[email-masked]> wrote:

> Ben, hi
> 
> In principle, I agree with you but what you are saying seems to be a
> SHOULD requirement rather than a MUST! (Which I guess states it more
> clearly than my original comment:-)
> 
> Thanx for the comment,
> Yaacov
> 
> PS this will not reach the MEAD team unless you forward it to them!
> 
> -----Original Message-----
> From: ext Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Tuesday, April 07, 2009 02:19
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); IETF MEAD team
> Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> Subject: Re: [Mpls-interop] FW: Comment on MPLS-TP OAM Reqs document
> 
> Couple of opinions to a couple of the comments
> 
>       In some environments (e.g., IP/MPLS environments), IP routing and
>       forwarding capabilities are inherently present. In this case, the
>       OAM functionality MUST support the use of IP routing and
>       forwarding capabilities.
> 
> YW comment: Why is this a MUST support - I was always under the
> impression
> that they Should NOT preclude IP forwarding, but this seems to say that
> it
> must use the IP Forwarding if the network supports it!
> 
> BN: I can see your point. However, if the network supports IP forwarding
> why
> would one want to use something else?
> 
> Really the "MUST not preclude IP forwarding" statement is about saying
> "Please don't run off and invent something that fits nicely in
> traditional
> transport land but precludes all of us in data land from reusing it as
> well
> without deploying some additional networking/forwarding/routing
> protocol"
> 
> I would like to think we are all agreed that the future for DCNs
> ("transport" and "data") is IP. In the transport world we are not there
> yet
> although it is the direction I perceive everyone is trying to head
> (certainly in BT it is the direction we are heading). Therefore it seems
> reasonable to me that if the transport network under consideration
> already
> supports IP forwarding/routing then the OAM for that network MUST
> support IP
> routing/forwarding capabilities. That is not to say the OAM can't also
> support other routing/forwarding capabilities.
> 
> 
> On 06/04/2009 14:37, "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
> <[email-masked]> wrote:
> 
>> Hi,
>> Please find below the comments Yaacov sent to the authors of the
> MPLS-TP
>> OAM requirements.
>> Best regards,
>> Nurit
>> 
>> _____________________________________________
>> From: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>> Sent: Sunday, April 05, 2009 9:59 AM
>> To: VIGOUREUX MARTIN; [email-masked]; [email-masked]
>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson;
>> [email-masked]
>> Subject: Comments on MPLS-TP OAM Reqs document
>> 
>> Hi,
>> 
>> Attached is a commented version of the latest MPLS-TP OAM requirements
>> documented.  In order to update the OAM Analysis and align it with the
>> latest version of the OAM requirements it would be helpful if you
> could
>> address these comments, expeditiously!  Thanx for your help in this
>> matter.
>>  <<draft-ietf-mpls-tp-oam-requirements-01-commented.doc>>
>> 
>> Best regards,
>>  
>> Yaacov Weingarten
>> Industry Environment, Carrier Ethernet
>> Nokia Siemens Networks
>> Hod Hasharon, Israel 45241
>> Tel: +972-9-775 1827
>> Mob: +972-54-220 0977
>> 
>> _______________________________________________
>> Mpls-interop mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls-interop
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Apr 2009 23:57:30 +0100

Yaacov,

On 07/04/2009 06:02, "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
<[email-masked]> wrote:

> Ben, hi
> 
> My question was merely the following - the requirement states that the
> option "MUST be disabled".  Therefore, in order for this to be useful
> for someone then there should be some way of enabling the option.  Is
> this only through use of a control or management tool or should there be
> an option to enable directly through some hook?  A statement about this
> (even not as a formal requirement) would be nice, IMHO.

OK I see what you're saying. By implication if something is disabled by
default then there needs to be a mechanism to enable it.

Personally I do not feel that needs to be explicitly stated but if you feel
it should be then I have no objections to that.

Ben

> 
> Thanx for the comments,
> Yaacov
> 
> PS - this will not reach the MEAD team unless you send it to them!
> 
> Sent: Tuesday, April 07, 2009 02:25
> To: Benjamin Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod HaSharon);
> IETF MEAD team
> So I have my keyboard shortcuts muddled and sent instead of pasted -
> D'Oh.
> 
> My second comment to Yaacov's comments
> 
>    The design of OAM mechanisms, for MPLS-TP, MUST support the ability
> to
>    use vendor specific and experimental OAM functions.  These
>    functions MUST be disabled by default.
> 
> YW comment: Question for clarification - at what level is it enabled
> (shouldn't we state that enabling does not require a management or
> control
> plane?)
> 
> BN: I am not sure really what you are asking? Is it that such vendor
> specific/experimental OAM should be allowed to be enabled via the device
> CLI? If so then the answer is yes (IMO CLI is a [degenerate] form of
> management plane)
> 
> Ben
> 
> On 07/04/2009 00:19, "Benjamin Niven-Jenkins"
> <[email-masked]> wrote:
> 
>> that they Should NOT preclude IP forwarding, but this seems to say
> that it
>> BN: I can see your point. However, if the network supports IP
> forwarding why
>> ("transport" and "data") is IP. In the transport world we are not
> there yet