Segment Routing Circle

  • 1.  Service Mapping with Transport RIBs

    Posted 08-11-2020 01:40

    Traffic Engineering is one of the most important features
    for the WAN networks. Once the TE tunnels are created and forwarding
    state is created on the routers, next most important thing is the ability
    to map the service prefixes onto appropriate Tunnels.

     

    The service mapping feature needs to be very flexible and
    should be able to accommodate variety of end user requirements
    and map them to the required behavior on the router.

     

    We have been working on new service mapping architecture in JUNOS which is
    flexible and easy to use.The new architecture uses
    Transport Class and Transport RIBs.

     

    Transport Class is a set of paths that setisfy certain constraint
    or certain SLAs.

    Transport RIB is a collection of tunnels that correspond to a
    Transport Class

    With this new architecture, TE tunnels created using various protocols such as
    SR-TE, RSVP, and flex-algo will be placed in corresponding Transport RIBs
    for example red.inet.3/blue.inet.3 and so on.

     

    Each Trasport Class has an associated color and the
    service prefix also carries the color extended community which automatically
    makes the service prefix resolve on the right Transport RIB.

     

    We are considering below requirements for this service mapping architecture
    and would be good to get feedback from this group on any additional requirements.
    Feedback and suggestions most welcome.

    Service Mapping Requirements
    -----------------------------------------------------------------------

    > DSCP based mapping with each DSCP mapping to a Transport Class.

    > DSCP based mapping with default mapping to a best-effort transport

    > DSCP based mapping with fallback to best-effort when primary
    transport tunnel goes down.

    > Extended color community based mapping with fallback to best
    effort

    > Fallback options with specific protocol during migrations

    > Falback options to a different Transport Class.

    > No Fallback permitted.

    > Firewall filter with 5-tuple mapping to a Transport class for
    global as well as VPN traffic


    More details can be found in below IETF drafts
    https://tools.ietf.org/html/draft-hegde-spring-mpls-seamless-sr-01
    https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes-01



  • 2.  Re: Service Mapping with Transport RIBs

     
    Posted 08-17-2020 09:27

    Hi all, 

     

    Any feedback on this important topic?  This is an active discussion in IETF as well and we would love to get inputs from broader customer community.

     

    --Sachin 



  • 3.  Re: Service Mapping with Transport RIBs

    Posted 08-17-2020 13:37

    Hi Schraddha

     

    The main feedback it's you to try to have support (co-editor) of other network vendors  in the  "BGP Classful Transport Planes" IETF draft.  In the Seamless SR draft I see AT&T, Google, Alibaba and others as your coauthor.  In our specific case we are very interested in Nokia (it's 50% of our main MPLS Network) and we tried several weeks ago

     

     

    #######################################

    We had the opportunity to listen and watch the Presentation of BGP Classful Transport before creation of SP-Circle forum
    and some of us were/are very interested in

    • [POI1] Transport RIB to solve the issues of Service-Mapping
    • [POI2] Having another approach for E2E TE in our Multi-Domain/IGP Network


    [POI1] was the most interesting for us to start with. If we understood correctly to you we even wouldn't need new sessions/AFI-SAFI, just Transport RIBs in the Ingress PE. At least 3 main advantages in our Multi-IGP.

     

    • [Adv1] Total coverage of MPLS Label Distribution Protocols (LDP, RSVP-TE, L-BGP, SR/SR-TE)
    • [Adv2] And all the VPN Services including old VPLS (sorry Lasserre flavor) that we still have in the Metro (pending FullFillment Systems to implement migration to E-VPN)
    • [Adv3] And all the fallback combinations: At least from RSVP-TE/SR-TE LSP to L-BGP (Default for old Seamless MPLS)
    • [Adv4?] There would be a fourth advantage if you confirmed it. Currently the only solution in our bi-vendor network  is to use Auxiliary Loopback Address (BGP NH) in the Egress PE if we want LSP to be used selectively for some subset of Service Instances in the Ingress PE.  With the Transport-RIBs in the Ingress PE combined with BGP Colors from the Egress PE we believe we could get rid of this extra Auxiliary IP Addresses in the ePE. That is BGP Color as demultiplexor instead of BGP NH

    ######################################
    [POI2] Regarding this Middle Layer Transport Label it seems a very logical next-step for Seamless MPLS based in L-BGP but still we need need to understand the CLI changes (we have some info for the TransportRIB) and how to reuse the Labele-BGP Session between  our Boder Nodes (Just a new AFI/SAFI with or without next-hop-selfm... )

     

    ################################### Service Mapping. Combinations
    Regarding Service mapping I think you consider more combinations that we were thinking of. I will only mention 2 extreme cases. Influenced by SR pressure we were thinking mainly in:

    1. Extended color community based mapping (SR-TE and RSVP-TE) with fallback to best
      effort when primary transport tunnel goes down..  Understanding in our case that BestEffort would be our L-BGP entry in inet.3
    2. For very specific cases a more granular solution that would be covered by your "Firewall filter with 5-tuple mapping to a Transport class for global as well as VPN traffic"

     

    ################################### Other vendor's position
    Our main concern is the endorsement in the IETF and SW Roadmap by other network vendors.
    We asked 2 of them more than 1 month ago:

    • [Vendor1] One hasn't provided any answer yet.
    • [Vendor2] The other has been analyzing the IETF draft and politely they have answered that they have a different strategy
      and so don't have any plan to implement it. That's even considering that they are no so far away from Transport RIBs because  it seems they have some of the building blocks already available.


    This is a problem in our network because having a solution that only works in 50% of it,  will be rejected directly by some of my colleagues or my manager.

    In any case I would like to test it in the Lab after been released (20.3/20.4?) and later try do have some of PoC/Demo in the Live Network (without real Customers) for the Transport RIB (POI1) in 1H-2021 because right now we don't know a better solution of Service-Mapping

     

     

    Regards

     

    Miguel



  • 4.  Re: Service Mapping with Transport RIBs

    Posted 08-18-2020 11:19

    Hi Miguel,

    Thanks for the comments.

    as you rightly pointed out, there are two independent aspects discussed in the
    Seamless SR draft.

    1. Service mapping
    2. E2E traffic engineering with BGP-CT

    1. Service Mapping
    Service mapping with Transport RIBs is mostly internal to the router.
    The protocol constructs used for service mapping are already standards, supported
    by most vendors. For example, a mapping-community is used to specify what kind of
    service mapping mechanism should be used. This mapping-community is a color extended
    community which is already a standard supported by most vendors.
    IMO, how the service mapping constructs are realised by the router are implementation depedent.
    We are planning to make the service mapping very flexible and satisfy all kinds of mapping and fallback
    requirements.However, you could imagine another vendor implementing a smaller subset of
    functionalities that still satisfies a good number of usecases. This wouldn't cause
    any inter-op issues.

    You rightly mentioned that this service mapping mechanism is applicable to all kinds of
    traffic-engineering mechanisms such as RSVP/SR-TE/Flex-algo/BGP-CT etc.

    We have basic building blocks of this service mapping mechanisms available and
    we can schedule time with you for a demo.


    2. E2E Traffic engineering with BGP-CT

    E2E Traffic engineering with BGP-CT requires support for new AFI/SAFI defined in BGP-CT.
    Ideally, the maximum benefit can be achieved when all the border nodes support BGP-CT in the network.
    However, one could imagine an evolutionary approach where initially only a subset of nodes support BGP-CT
    and inter-op with BGP-LU.
    We have a lot of customers interested in this mechanism. We are in the early stages of this draft and we are working on
    to get other vendors on-board as well.

    Rgds
    Shraddha