Subject: [mpls-tp] R: WG Last call on draft-ietf-mpls-tp-oam-framework-08.txt

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Sat, 2 Oct 2010 17:25:27 +0200

Yuji,

Regarding your comment 2:

> 2) If a different encapsulation of period field is detected,
> isn't section 5.1.1.3 applied?
> I.e. It should be described the detect in 5.1.1.3 must
> be prioir to this 5.1.1.4.

You are correct: if an incorrect period value is received section 5.1.1.3 applies.

However, I think that in the case a CC-V packet with a correct source MEP ID but wrong transmission period and wrong encapsulation, it is worth raising both warnings for period misconfiguration and unexpected encapsulation so the operator can fix both problems.

What do you think?

Thanks, Italo

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto
> di Yuji Tochio
> Inviato: martedì 28 settembre 2010 9.17
> A: [email-masked]
> Oggetto: Re: [mpls-tp] WG Last call on draft-ietf-mpls-tp-oam-framework-
> 08.txt
> 
> Hi
> 
> Some comments on sec 5.1.1.4 that is new since version 08.
> 
> 
> 1) First sentense:
> If pro-active CC-V OAM packets are received with a correct globally
> unique Source MEP identifier but with an encapsulation,
> 
> Should this be as following?
> ... but with an *unexpected* encapsulation,
> 
> 2) If a different encapsulation of period field is detected,
> isn't section 5.1.1.3 applied?
> I.e. It should be described the detect in 5.1.1.3 must
> be prioir to this 5.1.1.4.
> 
> 3) What kind of defect is this for if detected?
> Is this a new or another version of dLOC? or same as it?
> 
> 4)
> I cannot understand the paragraph of "It should be noted that..."
> The essense, I think, of this section is that this defect does not
> impact on misconnectivity, but different encapsulation from
> that as configured.
> So It should be that the essense I wrote above put at the
> first of this section, i.e. some text in this paragraph should be
> put at the first of this section
> 
> ... And if editors are worring about OAM frames are gone before
> processing, this warning notes should be put at the 5.1.1.1 since
> this is the matter of LOC rather than this section.
> 
> 5)
> What would be the consequent action for this?
> Is this expected to block the traffic?
> (Overall, the description of consequent actions for defect in
> 5.1 seems to be lack...)
> 
> Regards,
> Yuji
> 
> 
> Loa Andersson wrote:
> > All,
> >
> > this is to start a further one week final working group last call on
> > draft-ietf-mpls-tp-oam-framework-08.txt
> >
> > The document has been updated to address the comments received during
> > the previous last call
> >
> > Please note that the purpose of this working group last call is
> > only to verify that comments from the previous working group last call
> > have been correctly addressed.
> >
> > The authors have been instructed to post a note to the mailing list
> > outlining what comments were raised and how they have addressed them.
> >
> > Please note that even though the document is Informational and not
> > implementable per se we have a very late IPR disclosure (arrived after
> > the previous wg last call):
> >
> > https://datatracker.ietf.org/ipr/1369/
> >
> > The terms cited are RAND and do not include the mutual free terms seen
> > in other IPR disclosures.
> >
> > It might be that in cases where the framework indicates the use of
> > a particular technology, then any solutions document conforming to
> > the framework would be at risk from the IPR.
> >
> > Please send your comments to the [email-masked] mailing list.
> >
> > This working group last call ends Sep 28th.
> >
> > Loa and George
> >
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 2 Oct 2010 16:38:35 +0100

I'd go with Italo on this.

It is very frustrating to chase a sequence of alarms. Much better to raise 
as many as possible at once.

A
----- Original Message ----- 
From: "BUSI, ITALO (ITALO)" <[email-masked]>
To: "Yuji Tochio" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, October 02, 2010 4:25 PM
Subject: [mpls-tp] R: WG Last call on 

Yuji,

> be prioir to this 5.1.1.4.

You are correct: if an incorrect period value is received section 5.1.1.3 
applies.

However, I think that in the case a CC-V packet with a correct source MEP ID 
but wrong transmission period and wrong encapsulation, it is worth raising 
both warnings for period misconfiguration and unexpected encapsulation so 
the operator can fix both problems.

What do you think?

Thanks, Italo

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 03 Oct 2010 11:43:19 +0200

Hello Italo,

You wrote:

> However, I think that in the case a CC-V packet with a correct
 > source MEP ID but wrong transmission period and wrong encapsulation,
 > it is worth raising both warnings for period misconfiguration
 > and unexpected encapsulation so the operator can fix both problems.

I get the impression that it is required to verify *ALL* possible
CC/CV defects (5.1.1.1, 5.1.1.2, 5.1.1.3 *AND* 5.1.1.4) before
reporting them.
Wouldn't it be more efficient to stop the verification as soon
as *ONE* of the defects is detected?

I.e. change in 5.1.1 the text:
"For all of the described defect cases, the sink MEP
  should notify the equipment fault management process
  of the detected defect."
into:
"For any (one or more) of the described defect cases,
  the sink MEP should notify the equipment fault management
  process of the detected defect."

In addition: is the order of verification implied by the order
of sections 5.1.1.1, 5.1.1.2, 5.1.1.3 and 5.1.1.4 mandatory or
are the defect conditions described in no specific order?

If it is the latter the following text could be added to 5.1.1:
"The defect conditions are described in no specific order"

Best regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: <[email-masked]>
Date: Mon, 4 Oct 2010 08:43:07 +0100

Just as an aside observation to this discussion......

This is illustrating quite nicely why you often hear me stating that the OAM for defect detection/handling needs to be as simple/sparse as possible.  Here we have 2 generic defect cases:
-	real misconnectivity failures of DP forwarding
-	self-inflicted misconfiguration failures of DP forwarding...due to having configurable options.

OAM used for defect detection/handling (which I differentiate from 'on-demand' investigative OAM) needs to be considerably more reliable than the intrinsic 'real' defect rate of the network DP constructs it is monitoring...so it needs to be as simple/sparse as we can make it.  One of the things this means is we need to minimise OAM configuration options.....and IMO strong opinion this also means do not use TCM techniques (I'll refrain from giving a long-list of the additional factors of why I and colleagues in BT hold this opinion).

regards, Neil

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: 03 October 2010 10:43
> To: BUSI, ITALO (ITALO)
> Cc: [email-masked]
> Subject: Re: [mpls-tp] R: WG Last call on 
> >> 2) If a different encapsulation of period field is detected, isn't 
> >> section 5.1.1.3 applied?
> >> I.e. It should be described the detect in 5.1.1.3 must be 
> prioir to 
> >> this 5.1.1.4.
> >
>  > source MEP ID but wrong transmission period and wrong 
> encapsulation,  > it is worth raising both warnings for 
> period misconfiguration  > and unexpected encapsulation so 
> I get the impression that it is required to verify *ALL* 
> possible CC/CV defects (5.1.1.1, 5.1.1.2, 5.1.1.3 *AND* 
> 5.1.1.4) before reporting them.
> Wouldn't it be more efficient to stop the verification as 
> soon as *ONE* of the defects is detected?
> 
> In addition: is the order of verification implied by the 
> order of sections 5.1.1.1, 5.1.1.2, 5.1.1.3 and 5.1.1.4 
> mandatory or are the defect conditions described in no specific order?
> 
> >> Da: [email-masked] [mailto:[email-masked]] Per 
> >> conto di Yuji Tochio
> >> Oggetto: Re: [mpls-tp] WG Last call on 
> >> draft-ietf-mpls-tp-oam-framework- 08.txt
> >>
> >> Hi
> >>
> >> 2) If a different encapsulation of period field is detected, isn't 
> >> section 5.1.1.3 applied?
> >> I.e. It should be described the detect in 5.1.1.3 must be 
> prioir to 
> >> this 5.1.1.4.
> >>
> >> impact on misconnectivity, but different encapsulation 
> from that as 
> >> configured.
> >> So It should be that the essense I wrote above put at the first of 
> >> this section, i.e. some text in this paragraph should be 
> put at the 
> >> first of this section
> >>