Subject: Re: [Pals] PALS Working Group Last Call for draft-ietf-pals-seamless-vccv-01

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 10 Feb 2016 07:22:22 +0000

Greg, Carlos and all,

Just a short question:

Are FAT PWs in scope for this work?

IMHO they should be -because they provide a good use case for multiple S-BFD sessions per PW.

Of course this may be left FFS - but worth mentioning as such if you think it is relevant.

My 2c

Thumb typed on my LG,
Sasha

------ Original message ------
From: Gregory Mirsky
Date: 10/02/2016 04:18
To: Carlos Pignataro (cpignata);
Cc: Alexander Vainshtein;Andrew G. Malis;[email-masked];
Subject:RE: [Pals] PALS Working Group Last Call for draft-ietf-pals-seamless-vccv-01

Hi Carlos,
thank you for the most expedient response and your kind consideration of my comments.
Yes, MS-PW out the scope of this work – point taken.
Reading the diff rather than the document in its entirety is bit of a challenge. I second Sasha and encourage authors to publish the updated version.

                Regards,
                                Greg

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 09, 2016 6:00 PM
To: Gregory Mirsky
Cc: Alexander Vainshtein; Andrew G. Malis; [email-masked]
Subject: Re: [Pals] PALS Working Group Last Call for draft-ietf-pals-seamless-vccv-01

Hi, Greg,

Great discussion indeed — thanks for the comments, definitely help.

More inline.

On Feb 9, 2016, at 6:29 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos, Sasha, et. al,
very interesting discussion. Hope my in-line comments tagged GIM>> would help.

                Regards,
                                Greg

From: Pals [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, February 09, 2016 10:26 AM
To: Alexander Vainshtein
Cc: Andrew G. Malis; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pals] PALS Working Group Last Call for draft-ietf-pals-seamless-vccv-01

Sasha,

Thanks for the follow-up, and the useful comments. Please see inline.

On Feb 9, 2016, at 6:39 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,
Lots of thanks for a prompt response.

Please see some comments on the proposed changes inline below.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 09, 2016 1:18 PM
To: Alexander Vainshtein
Cc: Andrew G. Malis; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pals] PALS Working Group Last Call for draft-ietf-pals-seamless-vccv-01

[removing "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> as originally requested by Andy]

Sasha,

Thank you for reviewing and for your comments! This is what WGLCs are for.

I believe our working copy fixes all these issues. You can find HTML Diffs attached to this email, we can submit when Andy signals us to.
[[Sasha]] Well, this is for Andy to decide. Personally I would expect the WG LC to be done on the posted version of the draft, of course.

Indeed, we are cleaning up the “TBDs”. Here’s our disposition and follow-ups to your concerns. Note that there are some TBDs that you missed but we are also fixing.

1.a. Yes, this is our new text:

2.2.2.1.  Demultiplexing

   Demultiplexing of S-BFD is achieved using the PW context, following
   the procedures in Section 7.1 of [I-D.ietf-bfd-seamless-base].

1.b. Why? I do not want to be overly limiting for no real reason, blocking future uses and ideas.
[[Sasha]] It is up to you and your co-authors to decide whether more than one S-BFD session per PW is required, of course.  The text you’ve proposed seems a bit ambiguous to me because Section 7.1. of the base draft states that the Reflector always demultiplexes based on received Your Discriminator value. Adding that this is done using the PW context could be interpreted as if advertised Discriminator values can overlap for different PWs. Is this indeed your intent?

See the response that follows below regarding multiple discriminators.

The uniqueness bit is well covered in Section 4.1. of draft-ietf-bfd-seamless-base, titled "S-BFD Discriminator Uniqueness"
GIM>> I’ll differentiate SS-PW and MS-PW use cases. I think that regardless of S-BFD discriminator used multiple S-BFD over SS-PW would be breaking requirement expressed in Section 2 RFC 5881:
   Each BFD session between a pair of systems MUST traverse a separate
   network-layer path in both directions.  This is necessary for
   demultiplexing to work properly, and also because (by definition)
   multiple sessions would otherwise be protecting the same path.
For MS-PW case, in my view, multiple S-BFD sessions may be used if the abovementioned requirement can be complied with.

That’s a very good point, note that the doc clarifies this is scoped for SS-PW: “This document concerns itself with the S-BFD VCCV operation over single-segment pseudowires (SS-PWs)."

I do not think that RFC 5881 applies (since that is Traditional BFD for Single IP Hops), but I do see why you’d extrapolate.

This is actually something that is being solved directly in the bfs-seamless-base specification, so that solution will apply to all dependent documents, this one included. See DISCUSS from Alvaro.
[[Sasha]] Not sure to which DISCUSS you refer.

Apologies for the lack of precision and not giving enough context. I meant a DISCUSS position on another S-BFD document in the document set, about ISIS.

The net-net of that discussion (which happened not in PALS but on draft-ietf-bfd-seamless-base, applicable to all the bfd-seamelss documents, is the addition of the following text:

   The use of multiple S-BFD discriminators by a single network node is
   outside the scope of this document.

Since that text applies to draft-ietf-bfd-seamless-base, and that is a Normative reference to this document, that should address your comment.

2.a. Incorrect. S-BFD can be used with signaled PWs over an MPLS PSN. It is just not specified on how it is advertised with LDP TLVs. We are specifying the protocol constructs we are using, but you are free to specify the LDP distribution of S-BFD discriminators. I’m adding this paragraph to clarity:

2.2.2.3.  Advertisement of Target Discriminators using LDP

   The advertisement of the target discriminator using LDP is left for
   further study.  It should be noted that S-BFD can still be used with
   signaled PWs over an MPLS PSN, by provisioning of the S-BFD
   discriminators or by learning the S-BFD discriminators by other
   means.

In the highlighted text, “advertises” should be “can advertise"
[[Sasha]] Sorry, but I disagree. I do not think that manual configuration of the target discriminator from the remote side of a signaled PW is a reasonable approach. To the best of my recollection, the common practice with signaled PWs is that you learn all the information associated with the remote endpoint via signaling. From my POV if one of the S-BFD CV types is signaled by a Reflector PW endpoint, it should be accompanied by the range of target discriminators. Alternatively you could restrict the draft for just one S-BFD session per PW (probably covering 99.99% of the use cases) and use some hard-coded target discriminator value.

Sasha, it seems to me you are mixing up two independent issues, and sprinkling some misconceptions on top.

Let me attempt to clarify.

First, this document concerns itself with:

   This document extends the procedures and Connectivity Verification
   (CV) types already defined for Bidirectional Forwarding Detection
   (BFD) for Virtual Circuit Connectivity Verification (VCCV) to define
   Seamless BFD (S-BFD) for VCCV.
It does not attempt to solve the distribution of S-BFD discriminators. It does list potential ways of doing it, and in the case of L2TPv3, a preferred one.

For MPLS, LDP is potentially one way of distributing discriminators. Interestingly, if you look at RFC 5884, traditional BFD uses MPLS LSP Ping for doing the discriminator learning, and not, say, LDP.
GIM>> BFD bootstrap in RFC 5884 required to establish mapping between source and discriminator thus avoiding ambiguity resulting from PHP or use of explicit null label. I believe that there’s no apparent need to use LSP bootstrap for VCCV (S-)BFD.

Correct.

The second topic being mixed up is about S-BFD sessions per PW, which I believe was the previous comment.

The additional clarification is that you talk about a “range of target discriminators” — but there is not such a thing as a “range”.

[BTW, I had pointed to you in a separate thread on a separate document that strictly following common practice is a wonderful recipe to not innovate :-) Let’s continue discussing technical merits, but ‘common practice is to signal’ does not seem to stand on firm ground]

Net-net, specifying CV Type is independent of how discriminators are learned.

GIM>> I agree, that enhancing list of available CV Types is necessary to enable use of S-BFD over PW. And I agree with Sasha that providing companion extension to LDP in this document is logical thing to expect since L2TPv3 extension already documented. Perhaps moving proposal regarding L2TPv3 extension into a new document that would include, at some day, LDP extension to advertise S-BFD Discriminator (or group of them) may be viable option to consider.

There’s a slight misunderstanding.

This document, draft-ietf-pals-seamless-vccv-01, only includes CV Types for MPLS and L2TPv3.

A separate document, draft-ietf-l2tpext-sbfd-discriminator, specifies the Discriminator advertisement using L2TPv3.

This is good document modularity.

If someone is interested in the S-BFD Discriminator advertisement using LDP, then by all means he or she should pursue it.

So, the L2TPv3 extensions are *not* documented in this document. They are moved out already into an L2TPEXT document. There is no plan to include LDP into that document, any day.

Thanks!

— Carlos.

2.b. Again, why “resolve” something we are not requiring at this point?
[[Sasha]] One reason is that you resolve this issue for L2TPv3 PWs☺…

Please see above.

Reality is that there is a document specifying a way to distribute discriminators for L2TPv3, but for LDP-based PWs, it has not been studied yet. That’s what the document says.

If further says that any way in which these are learned, it is orthogonal to the CV VCCV advertisement.

If this is not clear from the document, which is absolutely possible, would you please propose some text?

Another alternative is to define only the L2TPv3 CVs and forget the MPLS ones. I believe we are going the extra mile in defining the most general approach.

Additional comment — yes, but I prefer to remove the section # directly.
[[Sasha]] My objection was about a reference to the TBD section in a draft that is currently under IESG consideration. You can provide specific section number(s) or you can drop sections altogether, but the current state definitely looks strange☺…

I understood. As I said, removing the section # is best.

The current text reads:

      S-BFD Reflector operation for BFD protocol fields MUST be
      according to the specifications of [I-D.ietf-bfd-seamless-base].

Thanks,

— Carlos.

Thanks,

— Carlos.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 10 Feb 2016 15:46:00 +0000

Carlos and all,
I have looked up the latest (-07) revision of the base S-BFD draft that has been posted today.

One of the changes when compared to the previous version is in the last para of Section 3. It says:

When a node allocates multiple S-BFD discriminators, how remote nodes determine which of the discriminators is associated with a specific
entity is currently unspecified.  The use of multiple S-BFD discriminators by a single network node is therefore discouraged  until a means of learning the mapping is defined.

I wonder how this (admittedly, non-normative) statement should  be interpreted in the context of the draft we are discussing, especially for signaled PWs over MPLS PSN.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Alexander Vainshtein
Sent: Wednesday, February 10, 2016 9:22 AM
To: Gregory Mirsky; Carlos Pignataro (cpignata)
Cc: Andrew G. Malis; [email-masked]
Subject: Re: [Pals] PALS Working Group Last Call for draft-ietf-pals-seamless-vccv-01

Greg, Carlos and all,

Just a short question:

My 2c

Thumb typed on my LG,
Sasha

------ Original message ------
From: Gregory Mirsky
Date: 10/02/2016 04:18
To: Carlos Pignataro (cpignata);
Cc: Alexander Vainshtein;Andrew G. Malis;[email-masked];

                Regards,
                                Greg

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 09, 2016 6:00 PM
To: Gregory Mirsky
Cc: Alexander Vainshtein; Andrew G. Malis; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pals] PALS Working Group Last Call for draft-ietf-pals-seamless-vccv-01

Hi, Greg,

More inline.

                Regards,
                                Greg

Sasha,

Carlos,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

2.2.2.1.  Demultiplexing

Correct.

Thanks!

— Carlos.

Please see above.

The current text reads:

Thanks,

— Carlos.

Thanks,

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 11 Feb 2016 05:03:55 +0000

Sasha,

This is a great question!

My initial reaction is that FAT PWs are out of scope for this document as far as multiple S-BFD discriminators. FAW PWs are not considered or included in RFC 5885, so I think FAT PW work should scope both BFD and S-BFD. They are considered but only as far as https://tools.ietf.org/html/rfc6391#section-7

I will add a sentence about it.

Thanks,

— Carlos.

> On Feb 10, 2016, at 2:22 AM, Alexander Vainshtein <[email-masked]> wrote:
> 
> Greg, Carlos and all,
> Just a short question:
> Cc: Alexander Vainshtein;Andrew G. Malis;[email-masked] <mailto:[email-masked]>;
> From: Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
> Cc: Alexander Vainshtein; Andrew G. Malis; [email-masked] <mailto:[email-masked]>
> On Feb 9, 2016, at 6:29 PM, Gregory Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From: Pals [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Carlos Pignataro (cpignata)
> Cc: Andrew G. Malis; [email-masked] <mailto:[email-masked]>
> On Feb 9, 2016, at 6:39 AM, Alexander Vainshtein <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Carlos,
> Email:   [email-masked] <mailto:[email-masked]>
> 
> From: Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
> Cc: Andrew G. Malis; [email-masked] <mailto:[email-masked]>
> [removing "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> as originally requested by Andy]
> 
> Sasha,
> 
> [[Sasha]] One reason is that you resolve this issue for L2TPv3 PWsJ…
> 
> Please see above.
> 
> [[Sasha]] My objection was about a reference to the TBD section in a draft that is currently under IESG consideration. You can provide specific section number(s) or you can drop sections altogether, but the current state definitely looks strangeJ…
> 
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 11 Feb 2016 05:03:59 +0000

Sasha,

Another good point — instead of leaving up for interpretation, we should explain the implication directly in the PALS draft.

I think that specifically, we should call out the single disc per PW — connecting with your other email, things like FAT PWs are good cases for multiple disc per PW, but there needs to be an interoperable way of establishing the mapping of Flow to S-BFD Disc.

Thanks,

— Carlos.

> On Feb 10, 2016, at 10:46 AM, Alexander Vainshtein <[email-masked]> wrote:
> 
> Carlos and all,