Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

From: David Allan I <[email-masked]>
Date: Tue, 3 Jan 2012 17:48:35 -0500

HI Chao:

Some answers in line...

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chao Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To: [email-masked]
Subject: [mpls] Some doubts in RFC 6371 and RFC 6428

Hi all,

I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who can help me to clarify them? Thanks a lot!

1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect:
   If proactive CC-V OAM packets are received with the expected globally
   unique Source MEP identifier but with a transmission period different
   than the locally configured reception period, then a CC-V period
   misconfiguration defect is detected.
   o  Entry criteria: A MEP receives a CC-V proactive packet with the
      expected globally unique Source MEP identifier but with a
      transmission period different than its own CC-V-configured
      transmission period.

   My doubt: It is said to compare with the locally configured reception period in the definition, but in the Entry criteria, it is compared with it own CC-V-configured transmission period. Are they same? Just because these two values should be same? For LOC in 5.1.1.1, it also uses the receiving MEP's configured CC-V reception period.
   And such Period Misconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? Why it is not in RFC 6428?

The short story is that a mismatch is a problem  but not one that many felt tearing the service down or forcing a protection switch was a suitable consequent action. It does not indicate an impairment in information transfer capability, just in the ability to measure it. Hence flag it northbound and presumably offline action would bring the OAM back into spec. Now as for an implementation explicitly modifying the periodicity to an unacceptable value, how the other end reacts is implementation or policy dependant.

Part of this is a consequence of beleiving that some of the BFD handshaking could be dispensed with at the time 6371 was written. That view changed after the BFD WG did a thorough review of what became 6428.

 2. In 5.1.2 of RFC 6371:
   If a MEP detects a LOC defect that is not caused by a period
   misconfiguration, it should block all the traffic (including also the
   user data packets) that it receives from the transport path, if this
   consequent action has been enabled by the operator.

   My doubt: Does it mean the period misconfiguration should or might cause the LOC? Will the packets be discarded? If not, there should not be LOC. My opinion is that the period misconfiguration should not cause LOC.

There could be a corner cases if without any warning one end reduced the periodicity of CC/CV to less than 1/3 of the expected rate so that one got an LOC. Once a lower rate BFD PDU was received that advertised the changed rate, the receiver could adapt vs. staying in a defect state.

3. In 5.1.3 of RFC 6371:
   Note that the reception period is the same as the configured transmission rate.

   My doubt: Does it mean no need to configure reception period? But many places mention "configured reception period", do they mean the configured transmission rate?

 A configured reception rate would be an expected rate which IMO would be optional. Again an artifact of the original expectation of no handshaking between the MEPs in establishing a session periodicity and configuration would be the only way such agreement would happen.

 4. In 3.7.3 of RFC 6428:
  It will also communicate session DOWN to its session peer using CC messages.

  My doubt: Does it mean only notify the peer to bring the session DOWN but the local session will not be DOWN? Or we should bring the local session DOWN also? But it is not in the BFD State machine of Figure 7.

It is telling it's peer that it has taken the session into the down state at it's end.

So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local inputs to the state machine that will transition it from UP to DOWN.

Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from UP to DOWN in coordinated session operation.

 5.  In 3.7.1 of RFC 6428: Session Initiation and Modification

   Session initiation occurs starting from MinRx = 1 second, MinTx >= 1
   second, and the detect multiplier = 3.

   Once in the UP state, Poll/Final discipline is used to modify the
   periodicity of control message exchange from their default rates to
   the desired rates and to set the detect multiplier to 3.

   My doubt: Does it mean the BFD session will not be started with the configured values but use the default values? What the values will be filled in the packet? The default ones or the configured values?
   Why need P/F here? There is no timer negotiation. I think here the configured transmission rates should be same on both Engpoints, otherwise there are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371.

 P/F is needed as examination of any other slow start mechanism revealed that we would have to reinvent what we already had. So there is a handshake to get from the default to the desired rate.

I hope this helps

Dave

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 4 Jan 2012 08:55:59 +0200

Dave, Chao and all,

It looks like Chao has discovered multiple technical inconsistencies between 6371 (Informational)  and 6428 (Standards Track)  - and that in spite of just two months between their publication dates (09/11 vs. 11/11)

This is not completely unexpected for those who have closely followed the MPLS-TP story, but does not sound well for the beginner readers/new implementers.

IMHO and FWIW the least we could do is to file appropriate technical Errata on 6371 for each of these inconsistencies (starting from ones identified by Chao and adding new ones as we discover them).

It is also worth considering 6371bis (provided we find volunteers for this job:-) in order to align the framework with the MPLS-TP reality.

My 2c,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of David Allan I [[email-masked]]
Sent: Wednesday, January 04, 2012 12:48 AM
To: Chao Fu; [email-masked]
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

HI Chao:

Some answers in line...

Hi all,

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 4 Jan 2012 15:08:54 -0500

Dear Dave, Chao, et al.
I think that an BFD peer would not be "suddenly" change frequency of CC messages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to change timers via AdminDown state. Secondly, even if operator prefers this operation to be more BFD-ish, it will work through P/F sequence and old frequency should be used until remote peer acknowledges the change with F bit in its CC packet.

I'd note that RFC 6428 addresses CC-CV while pure CC mode of MPLS-TP OAM is, as I understand, is per RFC 5884/5885.

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, January 03, 2012 2:49 PM
To: Chao Fu; [email-masked]
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

HI Chao:

Some answers in line...

Hi all,

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

---

From: David Allan I <[email-masked]>
Date: Wed, 4 Jan 2012 17:13:19 -0500

Hi Greg:

I agree that a sudden change in frequency would not happen, and there is an actual discipline for doing so which 6428 does go into in some detail. A sudden actual change would be an interesting implementation bug.

However I think Sasha is correct in that an Errata to 6371 would clean up misconceptions, as much as my first reaction was that it was an informational step in a journey was a not fully defined end. I think the tweaks to address the first three points could be quite minor.

best
D

________________________________
From: Gregory Mirsky
Sent: Wednesday, January 04, 2012 12:09 PM
To: David Allan I; Chao Fu; [email-masked]
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Dear Dave, Chao, et al.

    Regards,
        Greg

HI Chao:

Some answers in line...

Hi all,

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 4 Jan 2012 17:35:48 -0500

Hi Dave, et al.,
I do agree that RFC 6371 might be in need of revision at some time. But I'm not sure that we're at that point already.
I've re-checked Section 5.1.1.3 Period Misconfiguration and it refers to period of CV message. My understanding that this period is fixed at 1 sec and since Detect Multiplier is 1 generation randomized within 0.75 - 0.9 range. So, we're talking not about Period Misconfiguration per se, but about wrong frequency of CV messages, message with unique MEP ID, as they are referenced in the RFC.

Hope I've interpreted the 5.1.1.3 correctly.

    Regards,
        Greg

________________________________
From: David Allan I
Sent: Wednesday, January 04, 2012 2:13 PM
To: Gregory Mirsky; Chao Fu; [email-masked]
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Hi Greg:

best
D

Dear Dave, Chao, et al.

    Regards,
        Greg

HI Chao:

Some answers in line...

Hi all,

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 5 Jan 2012 10:56:34 +0200

Dear Greg,
Lots of thanks for a prompt response.

You've said that "pure CC mode of MPLS-TP OAM is, as I understand, is per RFC 5884/5885".

I tend to disagree with statement on both counts.

RFC 5884<http://tools.ietf.org/html/rfc5884> in its Section 7 "Encapsulation" explicitly states:

   The BFD Control packet sent by the ingress LSR MUST be a UDP packet

   with a well-known destination port 3784 [BFD-IP<http://tools.ietf.org/html/rfc5884#ref-BFD-IP>] and a source port

   assigned by the sender as per the procedures in [BFD-IP<http://tools.ietf.org/html/rfc5884#ref-BFD-IP>].  The source

   IP address is a routable address of the sender.  The destination IP

   address MUST be randomly chosen from the 127/8 range for IPv4 and

   from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following

   exception.  If the FEC is an LDP IP FEC, the ingress LSR may discover

   multiple alternate paths to the egress LSR for this FEC using LSP

   Ping traceroute.  In this case, the destination IP address, used in a

   BFD session established for one such alternate path, is the address

   in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6

   discovered by LSP Ping traceroute [RFC4379<http://tools.ietf.org/html/rfc4379>] to exercise that

   particular alternate path.

I suspect that the highlighted text does not sit well with MPLS-TP with its emphasis on independence from IP.

RFC 5885 in the part that describes PW-ACH encapsulation for the BFD control packets (without IP/UDP headers) could be easily reused in RFC 6428.
However, these documents have defined different ACH types for BFD packets:

*         RFC 5885 uses type 0x0007 for CC

*         RFC 6428 uses type 0x0022 for CC.

Taking into account that PWs are supposed to be part of MPLS-TP, this looks a bit fishy to me, but I am not sure what could be done about that.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Wednesday, January 04, 2012 10:09 PM
To: David Allan I; Chao Fu; [email-masked]
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

Dear Dave, Chao, et al.

    Regards,
        Greg

Some answers in line...

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 5 Jan 2012 11:35:42 +0200

Dear Greg,

I've followed your example and checked Section 5.1.1.3 "Period Misconfiguration Defect" in RFC 6371<http://datatracker.ietf.org/doc/rfc6371/?include_text=1>, and I disagree with your reading..

First of all, this document does not distinguish between Connectivity Check (CC) and Connectivity Verification (CV). It almost explicitly assumes that the same packet is used for both purposes - at least when we speak about proactive CC and CV (because" CC packets" are not mentioned  in the text, and "CV packets" are always mentioned as "on-demand CV -packets"). And, in particular, Section 5.1.1.3 refers to "CC-V packets" with CC-V standing for "Connectivity Check and Connectivity Verification" in the Terminology section.

When it comes to the Period Misconfiguration defect, IMHO the text in RFC 6371 admits at least two readings:

1.       Transmission period is encoded in the CC-V packets, and the receiver compares the received value with its configured one. This reading matches the definition of the Unexpected Period defect in  Annex I.5 of ITU-T Y.1731 (02/08) and is trivial to implement

2.       The receiver of CC-V messages evaluates the actual transmission period of CC-V messages and compares it with the configured value.  I cannot say that such a reading strictly contradicts 6371, but it leaves multiple open questions, e.g.:

a.       How do you evaluate the transmission period? The receiver has to somehow eliminate the PDV effects, and the estimate may depend on the specific elimination method and its parameters

b.      How do you compare the estimated actual transmission period with the configured one? This requires definition of some limits of tolerance etc.
Taking into account the history of MPLS-TP, I'd say that the first reading above looks like matching the intention of the authors/Editors.

My 2c,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Thursday, January 05, 2012 12:36 AM
To: David Allan I; Chao Fu; [email-masked]
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

Hi Dave, et al.,

    Regards,
        Greg

best
D

    Regards,
        Greg

Some answers in line...

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 5 Jan 2012 13:33:04 -0500

Dear Sasha,
your analysis is thorough as always. I hope Editors will provide their opinions. In the meantime I'll note that in explaining entry and exit conditions for the Period Misconfiguration Defect text is explititly calls for "expected globally unique Source MEP identifier" which to me is implicit reference to MPLS-TP CV message as it is defined in the Section 3.5 of the RFC 6428. AFAIK, CC message does not include MEP ID and I've concluded that the Period Misconfiguration Defect is not applicable to CCs.

    Regards,
        Greg

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Thursday, January 05, 2012 1:36 AM
To: Gregory Mirsky
Cc: David Allan I; Chao Fu; [email-masked]
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Dear Greg,

My 2c,
     Sasha

Hi Dave, et al.,

    Regards,
        Greg

best
D

    Regards,
        Greg

Some answers in line...

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 5 Jan 2012 20:51:32 +0200

Dear Greg,

I would also be happy to hear the Editors' position on the ambiguous issue - Dave and  Italo, could you please comment?

Regarding presence of the globally unique Source MEP identifier in the CC or CV messages - I suspect that this is just one more case of inconsistency between 6371 (which, IMHO, has been strongly associated with Y.1731) and 6428... should we file one more Errata on that?

My 2c,
     Sasha

________________________________
From: Gregory Mirsky [[email-masked]]
Sent: Thursday, January 05, 2012 8:33 PM
To: Alexander Vainshtein
Cc: David Allan I; Chao Fu; [email-masked]
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Dear Sasha,

    Regards,
        Greg

Dear Greg,

I’ve followed your example and checked Section 5.1.1.3 “Period Misconfiguration Defect” in RFC 6371<http://datatracker.ietf.org/doc/rfc6371/?include_text=1>, and I disagree with your reading..

First of all, this document does not distinguish between Connectivity Check (CC) and Connectivity Verification (CV). It almost explicitly assumes that the same packet is used for both purposes – at least when we speak about proactive CC and CV (because” CC packets” are not mentioned  in the text, and “CV packets” are always mentioned as “on-demand CV –packets”). And, in particular, Section 5.1.1.3 refers to “CC-V packets” with CC-V standing for “Connectivity Check and Connectivity Verification” in the Terminology section.

b.      How do you compare the estimated actual transmission period with the configured one? This requires definition of some limits of tolerance etc.
Taking into account the history of MPLS-TP, I’d say that the first reading above looks like matching the intention of the authors/Editors.

My 2c,
     Sasha

Hi Dave, et al.,

    Regards,
        Greg

best
D

    Regards,
        Greg

Some answers in line...

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 5 Jan 2012 14:34:17 -0500

Dear Sasha,
immenesly appreciate your input.
My statement in question was based on my interpretation of Section 3.1 of the RFC 6428.
The very first paragraph suggests that CC-only mode of MPLS-TP OAM may be supported "via protocols and procedures described in RFC 5885<http://tools.ietf.org/html/rfc5885> [7<http://tools.ietf.org/html/rfc6428#ref-7>] with ACH channel 7".
And the second paragraph outlines interoperation with the RFC 5884, i.e. IP/UDP encapsulation of BFD over LSP/PW.

    Regards,
        Greg

Sent: Thursday, January 05, 2012 12:57 AM

Dear Greg,

Regards,
     Sasha

Dear Dave, Chao, et al.

    Regards,
        Greg

Some answers in line...

 2. In 5.1.2 of RFC 6371:

3. In 5.1.3 of RFC 6371:

 4. In 3.7.3 of RFC 6428:

I hope this helps

Dave

---

From: Chao Fu <[email-masked]>
Date: Fri, 6 Jan 2012 13:05:05 +0800

Hi Dave,

Thank you very for your response.

For the first point, I just wonder that we use "*configured reception
period"  *or * "configured transmission period" *to get the Period
Misconfiguration Defect. And I think it is not clear in RFC 6371 on the
usage of *configured reception period.*

For the fourth point "4. In 3.7.3 of RFC 6428", just because there is
Period Misconfiguration Defect in RFC 6371, and if the defect is introduced
into RFC 6428 also, then it will bring the local BFD session state down.
But I don't think it is necessary.

For the fifth point " 5.  In 3.7.1 of RFC 6428: Session Initiation and
Modification": Does it mean the P/F is used here just because the slow
start mechanism? Is the P/F used to avoid LOC defect when the transmission
interval misconfiguration?  I think the P/F is useful only when the
transmission intervals can be different on both endpoints, and there can be
different LOC detection timers. Otherwise it is useless if the
mis-configuration defect of RFC6371 has come when we initialize the BFD
session. Is my understanding correct? Thanks!

Regards

Chao Fu

2012/1/4 David Allan I <[email-masked]>

> **
> HI Chao:
>
> Some answers in line...
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Chao Fu
> *Sent:* Wednesday, December 28, 2011 6:51 PM
> *To:* [email-masked]
> *Subject:* [mpls] Some doubts in RFC 6371 and RFC 6428
>
>  Hi all,
>
> I have some doubts on RFC 6371 "OAM Framework for MPLS-Based Transport"
> and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who can help me to clarify
> them? Thanks a lot!
>
>    My doubt:* It is said to compare with the locally configured reception
> period in the definition, but in the Entry criteria, it is compared with it
> own CC-V-configured transmission period. Are they same? Just because these
> two values should be same? For LOC in 5.1.1.1, it also uses the receiving
> MEP's configured CC-V reception period.*
> *   And such Period Misconfiguration Defect is not defined in RFC 6428.
> Does MPLS TP need it? Why it is not in RFC 6428?*
>
>
> The short story is that a mismatch is a problem  but not one that many
> felt tearing the service down or forcing a protection switch was a suitable
> consequent action. It does not indicate an impairment in information
> transfer capability, just in the ability to measure it. Hence flag it
> northbound and presumably offline action would bring the OAM back into
> spec. Now as for an implementation explicitly modifying the periodicity to
> an unacceptable value, how the other end reacts is implementation or policy
> dependant.
>
> Part of this is a consequence of beleiving that some of the BFD
> handshaking could be dispensed with at the time 6371 was written. That view
> changed after the BFD WG did a thorough review of what became 6428.
>
>  2. In 5.1.2 of RFC 6371:
>    *My doubt: Does it mean the period misconfiguration should or might
> cause the LOC? Will the packets be discarded? If not, there should not be
> LOC. My opinion is that the period misconfiguration should not cause LOC.
> *
>
> There could be a corner cases if without any warning one end reduced the
> periodicity of CC/CV to less than 1/3 of the expected rate so that one got
> an LOC. Once a lower rate BFD PDU was received that advertised the changed
> rate, the receiver could adapt vs. staying in a defect state.
>
>
> 3. In 5.1.3 of RFC 6371:
>    *My doubt: Does it mean no need to configure reception period? But
> many places mention "configured reception period", do they mean the
> configured transmission rate?*
> *
> * A configured reception rate would be an expected rate which IMO would
> be optional. Again an artifact of the original expectation of no
> handshaking between the MEPs in establishing a session periodicity and
> configuration would be the only way such agreement would happen.
>
>  4. In 3.7.3 of RFC 6428:
>   *My doubt: **Does it mean only notify the peer to bring the session
> DOWN but the local session will not be DOWN? Or we should bring the local
> session DOWN also? But it is not in the BFD State machine of Figure 7.
>  *
> So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are
> local inputs to the state machine that will transition it from UP to DOWN.
>
> Receiving ADMIN DOWN or DOWN from a peer will also cause a transition from
> UP to DOWN in coordinated session operation.
>
>    *My doubt: Does it mean the BFD session will not be started with the
> configured values but use the default values? What the values will be
> filled in the packet? The default ones or the configured values?
>    Why need P/F here? There is no timer negotiation. I think here the
> configured transmission rates should be same on both Engpoints, otherwise
> there are Period Misconfiguration Defects defined in 5.1.1.3 of RFC 6371.
>
> * P/F is needed as examination of any other slow start mechanism revealed
> that we would have to reinvent what we already had. So there is a handshake
> to get from the default to the desired rate.
>
> I hope this helps
>
> Dave
>
>

-- 
Regards
Chao Fu