[Idr] Re: Shepherd's review of draft-zhang-idr-sr-policy-enhanced-detnet-03

["zhangli (CE)" <[e-mail]>]

Hi Susan,
Thanks a lot for your kindly review, I will update the draft according to your comments recently.

For your question:

1.     Are you planning to add multicast (P2MP)to this draft?

Yes, I think this document should include P2MP, I will contact the authors of [draft-ietf-idr-sr-p2mp-policy].



2.     Are you planning to update the Unicast portion of the text?

Yes, I will update the unicast portion as you suggested.



3.     Do you wish to present at the IDR interim on SR and BGP-LS On September 9, 2024 [10:00-12:00 EDT]?

Oh, sorry for that I am busy on September 9, so maybe I can present it in the next meeting.

Best regards
Li
发件人: Susan Hares <[e-mail]>
发送时间: 2024年9月6日 12:28
收件人: [e-mail]
抄送: zhangli (CE) <[e-mail]>; Xuesong Geng <[e-mail]>; Lizhenbin <[e-mail]>
主题: Shepherd's review of draft-zhang-idr-sr-policy-enhanced-detnet-03

Li, Xuesong, and Robin:

Below I’ve provided a shepherd review for
draft-zhang-idr-sr-policy-enhanced-detnet.

Please let me know if you have any questions regarding
my review of this draft.

Would you answer a few questions for me:


1.   Are you planning to add multicast (P2MP)to this draft?

If so, the appropriate IDR draft to reference is:
[draft-ietf-idr-sr-p2mp-policy].

The authors of [draft-ietf-idr-sr-p2mp-policy]
have not updated this IDR draft for a while.
It would be good to contact them and let them
know you are interested in P2MP SR Candidate Routes.

Please note that P2MP (multicast) uses a different
NLRI (P2MP Policy) and a new tunnel type (P2MP Policy Tunnel.

I am asking this group to rename these to add “SR” to these names.
I will let you know once I’ve gotten a response from the authors.


2.   Are you planning to update the Unicast portion of the text?

3.   Do you wish to present at the IDR interim on SR and BGP-LS
On September 9, 2024 [10:00-12:00 EDT]?

I think your draft would benefit from a longer discussion.

Cheerily, Sue Hares


=============================
Shepherd Review for:
draft-zhang-idr-sr-policy-enhanced-detnet-03

status: individual draft,
Status: Proposed Standard,
version: revision needed (-04)
implementations: unknown
Authors: 3

Shepherd Detailed review

Issue-1.) Abstract changes to add [RFC9012]

Old text:/
   SR Policy is a set of candidate SR paths consisting of one or more
   segment lists and necessary path attributes.  It enables
   instantiation of an ordered list of segments with a specific intent
   for traffic steering.  DetNet provides the capability to carry
   specified unicast or multicast data flows with extremely low data
   loss rates and bounded end-to-end latency within a network domain.
   This document defines the SR policy enhancement to carry the Bounded
   Latency Information with a candidate path of SR policy.  So that BLI
   behavior can be enabled automatically when the SR Policy is applied./

new text:/
   SR Policy is a set of candidate SR paths consisting of one or more
   segment lists and necessary path attributes.  It enables
   instantiation of an explicit ordered list of segments with a specific intent
   for traffic steering.  BGP distributes the SR Policy for unicast
   Segment Routing (SR) paths via the SR-Policy NLRIs accompanied
   with the Tunnel Encapsulation attribute for the SR Policy Tunnel.
   For multicast SR paths, BGP distributes the SR P2MP NLRIs accompanied
   by the SR P2MP Policy tunnel.

   DetNet provides the capability to carry specified unicast or
   multicast data flows with extremely low data loss rates and
   bounded end-to-end latency within a network domain.
   This document defines the SR policy enhancement to carry the Bounded
   Latency Information with a candidate path of unicast and multicast
   SR paths. The distribution of the Bounded Latency Information (BLI)
   allows the behavior can be enabled automatically when the SR Policy
   is applied./


Issue-2. Sections 1-8 , needs to be updated to correct references.

[draft-ietf-spring-segment-routing-policy] has been replace by [RFC9256]
[draft-ietf-idr-segment-routing-te-policy] has been replaced by
[draft-ietf-idr-sr-policy-safi] and [draft-ietf-idr-sr-segtypes-ext].

Issue-3. Section 1, text needs to indicate what SR Policy is

Old text:/
   Segment Routing Policy is defined
   in[I-D.ietf-spring-segment-routing-policy].  A SR Policy is a set of
   candidate path which consist of one or more segment lists.  The
   headend node instructs the source routing and writes it into package.
   The packets steered into an SR Policy have an ordered list of
   segments associated with that SR Policy written into them. [RFC8655]
   provides the overall architecture for Deterministic Networking
   (DetNet), which provides the capability to carry specified unicast or
   multicast data flows with extremely low data loss rates and bounded
   end-to-end latency within a network domain. /
   /

New text:/
   Segment Routing (SR) Policy is defined in [RFC9256]. A SR Policy is a set of
   candidate path which consist of one or more segment lists.  The
   headend node instructs the source routing and writes it into SR Header.
   The packets steered into an SR Policy have an ordered list of
   segments associated with that SR Policy written into them./


   An explicit SR Candidate Path is described in [RFC9256] in section 5.1.
   BGP passes the explicit segment paths for unicast Segment Routing (SR) paths
   via the SR-Policy NLRIs accompanied with the Tunnel Encapsulation
   (Tunnel-Encaps) attribute with the SR Policy Tunnel type TLV
   for unicast traffic as defined in [draft-ietf-idr-sr-policy-safi]
   and augmented by [draft-ietf-idr-sr-segtypes-ext].  BGP pases the
   explicit segment paths for multicast SR paths via the
   SR P2MP Policy NLRI accompanied by the Tunnel-Encaps attribute
   for the SR P2MP Policy tunnel type as defined by
   [draft-ietf-idr-sr-p2mp-policy].


  [RFC8655] provides the overall architecture for Deterministic Networking
   (DetNet), which provides the capability to carry specified unicast or
   multicast data flows with extremely low data loss rates and bounded
   end-to-end latency within a network domain. (continue on with paragraph)/


 Old text at end of section:/
    This document defines the SR policy enhancement to carry the Bounded
   Latency Information with a candidate path of SR policy.  So that BLI
   behavior can be enabled automatically when the SR Policy is applied./

 new text:/
    This document defines a new sub-TLV for Segment List Sub-TLV
    that defines the Unicast Explicit SR Path for an SR candidates policy./

Note: If you intend to add this to multicast, then add the following text:

New-text-adition:
    This document defines a new Sub-TLV for the Segment List Sub-TLV that
     defines bounded latency information (BLI) that can be part of a
    Segment List Sub-TLV for a Unicast Explicit SR Candidate Policy.
    This new Sub-TLV for BLI can also be a part of the segment-list of
     the SR P2MP Tunnel TLV. /

Issue 4 - Section 4, fix references to Unicast SR Policy

[draft-ietf-idr-segment-routing-te-policy] has been replaced by
[draft-ietf-idr-sr-policy-safi] and [draft-ietf-idr-sr-segtypes-ext].

Issue-5 - Add a Section for P2MP - if you wish to add BLI to P2MP (multicast)


Issue-6: Add an operations or manageability section

Issue-6: Add a Security section
See [draft-ietf-sr-policy-safi] for ideas.
You do not need to add text that is in [draft-ietf-sr-policy-safi], but
you need to add security comments about BLI as new critical information.