Subject: Re: [mpls] A question about draft-ietf-mpls-sfl-framework

From: Stewart Bryant <[email-masked]>
Date: Thu, 3 Jan 2019 14:27:10 +0000

On 25/12/2018 11:45, Alexander Vainshtein wrote:
>
> Dear authors of draft-ietf-mpls-sfl-framework 
> <https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>,
>
> I have a question about use of Synonymous Flow Labels in the when 
> application labels are present.
>
> The relevant text in Section 4.1 of the draft says:
>
>    At the egress LSR the LSP label is popped (if present).  Then the SFL
>
>    is processed in exactly the same way as the corresponding application
>
>    label would have been processed.
>
> If the application label has been statically configured in the egress 
> LSR,  then, presumably, so would be each of the Synonymous labels.
>
Yes.
>
> However, if the application label has been dynamically allocated by 
> the egress LSR and advertised to ingress LSR using some control plane 
> mechanisms, then the synonymous labels would also have to be 
> dynamically allocated and advertised by the same control plane mechanisms.
>
Not necessarily.

We had a proposal for a simple control plane that I propose to refresh:

https://tools.ietf.org/html/draft-bryant-mpls-sfl-control-02

The idea with this is that the application control protocol runs as 
normal and this protocol modifies the label for SFL purposes.

There was a lot of interest in the WG at the time for modifying each and 
every control protocol, but there is not much interest in writing the 
drafts needed to do it.

> The draft in question is a framework draft and does not discuss any 
> control plane issues (at least I have not found any mention of such 
> issues in the text).
>
> I wonder if any work on control plane mechanisms for advertisement of 
> synonymous labels is going on or planned. ( A quick search in the 
> documents of the MPLS, BESS and PALS WGs did not find any relevant 
> documents).
>
Only the one I cite above.

I would be more than willing to work with anyone (actively or just as a 
reviewer) that wanted to write the control plane drafts.

> If the intended applicability of the SFL framework is just for 
> statically configured application labels, this should be explicitly 
> stated in the draft IMHO.
>
No, I think the intent was always that there would be a control plane if 
needed.

Best regards

Stewart

> Your timely feedback would be highly appreciated.
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   [email-masked]
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 3 Jan 2019 15:19:49 +0000

Stewart,
Lots of thanks for a very detailed response.

I have completely missed the (now expired) SFL Control draft. It looks to me as a reasonable approach for applying SFL to PWs (and PW-based services) and LSPs.
But using it with BGP-based services, be it BGP/MPLS IP VPN or EVPN (including EVPN-based VPWS services) would be non-trivial IMHO:

-          There are no (bi-directional) PWs in these services

-          There may be no end-to-end tunnel LSPs (e.g., if inter-AS Option B is used)

-          Sending SFL Request messages with GAL and ACH following the VPN application label is possible, but I do not see how the Reply can be sent back

-          I do not think these messages can be piggy-backed on MP-BGP (even if these days lots of things are).
Did I miss something?

Regards,
Sasha

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

From: Stewart Bryant <[email-masked]>
Sent: Thursday, January 3, 2019 4:27 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]; Shell Nakash <[email-masked]>; Jun Ye <[email-masked]>
Subject: Re: A question about draft-ietf-mpls-sfl-framework

On 25/12/2018 11:45, Alexander Vainshtein wrote:
Dear authors of draft-ietf-mpls-sfl-framework<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>,
I have a question about use of Synonymous Flow Labels in the when application labels are present.
The relevant text in Section 4.1 of the draft says:

If the application label has been statically configured in the egress LSR,  then, presumably, so would be each of the Synonymous labels.
Yes.

However, if the application label has been dynamically allocated by the egress LSR and advertised to ingress LSR using some control plane mechanisms, then the synonymous labels would also have to be dynamically allocated and advertised by the same control plane mechanisms.

Not necessarily.

The idea with this is that the application control protocol runs as normal and this protocol modifies the label for SFL purposes.

There was a lot of interest in the WG at the time for modifying each and every control protocol, but there is not much interest in writing the drafts needed to do it.

The draft in question is a framework draft and does not discuss any control plane issues (at least I have not found any mention of such issues in the text).
I wonder if any work on control plane mechanisms for advertisement of synonymous labels is going on or planned. ( A quick search in the documents of the MPLS, BESS and PALS WGs did not find any relevant documents).

I would be more than willing to work with anyone (actively or just as a reviewer) that wanted to write the control plane drafts.

If the intended applicability of the SFL framework is just for statically configured application labels, this should be explicitly stated in the draft IMHO.

No, I think the intent was always that there would be a control plane if needed.

Best regards

Stewart

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

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

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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 3 Jan 2019 16:15:14 +0000

Sasha,

On 03/01/2019 15:19, Alexander Vainshtein wrote:
> I have completely missed the (now expired) SFL Control draft. It looks 
> to me as a reasonable approach for applying SFL to PWs (and PW-based 
> services) and LSPs.
>
> But using it with BGP-based services, be it BGP/MPLS IP VPN or EVPN 
> (including EVPN-based VPWS services) would be non-trivial IMHO:
>
> -There are no (bi-directional) PWs in these services
>
No, but to do a performance measurement we need to establish a label 
that is unique to the pair.
>
> -There may be no end-to-end tunnel LSPs (e.g., if inter-AS Option B is 
> used)
>
If it is interAS there may be a security issue, but Section 4 specifies 
the use of the RFC6374 return address TLV so we can get the message to 
the responder on the normal LSP and get the reply back using IP.

> -Sending SFL Request messages with GAL and ACH following the VPN 
> application label is possible, but I do not see how the Reply can be 
> sent back
>
> -I do not think these messages can be piggy-backed on MP-BGP (even if 
> these days lots of things are).
>
> Did I miss something?
>
Please look at section 4. The only concern I have is whether I need to 
add security to the system to cope with the inter AS case.

Best regards

Stewart

> *From:*Stewart Bryant <[email-masked]>
> *Sent:* Thursday, January 3, 2019 4:27 PM
> *To:* Alexander Vainshtein <[email-masked]>; 
> [email-masked]
> *Cc:* [email-masked]; Shell Nakash <[email-masked]>; Jun Ye 
> <[email-masked]>
> *Subject:* Re: A question about draft-ietf-mpls-sfl-framework
>
>     If the application label has been statically configured in the
>     egress LSR,  then, presumably, so would be each of the Synonymous
>     labels.
>
> Yes.
>
>     However, if the application label has been dynamically allocated
>     by the egress LSR and advertised to ingress LSR using some control
>     plane mechanisms, then the synonymous labels would also have to be
> There was a lot of interest in the WG at the time for modifying each 
> and every control protocol, but there is not much interest in writing 
> the drafts needed to do it.
>
>     The draft in question is a framework draft and does not discuss
>     any control plane issues (at least I have not found any mention of
>     such issues in the text).
>
>     I wonder if any work on control plane mechanisms for advertisement
>     of synonymous labels is going on or planned. ( A quick search in
>     the documents of the MPLS, BESS and PALS WGs did not find any
>     relevant documents).
>
> I would be more than willing to work with anyone (actively or just as 
> a reviewer) that wanted to write the control plane drafts.
>
>     statically configured application labels, this should be
>     explicitly stated in the draft IMHO.
>
>     <mailto:[email-masked]>
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 3 Jan 2019 16:31:29 +0000

Stewart,
Lots of thanks for a prompt response.

Please note that in inter-AS Option B (and Option A) there are no PE-to-PE tunnel LSPs between PEs in different AS (obvious in Option A where the link between AS simply does not support MPLS).

I see two possibilities for IP VPNs

1.       The address TLV carries the (globally) routable  address of the Querier PE. In this case you can send the Reply using some form of an IP tunnel, e.g., MPLS-in-GRE. Security issues can be non-trivial

2.       The address TLV carries some stable IP address in the "Querier VRF" that is reachable from the Responding VRF (i.e. the responding VRF has a labeled IP route with this address as its destination prefix. In this case you can send the Reply using GAL and GACH under the application label for this address.
The first of these options would work also for EVPN, the 2nd will not (or so I think).

Does this make any sense to you?

Regards,
Sasha

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

From: Stewart Bryant <[email-masked]>
Sent: Thursday, January 3, 2019 6:15 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; Shell Nakash <[email-masked]>; Jun Ye <[email-masked]>; [email-masked]
Subject: Re: A question about draft-ietf-mpls-sfl-framework

Sasha,

-          There are no (bi-directional) PWs in these services
No, but to do a performance measurement we need to establish a label that is unique to the pair.

If it is interAS there may be a security issue, but Section 4 specifies the use of the RFC6374 return address TLV so we can get the message to the responder on the normal LSP and get the reply back using IP.

Please look at section 4. The only concern I have is whether I need to add security to the system to cope with the inter AS case.

Best regards

Stewart

Regards,
Sasha

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

From: Stewart Bryant <[email-masked]><mailto:[email-masked]>
Sent: Thursday, January 3, 2019 4:27 PM
To: Alexander Vainshtein <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]><mailto:[email-masked]>; Jun Ye <[email-masked]><mailto:[email-masked]>
Subject: Re: A question about draft-ietf-mpls-sfl-framework

Not necessarily.

Best regards

Stewart

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