Thanks & R= egards,

Hi Malcolm and Huub,

I have squeezed a little time from the current ITU-T meeting to look at
your

draft and write-up. I have also read the email threads on the IETF discussion

list and the MPLS list. Sorry that this has taken me a week to process,
but your

publication request came at pretty much the worst possible time for getting
me

to do this task.

I don't like proliferating threads across multiple mailing lists. On the
other

hand it is difficult to ensure that all the constituencies are present,
so I am

perpetuating the cross-posting.

My review of the document...

1. idnits (
http://www.ietf.org/tools/idnits/
)
shows a couple of nits. I think

only one of these is real (the spurious space in a citation). The other
nits are

spurious caused by citations wrapping across lines. Could you please keep
a note

of the nit so that you can fix it the next time the draft is respun or
so it can

be captured in an RFC Editor Note at a later stage (you don't have to post
a new

revision to address this now unless you really want to).

2. This document requests a code point from a registry that contains code
points

that are used equally for MPLS LSPs and pseudowires. I can't tell from
the I-D

whether it is your intention that your code point would also be applicable
in

both cases. What is your intention? Is this "obvious" from G.8113.1
or does it

need to be clarified?

My review of the write-up and discussions...

3. There seems to be quite a feeling on the mailing lists that this document

should be run through the MPLS working group. The write-up makes a case
for

progressing it as AD sponsored. As far as I can see, the main assertions
to

answer are as follows. Do you have a view on these points before I make
a

decision on what to do?

a. This is a proposal to use an MPLS code point and so is part of MPLS
by

definition.

b. The type of network being managed by the OAM described in G.8113.1 is
an MPLS

network. Therefore, this is clearly relevant to the MPLS working .

Do you object to this going through the MPLS on principle, or were you
just

hoping to save the WG the work? If the latter, and if the WG wants to look
at

the draft, the easiest approach seems to be to redirect the work to the
working

group.

4. G.8113.1 is clearly important to understanding to which the code point
is

being put. Thus, an available and stable copy of group. G.8113.1 will be
key to

the last call review of you I-D. Can you make a stable copy available (for

example, through liaison)? How does the editing work currently in progress
in

the SG15 meeting affect that availability?

5. Can you clarify for me why the suggested value has been suggested. This
will

help guide IANA who would normally do their allocation in a "tidy"
way.

Looking forward to your reply.

Thanks,

Adrian

_______________________________________________

Ietf mailing list

Ietf@ietf.org

https://www.ietf.org/mailman/listinfo/ietf

Hi Malcolm and Huub,

I =
have squeezed a little time from the current ITU-T meeting to look at =
your
draft and write-up. I have also read the email threads on the =
IETF discussion
list and the MPLS list. Sorry that this has taken me =
a week to process, but your
publication request came at pretty much =
the worst possible time for getting me
to do this task.

I =
don't like proliferating threads across multiple mailing lists. On the =
other
hand it is difficult to ensure that all the constituencies are =
present, so I am
perpetuating the cross-posting.

My review of =
the document...

1. idnits (
http://www.ietf.org/tools/idnits/
) shows a couple of nits. I think
only one of these is =
real (the spurious space in a citation). The other nits are
spurious =
caused by citations wrapping across lines. Could you please keep a =
note
of the nit so that you can fix it the next time the draft is =
respun or so it can
be captured in an RFC Editor Note at a later =
stage (you don't have to post a new
revision to address this now =
unless you really want to).

2. This document requests a code =
point from a registry that contains code points
that are used equally =
for MPLS LSPs and pseudowires. I can't tell from the I-D
whether it =
is your intention that your code point would also be applicable =
in
both cases. What is your intention? Is this "obvious" from =
G.8113.1 or does it
need to be clarified?

My review of the =
write-up and discussions...

3. There seems to be quite a feeling =
on the mailing lists that this document
should be run through the =
MPLS working group. The write-up makes a case for
progressing it as =
AD sponsored. As far as I can see, the main assertions to
answer are =
as follows. Do you have a view on these points before I make =
a
decision on what to do?

a. This is a proposal to use an MPLS =
code point and so is part of MPLS by
definition.

b. The type =
of network being managed by the OAM described in G.8113.1 is an =
MPLS
network. Therefore, this is clearly relevant to the MPLS working =
.

Do you object to this going through the MPLS on principle, or =
were you just
hoping to save the WG the work? If the latter, and if =
the WG wants to look at
the draft, the easiest approach seems to be =
to redirect the work to the working
group.

4. G.8113.1 is =
clearly important to understanding to which the code point is
being =
put. Thus, an available and stable copy of group. G.8113.1 will be key =
to
the last call review of you I-D. Can you make a stable copy =
available (for
example, through liaison)? How does the editing work =
currently in progress in
the SG15 meeting affect that =
availability?

5. Can you clarify for me why the suggested value =
has been suggested. This will
help guide IANA who would normally do =
their allocation in a "tidy" way.

Looking forward to your =
reply.

Thanks,
Adrian

___________________________________=
____________
Ietf mailing list
Ietf@ietf.org

https://www.ietf.org/mailman/listinfo/ietf
<=
font =
size=3D"2">

   The BFD Control packet sent by the ingress LSR MUST be a UDP packet<=
/span>
   with a well-known destina=
tion port 3784 [BFD-IP] and a source port
=
   assigned by the sender as per the procedures in [BFD-IP].&n=
bsp; The source<=
/o:p>
&nbs=
p;  IP address is a routable address of the sender.  The destinati=
on IP
&=
nbsp;  address MUST be randomly chosen from the 127/8 range for IPv4 an=
d
&nbs=
p;  from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following
   multiple alternat=
e paths to the egress LSR for this FEC using LSP
   BFD session establ=
ished for one such alternate path, is the address
   discovered by LSP Ping=
 traceroute [RFC=
4379] to exercise that
   partic=
ular alternate path.
 <=
/pre>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 
·&n=
bsp;        RFC 6428 uses type 0x0022 for CC.<=
/span>

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 abou=
t that.

Regards,
     Sasha

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org=
] On Behalf Of Gregory Mirsky
Sent: Wednesday, January 04,=
 2012 10:09 PM
To: David Allan I; Chao Fu; mpls@ietf.org
Sub=
ject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428<=
/p>

Dear Dave, Chao, et al.
I thin=
k 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 th=
is 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 whi=
le pure CC mode of MPLS-TP OAM is, as I understand, is per RFC 5884/5885.

    Regards,
        Greg

=
From: mpls-bounces@ietf.org=
 [mailto:mpls-bounces@ietf.org] On Behalf Of David Allan I
Sent=
: Tuesday, January 03, 2012 2:49 PM
To: Chao Fu; mpls@ietf.org=

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

Some answers in line...=

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf O=
f Chao Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To:=
 mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC=
 6428
Hi all,<=
/div> 
I have some doubts on RFC 6371 "OAM Framework for MPLS-Bas=
ed Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".&nbs=
p; Who can help me to clarify them? Thanks a lot!
1.=
 Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration Defect:
&nbs=
p;  If proactive CC-V OAM packets are received with the expected global=
ly
   unique Source MEP identifier but with a transmission peri=
od different
   than the locally configured reception period, t=
hen a CC-V period
   misconfiguration defect is detected.
&n=
bsp;  o  Entry criteria: A MEP receives a CC-V proactive packet wi=
th the
      expected globally unique Source MEP=
 identifier but with a
      transmission period=
 different than its own CC-V-configured
      tr=
ansmission period.

   My doubt: It is said to compare with the locally configu=
red reception period in the definition, but in the Entry criteria, it is com=
pared with it own CC-V-configured transmission period. Are they same? Just b=
ecause 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.  &n=
bsp;
   And such Period=
 Misconfiguration Defect is not defined in RFC 6428. Does MPLS TP need it? W=
hy it is not in RFC 6428? <=
/o:p>

The short story is that a mismatch is a problem=
  but not one that many felt tearing the service down or forcing a prot=
ection switch was a suitable consequent action. It does not indicate an impa=
irment 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 perio=
dicity 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 th=
e time 6371 was written. That view changed after the BFD WG did a thorough r=
eview 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 (i=
ncluding also the
   user data packets) that it receives from t=
he transport path, if this
   consequent action has been enable=
d by the operator.

   My doubt: Does it mean the period misconfiguration shoul=
d or might cause the LOC? Will the packets be discarded? If not, there shoul=
d not be LOC. My opinion is that the period misconfiguration should not caus=
e LOC.
 =
; 
There could be a corner cases if with=
out 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 rec=
eived 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?  
&nbs=
p;  
 A configured reception rate woul=
d 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 s=
ession periodicity and configuration would be the only way such agreement wo=
uld 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 s=
ession 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 sessi=
on into the down state at it's end. 
So LDI/LK=
R, 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 trans=
ition from UP to DOWN in coordinated session operation.
 5.  In 3.7.1 of RFC 6428: Session Initiation and=
 Modification
   Session initiation occurs starti=
ng from MinRx =3D 1 second, MinTx >=3D 1
   second, and the=
 detect multiplier =3D 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 de=
sired rates and to set the detect multiplier to 3.

=
   My doubt: Does it mean t=
he BFD session will not be started with the configured values but use the de=
fault 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 thi=
nk here the configured transmission rates should be same on both Engpoints,=
 otherwise there are Period Misconfiguration Defects defined in 5.1.1.3 of R=
FC 6371.

 P/F is needed as examinat=
ion of any other slow start mechanism revealed that we would have to re=
invent what we already had. So there is a handshake to get from the default=
 to the desired rate.
I hope this helps=
Dave 
&nbs=
p;

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

--_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF6F8ILPTMAIL02e_--

From Alexander.Vainshtein@ecitele.com  Thu Jan  5 01:35:53 2012
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D2221F85A6 for ; Thu,  5 Jan 2012 01:35:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[AWL=1.001,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbaZo-tY9mXE for ; Thu,  5 Jan 2012 01:35:47 -0800 (PST)
Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id A1B6221F860B for ; Thu,  5 Jan 2012 01:35:46 -0800 (PST)
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325756093!49014687!5
X-Originating-IP: [147.234.242.235]
X-StarScan-Version: 6.4.3; banners=-,-,-
Received: (qmail 18762 invoked from network); 5 Jan 2012 09:35:00 -0000
Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-5.tower-27.messagelabs.com with SMTP; 5 Jan 2012 09:35:00 -0000
X-AuditID: 93eaf2e8-b7fc36d000002072-c4-4f056fe94155
Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 45.5F.08306.9EF650F4; Thu,  5 Jan 2012 11:39:53 +0200 (IST)
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 5 Jan 2012 11:35:43 +0200
From: Alexander Vainshtein 
To: Gregory Mirsky 
Date: Thu, 5 Jan 2012 11:35:42 +0200
Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428
Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAABH5UoAAAwreQABX/mFA=
Message-ID: 
References:  <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se>  <60C093A41B5E45409A19D42CF7786DFD5228FC5248@EUSAACMS0703.eamcs.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF734ILPTMAIL02e_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA3WTaWjTYBjHeZO0TeciWXe9m37ooojHOlovKq4qiDg/aOcBigcza981wSap TaZWHQ4UJvOLOh1aPKbOOTdlUu9zWlFUdqEIOue5QbVeMDyHcyYLmwMxn355/s/xT3geErfs NGWSvKigoMj6GWMCURHv/mJ7Jxnc9ot1o5yvWy/iztuH7hicsa5y4Gw/ftIwi8jr+frYmHc5 /NyUV139E8vHl5eCXFYUJYVVkNWLZI+LyQ/y61hPiLHyXhfjYKwBP+tBAhIVF8MGAkj0MjMS rP88uWoaL1qR6JG8vOhzMfMWu21O55RpNgczY8wox6TpCUs4XrYim8DyfquAZJn1IasaWX0O 537VVhKBin3Yht0HKk2l4G43KAdmEtKTYXXPBYPOabDtRYNRYwt9GcA9HUvLQYLKFQCeevUR 0wQj7YKR+uf9SSm0HT6rOYFrjNNr4cfYI0Jjgh4Nf5Z19XMy7YTf7j8l9PxpMBKvVIeRKi+A X49maEjRC+GOshH62O04fNWyWWMzvQy2vW43aQxUa98fnML0SemwveswplumYfW1VlznVPiu 87dBz0+FHWUNQM+XYHPvoX7HFJ0E7+/XnUE6A96qfULsBGnhIW3DQ0rCQ0r0eDasutpt1HkC rDnyHh/gppud2NB4FTDVgQzeH1AKBZ99ok0qVnKQh1eQH+V4JCEC9HV6ewk8axoXBTQJmETq TSnhthjYdXJIiIIMEmNSqRLB4LYML5S8IY6VuYJgsR/JUQBJnEmhPmsa5WVDG1FQGpDmqP9/ F545zCOpiysqBZPs9v+/MOnUDs+H+Rbap27nGoQCKDjQZyRJMpBq1EYkBZEPbSji/cpfGSPN mo1E1UZNvw05wAoy79P1ByArM52KaQKtCVyxOFirHdKWvr6+OEhXPzqZEkQ1K1E9s8HquNoY UxsvTyG0xurlDEqZpSDPFWkuydrKGd0/Lom+ktHxh9EnsbNbciMra6UryYWzc4umdiTlvOh9 yp1vmxhpWpHdVLbaNHeVmYuEhm+6t7f+U6So6nTqlJlj07Z1tLRuqun0H4w3Nuw7ft1cbitw RHsaerHFljMjFi25e2XeTBCcGl5/51ssy/iyJ2nNjWOTJ0gMIXOsYzwelNk/hWqVQCMEAAA=
Cc: "mpls@ietf.org" , Chao Fu 
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jan 2012 09:35:53 -0000

--_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF734ILPTMAIL02e_
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable

Dear Greg,

I've followed your example and checked Section 5.1.1.3 "Period Misconfigurat=
ion Defect" in RFC 6371, 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 pr=
oactive 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 part=
icular, Section 5.1.1.3 refers to "CC-V packets" with CC-V standing for "Con=
nectivity Check and Connectivity Verification" in the Terminology section.

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

1.       Transmission period is encoded in the CC-V packets, and the receive=
r 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.173=
1 (02/08) and is trivial to implement

2.       The receiver of CC-V messages evaluates the actual transmission per=
iod of CC-V messages and compares it with the configured value.  I cannot sa=
y 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 so=
mehow 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 a=
bove looks like matching the intention of the authors/Editors.

My 2c,
     Sasha

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg=
ory Mirsky
Sent: Thursday, January 05, 2012 12:36 AM
To: David Allan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

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 per=
iod of CV message. My understanding that this period is fixed at 1 sec and s=
ince Detect Multiplier is 1 generation randomized within 0.75 - 0.9 range. S=
o, we're talking not about Period Misconfiguration per se, but about wrong f=
requency 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; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428
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 su=
dden actual change would be an interesting implementation bug.

However I think Sasha is correct in that an Errata to 6371 would clean up mi=
sconceptions, 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 addres=
s 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; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428
Dear Dave, Chao, et al.
I think that an BFD peer would not be "suddenly" change frequency of CC mess=
ages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to ch=
ange timers via AdminDown state. Secondly, even if operator prefers this ope=
ration to be more BFD-ish, it will work through P/F sequence and old frequen=
cy should be used until remote peer acknowledges the change with F bit in it=
s 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Davi=
d Allan I
Sent: Tuesday, January 03, 2012 2:49 PM
To: Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428
HI Chao:

Some answers in line...

________________________________
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao=
 Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To: mpls@ietf.org
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? T=
hanks 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 per=
iod 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 cons=
equent action. It does not indicate an impairment in information transfer ca=
pability, just in the ability to measure it. Hence flag it northbound and pr=
esumably offline action would bring the OAM back into spec. Now as for an im=
plementation 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 aft=
er 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 per=
iodicity of CC/CV to less than 1/3 of the expected rate so that one got an L=
OC. 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 pl=
aces mention "configured reception period", do they mean the configured tran=
smission rate?

 A configured reception rate would be an expected rate which IMO would be op=
tional. Again an artifact of the original expectation of no handshaking betw=
een the MEPs in establishing a session periodicity and configuration would b=
e 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 message=
s.

  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 DO=
WN 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 loc=
al 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 U=
P to DOWN in coordinated session operation.

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

   Session initiation occurs starting from MinRx =3D 1 second, MinTx >=3D 1
   second, and the detect multiplier =3D 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 confi=
gured values but use the default values? What the values will be filled in t=
he packet? The default ones or the configured values?
   Why need P/F here? There is no timer negotiation. I think here the config=
ured transmission rates should be same on both Engpoints, otherwise there ar=
e 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 tha=
t 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

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

--_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF734ILPTMAIL02e_
Content-Type: text/html; charset="us-ascii"
content-transfer-encoding: quoted-printable

Dear Greg,
 <=
p class=3DMsoNormal>I’ve followed your example and checked Secti=
on 5.1.1.3 “Period Misconfiguration Defect” in RFC 6371, an=
d I disagree with your reading..
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4=
97D'> 
First of all, th=
is document does not distinguish between Connectivity Check (CC) and Connect=
ivity Verification (CV). It almost explicitly assumes that the same packet i=
s used for both purposes – at least when we speak about proactive CC a=
nd CV (because” CC packets” are not mentioned  in the text,=
 and “CV packets” are always mentioned as “on-demand CV &#=
8211;packets”). And, in particular, Section 5.1.1.3 refers to “C=
C-V packets” with CC-V standing for “Connectivity Check and Conn=
ectivity Verification” in the Terminology section.

When it comes to the Period Misconfiguration defect, IMHO the=
 text in RFC 6371 admits at least two readings:
<=
![if !supportLists]>1.       Transmission period is enc=
oded in the CC-V packets, and the receiver compares the received value with=
 its configured one. This reading matches the definition of the Unexpected P=
eriod defect in  Annex I.5 of ITU-T Y.1731 (02/08) and is trivial to im=
plement
2.  =
;     The receiver of CC-V messages evaluates the actual transmission pe=
riod of CC-V messages and compares it with the configured value.  I can=
not say that such a reading strictly contradicts 6371, but it leaves multipl=
e open questions, e.g.:
a.       =
How do you evaluate the transm=
ission period? The receiver has to somehow eliminate the PDV effects, and th=
e estimate may depend on the specific elimination method and its parameters<=
o:p>
b.=
      How do you compare the estimated actual transmission period w=
ith the configured one? This requires definition of some limits of tolerance=
 etc.
Taking into account th=
e history of MPLS-TP, I’d say that the first reading above looks like=
 matching the intention of the authors/Editors. 

<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4=
97D'>My 2c,
  &nbs=
p;  Sasha
=

From: mpls-bounc=
es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsk=
y
Sent: Thursday, January 05, 2012 12:36 AM
To: David Al=
lan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in R=
FC 6371 and RFC 6428
<=
o:p> 
Hi Dave, et al.,=
I do agree that RFC 6371 might be in need of revis=
ion at some time. But I'm not sure that we're at that point already.<=
o:p>
I've re-checked Section 5.1.1.3 Period M=
isconfiguration 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 r=
andomized within 0.75 - 0.9 range. So, we're talking not about Period Miscon=
figuration per se, but about wrong frequency of CV messages, message with un=
ique MEP ID, as they are referenced in the RFC.

Hope I've interpret=
ed the 5.1.1.3 correctly.

    Regards,
        Gre=
g

From: David Allan I 
Sent: Wednesday, January 04, 2012 2:13 PM<=
br>To: Gregory Mirsky; Chao Fu; mpls@ietf.org
Subject: RE:=
 [mpls] Some doubts in RFC 6371 and RFC 6428
Hi Greg:
 =
I agree that a sudden change in frequency wo=
uld not happen, and there is an actual discipline for doing so which 6428 do=
es go into in some detail. A sudden actual change would be an interesting im=
plementation bug.

However I think Sasha is correct in that an Errat=
a to 6371 would clean up misconceptions, as much as my first reaction was th=
at 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 A=
llan I; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in=
 RFC 6371 and RFC 6428
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 time=
rs 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 s=
hould 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.=

 &nb=
sp;  Regards,
  &n=
bsp;     Greg

From: mpls-bounces@ietf.org [mailto:mpls-bo=
unces@ietf.org] On Behalf Of David Allan I
Sent: Tuesday, J=
anuary 03, 2012 2:49 PM
To: Chao Fu; mpls@ietf.org
Subject:<=
/b> Re: [mpls] Some doubts in RFC 6371 and RFC 6428
HI Chao:
 =
;
Some answers in line...

From: mpls-bounc=
es@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To: mpls@ietf.org<=
br>Subject: [mpls] Some doubts in RFC 6371 and RFC 6428
Hi all,

I have som=
e 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 proacti=
ve CC-V OAM packets are received with the expected globally
  =
 unique Source MEP identifier but with a transmission period different
&n=
bsp;  than the locally configured reception period, then a CC-V period<=
br>   misconfiguration defect is detected.
   o =
 Entry criteria: A MEP receives a CC-V proactive packet with the
 &n=
bsp;    expected globally unique Source MEP identifier but wi=
th a
      transmission period different than it=
s own CC-V-configured
      transmission period.=

   My=
 doubt: It is said to compare with the locally configured reception peri=
od 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 R=
FC 6428? 
 =
; 
The short story is that a mismatch is a problem  but not on=
e that many felt tearing the service down or forcing a protection switch was=
 a suitable consequent action. It does not indicate an impairment in informa=
tion transfer capability, just in the ability to measure it. Hence flag it n=
orthbound and presumably offline action would bring the OAM back into spec.=
 Now as for an implementation explicitly modifying the periodicity to an una=
cceptable value, how the other end reacts is implementation or policy depend=
ant.
Part of this is a consequence of beleiving tha=
t some of the BFD handshaking could be dispensed with at the time 6371 was w=
ritten. That view changed after the BFD WG did a thorough review of what bec=
ame 6428.
 2. In 5.1.2 of RFC 6371:
 &n=
bsp; If a MEP detects a LOC defect that is not caused by a period
 &=
nbsp; misconfiguration, it should block all the traffic (including also the<=
br>   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 t=
he LOC? Will the packets be discarded? If not, there should not be LOC. My o=
pinion is that the period misconfiguration should not cause LOC.=

There could be a corner cases if without any warning on=
e 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 adverti=
sed 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 transmi=
ssion rate.

   My doubt: Does it mean no need to configure reception period? B=
ut many places mention "configured reception period", do they mean=
 the configured transmission rate?  
   <=
i>
 A configured reception rate would be an expected rat=
e which IMO would be optional. Again an artifact of the original expectation=
 of no handshaking between the MEPs in establishing a session periodicity an=
d configuration would be the only way such agreement would happen.
 4. In 3.7.3 of RFC 6428:
  It will also communi=
cate session DOWN to its session peer using CC messages.

=
  My doubt: Does it mean only no=
tify the peer to bring the session DOWN but the local session will not be DO=
WN? 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, MISCONNEC=
TIVIY 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 =3D 1 s=
econd, MinTx >=3D 1
   second, and the detect multiplier =3D=
 3.
   Once in the UP state, Poll/Final disciplin=
e is used to modify the
   periodicity of control message excha=
nge 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 no=
t 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 val=
ues?
   W=
hy 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 Pe=
riod Misconfiguration Defects defined in 5.1.1.3 of RFC 6371.

 P/F is needed as examination of any other slow&=
nbsp;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 

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

--_000_A3C5DF08D38B6049839A6F553B331C760115EDBFF734ILPTMAIL02e_--

From loa@pi.nu  Thu Jan  5 03:24:27 2012
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB1321F86B4 for ; Thu,  5 Jan 2012 03:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK-OhSdB3xJV for ; Thu,  5 Jan 2012 03:24:27 -0800 (PST)
Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 479C921F86B2 for ; Thu,  5 Jan 2012 03:24:27 -0800 (PST)
Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 97C2F2A8003 for ; Thu,  5 Jan 2012 12:24:24 +0100 (CET)
Message-ID: <4F05886A.6070603@pi.nu>
Date: Thu, 05 Jan 2012 12:24:26 +0100
From: Loa Andersson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "mpls@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [mpls] Poll on two drafts (draft-fbb-mpls-gach-adv and draft-fbb-mpls-tp-ethernet-addressing)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jan 2012 11:24:28 -0000

Working Group,

this is to start a two week poll to see if there is support to make
    draft-fbb-mpls-gach-adv-01
    draft-fbb-mpls-tp-ethernet-addressing-01
mpls working group drafts.

Pleased send your comments to the mpls working group mailing list
(mpls@ietf.org).

This poll ends January 18, 2012!

Loa
for the mpls wg chairs

-- 

Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

From yaacov.weingarten@nsn.com  Thu Jan  5 04:06:49 2012
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5A21F87F1 for ; Thu,  5 Jan 2012 04:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D38FfA9tMBfq for ; Thu,  5 Jan 2012 04:06:48 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 89B9721F87E3 for ; Thu,  5 Jan 2012 04:06:48 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q05C6eaN004516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2012 13:06:40 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q05C6dfW017795; Thu, 5 Jan 2012 13:06:40 +0100
Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 5 Jan 2012 13:06:38 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Jan 2012 13:06:36 +0100
Message-ID: 
In-Reply-To: <76CD132C3ADEF848BD84D028D243C927229F4ED7@szxeml509-mbx.china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [mpls] Comments on draft-weingarten-mpls-tp-ring-protection-06
Thread-Index: Acya1oQkEkmaA6JvQ7S2g+rIofFNNwwyiw0A
References: <76CD132C3ADEF848BD84D028D243C927229F4ED7@szxeml509-mbx.china.huawei.com>
From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" 
To: "ext Jie Dong" , 
X-OriginalArrivalTime: 05 Jan 2012 12:06:38.0072 (UTC) FILETIME=[7A1C5780:01CCCBA2]
Subject: Re: [mpls] Comments on draft-weingarten-mpls-tp-ring-protection-06
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jan 2012 12:06:49 -0000

Jie, Hi

Sorry for the long delay in replying to this set of comments - but it
has been a rather busy time, and I have finally been freed up a little
to address the Ring Protection document.

Please see my replies in-line below.  I will, hopefully submit an
updated version of the draft based on the resolution of your comments
(as soon as everyone is satisfied with the resolutions).

Thank you,
yaacov

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
ext Jie Dong
Sent: Friday, November 04, 2011 11:46 AM
To: mpls@ietf.org
Subject: [mpls] Comments on draft-weingarten-mpls-tp-ring-protection-06

Hi,=20

Here are some comments on this tp ring protection draft.=20

1. This draft describes the label stack operation of each protection
mechanism. For better clarity, I would recommend using the same
protected LSP as example when possible, i.e. using LSR-B as the ingress
and LSR-E as the egress in all description of p2p protection, and
describes the label stack operation from the ingress to the egress.

[yw>] I will try to align the examples on p2p protection to use the
working path B-A-F in section 2.3

2. Label operation in the last paragraph before 2.3.1, "packets arrive
at LSR-B with label [LI], and then send out to LSR-A with [[PA(F)|L1]]".
Should B swap the inner label LI with LE, which is expected by the
egress LSR-F?
[yw>] On the assumption that you mean the paragraph just prior to
Section 2.3.1, you are correct and I will correct the text, thank you!

3. Label stack operation of wrapping in sec 2.3.2 needs some
clarification:

  "1. The data packet arrives at LSR-A with label stack [LI+S] (i.e. top
label from the LSP and bottom-of-stack indicator)"

If the section takes the protected LSP in figure 1 as example, LSR-A is
the ingress of SPME A-F, NOT the ingress of the ring. If the ingress LSR
is B, packets arrive at A may contain the label for SPME B-A, and the
inner LSP label LI should be swapped on LSR-B.
[yw>] To be honest, this is tied to your first question, i.e. we have
confused you by referring to a different working path, the working path
in this description is the path A-F and not B-A-F, but I will try and
align (as I mentioned above)

  "2. In the normal case (no switching), LSR-A forwards the packet with
label stack [PA1(F)|LE+S] (i.e. swap the label for the LSP, to be
acceptable to the SPME egress, and push the label for the primary SPME
from LSR-A to LSR-F)."

"LE" is defined as "the label of the LSP that is expected at the egress
point from the ring", but here it is used as the label expected by SPME
egress. Since the inner LSP label needs be swapped each time the SPME
label is popped, using "LE" for this operation may be confusing. It
would be clearer to define a new term for this.
[yw>] see my previous comment!

4. In some specifications "+S" is added to the LSP label. Does it also
allow carrying PW label or other labels in the label stack?
[yw>] This document is based on use of the Linear Protection defined in
RFC6378 which is only applicable to LSPs, so I am not sure that I
understand the full context and implications of your question.

Best regards,
Jie

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

From gregory.mirsky@ericsson.com  Thu Jan  5 10:33:27 2012
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF921F8853 for ; Thu,  5 Jan 2012 10:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEiBdkj3LdL7 for ; Thu,  5 Jan 2012 10:33:21 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1370A21F8854 for ; Thu,  5 Jan 2012 10:33:21 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q05IXA4h012053; Thu, 5 Jan 2012 12:33:13 -0600
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 5 Jan 2012 13:33:05 -0500
From: Gregory Mirsky 
To: Alexander Vainshtein 
Date: Thu, 5 Jan 2012 13:33:04 -0500
Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428
Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAABH5UoAAAwreQABX/mFAAE895QA==
Message-ID: 
References:  <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se>  <60C093A41B5E45409A19D42CF7786DFD5228FC5248@EUSAACMS0703.eamcs.ericsson.se>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1322993517AEUSAACMS0715e_"
MIME-Version: 1.0
Cc: "mpls@ietf.org" , Chao Fu 
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jan 2012 18:33:27 -0000

--_000_FE60A4E52763E84B935532D7D9294FF1322993517AEUSAACMS0715e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Sasha,
your analysis is thorough as always. I hope Editors will provide their opin=
ions. In the meantime I'll note that in explaining entry and exit condition=
s for the Period Misconfiguration Defect text is explititly calls for "expe=
cted globally unique Source MEP identifier" which to me is implicit referen=
ce to MPLS-TP CV message as it is defined in the Section 3.5 of the RFC 642=
8. AFAIK, CC message does not include MEP ID and I've concluded that the Pe=
riod Misconfiguration Defect is not applicable to CCs.

    Regards,
        Greg

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

Dear Greg,

I've followed your example and checked Section 5.1.1.3 "Period Misconfigura=
tion Defect" in RFC 6371, 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 p=
roactive CC and CV (because" CC packets" are not mentioned  in the text, an=
d "CV packets" are always mentioned as "on-demand CV -packets"). And, in pa=
rticular, Section 5.1.1.3 refers to "CC-V packets" with CC-V standing for "=
Connectivity Check and Connectivity Verification" in the Terminology sectio=
n.

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

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

2.       The receiver of CC-V messages evaluates the actual transmission pe=
riod 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 o=
pen questions, e.g.:

a.       How do you evaluate the transmission period? The receiver has to s=
omehow eliminate the PDV effects, and the estimate may depend on the specif=
ic elimination method and its parameters

b.      How do you compare the estimated actual transmission period with th=
e 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre=
gory Mirsky
Sent: Thursday, January 05, 2012 12:36 AM
To: David Allan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

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 pe=
riod 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 wro=
ng frequency of CV messages, message with unique MEP ID, as they are refere=
nced 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; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428
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 s=
udden actual change would be an interesting implementation bug.

However I think Sasha is correct in that an Errata to 6371 would clean up m=
isconceptions, as much as my first reaction was that it was an informationa=
l step in a journey was a not fully defined end. I think the tweaks to addr=
ess 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; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428
Dear Dave, Chao, et al.
I think that an BFD peer would not be "suddenly" change frequency of CC mes=
sages 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 fre=
quency 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav=
id Allan I
Sent: Tuesday, January 03, 2012 2:49 PM
To: Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428
HI Chao:

Some answers in line...

________________________________
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Cha=
o Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To: mpls@ietf.org
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 pe=
riod in the definition, but in the Entry criteria, it is compared with it o=
wn CC-V-configured transmission period. Are they same? Just because these t=
wo values should be same? For LOC in 5.1.1.1, it also uses the receiving ME=
P'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 con=
sequent 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 a=
n implementation explicitly modifying the periodicity to an unacceptable va=
lue, 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 af=
ter 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. M=
y opinion is that the period misconfiguration should not cause LOC.

There could be a corner cases if without any warning one end reduced the pe=
riodicity 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 ra=
te, 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 transmissio=
n rate.

   My doubt: Does it mean no need to configure reception period? But many p=
laces mention "configured reception period", do they mean the configured tr=
ansmission rate?

 A configured reception rate would be an expected rate which IMO would be o=
ptional. Again an artifact of the original expectation of no handshaking be=
tween the MEPs in establishing a session periodicity and configuration woul=
d 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 messag=
es.

  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 D=
OWN 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 a=
t it's end.

So LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are lo=
cal 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 =3D 1 second, MinTx >=3D 1
   second, and the detect multiplier =3D 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 conf=
igured 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 confi=
gured 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 th=
at we would have to reinvent what we already had. So there is a handshake t=
o get from the default to the desired rate.

I hope this helps

Dave

This e-mail message is intended for the recipient only and contains informa=
tion 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, p=
hone or fax, and then delete the original and all copies thereof.

--_000_FE60A4E52763E84B935532D7D9294FF1322993517AEUSAACMS0715e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

  &n=
bsp; Regards,
        Greg

From: Alexander Vainshtein=20
[mailto:Alexander.Vainshtein@ecitele.com] 
Sent: Thursday, Januar=
y 05,=20
2012 1:36 AM
To: Gregory Mirsky
Cc: David Allan I; Chao=
 Fu;=20
mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC=
=20
6428

Dear=20
Greg,

I’ve=20
followed your example and checked Section 5.1.1.3 “Period Misconfi=
guration=20
Defect” in RFC 6371=
, and=20
I disagree with your reading..

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

When=20
it comes to the Period Misconfiguration defect, IMHO the text in RFC 6371 a=
dmits=20
at least two readings:
1.      =
=20
Transmission=20
period is encoded in the CC-V packets, and the receiver compares the receiv=
ed=20
value with its configured one. This reading matches the definition of the=20
Unexpected Period defect in  Annex I.5 of ITU-T Y.1731 (02/08) and is=
=20
trivial to implement
2.      =
=20
The=20
receiver of CC-V messages evaluates the actual transmission period of CC-V=
=20
messages and compares it with the configured value.  I cannot say that=
 such=20
a reading strictly contradicts 6371, but it leaves multiple open questions,=
=20
e.g.:
<=
![if !supportLists]>a.      =
=20
How=20
do you evaluate the transmission period? The receiver has to somehow elimin=
ate=20
the PDV effects, and the estimate may depend on the specific elimination me=
thod=20
and its parameters
<=
![if !supportLists]>b.     =20
How=20
do you compare the estimated actual transmission period with the configured=
 one?=20
This requires definition of some limits of tolerance etc.=

Taking=20
into account the history of MPLS-TP, I’d say that the first reading a=
bove looks=20
like matching the intention of the authors/Editors. 

My=20
2c,
    =20
Sasha

From:<=
/B>=20
mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gr=
egory=20
Mirsky
Sent: Thursday, January 05, 2012 12:36 AM
To: Da=
vid=20
Allan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts i=
n RFC=20
6371 and RFC 6428

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

H=
ope=20
I've interpreted the 5.1.1.3 correctly.

    R=
egards,
        G=
reg

From:<=
/B> David Allan =
I=20

Sent: Wednesday, January 04, 2012 2:13 PM
To: Gregory=
=20
Mirsky; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in=
 RFC=20
6371 and RFC 6428

H=
i=20
Greg:

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

H=
owever=20
I think Sasha is correct in that an Errata to 6371 would clean up=20
misconceptions, as much as my first reaction was that it was an information=
al=20
step in a journey was a not fully defined end. I think the tweaks to addres=
s the=20
first three points could be quite minor.

b=
est
D=

From:<=
/B> Gregory Mirs=
ky=20

Sent: Wednesday, January 04, 2012 12:09 PM
To: David A=
llan=20
I; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC =
6371=20
and RFC 6428

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

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

    R=
egards,
        G=
reg

From:<=
/B>=20
mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Da=
vid=20
Allan I
Sent: Tuesday, January 03, 2012 2:49 PM
To: Cha=
o Fu;=20
mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC=
=20
6428

H=
I=20
Chao:

S=
ome=20
answers in line...

From:<=
/B>=20
mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ch=
ao=20
Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To:=20
mpls@ietf.org
Subject: [mpls] Some doubts in RFC 6371 and RFC=20
6428

Hi all,

I have some doubts on RFC 6371 "OAM Framework for=
=20
MPLS-Based Transport" and RFC 6428 "CC, CV, and RDI for MPLS-TP".  Who=
 can=20
help me to clarify them? Thanks a lot!
1. Section 5.1.1.3 of RFC 6371 defines Period Misconfiguration=20
Defect:
   If proactive CC-V OAM packets are received with the=
=20
expected globally
   unique Source MEP identifier but with a=20
transmission period different
   than the locally configured=20
reception period, then a CC-V period
   misconfiguration defec=
t is=20
detected.
   o  Entry criteria: A MEP receives a CC-V=20
proactive packet with the
      expected global=
ly=20
unique Source MEP identifier but with a
     =20
transmission period different than its own=20
CC-V-configured
      transmission=20
period.

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

T=
he=20
short story is that a mismatch is a problem  but not one that many fel=
t=20
tearing the service down or forcing a protection switch was a suitable=20
consequent action. It does not indicate an impairment in information transf=
er=20
capability, just in the ability to measure it. Hence flag it northbound and=
=20
presumably offline action would bring the OAM back into spec. Now as for an=
=20
implementation explicitly modifying the periodicity to an unacceptable valu=
e,=20
how the other end reacts is implementation or policy=20
dependant.
P=
art of=20
this is a consequence of beleiving that some of the BFD handshaking could b=
e=20
dispensed with at the time 6371 was written. That view changed after the BF=
D WG=20
did a thorough review of what became 6428.
 2. In 5.1.2 of RFC 6371:
   If a MEP detects a LOC de=
fect=20
that is not caused by a period
   misconfiguration, it should =
block=20
all the traffic (including also the
   user data packets) that=
 it=20
receives from the transport path, if this
   consequent action=
 has=20
been enabled by the operator.

   My doubt: Does it mean the period misconfigur=
ation=20
should or might cause the LOC? Will the packets be discarded? If not, there=
=20
should not be LOC. My opinion is that the period misconfiguration should no=
t=20
cause LOC.
 &=
nbsp;
T=
here=20
could be a corner cases if without any warning one end reduced the=20
periodicity of CC/CV to less than 1/3 of the expected rate so that one got =
an=20
LOC. Once a lower rate BFD PDU was received that advertised the changed rat=
e,=20
the receiver could adapt vs. staying in a defect state.

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

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

<=
/I>&=
nbsp;A=20
configured reception rate would be an expected rate which IMO would be opti=
onal.=20
Again an artifact of the original expectation of no handshaking between the=
 MEPs=20
in establishing a session periodicity and configuration would be the only w=
ay=20
such agreement would happen.

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

  <=
SPAN=20
style=3D"BACKGROUND: #ffff99">My doubt: Does it mean only notify the peer t=
o bring=20
the session DOWN but the local session will not be DOWN? Or we should bring=
 the=20
local session DOWN also? But it is not in the BFD State machine of Figure=20
7.

I=
t is=20
telling it's peer that it has taken the session into the down state at it's=
=20
end. 
S=
o=20
LDI/LKR, TIME OUT, MISCONNECTIVIY or a local focing of ADMIN DOWN are local=
=20
inputs to the state machine that will transition it from UP to=20
DOWN.
R=
eceiving=20
ADMIN DOWN or DOWN from a peer will also cause a transition from UP to DOWN=
 in=20
coordinated session operation.
&=
nbsp;5.  In=20
3.7.1 of RFC 6428: Session Initiation and Modification
   Session initiation occurs starting from MinRx =3D 1 second,=
 MinTx=20
>=3D 1
   second, and the detect multiplier =3D 3.
   Once in the UP state, Poll/Final discipline is used to modi=
fy=20
the
   periodicity of control message exchange from their defa=
ult=20
rates to
   the desired rates and to set the detect multiplier=
 to=20
3.

   My doubt: Does it mean the BFD session will n=
ot be=20
started with the configured values but use the default values? What the val=
ues=20
will be filled in the packet? The default ones or the configured=20
values?
 &nb=
sp; Why=20
need P/F here? There is no timer negotiation. I think here the configured=20
transmission rates should be same on both Engpoints, otherwise there are Pe=
riod=20
Misconfiguration Defects defined in 5.1.1.3 of RFC 6371.
&=
nbsp;P/F=20
is needed as examination of any other slow start mechanism revealed th=
at we=20
would have to reinvent what we already had. So there is a handshake to get =
from=20
the default to the desired rate.
I=
 hope=20
this helps
D=
ave 

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

--_000_FE60A4E52763E84B935532D7D9294FF1322993517AEUSAACMS0715e_--

From Alexander.Vainshtein@ecitele.com  Thu Jan  5 10:51:59 2012
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032A021F8874 for ; Thu,  5 Jan 2012 10:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[AWL=0.901,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edyFzvEZZTrP for ; Thu,  5 Jan 2012 10:51:57 -0800 (PST)
Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id BD89421F87ED for ; Thu,  5 Jan 2012 10:51:55 -0800 (PST)
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325789487!51689042!5
X-Originating-IP: [147.234.242.235]
X-StarScan-Version: 6.4.3; banners=-,-,-
Received: (qmail 32354 invoked from network); 5 Jan 2012 18:51:32 -0000
Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-11.tower-27.messagelabs.com with SMTP; 5 Jan 2012 18:51:32 -0000
X-AuditID: 93eaf2e8-b7fc36d000002072-fa-4f05f241d7c2
Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id A5.7B.08306.142F50F4; Thu,  5 Jan 2012 20:56:01 +0200 (IST)
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 5 Jan 2012 20:51:51 +0200
From: Alexander Vainshtein 
To: Gregory Mirsky , David Allan I , "Italo.Busi@alcatel-lucent.com" 
Date: Thu, 5 Jan 2012 20:51:32 +0200
Thread-Topic: [mpls] Some doubts in RFC 6371 and RFC 6428
Thread-Index: AczF1LuW09VimK5ZRMyAUCzOir8ClAEjyKlgAC3XZdAABH5UoAAAwreQABX/mFAAE895QAAAsP+b
Message-ID: 
References:  <60C093A41B5E45409A19D42CF7786DFD5228FC4BCF@EUSAACMS0703.eamcs.ericsson.se>  <60C093A41B5E45409A19D42CF7786DFD5228FC5248@EUSAACMS0703.eamcs.ericsson.se>  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6891ILPTMAIL02e_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLsWRmVeSWpSXmKPExsUy+dWnL7pOn1j9DQ40slg8PL+d2eLwvKOs Fs+fdDFaHN1qYXFr6UpWB1aP1md7WT1+fb3K5rFz1l12jyVLfjIFsEQ1MNok5uXllySWpCqk pBYn2yoFFGWWJSZXKilkptgqGSopFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8 lMy8dFslz2B/XQsLU0tdQyU7NWVDY2uukIzMYoVU3dzEzByF3NTi4sT0VAWgSMIW5oy37/ez FfzeyFQx4+oq1gbGrU1MXYycHBICJhJ3Hj1jhbDFJC7cW8/WxcjFISSwk1HixsqZjBDOZEaJ 1ke9LCBVbAK2EptW3wWrEhFYyCgx53QfM0iCWcBZon36HvYuRg4OFgEViTNtUiBhYQELiW8n b4L1ighYSmx6NY0Vwo6SOPW/D+wKXoFAiVkrnrNDLJvDIrHy2TZGkASnQITE8z0dYDYj0Hnf T61hgtglLnHryXyoFwQkluw5zwxhi0q8fPyPFaJeVOJO+3pGiPp8ie6F/1gglglKnJz5hAWi XlLi4IobLBMYxWYhGTsLScssJC0QcQOJ9+fmM0PY2hLLFr6GsvUlNn45y4gsvoCRfRWjZGZO QUlSbrqBkW5+aYleanJmSWpOql5yfu4mRkjaerGD8fYZzUOMAhyMSjy8jxpY/IVYE8uKK3MP MUpyMCmJ8u58y+ovxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ3bhVQjjclsbIqtSgfJuUKjIGJ zFLcyfnAVJxXEm9sYICboyTO2538xldIIB2YQrNTUwtSi2DmyHBwKEnwHvsAtEKwKDU9tSIt M6cEIc3EwQlyBg/QGQdBaniLCxJzizPTIfKnGHU5bixYcI5RiCUvPy9VSpx3CkiRAEhRRmke 3BxQDqv/////K0ZxYAAI89aCVPEA8x/cpFdAS5iAlkSJsIAsAeYkuJRUA2Nzk5tM7Cep+1rH 5N14/JYUv5xY7flwGvfXd5yz1Rad3ll9oj9DhW3hCyGbiaEft9YXFb19fOp0svQFRc6NQUpV s+2aF+k/1nzQ8fzC0z8K7aZ//E/f6FB0L65oLnUXvHvikeXBc1cUZp1VXTTvmhvrnbXxYnmX nHym9h4rkC3iqJ6idmypWYISS3FGoqEWc1FxIgC44SLsPAQAAA==
Cc: "mpls@ietf.org" , Chao Fu 
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jan 2012 18:51:59 -0000

--_000_A3C5DF08D38B6049839A6F553B331C760115ED9B6891ILPTMAIL02e_
Content-Type: text/plain; charset="Windows-1252"
content-transfer-encoding: quoted-printable

Dear Greg,
Lots of thanks for a prompt response.

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 be=
tween 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 [gregory.mirsky@ericsson.com]
Sent: Thursday, January 05, 2012 8:33 PM
To: Alexander Vainshtein
Cc: David Allan I; Chao Fu; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428

Dear Sasha,
your analysis is thorough as always. I hope Editors will provide their opini=
ons. In the meantime I'll note that in explaining entry and exit conditions=
 for the Period Misconfiguration Defect text is explititly calls for "expect=
ed 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 Perio=
d Misconfiguration Defect is not applicable to CCs.

    Regards,
        Greg

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

Dear Greg,

I=92ve followed your example and checked Section 5.1.1.3 =93Period Misconfig=
uration Defect=94 in RFC 6371, 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 =96 at least when we speak about=
 proactive CC and CV (because=94 CC packets=94 are not mentioned  in the tex=
t, and =93CV packets=94 are always mentioned as =93on-demand CV =96packets=
=94). And, in particular, Section 5.1.1.3 refers to =93CC-V packets=94 with=
 CC-V standing for =93Connectivity Check and Connectivity Verification=94 in=
 the Terminology section.

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

1.       Transmission period is encoded in the CC-V packets, and the receive=
r 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.173=
1 (02/08) and is trivial to implement

2.       The receiver of CC-V messages evaluates the actual transmission per=
iod of CC-V messages and compares it with the configured value.  I cannot sa=
y 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 so=
mehow 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=92d say that the first reading=
 above looks like matching the intention of the authors/Editors.

My 2c,
     Sasha

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg=
ory Mirsky
Sent: Thursday, January 05, 2012 12:36 AM
To: David Allan I; Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428

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 per=
iod of CV message. My understanding that this period is fixed at 1 sec and s=
ince Detect Multiplier is 1 generation randomized within 0.75 - 0.9 range. S=
o, we're talking not about Period Misconfiguration per se, but about wrong f=
requency 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; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428
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 su=
dden actual change would be an interesting implementation bug.

However I think Sasha is correct in that an Errata to 6371 would clean up mi=
sconceptions, 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 addres=
s 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; mpls@ietf.org
Subject: RE: [mpls] Some doubts in RFC 6371 and RFC 6428
Dear Dave, Chao, et al.
I think that an BFD peer would not be "suddenly" change frequency of CC mess=
ages when running MPLS-TP CC-CV (case #2). Firstly, there's suggestion to ch=
ange timers via AdminDown state. Secondly, even if operator prefers this ope=
ration to be more BFD-ish, it will work through P/F sequence and old frequen=
cy should be used until remote peer acknowledges the change with F bit in it=
s 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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Davi=
d Allan I
Sent: Tuesday, January 03, 2012 2:49 PM
To: Chao Fu; mpls@ietf.org
Subject: Re: [mpls] Some doubts in RFC 6371 and RFC 6428
HI Chao:

Some answers in line...

________________________________
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Chao=
 Fu
Sent: Wednesday, December 28, 2011 6:51 PM
To: mpls@ietf.org
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? T=
hanks 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.