search

ietf-wg-idr / draft-ietf-idr-bgp-ct

1 stars 2 forks source link

Section 4.2 Editorial comments #41

Closed suehares closed 8 months ago

suehares commented 9 months ago

9) Clarification Section 4.2.

An implementation may realize the TRDB e.g., as a "Routing Table" referred in Section 9.1.2.1 of RFC4271 [editor.org/rfc/rfc4271#section-9.1.2.1)] which is "only" used for resolving next hop reachability in control plane with no footprint in forwarding plane. However, an implementation may choose a different methodology to realize this logical construct while still adhering to the procedures defined in this document. **#Keyur:** This seems very rsvp specific? In case of pure segment routing where the control plane does carry nexthop specific information, this won’t be correct. Suggest removing everything from "with no footprint..." **Response from Kaliraj:** KV> Its not RSVP specific. Even SRTE routes in a TRDB don’t need to be installed to FIB as a FEC/destination. Only if they are resolved over by another overlay route, KV> it will be installed as nexthop. I can try to clarify this in the text.
suehares commented 9 months ago

Keyur's review Section 4.2.

SNs or BNs originate routes for 'Classful Transport' address family from the TRDB. These routes have NLRI "RD:Endpoint", Transport Class RT and an MPLS label (or an identifier that represents an equivalent of a label in a different forwarding architecture). **#Keyur:** It could be more than an identifier (Tunnel class and tunnel parameters). Curious as to why mention the text in ()? **Kaliraj respose:** text in () refers to other encaps like SID in SR forwarding architecture. It is denote support for different forwarding architectures.
kalirajv commented 8 months ago

reworded text as agreed during review call with Keyur, Sue:

These routes have "RD:Endpoint" in NLRI, transport-class and MPLS label...