creola
Uploaded by
9 SLIDES
226 VUES
90LIKES

Multi-Protocol Next Hop Attribute Specification

DESCRIPTION

The Multi-Protocol Next Hop (MP_NH) attribute draft introduces a method to advertise next-hop network addresses across different Address Families (AFIs) in networking protocols such as BGP. It outlines a structured format for encoding next-hop information, allowing for multi-homed networks and better integration of IPv4 and IPv6 addressing schemes. The draft addresses specific applications needing diverse next-hop advertising, proposing a flexible mechanism to convey path attributes and associated parameters for multiple next hops within the same routing update, enhancing routing efficiency and protocol versatility.

1 / 9

Télécharger la présentation

Multi-Protocol Next Hop Attribute Specification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Multiprotocol Next Hop Attribute (MP_NH)draft-lefaucheur-multiprotocol-nh-00.txt Francois Le Faucheur Dan Tappan Gargi Nalawade

  2. MP_REACH_NLRI +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier| +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Number of SNPAs (1 octet) | +---------------------------------------------------------+ | Length of first SNPA(1 octet) | +---------------------------------------------------------+ | First SNPA (variable) | +---------------------------------------------------------+ | Length of second SNPA (1 octet) | +---------------------------------------------------------+ | Second SNPA (variable) | +---------------------------------------------------------+ | ... | +---------------------------------------------------------+ | Length of Last SNPA (1 octet) | +---------------------------------------------------------+ | Last SNPA (variable) | +---------------------------------------------------------+ | Network Layer Reachability Information +---------------------------------------------------------+ * Single AFI/AFI * Single Next Hop

  3. Next Hop of Different AFI than NLRI • Some applications need to advertise a Next Hop of different AFI than NLRI • Existing applications have worked their way around: • “VPN-V4 over V4” does this by padding RD=0 • “V6 over V4” does this by embedding v4@ inside v6@ • “VPN-V6 over v4” does this by padding RD=0 and embedding v4@ into v6@ • Some new applications won’t be able to work their way around in the same manner (v6@ doesn’t fit!): • “V4 over V6”, • “VPN-V4 over V6”  Need to signal AFI for Next Hop & AFI for NLRI

  4. Advertising Multiple Next Hops • Possible applications for advertising multiple next hops: • advertise @ in multiple protocols for a given next hop (eg advertise both a v4@ and v6@ for a given next-hop on a dual stack core) • advertise multiple next-hops of same AFI for multipaths  Need to be able to signal multiple next hops for given NLRI

  5. Avertising next-hop related parameters • Some possible applications that may benefit from advertising next-hop related parameters: • different labels for different next-hops • different path attributes for different next-hops  need to be able to convey per next hop information (eg.TLVs) for one or more next hops

  6. Reserved-1 (Number of Next Hops) Length of Next Hop (2octets) AFI (2octets) SAFI (1octet) Length of Next Hop Address (1octet) Network Address of Next Hop(variable) Set of Next Hop TLVs (variable) MultiProtocol_Next_Hop attribute

  7. Notes • Does not suggest that existing applications (eg VPN-v4) have to be modified to use new attribute • Effectively goes back to separating next-hop info from NLRIs (like the original NEXT_HOP attribute in BGP)

  8. Next Steps • Get feed-back ! • Update migration approach using BGP Capability Negotiation? • “MultiProtocol_NH”  “Generalised_NH”

  9. Thank You !

More Related