Subject: [mpls-tp] Questions/notes to draft-ietf-mpls-tp-cc-cv-rdi-02

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Nov 2010 17:49:55 -0700

Dear Authors,
I've put my questions and notes below. Your comments greatly appreciated:

   - Second paragraph in Introduction limits the scope of the document to
   MEP-to-MEP CC/CV. Does that mean that TCM is supported only a H-LSP by SPME?
   If that is the case, then I think that it would be helpful to state
   explicitly that CC/CV to and from MIP are out of scope of the document.
   - Fourth paragraph in Introduction lists three BFD encapsulation options.
   Currently GAL/G-ACh and UDP/IP can be used on LSP, Section, and SPME, while
   on PWs VCCV and UDP/IP can be used. But Figures 2 and 3 present only
   GAL/G-ACh-VCCV encapsulation. And it would be helpful to add UDP/IP
   encapsulation of CV Message over LSP, Section, and SPME figure to the
   document. How would BFD UDP/IP encapsulation can be differentiated from CV
   BFD UDP/IP encapsulation? Is Unique MEP-ID part of UDP/IP encapsulation of
   CV BFD?
   - Last paragraph of Section 3.1 introduces optional concurrency of CC and
   CV on the same ME. I think it is newly introduced model. Is proposed
   scenario (n-th CC packet sent as CV) suggests to have CV rate 'n' times
   slower than CC's? In case CC and CV ran simultaneously on the ME, should CV
   be treated as CC even though it's sent as different ACh Type in order to
   avoid false positives when Detection Multiplier == 1?
   - Section 3.3 I think that new CV message format makes it HW-friendlier.
   Is Unique MEP ID now viewed as part of G-ACh message, not ACH TLV? If MEP ID
   is not ACH TLV, then allocated ACh Type BFD CV is only for MEP-to-MEP and
   can not be adopted to any use for MIP. If MEP ID is ACH TLV, then presented
   format is not compliant with Section 3.1 RFC 5586.
   - Section 3.5, third paragraph "This document specifies bi-directional
   BFD for p2p transport LSPs, hence the M bit MUST be clear." I propose to
   update the sentence to list Section, SPME, and PW after "transport LSPs".
   - Section 3.5 p.8 first line. Perhaps can benefit from re-wording.
   Instead of "... on the reverse component ..." use "... to another MEP ..."
   or "... to originating MEP ..."
   - Section 3.5.7 prohibits from on-a-fly update of My Discriminator in CV
   mode. Does that imply that on-a-fly modification of My Discriminator is
   allowed in CC mode? If the answer is No, then it'd be reasonable to state
   that explicitly too.

Regards,
Greg

---

From: David Allan I <[email-masked]>
Date: Wed, 3 Nov 2010 09:49:45 -0400

HI Greg:

Comments embedded in line....

 *   Second paragraph in Introduction limits the scope of the document to MEP-to-MEP CC/CV. Does that mean that TCM is supported only a H-LSP by SPME? If that is the case, then I think that it would be helpful to state explicitly that CC/CV to and from MIP are out of scope of the document.

It is correct that TCM is limited to use of SPMEs. We can put a sentence in to that effect but is seems somewhat redundant.

 *   Fourth paragraph in Introduction lists three BFD encapsulation options. Currently GAL/G-ACh and UDP/IP can be used on LSP, Section, and SPME, while on PWs VCCV and UDP/IP can be used. But Figures 2 and 3 present only GAL/G-ACh-VCCV encapsulation. And it would be helpful to add UDP/IP encapsulation of CV Message over LSP, Section, and SPME figure to the document. How would BFD UDP/IP encapsulation can be differentiated from CV BFD UDP/IP encapsulation? Is Unique MEP-ID part of UDP/IP encapsulation of CV BFD?

To a certain extent BFD always had CV due to the presence of the IP header, which provided a unique source. So there is only one encapsulation for CC/CV when using the backwards compatible encapsulation.

 *   Last paragraph of Section 3.1 introduces optional concurrency of CC and CV on the same ME. I think it is newly introduced model. Is proposed scenario (n-th CC packet sent as CV) suggests to have CV rate 'n' times slower than CC's? In case CC and CV ran simultaneously on the ME, should CV be treated as CC even though it's sent as different ACh Type in order to avoid false positives when Detection Multiplier == 1?

Correct, CC++.... We will add some text in the next version.

 *   Section 3.3 I think that new CV message format makes it HW-friendlier. Is Unique MEP ID now viewed as part of G-ACh message, not ACH TLV? If MEP ID is not ACH TLV, then allocated ACh Type BFD CV is only for MEP-to-MEP and can not be adopted to any use for MIP. If MEP ID is ACH TLV, then presented format is not compliant with Section 3.1 RFC 5586.

In our opinion the TLV is not an ACH TLV but a BFD extension.

 *   Section 3.5, third paragraph "This document specifies bi-directional BFD for p2p transport LSPs, hence the M bit MUST be clear." I propose to update the sentence to list Section, SPME, and PW after "transport LSPs".

OK

 *   Section 3.5 p.8 first line. Perhaps can benefit from re-wording. Instead of "... on the reverse component ..." use "... to another MEP ..." or "... to originating MEP ..."

OK

 *   Section 3.5.7 prohibits from on-a-fly update of My Discriminator in CV mode. Does that imply that on-a-fly modification of My Discriminator is allowed in CC mode? If the answer is No, then it'd be reasonable to state that explicitly too.

IIRC CC mode will not produce race conditions that could alias as a defect. Hence  the reference to CV mode only...

thanks for the feedback
Dave

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 3 Nov 2010 11:00:22 -0700

Dear Dave,
thank you for your answers. I've got one follow-up tagged below with GIM>>:

To a certain extent BFD always had CV due to the presence of the IP header,
which provided a unique source. So there is only one encapsulation for
CC/CV when using the backwards compatible encapsulation.

GIM>> If Source IP and Your Discriminator in CC/CV UDP/IP encapsulation
implicitly present Unique MED ID, then CC/CV with UDP/IP encapsulation is
BFD with UDP/IP encapsulation as in RFC 5885. Is that intention of the
document?

Regards,
Greg

On Wed, Nov 3, 2010 at 6:49 AM, David Allan I <[email-masked]>wrote:

> It is correct that TCM is limited to use of SPMEs. We can put a sentence in
> to that effect but is seems somewhat redundant.
>
>
>    - Fourth paragraph in Introduction lists three BFD encapsulation
>    options. Currently GAL/G-ACh and UDP/IP can be used on LSP, Section, and
>    SPME, while on PWs VCCV and UDP/IP can be used. But Figures 2 and 3 present
>    only GAL/G-ACh-VCCV encapsulation. And it would be helpful to add UDP/IP
> To a certain extent BFD always had CV due to the presence of the IP header,
> which provided a unique source. So there is only one encapsulation for
> CC/CV when using the backwards compatible encapsulation.
>
>    - Last paragraph of Section 3.1 introduces optional concurrency of CC
>    and CV on the same ME. I think it is newly introduced model. Is proposed
>    - Section 3.3 I think that new CV message format makes it
>    HW-friendlier. Is Unique MEP ID now viewed as part of G-ACh message, not ACH
>    TLV? If MEP ID is not ACH TLV, then allocated ACh Type BFD CV is only for
>    MEP-to-MEP and can not be adopted to any use for MIP. If MEP ID is ACH TLV,
>    then presented format is not compliant with Section 3.1 RFC 5586.
>
>    - Section 3.5.7 prohibits from on-a-fly update of My Discriminator in
>    CV mode. Does that imply that on-a-fly modification of My Discriminator is

---

From: David Allan I <[email-masked]>
Date: Wed, 3 Nov 2010 14:19:20 -0400

Hi Greg:

5885 is VCCV, which is of course compatible with PWs but not LSPs. For backwards compatibility with LSPs it would be UDP/IP after S=1 label. No G-ACh.

I hope that is clearer...

Dave

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, November 03, 2010 2:00 PM
To: David Allan I
Cc: John E Drake; [email-masked]; Annamaria Fulignoli; Sami Boutros; [email-masked]; Siva Sivabalan(msiva); David Ward; [email-masked]; [email-masked]
Subject: Re: Questions/notes to draft-ietf-mpls-tp-cc-cv-rdi-02

Dear Dave,

GIM>> If Source IP and Your Discriminator in CC/CV UDP/IP encapsulation implicitly present Unique MED ID, then CC/CV with UDP/IP encapsulation is BFD with UDP/IP encapsulation as in RFC 5885. Is that intention of the document?

Regards,
Greg

On Wed, Nov 3, 2010 at 6:49 AM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
HI Greg:

OK

OK

thanks for the feedback
Dave