Re: Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt [9/17 to 10/1/2019]

"Chengli (Cheng Li)" <[email protected]>
Newsgroups gmane.ietf.idr
Message-ID <C7C2E1C43D652C4E9E49FE7517C236CB026ECE14@dggeml509-mbs.china.huawei.com>
Hi Linda,

Many thanks for your comments. Will consider it in the future revision.

Best,
Cheng


From: Linda Dunbar [mailto:[email protected]]
Sent: Saturday, September 21, 2019 2:59 AM
To: Chengli (Cheng Li) <[email protected]>; Susan Hares <[email protected]>; 'idr wg' <[email protected]>
Subject: RE: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt [9/17 to 10/1/2019]

Cheng,

Thanks for the explanation.

if For data plane, Path Segment is one of the segments in the Segment List, But for Control plane, it is more like a resource or attributes.

Why not have a separate name to represent the "resource or attributes" of the path? Will it be more clear for future, for people who are not in today's IETF discussion?

Linda

From: Chengli (Cheng Li) <[email protected]<mailto:[email protected]>>
Sent: Friday, September 20, 2019 3:16 AM
To: Linda Dunbar <[email protected]<mailto:[email protected]>>; Susan Hares <[email protected]<mailto:[email protected]>>; 'idr wg' <[email protected]<mailto:[email protected]>>
Subject: RE: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt [9/17 to 10/1/2019]

Hi Linda,

Many thanks, please see my reply inline.

Best,
Cheng


From: Idr [mailto:[email protected]] On Behalf Of Linda Dunbar
Sent: Friday, September 20, 2019 3:57 AM
To: Susan Hares <[email protected]<mailto:[email protected]>>; 'idr wg' <[email protected]<mailto:[email protected]>>
Subject: Re: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt [9/17 to 10/1/2019]

I have read through both documents. I support WG adoption with the following comments:

Path Segment is one of the segments in the Segment List, correct?
[Cheng] For data plane, yes. But for Control plane, it is more like a resource or attributes.

But draft-li-idr-sr-policy-path-segment-distribution-01 has a statement saying that Path Segment can be a list of SIDs (Section 3 on Page 3). Does it mean that Path Segment can be mapped to multiple SIDs?
"The Path Segment can be used for identifying an SR path(specified by SID list)".
[Cheng] Depends on use cases. If we would like to measure the SR policy, then a Path Segment can map to an SR policy, and it will be shared by the SID lists within the SR policy.

The following statement of draft-li-idr-sr-policy-path-segment-distribution-01 seems to indicate that Path Segment is one of the Path attributes, just like an attribute for the Path QoS attribute, is it correct?
"For each SR path, it may also have its own path attributes, and Path Segment is one of them."
[Cheng] Correct.

draft-li-idr-bgp-ls-sr-policy-path-segment-03 has a statement in the Abstract stating that the document is to define ways for collecting configuration and states of SR policies by BGP-LS. So, it really not SR Policies Extensions (as stated in the title), is it?
[Cheng] I am not sure about what kind of extension belongs to SR policies extension. If I make a mistake, we can modify the title.
                 As my understanding , this extension is for collecting states of SR policies, then it is a SR policy extension.

Linda Dunbar



From: Idr [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Susan Hares
Sent: Wednesday, September 18, 2019 12:35 AM
To: 'idr wg' <[email protected]<mailto:[email protected]>>
Subject: [Idr] Adoption: draft-li-idr-bgp-ls-sr-policy-path-segment-03.txt and draft-li-sr-policy-path-segment-01.txt [9/17 to 10/1/2019]

This begins a 2 week WG Adoption call two related drafts [9/17 to 10/1/2019]
*         draft-li-bgp-ls-sr-policy-path-segment-03.txt and
*         draft-li-idr-sr-policy-path-segment-01.txt.

You can access these two drafts at the following location:

https://datatracker.ietf.org/doc/draft-li-idr-bgp-ls-sr-policy-path-segment/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-idr-bgp-ls-sr-policy-path-segment%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cfc71199bcad34efa093608d73da2c0d3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637045641561053885&sdata=3IIFnDFwEMatkK24DfoWTpj1JCQ4k60%2FpOnmqwUAjmo%3D&reserved=0>

https://datatracker.ietf..org/doc/draft-li-idr-sr-policy-path-segment/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker..ietf.org%2Fdoc%2Fdraft-li-idr-sr-policy-path-segment%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cfc71199bcad34efa093608d73da2c0d3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637045641561053885&sdata=GScgio9fqeJIVw0VoqcynIUFVe0pyP3v90QMhXRKF9M%3D&reserved=0>

The authors have pointed out that the adoption of this
draft since the following  SR-MPLS Path Segment draft has been adopted:

https://tools.ietf.org/html/draft-ietf-spring-mpls-path-segment-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-mpls-path-segment-00&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cfc71199bcad34efa093608d73da2c0d3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637045641561063877&sdata=iCZKAyty4%2FNOoN8RJbHBhyg%2BJrKH3cMQWnr%2BQ7N8Yzg%3D&reserved=0>

Please consider the following questions in your responses?

1)      Should this SR Policy technology be included in BGP for SR-MPLS



Spring has adopted the draft, but IDR can provide feedback

to spring about putting this technology in BGP.

2)      Is this technology a good way to implement the required

Features in BGP?


3)      Is this technology ready for adoption?


4)      Do you have any concerns about adopting this technology?



Cheers, Susan Hares

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.