Re: [Idr] are the Tunnel Encap Attribute in a BGP UPDATE applicable to all the NLRI listed in the MP_REACH_NLRI path attribute?

[John Scudder <[e-mail]>]

Hi Linda,

Per my recollection, and without checking back in the draft:


  1.  Yes.
  2.  Yes, although if I recall correctly there's a special case that lets you leave out the address in the case when address == next_hop, which is true in your example.
  3.  Yes, although you can avoid re-advertisement of the full set of affected NLRI by having R2 advertise a secondary loopback (let's call it R2') such that 10.1/16 and 10.2/16 have R2' as their next hop, and R2' has R2 as its next hop and carries the tunnel-encap attribute. If you use that approach, then only R2' needs to be re-advertised if the underlying tunnel changes. The two /16 NLRI recurse twice to get to the tunnel. This is described in the draft, I forget exactly where.

Regards.

--John
________________________________
From: Linda Dunbar <[e-mail]>
Sent: Tuesday, October 22, 2019 1:27 PM
To: John Scudder <[e-mail]>
Cc: Hares Susan <[e-mail]>; [e-mail] <[e-mail]>
Subject: are the Tunnel Encap Attribute in a BGP UPDATE applicable to all the NLRI listed in the MP_REACH_NLRI path attribute?


John,



Thank you very much for the explanation.



Just want to confirm my understanding:



Assume we have :  R1  ----- R2

where R2 is the next hop for 10.1.x.x/16 and  10.2.x.x./16

and R2 supports both GRE and VxLAN encapsulation.



R2 would send a BGP UPDATE with the following path attributes:



        Path Attribute - MP_REACH_NLRI    (Type Code=14)

  Next hop network address : R2

  Network layer reachability information:

10.1.x.x/16

10.2.x.x./16



        Path Attribute – Tunnel-Encap    (Type Code=23)

Tunnel-Type = VxLAN

Tunnel Endpiont Sub-TLV (4 octets for AS, 2 octets for Address family, Address?) /* is  the actual address = R2?*/

VxLAN’s MAC address sub-TLV

Tunnel-Type = GRE

Tunnel Endpiont Sub-TLV (4 octets for AS, 2 octets for Address family, Address?) /* is  the “Address” = R2?*/

GRE subTLV /*



Question:

  1.  does it mean that all the tunnel types listed in the Type-code =23 (Tunnel-Encap) are applicable to all the NLRIs in the update?
  2.  Does R2 appeal multiple times as “Tunnel Endpoint Sub-TLV”  under each Tunnel-Type?
  3.  When there are changes to the tunnel information carried by TUNNEL Path attributes, does it mean all the NLRI has to be repeated?



Thank you very much,



Linda Dunbar



From: John Scudder <[e-mail]>
Sent: Friday, October 11, 2019 12:39 PM
To: Linda Dunbar <[e-mail]>
Cc: Hares Susan <[e-mail]>
Subject: Re: Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?



In thinking about this further, I have a guess as to where the disconnect may be occurring. Let me try:



We use BGP updates to advertise reachability for given destinations. Let us recall the definition in RFC 4271:



   Route

      A unit of information that pairs a set of destinations with the

      attributes of a path to those destinations.  The set of

      destinations are systems whose IP addresses are contained in one

      IP address prefix carried in the Network Layer Reachability

      Information (NLRI) field of an UPDATE message.  The path is the

      information reported in the path attributes field of the same

      UPDATE message.



So, when a router is trying to forward a packet towards destination D, and it matches against its FIB, as far as BGP is concerned the prefixes in its FIB are derived exclusively from the NLRI portion of the BGP updates it’s received. The associated next hops are derived from the NEXT_HOP attribute, or from the tunnel-encaps attribute.



Addresses found within any attribute that is not NLRI, are not used as destinations.



Part of my confusion about your question comes from your use of the term “are in”, as in “prefixes … are in … the tunnel encapsulation attribute”. I don’t think there is a field in the tunnel encapsulation attribute that can even encode a prefix (other than a /32 IPv4 “prefix” or a /128 IPv6 “prefix”). So a prefix can’t be physically in the attribute. A prefix can be “in” a tunnel in the sense of, the prefix is in the NLRI and the tunnel attribute is in the same update as that NLRI, and therefore the prefix is logically paired with the tunnel according to section 5 of the draft.



HTH,



—John





On Oct 11, 2019, at 12:34 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:



John,



Thank you very much for the explanation.



My question is:

If prefixes A, B, and C are in tunnel T in the tunnel encapsulation attribute under Next Hop R2, can Prefixes A, B, C also appear under the NLRI field under Next Hop R2? Assuming that R2 is the next hope for prefixes A, B, C and R2 supports tunnel T encapsulations (say GRE, VxLAN, etc.).



When R1 receives this Update with both NLRI (Code 14) and Tunnel Encapsulation attribute (code 23), does it mean R1 can use either plain forwarding or the tunnel T forwarding for the prefixes A, B, C?





Thank you.



Linda





From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 10, 2019 7:58 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Hares Susan <[e-mail]<mailto:[e-mail]>>
Subject: Re: Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?



Hi Linda,



This is a quick reply, without referring to the draft since it’s getting late here but I want to answer. That said, I’m reasonably confident.



- The tunnel encapsulation attribute does NOT replace the “Network Layer Reachability Information” field of MP_REACH_NLRI. It is its own path attribute.

- So yes, it is listed at the same level as MP_REACH_NLRI (Code Point 14) in the Path Attributes lists.

- You can think of the tunnel encapsulation attribute as being kind of a replacement for the NEXT_HOP in the update. So, let’s say the update contains prefixes A, B, and C in the NLRI field, and tunnel T in the tunnel encapsulation attribute. This means packets for prefixes A, B, and C should be forwarded through tunnel T. (Actually I think it is “must be forwarded” but there may be some exception allowing fallback to regular forwarding if the tunnel type isn’t supported, I forget.)



Hope this helps.



—John




On Oct 10, 2019, at 6:59 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:



John and Sue,



Do you know the answer to my question? Can you get the authors to respond to my question posted on the list?



Thank you very much.



Linda



From: Linda Dunbar
Sent: Wednesday, October 09, 2019 3:26 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?



Dear authors:

draft-ietf-idr-tunnel-encaps specifies the The Tunnel Encapsulation attribute as an optional transitive BGP Path

attribute, with code point 23.

Does it mean Tunnel Encapsulation Attribute is listed at the same level as MP_REACH_NLRI (Code Point 14) in the Path Attributes lists shown in the following captured packets from Wireshark? 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/?





<image004.png>





Does the Tunnel Encapsulation Attributes have the same fields as MP_REACH_NLRI (RFC4760)?

Or the Tunnel Encapsulation Attributes is the “Network Layer Reachability Information” field of MP_REACH_NLRI?



<image006.png>





Thank you very much,



Linda Dunbar




Juniper Business Use Only