Re: Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?
Robert Raszuk <[email protected]>
| Newsgroups | gmane.ietf.idr |
|---|---|
| Message-ID | <CAOj+MMGqKj=zKbws92ni1fL2O-So=dbcW-mb02uRnQ+G55xm_w@mail.gmail.com> |
Hey Srihari, > The presence of Tunnel Encapsulation attribute in an update that carries MP_REACH > attribute indicates the data path destined for prefixes encoded in the NLRI field of MP_REACH. My reading of Linda's point was a question regarding the case where for prefix A NLRI points to next hop NH_1 but tunnel endpoint says go to NH_2. Is such update still valid ? Has tunnel encapsulation attribute power to "overrule" BGP next hop from MP_REACH ? When BGP best path runs and validates NH_1 is basic next hop validation also performed on NH_2 before considering this path as valid ? When BGP selects such path as best and installs it to RIB does it install it with NH_1 or NH_2 ? Note that both next hops may be reachable via local IGP or even going further could be recursive via yet more BGP routes. Many thx, Robert. If a Destination address is already listed in the MP_RACH_NLRI, is it > listed again in the Tunnel Encap subTLV (if it can be reached via some > tunnel, such as VxLAN/GRE/? > > > > I’m not clear what you mean here. The MP_REACH provides the reachability > information while the Tunnel Encapsulation Attribute provides the Tunnel > details (remote-endpoint, encapsulation, etc). The presence of Tunnel > Encapsulation attribute in an update that carries MP_REACH attribute > indicates the data path destined for prefixes encoded in the NLRI field of > MP_REACH. > > > > Thanks. > > srihari… > _______________________________________________ Idr mailing list [email protected] https://www.ietf.org/mailman/listinfo/idr
image001.png
(image/png, 388.1 KB) - not displayed
image002.png
(image/png, 101.1 KB) - not displayed