Hi Bruno,
Thank you very much for your valuable point.
We have updated the draft to address it.
Best Regards,
Huaimo
________________________________
From: bruno.decra...@orange.com <bruno.decra...@orange.com>
Sent: Thursday, February 10, 2022 5:40 AM
To: Huaimo Chen <huaimo.c...@futurewei.com>;
draft-hu-spring-segment-routing-proxy-forward...@ietf.org
<draft-hu-spring-segment-routing-proxy-forward...@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
[speaking as WG contributor]
Hi Huaimo,
Thanks for the follow up.
Please see one point inline [Bruno]
Orange Restricted
From: spring <spring-boun...@ietf.org> On Behalf Of Huaimo Chen
Sent: Wednesday, February 9, 2022 2:48 AM
To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>;
draft-hu-spring-segment-routing-proxy-forward...@ietf.org
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call -
draft-hu-spring-segment-routing-proxy-forwarding
Hi Bruno,
Thank you very much for your valuable comments.
My responses/explanations are inline below with [HC].
Best Regards,
Huaimo
on behalf of co-authors
________________________________
From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Sent: Tuesday, February 8, 2022 6:01 AM
To:
draft-hu-spring-segment-routing-proxy-forward...@ietf.org<mailto:draft-hu-spring-segment-routing-proxy-forward...@ietf.org>
<draft-hu-spring-segment-routing-proxy-forward...@ietf.org<mailto:draft-hu-spring-segment-routing-proxy-forward...@ietf.org>>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
[speaking as WG contributor]
Hi authors, all
I have some comments specific to the binding SID aspect.
§2
“ For a binding segment of a possible failed node, the node advertises
the information about the binding segment, including the binding SID
and the list of SIDs associated with the binding SID, to its direct
neighbors only. Note that the information is not advertised in the
network domain. »
§3.2.2
“For supporting binding SID proxy forwarding, a new IS-IS TLV, called
Binding Segment TLV, is defined. It contains a binding SID and a
list of segments (SIDs). This TLV may be advertised in IS-IS Hello
(IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP)
[RFC7356<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7356&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cee4806bcfe6143e86bba08d9ec81c58f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637800864401143210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ocQIQa5Qz0PwS5iKYOgW7WL9pCTnSrAEH%2BtYIVVoLmo%3D&reserved=0>].
»
>From an IS-IS standpoint, it seems to me that:
- Advertising it in the LSP PDU would flood the information in the whole
area/level, hence does not match the goal stated in §2
- Advertising it in the Hello PDU is not a reliable way to sync information
(except if duplicated in all hello which implies others issues such as lack of
space) and adding the reliability seem like a major change to IS-IS
In all cases, as already raised by Stéphane, this is a subject for the LSR WG.
[HC]: We will remove IS-IS Hello (IIH) PDUs and LSPs, and update the
related text accordingly.
More importantly, the binding SIDs are probably coming from “somewhere” such as
configuration, PCE, BGP, BGP-LS… Why not using the exact same signaling to
duplicate it on the neighbors? (this may probably require some extensions for
some protocols but a priori light ones and would not impact the IGP with
information which may not belong to the IGP.)
[HC]: Using the same signaling (configuration, PCE, or BGP, ...) to
duplicate it on the neighbors works well if there are sessions between
the neighbors and PCE, or BGP, ...
[Bruno] Indeed, signaling session would be needed. That seems doable à priori
(especially if we assume that BSID may already be needed on other nodes)
My point is that _today_, using BSID requires configuration/signaling of this
BSID on the BSID node itself and on all ingress nodes using it. None of these
signaling involves the IGP. So it’s not clear to me that IGP would be the
obvious choice specifically for the neighbors of the protected node, while a
different protocol would be used for the BSID on the protected and ingress
nodes. Theoretically feasible but, IMHO as a network operator subject, subject
to a risk of lack of feature parity in short and long term. At minimum I would
expect the document to (also) explore how this could be performed using the
protocols signaling the BSID on the protected node and ingress (e.g. PCE, BGP,
configuration). Also in my experience, the LSR WG is usually not that found of
using the IGP for configuration/signaling.
Thanks,
Regards,
--Bruno
Orange Restricted
From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On
Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Subject: [spring] WG adoption call -
draft-hu-spring-segment-routing-proxy-forwarding
Dear WG,
This message starts a 2 week WG adoption call, ending 27/01/2022, for
draft-hu-spring-segment-routing-proxy-forwarding
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hu-spring-segment-routing-proxy-forwarding%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cee4806bcfe6143e86bba08d9ec81c58f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637800864401143210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mhaqd%2F%2F6yZwZf5leZO11bs708jNSDe300L3RCSZZrA8%3D&reserved=0>
After review of the document please indicate support (or not) for WG adoption
of the document to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this
is a stronger way to indicate your (non) support as this is not a vote.
If you are willing to work on or review the document, please state this
explicitly. This gives the chairs an indication of the energy level of people
in the working group willing to work on the document.
Thanks!
Bruno, Jim, Joel
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
