Hello Dhananjaya, Thanks a lot for your clarification, and references! I'm glad to know that the described case is going to be fully covered by the document. I've recently read both of the referred documents (a previous problem statement draft, and the SR-TE one), and it seems to me that an explanation in the SR-TE is more explicit and clear. If it's possible to preserve this style (maybe in a different way) for Section 6.2 it will be really helpful.
Hope it helps. вс, 17 июл. 2022 г. в 12:26, Dhananjaya Rao (dhrao) <dh...@cisco.com>: > Hi Igor, > > > > Thank you for the quick review. Please see inline (DR##) > > > > *From: *BESS <bess-boun...@ietf.org> on behalf of Igor Malyushkin < > gmalyush...@gmail.com> > *Date: *Sunday, July 17, 2022 at 2:50 AM > *To: *"Dhananjaya Rao (dhrao)" <dhrao=40cisco....@dmarc.ietf.org> > *Cc: *"b...@ietf.org" <b...@ietf.org> > *Subject: *Re: [bess] New draft > "draft-hr-spring-intentaware-routing-using-color" > > > > *Accidently unicasted the previous message to Dhananjaya, replying to the > group.* > > > > Hello Dhananjaya, > > > > Can you please clarify some moments in Section 6.2? First, I don't see any > sign of Section 5.1.9 (also referred to in Section 6.3.1.7) in the > document. Looks like missed. > > > > DR ## Thanks; yes, it was a reference to Section 5.9. Missed updating > during conversion. Will be fixed in next revision. > > > > I'm interested in the next scenario. Let's suppose that for a service > instance (VPN or a global table) there are two ingress flows per single > destination. This destination is color-marked and resolved by an > intent-aware underlay. Also, there is a best-effort path as a fallback. > Using per-flow steering that is based on 5-tuple IP flow is it possible to > send ingress traffic from a source S1 via the intent-aware path, and > ingress traffic from a source S2 via a fallback (best-effort) path at the > same time? My reading of Section 6.2 shows me that it's not possible. But I > strongly believe that there are cases when an intent/colored path for a > distinct destination must be used only by the subset of members of service, > and the same destination must be available for the rest members of the > service via a best-effort path(s) only. I can show some business logic > behind this if you will. > > > > DR## Sending one IP flow for a destination via an intent-aware path while > sending another flow for the same destination via a best-effort path (or a > different intent-aware path) is a valid use-case, which is intended to be > covered. It was described more explicitly in > https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/ > Section 1.2.11, but reduced in the merged doc. We can make it more > explicit. > > > > In fact, this scenario is already supported by existing intent-aware > solutions such as SR-TE : > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22#section-8.6 > > > > Regards, > > -Dhananjaya > > > > > Hope it helps, and thank you! > > > > сб, 16 июл. 2022 г. в 07:15, Dhananjaya Rao (dhrao) <dhrao= > 40cisco....@dmarc.ietf.org>: > > > > Hello BESS folks, > > > > The co-authors of > https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/ > and https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/ > have published a merged problem statement document : > > > > > https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/ > > > > We request working group to review and provide your inputs. > > > > Regards, > > -Dhananjaya (for the co-authors) > > > > > > _______________________________________________ > BESS mailing list > b...@ietf.org > https://www.ietf.org/mailman/listinfo/bess > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
