Re: [trill] cc in "draft-ietf-trill-oam-framework-00"

["Samer Salam (ssalam)" <[e-mail]>]

Hi Xuehui,

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 27, 2012 7:41 PM
To: "Samer Salam (ssalam)" <[e-mail]<mailto:[e-mail]>>, "Tissa Senevirathne (tsenevir)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: cc in "draft-ietf-trill-oam-framework-00"


Hi, all trill-oam-framework authors

I have some troubles on understanding cc function described in section 4.1.1 in draft-ietf-trill-oam-framework-00, wish you can help me for more clear understanding.

1. 4.1.1<http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00#section-4.1.1> Fault Detection (Continuity Check)
".....
The proactive fault detection function must detect the following
  types of defects:

  - Loss of continuity (LoC) to one or more remote MEPs
  - Unexpected connectivity between isolated VLANs (mismerge)
  - Unexpected connectivity to one or more remote MEPs
  - Period mis-configuration"

In my mind, maybe the sencond and third types of  defects should be defects detected by CV ?

The reason for having these functions part of CC as opposed to CV is primarily to allow for continuous checking of these defects, as they may be introduced at any point of time in the life-span of a live network, due to nodes being commissioned/ de-commissioned or VLANs being added/deleted. As long as these types of issues are being monitored by CC, the operator will be assured that there is pro-active detection, as opposed to only knowing of the issues when a user complains.


2. 4.1.2.1<http://tools.ietf.org/html/draft-ietf-trill-oam-framework-00#section-4.1.2.1> Forward Defect Indication

"......
a simple network comprising of four RBridges connected in tandem: RB1, RB2, RB3 and RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and RB3 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a forward defect indication towards RB1 while RB3 sends a forward defect indication towards RB4......"

my question is how to detect the link faliure between RB2 and RB3 , through TRILL oam? such as one hop TRILL BFD?

The link failure may be detected through a number of mechanisms:


  *   By observing the line-protocol state going down on the link.
  *   Through some link OAM mechanism such as 802.3 clause 57
  *   Through TRILL BFD as you indicated


3.Does CC should be supported on sections? if it is, how the ingress and egress nickname be set? the same as CV on sections( see the last paragraph in section 4.2.1.1 in trill-oam-framework)?

Per draft-ietf-trill-oam-req-04 section 4.3, this is a SHOULD requirement. One way to support this, as you mention, is to follow the same nickname scheme as CV on sections.

Regards,
Samer



please correct me if I have some misunderstanding :)


Best Regards,
xuehui