[hp-wan] Re: You are welcome to HP-WAN side meeting ( Time : Thursday July 24 15:30-16:30 PM Madrid, Room: SEGOVIA)

[Brian E Carpenter <[e-mail]>]

> welcome to have further discussion with you at that side meeting

Unfortunately I am not in Madrid and will be asleep at that time anyway :-(.

Obviously I like GRASP and it was designed in as general a way as possible, but I think you need to advance much further on requirements before considering specific solutions.

(If anybody wants to learn about GRASP, there is a tutorial etc at https://github.com/becarpenter/graspy/tree/master/documentation. Some refactoring would be needed for an HP-WAN deployment.)

Regards
    Brian Carpenter

On 21-Jul-25 16:13, [e-mail] wrote:
> Hi Brian,
> 
> 
> Thanks for sharing your insightful points on RSVP and GRASP!
> 
> 
> 
> I think the key point may be that how to design the architecture of collebration signalling between host and network.
> 
> There are three options listed in https://www.ietf.org/archive/id/draft-xiong-hpwan-signaling-solution-00.html#name-host-network-collaboration- <https://www.ietf.org/archive/id/draft-xiong-hpwan-signaling-solution-00.html#name-host-network-collaboration->
> 
> The stitching mode may be deployed as you suggested. The P2P signaling (e.g GRASP and RSVP) can be provisioned between the client and the network edge node.The quota reservation signaling (e.g  RSVP) can be provisioned along the network nodes.
> 
> 
> It may has concerns like that it can not be performed along the end-to-end path involving the client and server. And the network edge node may interact with more than one clients and it requires to ensure consistency of resources.  Whether the clients and the network edge nodes can be viewed as management agents in application layer while the CC algorithm could consider the rate as a signal to adjust the sending rate after the signalling?
> 
> 
> I am not sure about the GRASP and welcome to have further discussion with you at that side meeting. Thanks!
> 
> 
> Best Regards,
> 
> Quan
> 
> 
> 
> 
> Original
> *From: *BrianECarpenter <[e-mail]>
> *To: *黄光平10039714;[e-mail] <[e-mail]>;
> *Cc: *[e-mail] <[e-mail]>;
> *Date: *2025年07月21日 04:30
> *Subject: **[hp-wan] Re: You are welcome to HP-WAN side meeting ( Time : Thursday July 24 15:30-16:30 PM Madrid, Room: SEGOVIA)*
> Daniel,
> 
>  > As far as the hp-wan framework is concerned, we always keep in mind a clear-cut line be carved out between the solution part at WIT and the part at Routing area, the existing solutions would be utilized to address the hp-wan resource reservation requirements, and the fine-grained coordination between host and network would be addressed at transport.
> 
> I would suggest that the last line should be:
> 
> "fine-grained coordination between host and network would be addressed at or above transport."
> 
> In my opinion, the underlying reason that RSVP (and the whole Integrated Services model) failed was because it was designed as part of the routing and transport infrastructure, instead of being designed as a network management application. That limited its capability, and thus only RSVP-TE has succeeded.
> 
> I think experience with software defined networking has already shown that this sort of signalling has to be treated as an application layer protocol between management agents. That's why we designed GRASP as we did, and I think the HP-WAN solution should be similar.
> 
> Regards
>      Brian Carpenter
> 
> On 21-Jul-25 05:43, [e-mail] wrote:
>  > Hi Joel and all,
>  > Thanks for sharing your thoughts and concerns about RSVP-based host and network coordination fo hp-wan services. As you points out the working states at both application and network side, we've currently actually not yet made any focused discussions, as well as the feasibility from perspectives of implementation, particularly whent it comes to RSVP extention.
>  > So I would agree with your concerns, we need to think and discussion them through before we draw a conclusion of the specific signalling solution itself.
>  > What the draft of RSVP is trying to demonstrate, is actually an instantiation of an hp-wan signalling mechanism, as well as how it generally works out for end2end hp-wan service flow regardless of its comprehensive applicabilities. What the hp-wan community has a rough concensus is the fundamental requirements, rather than the specific solutions. what the side meeting at Thursday after noon is trying to achieve, is further rough consensus upon pros and cons of the solutions options available for us, and what we could do in IETF, specifically a home for hp-wan.
>  > As far as the hp-wan framework is concerned, we always keep in mind a clear-cut line be carved out between the solution part at WIT and the part at Routing area, the existing solutions would be utilized to address the hp-wan resource reservation requirements, and the fine-grained coordination between host and network would be addressed at transport.
>  >
>  > Kind regards,
>  > Daniel Huang
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > Original
>  > *From: *JoelHalpern <[e-mail]>
>  > *To: *黄光平10039714;[e-mail] <[e-mail]>;
>  > *Date: *2025年07月18日 21:35
>  > *Subject: **Re: [hp-wan] You are welcome to HP-WAN side meeting ( Time : Thursday July 24 15:30-16:30 PM Madrid, Room: SEGOVIA)*
>  >
>  > As requested, I am taking this to the hp-WAN list.
>  >
>  > I am not trying to debate whether hp-wan is a good idea.  I       understand that for operators offering this specialized service it       can be useful.  I presume that one of the drafts makes clear that       this is not intended for the general Internet, but for these       special service offering networks.
>  >
>  > My concern is about what is the hard part of the work and where       it should be done.  Yes, there is some application work to be done       to define how applications know to emit these requests, and what       they do.  There is some encoding work to be done to define how the       requests are packaged.  But it seems to me that the primary work       is to specify the needed network behavior in response to these       requests.  Network behavioral requirements, and the challenges       around them, are what killed RSVP (as distinct from RSVP-TE.)  For       example, it is not at all clear how RSVP soft-state interacts with       the description that applications will send these messages before       they start sending data.  I presume they will keep refreshing       them?  (And what is the interaction between soft-state and the       time windows in this protocol?) And it is not clear what state the       routers in these specialized network offerings need to keep.
>  >    These points can be addressed.  My point is that these need to be       worked on in a working group that deals with network state.
>  >
>  > Yours,
>  >
>  > Joel
>  >
>  > On 7/18/2025 12:47 AM, [e-mail] wrote:
>  >> Hi           Joel,
>  >> I           would say WIT or Transport actually             is the home of RSVP https://datatracker.ietf.org/group/rsvp/about/,             though the working group has been concluded. Nevertheless,             why we do RSCP extensions for hp-wan in WIT, as the solution             draft demonstrates, is because majority of the extensions             are about the coordination between host and network.
>  >> When             it comes to the resource reservation part of RSVP, I agree             it shoud be done in Routing Area, but my preliminary             understanding is here're only light enhancement of RSVP from             the perspective of standardization, which could be addressed             with one single draft in Routing Area, like TEAS.
>  >> What           we want to further narrow down in Madrid side meeting, is           trying to reach rough consensus of the signalling solution           option, among which RSVP is a candidate, and what parts should           be done in WIT and RTG or OPS respectively.
>  >> Any           further comments and suggesitions would be appreciated very           much.
>  >>
>  >> By           the way, I would suggest our conversation be post to the           mailing list if you do not mind, since there could be other           people sharing the similar concerns.
>  >>
>  >> You're           welcome to join us for the side meeting at Thursday afternoon.
>  >>
>  >> Kind           regards,
>  >> Daniel           Huang
>  >>
>  >>
>  >>
>  >>
>  >>
>  >
>  > *From: *JoelHalpern <[e-mail]>
>  > *To: *黄光平10039714;
>  > *Date: *2025年07月17日 22:28
>  > *Subject: **Re:    [hp-wan] You are welcome to HP-WAN side meeting (    Time : Thursday July 24 15:30-16:30 PM Madrid,    Room: SEGOVIA)*
>  >
>  > I looked at the current signaling draft.  If I                  understand, the       signaling originates with the                  host application, which is why yo       reference the                  WIT area?  It seems unlikely that a WIT working                  group could be chartered to define RSVP extensions as                  described in       the signaling draft?
>  >
>  > Yours,
>  >
>  > Joel
>  >
>  > On 7/17/2025 12:58 AM, [e-mail]                  wrote:
>  >> Hi                                all,
>  >> Taking                                into consideration both the discussions                      from the side meeting           at Bangkok as well                      as mailing list and what we've narrowed                      down on hp-wan solutions, we will have another                      focused and           short side meeting at Madrid                      on what specifically could to be           done in                      IETF particularly in WIT area for HP-WAN.
>  >> The                                date, time and room for the side meeting                      are as following :
>  >> Date                                    and time: Thursday July 24 - PM                        15:30-16:30 (Madrid) (PM             21：30-22：30                        Beijing Time)
>  >> Location:                                    Room SEGOVIA
>  >> IETF                                    Webex: https://ietf.webex.com/meet/ietfsidemeeting1 <https://ietf.webex.com/meet/ietfsidemeeting1>
>  >>
>  >>
>  >> And                                    we have a gitHub for the hp-wan                        information and update             aggregation:
>  >> https://github.com/xiongquan1230/IETF123-Sidemeeting-HP-WAN/tree/main <https://github.com/xiongquan1230/IETF123-Sidemeeting-HP-WAN/tree/main>
>  >>
>  >> Look                                    forward to seeing you there, and
>  >> Have                                    a good and safe travel !
>  >>
>  >> Cheers,
>  >> Daniel                                    Huang
>  >>
>  >>
>  >> _______________________________________________
>  >> hp-wan mailing list -- [e-mail] unsubscribe send an email to [e-mail]
>  >
>  >
>  >
>  > _______________________________________________
>  > hp-wan mailing list -- [e-mail]
>  > To unsubscribe send an email to [e-mail]
> _______________________________________________
> hp-wan mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
>