Subject: Re: [mpls] [mpls-tp] mpls wg last callondraft-ietf-mpls-tp-cc-cv-rdi-03

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 17 Feb 2011 10:42:23 -0500

Hi,

W.r.t ITU standard, Mismerge and Unexpected MEP are identified as follows,

If a CCM frame with same MEG Level but with a MEG ID different than the
receiving MEP’s own MEG ID is
received, *Mismerge* is detected.

• If a CCM frame with the same MEG Level and a correct MEG ID but with an
incorrect MEP ID, including
receiving MEP’s own MEP ID, is received, *Unexpected MEP* is detected.

I think, the authors should clearly differentiate the unexpected MEP and
Mismerge defects in the MPLS-TP OAM?

-- 
BR,
Venkat.

Hi Feng:

I'm not sure how unexpected MEP is not indicative of a mismerge.
Either the source MEP ID has been misconfigured, or you are receiving
a message from a MEP due to LIB corruption or similar defect somewhere
in the network.

As for your second point, it is not that negotiation is not used,
there is simply no give and take allowed, so the procedures are simply
modified slightly in the TP case . If the far end refuses to support
the requested periodicity for whatever reason, you do not progress
beyond the INIT state and presumably send some indication to
management that the session could not come "UP". You have that option
whether you are conformant to CC-CV-RDI draft or simply RFC 5884. So
as far as I can tell interoperability options exist, they were always
there in the protocol, we are simply providing implementation
guidelines for the TP application...

I hope this helps
Dave

----- Original Message -----
From: HUANG Feng F
[mailto:[email-masked]<https://inowa.aricent.com/owa/redir.aspx?C=85c311909efa463381c5914b036b0942&URL=mailto%3aFeng.f.Huang%40alcatel-sbell.com.cn>
]
Sent: Thursday, February 17, 2011 11:57 AM
To: David Allan I <[email-masked]>; MPLS TP; [email-masked] <
[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [mpls-tp] [mpls] mpls wg last
callondraft-ietf-mpls-tp-cc-cv-rdi-03

Hi,Dave,
     Thanks, LSP MEP ID in draft-ietf-mpls-tp-identifiers-03 is:
Node_ID::Tunnel_Num::LSP_Num,

and for LSP MEG ID: (7.1.2.1.)
    Since a MEG pertains to a single MPLS-TP LSP, IP compatible MEG_IDs
   for MPLS-TP LSPs are simply the corresponding LSP_IDs.  We note that
   while the two identifiers are syntactically identical, they have
   different semantics.  This semantic difference needs to be made
   clear.  For instance if both a MPLS-TP LSP_ID and MPLS-TP LSP MEG_IDs
   are to be encoded in TLVs different types need to be assigned for
   these two identifiers.

you can only detect wrong MEP ID, that's Unexpected MEP, it is not
Mis-merge.

If period negotiation is not used, how to insure interoperability with BFD
used in IP/MPLS asked always by providers?

B.R.
Feng

-----Original Message-----
From: David Allan I
[mailto:[email-masked]<https://inowa.aricent.com/owa/redir.aspx?C=85c311909efa463381c5914b036b0942&URL=mailto%3adavid.i.allan%40ericsson.com>
]
Sent: 2011年2月17日 0:51
To: HUANG Feng F; [email-masked]; [email-masked]; [email-masked]
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls wg last
callondraft-ietf-mpls-tp-cc-cv-rdi-03

HI Feng:

See section 7.1 of
http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-03<https://inowa.aricent.com/owa/redir.aspx?C=85c311909efa463381c5914b036b0942&URL=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-mpls-tp-identifiers-03>
 . IMO it is simply a terminology issue as to whether a MEG is encoded in
the LSP and PW formats or not.

Section 3.5.1 of the CC-CV-BFD draft identifies that period negotiation is
not used. So unexpected period occurs when one end unpexpectedly changes the
period advertised.

I hope this helps
Dave

-----Original Message-----
From: HUANG Feng F
[mailto:[email-masked]<https://inowa.aricent.com/owa/redir.aspx?C=85c311909efa463381c5914b036b0942&URL=mailto%3aFeng.f.Huang%40alcatel-sbell.com.cn>
]
Sent: Wednesday, February 16, 2011 5:43 PM
To: David Allan I; [email-masked]; [email-masked]; [email-masked]
Cc: Loa Andersson
Subject: RE: [mpls] [mpls-tp] mpls wg last callon
draft-ietf-mpls-tp-cc-cv-rdi-03

 Dear Dave,
     In 3.3. MPLS BFD proactive CV Message format, LSP/PW MEP ID is defined
without MEG, how to detect Mismerge?
     And BFD protocol is enabled for period negotiation, when period is
different, lower one is used, then how to detection Uexpect period?
B.R.
Feng

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]<https://inowa.aricent.com/owa/redir.aspx?C=85c311909efa463381c5914b036b0942&URL=mailto%3ampls-bounces%40ietf.org>]
On Behalf Of David Allan I
Sent: 2011年2月11日 18:12
To: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] [mpls-tp] mpls wg last callon
draft-ietf-mpls-tp-cc-cv-rdi-03

OK, will do...

Dave

-----Original Message-----
From: Mach Chen
[mailto:[email-masked]<https://inowa.aricent.com/owa/redir.aspx?C=85c311909efa463381c5914b036b0942&URL=mailto%3amach%40huawei.com>
]
Sent: Friday, February 11, 2011 12:12 AM
To: David Allan I; 'Loa Andersson'; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [mpls] [mpls-tp] mpls wg last call on
draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Dave,

Thanks for your prompt response!

> >3 Section 3.5.2
> >" 4. Receipt of an expected session discriminator with an unexpected
label
> (mis-connectivity defect).", For a receiver, how does it know that the
> session >discriminator is valid but the label is invalid? IMHO, this
defect is just
> another description of defect 3 . Suggest to remove it.
>
> If the session discriminator exists in the BFD database, it is
superficially a valid
> descriminator but the label of arrival can be incorrect. This may
> indicate
an
> implementation problem at the source MEP. What we were referring to in '3'
> was a session discriminator that did not exist in the local database,
> BFD
had
> never handed it out hence it could not be found.
>

OK, but more clarification text would be helpful.

Best regards,
Mach