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

[Alexander Vainshtein <[e-mail]>]

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: [phone]
Cell:      [phone]
Email:   [e-mail]

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


Sasha,
On 03/01/2019 15:19, Alexander Vainshtein wrote:
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
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



Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Stewart Bryant <[e-mail]><mailto:[e-mail]>
Sent: Thursday, January 3, 2019 4:27 PM
To: Alexander Vainshtein <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Shell Nakash <[e-mail]><mailto:[e-mail]>; Jun Ye <[e-mail]><mailto:[e-mail]>
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:

   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: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


___________________________________________________________________________

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.
___________________________________________________________________________

___________________________________________________________________________

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.
___________________________________________________________________________