Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

From: [email-masked]
Date: Mon, 18 Nov 2019 22:25:12 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : Advertising Segment
    Routing Policies in BGP
        Authors         : Stefano Previdi
                          Clarence Filsfils
                          Ketan Talaulikar
                          Paul Mattes
                          Eric Rosen
                          Dhanendra Jain
                          Steven Lin
	Filename        : draft-ietf-idr-segment-routing-te-policy-08.txt
	Pages           : 38
	Date            : 2019-11-18

Abstract:
   This document defines a new BGP SAFI with a new NLRI in order to
   advertise a candidate path of a Segment Routing (SR) Policy.  An SR
   Policy is a set of candidate paths, each consisting of one or more
   segment lists.  The headend of an SR Policy may learn multiple
   candidate paths for an SR Policy.  Candidate paths may be learned via
   a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP.
   This document specifies the way in which BGP may be used to
   distribute SR Policy candidate paths.  New sub-TLVs for the Tunnel
   Encapsulation Attribute are defined for signaling information about
   these candidate paths.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-segment-routing-te-policy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-08
https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-segment-routing-te-policy-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 19 Nov 2019 08:08:34 +0000

Hi All,

This update of the draft is to get it ready for the WG to review towards WGLC .

The following is the high level overview of the changes:

1) Introduced Error Handling section where all these aspects have been consolidated.

2) Added the request for IANA registry for Color Extended Community reserved field. Changed the process to Specification Required and added DE guidelines since the flags and other space is too small for FCFS.

3) Added security consideration section.

4) Add the clarification for handling of route target during propagation as per the request and discussions on the mailer and also clarified the matching with BGP Router ID part.

5) Changed the segment type naming from numbers to alphabets to align with upcoming update in the draft-ietf-segment-routing-policy to remove confusion between the segment types and the protocol code-points as discussed on the Spring and IDR lists recently.

Besides this, there are other minor and editorial changes to prepare for WGLC.

We are also trying to capture all the implementation reports at the wiki below and would request WG members to help update the same as there are multiple shipping implementations of this specification:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-segment-routing-te-policy%20implementations%20

Also note that the draft is on IDR agenda for presentation on Thu in Singapore.

Thanks,
Ketan (on behalf of co-authors)

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of [email-masked]
Sent: 19 November 2019 14:25
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Nandan Saha <[email-masked]>
Date: Tue, 19 Nov 2019 22:16:38 +0530

Hi Ketan,
 Thank you for the updated version. I'm still reviewing it, but spotted
something I wanted to quickly clarify.

ver-7 of section "4.2.1. Acceptance of an SR Policy NLRI" had text
mandating RFC7606 TAW if acceptance criteria fail. In ver-8 this has been
removed, and I can't quite tell what text in section "5 Error Handling"
covers this? I'm assuming we still want to do TAW if acceptance criteria
fail.
Please clarify.

Thanks,
Nandan

On Tue, Nov 19, 2019 at 1:39 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> 2) Added the request for IANA registry for Color Extended Community
> reserved field. Changed the process to Specification Required and added DE
> guidelines since the flags and other space is too small for FCFS.
>
> 4) Add the clarification for handling of route target during propagation
> as per the request and discussions on the mailer and also clarified the
> matching with BGP Router ID part.
>
> 5) Changed the segment type naming from numbers to alphabets to align with
> upcoming update in the draft-ietf-segment-routing-policy to remove
> confusion between the segment types and the protocol code-points as
> discussed on the Spring and IDR lists recently.
>
> We are also trying to capture all the implementation reports at the wiki
> below and would request WG members to help update the same as there are
> multiple shipping implementations of this specification:
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 19 Nov 2019 23:51:07 +0000

Hi Nandan,

When the acceptance criteria fails, the update is considered malformed and the TAW or AFI/SAFI disable or session reset would be the error handling based on what the specific error is as described in sec 5.

In Sec 4.2.1 we have the following text.

A router that receives an SR Policy update that is not valid
   according to these criteria MUST treat the update as malformed and
   the SR Policy candidate path MUST NOT be passed to the SRPM.

Then in the Sec 5 for error handling we specify the treatment for errors in the NLRI part, the Tunnel Encap Attribute (it’s existing TLVs) and then the new ones introduced in this document. E.g. for the TLV/sub-TLVs in the Tunnel Encap attribute (new and old)

In case of any error detected, either

   at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw"

   strategy of [RFC7606<https://tools.ietf.org/html/rfc7606>] MUST be applied.

Hope that clarifies.

Thanks,
Ketan

From: Nandan Saha <[email-masked]>
Sent: 20 November 2019 00:47
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; Prakash Badrinarayanan <[email-masked]>; Manoharan Sundaramoorthy <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Hi Ketan,
 Thank you for the updated version. I'm still reviewing it, but spotted something I wanted to quickly clarify.

ver-7 of section "4.2.1. Acceptance of an SR Policy NLRI" had text mandating RFC7606 TAW if acceptance criteria fail. In ver-8 this has been removed, and I can't quite tell what text in section "5 Error Handling" covers this? I'm assuming we still want to do TAW if acceptance criteria fail.
Please clarify.

Thanks,
Nandan

On Tue, Nov 19, 2019 at 1:39 PM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Thanks,

-----Original Message-----
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 19 November 2019 14:25
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Przemyslaw Krol <[email-masked]>
Date: Wed, 20 Nov 2019 09:36:15 +0800

Howdy Ketan,

Few nits:

2.2. SR Policy and Tunnel Encapsulation Attribute
If more than one TLV of type "SR Policy"
   appears, the update is considered malformed and the "treat-as-
   withdraw" strategy of [RFC7606] is applied.

Given this version introduces an explicit error handling section (5.  Error
Handling), would it be reasonable to delete this? I believe this has been
done for other tlv/sub-tlvs already.

3.  Color Extended Community

two bits from the RESERVED field (as
 defined in [I-D.ietf-idr-tunnel-encaps]) *is are* used as follows

4.2.1. Acceptance of an SR Policy NLRI This section explicitly requires
either Route Target(s) or Community in order to consider policy valid:

The SR Policy update MUST have either the NO_ADVERTISE community
      *or* at least one route-target

and clearly states the behavior when both are missing (policy not
accepted). Do you see a value in stating the behavior when both are
present? Based on the above wording this would deem policy not acceptable
and in consequence neither accepted locally not propagated down (must not
accepted, not necessarily usable, in order to propagate as stated in the
following section). Should it be clearly stated as erroneous condition?

4.2.4. Propagation of an SR Policy

It seems that the original wording was referring to just BGP when
addressing the default propagation. In the current version, there is a
distinction between EBGP (do not propagate) and IBGP (propagate). What is
the reason for such distinction?

Additionally,

A BGP node advertises a received SR Policy NLRI to its IBGP neighbors
according to normal IBGP propagation rules.

this would imply that if a node receives an advertisement by IBGP it would
not propagate it down via IBGP ("normal IBGP propagation rules"), is that
correct? If so, this section really describes a case when a node receives
SRTE policy via EBGP. Given the distinction between IBGP and EBGP
introduced in this version, would it make sense to be more specific in this
case as well?

thanks,
pk

On Wed, Nov 20, 2019 at 7:51 AM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Nandan,
>
>
>
> When the acceptance criteria fails, the update is considered malformed and
> the TAW or AFI/SAFI disable or session reset would be the error handling
> based on what the specific error is as described in sec 5.
>
>
>
> Then in the Sec 5 for error handling we specify the treatment for errors
> in the NLRI part, the Tunnel Encap Attribute (it’s existing TLVs) and then
> the new ones introduced in this document. E.g. for the TLV/sub-TLVs in the
> Tunnel Encap attribute (new and old)
>
>
>
>    strategy of [RFC7606 <https://tools.ietf.org/html/rfc7606>] MUST be applied.
>
>
>
> Hope that clarifies.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Nandan Saha <[email-masked]>
> *Sent:* 20 November 2019 00:47
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* [email-masked]; Prakash Badrinarayanan <[email-masked]>;
> Manoharan Sundaramoorthy <[email-masked]>
> *Subject:* Re: [Idr] I-D Action:
> draft-ietf-idr-segment-routing-te-policy-08.txt
>
>
>
> Hi Ketan,
>
> On Tue, Nov 19, 2019 at 1:39 PM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi All,
>

-- 
Przemyslaw Gniewomir "PK" Krol |   Network Engineer ing | [email-masked]

---

From: Nandan Saha <[email-masked]>
Date: Wed, 20 Nov 2019 08:31:37 +0530

Hi Ketan,
 Please see inline, [nandan]

On Wed, Nov 20, 2019 at 5:21 AM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> I don't think this is sufficient, since the acceptance can fail even if
the RT_TGT and NO_ADV communities aren't present. These are not part of
Tunnel Encap Attribute nor NLRI.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 20 Nov 2019 08:18:48 +0000

Hi Nandan,

Will adding the following text in Sec 5 address your concern?

An SR Policy update that is determined to be not acceptable, and therefore malformed, based on rules described in section 4.2.1 MUST be handled by the "treat-as-withdraw" strategy.

Thanks,
Ketan

Sent: 20 November 2019 11:02

Hi Ketan,

On Wed, Nov 20, 2019 at 5:21 AM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nandan,

   strategy of [RFC7606<https://tools.ietf.org/html/rfc7606>] MUST be applied.
I don't think this is sufficient, since the acceptance can fail even if the RT_TGT and NO_ADV communities aren't present. These are not part of Tunnel Encap Attribute nor NLRI.

Hope that clarifies.

Thanks,
Ketan

From: Nandan Saha <[email-masked]<mailto:[email-masked]>>
Sent: 20 November 2019 00:47
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Prakash Badrinarayanan <[email-masked]<mailto:[email-masked]>>; Manoharan Sundaramoorthy <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Hi Ketan,

Thanks,
Nandan

Thanks,

-----Original Message-----
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 19 November 2019 14:25
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Abstract:

---

From: Nandan Saha <[email-masked]>
Date: Wed, 20 Nov 2019 14:27:15 +0530

Hi Ketan,

On Wed, Nov 20, 2019 at 1:48 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> An SR Policy update that is determined to be not acceptable, and therefore
> malformed, based on rules described in section 4.2.1 MUST be handled by the
> "treat-as-withdraw" strategy.
>
Yes, I think adding this text makes things clearer!

> *Sent:* 20 November 2019 11:02
> On Wed, Nov 20, 2019 at 5:21 AM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Nandan,
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 20 Nov 2019 10:17:47 +0000

Thanks Nandan and will update this in the next rev.

Sent: 20 November 2019 16:57

Hi Ketan,

On Wed, Nov 20, 2019 at 1:48 PM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nandan,

Thanks,
Ketan

Hi Ketan,

Hope that clarifies.

Thanks,
Ketan

Hi Ketan,

Thanks,
Nandan

Thanks,

-----Original Message-----
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 19 November 2019 14:25
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Abstract:

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 20 Nov 2019 10:30:58 +0000

Hi PK,

Please check inline below for responses.

From: Przemyslaw Krol <[email-masked]>
Sent: 20 November 2019 09:36
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Nandan Saha <[email-masked]>; [email-masked]; Prakash Badrinarayanan <[email-masked]>; Manoharan Sundaramoorthy <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Howdy Ketan,

Few nits:

Given this version introduces an explicit error handling section (5.  Error Handling), would it be reasonable to delete this? I believe this has been done for other tlv/sub-tlvs already.
[KT] Ack

two bits from the RESERVED field (as
 defined in [I-D.ietf-idr-tunnel-encaps]) is are used as follows
[KT] Ack

4.2.1. Acceptance of an SR Policy NLRI
This section explicitly requires either Route Target(s) or Community in order to consider policy valid:

The SR Policy update MUST have either the NO_ADVERTISE community
      or at least one route-target

and clearly states the behavior when both are missing (policy not accepted). Do you see a value in stating the behavior when both are present? Based on the above wording this would deem policy not acceptable and in consequence neither accepted locally not propagated down (must not accepted, not necessarily usable, in order to propagate as stated in the following section). Should it be clearly stated as erroneous condition?
[KT] By itself, the NO_ADVERTISE indicates that the update should not be propagated (in general). If an RT is present, then it has to match the local BGP router-id otherwise the SR Policy is not usable on the local router. So I am not sure if this would be an error condition. However, I agree that this combination has not been covered in the spec and we can look for further feedback from the WG before concluding on this.

It seems that the original wording was referring to just BGP when addressing the default propagation. In the current version, there is a distinction between EBGP (do not propagate) and IBGP (propagate). What is the reason for such distinction?
[KT] The reason to not propagate for EBGP is security reasons since SR Policy information should not be send over to a different administrative domain. Even though Sec 4.2.4 had a MAY for IBGP propagation, we had this text in the introduction Sec 1 which was contradictory and hence clarified.

BGP can then be used to
   propagate the SR Policies and candidate paths.  The usual BGP rules
   for BGP propagation and "bestpath selection" are used.

Additionally,

this would imply that if a node receives an advertisement by IBGP it would not propagate it down via IBGP ("normal IBGP propagation rules"), is that correct? If so, this section really describes a case when a node receives SRTE policy via EBGP. Given the distinction between IBGP and EBGP introduced in this version, would it make sense to be more specific in this case as well?
[KT] BGP propagation rules are followed normally. The only special case is for EBGP due to the security reasons and this has been discussed in the Security Considerations section.

Thanks,
Ketan

thanks,
pk

On Wed, Nov 20, 2019 at 7:51 AM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nandan,

Hope that clarifies.

Thanks,
Ketan

Hi Ketan,

Thanks,
Nandan

Thanks,

-----Original Message-----
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 19 November 2019 14:25
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Abstract:

--
Przemyslaw Gniewomir "PK" Krol |
  Network Engineer
ing | [email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 20 Nov 2019 15:18:07 +0100

Przemek,

> following section). Should it be clearly stated as erroneous condition?

Why ? IMO when both present is a valid case as RT can be used locally for
import as well. RT ext-community and NO_ADV community are pretty orthogonal
and serve different purposes.

> the reason for such distinction?

Say when you are on RR suppressing IBGP would be a spec bug :).

Thx,
R.

---

From: Przemyslaw Krol <[email-masked]>
Date: Thu, 21 Nov 2019 05:38:47 +0800

Hi Robert,

That's a good point, although in SRTE, NO_ADVERTISE community has a special
meaning on top of the "normal" propagation limitation.  Draft says 'either
OR' so, in my opinion, this implies 'AND' is not acceptable. If that's the
case, then NLRI should be dropped. If, on the other hand, both are
acceptable, then it should probably state 'either RT or NO_ADVERTISE ot
both'.

Fair enough. I was reading the previous version as 'by default don't
propagate but you may' and was only curious why IBGP vs EBGP distinction
was made in this version. Security aspect does sound like a good
justification for it.

thanks,

On Wed, Nov 20, 2019 at 10:18 PM Robert Raszuk <[email-masked]> wrote:

>> accepted).. Do you see a value in stating the behavior when both are

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 20 Nov 2019 23:27:22 +0000

Hi PK,

I will make the text change for the community part as discussed below in the next update.

Thanks,
Ketan

From: Przemyslaw Krol <[email-masked]>
Sent: 21 November 2019 05:39
To: Robert Raszuk <[email-masked]>
Cc: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Prakash Badrinarayanan <[email-masked]>; Manoharan Sundaramoorthy <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Hi Robert,

Why ? IMO when both present is a valid case as RT can be used locally for import as well. RT ext-community and NO_ADV community are pretty orthogonal and serve different purposes.

That's a good point, although in SRTE, NO_ADVERTISE community has a special meaning on top of the "normal" propagation limitation.  Draft says 'either OR' so, in my opinion, this implies 'AND' is not acceptable. If that's the case, then NLRI should be dropped. If, on the other hand, both are acceptable, then it should probably state 'either RT or NO_ADVERTISE ot both'.

Fair enough. I was reading the previous version as 'by default don't propagate but you may' and was only curious why IBGP vs EBGP distinction was made in this version. Security aspect does sound like a good justification for it.

thanks,

On Wed, Nov 20, 2019 at 10:18 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Przemek,

and clearly states the behavior when both are missing (policy not accepted).. Do you see a value in stating the behavior when both are present? Based on the above wording this would deem policy not acceptable and in consequence neither accepted locally not propagated down (must not accepted, not necessarily usable, in order to propagate as stated in the following section). Should it be clearly stated as erroneous condition?

Why ? IMO when both present is a valid case as RT can be used locally for import as well. RT ext-community and NO_ADV community are pretty orthogonal and serve different purposes.

Thx,
R.

---

From: Nandan Saha <[email-masked]>
Date: Thu, 21 Nov 2019 09:30:07 +0530

Hi Ketan/PK,

> I will make the text change for the community part as discussed below in
Just to confirm, we're not treating both RT_TGT and NO_ADV  being present
as an error, right? The update will only be to clarify that both are
allowed together.

>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Przemyslaw Krol <[email-masked]>
> *Sent:* 21 November 2019 05:39
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; Prakash
> Badrinarayanan <[email-masked]>; Manoharan Sundaramoorthy <
> [email-masked]>
> That's a good point, although in SRTE, NO_ADVERTISE community has a
> special meaning on top of the "normal" propagation limitation.  Draft says
> 'either OR' so, in my opinion, this implies 'AND' is not acceptable. If
> that's the case, then NLRI should be dropped. If, on the other hand, both
> are acceptable, then it should probably state 'either RT or NO_ADVERTISE ot
> both'.
>
>
>
> ing | [email-masked]

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 21 Nov 2019 04:06:30 +0000

Hi Nandan,

Yes. That is correct.

Thanks,
Ketan

From: Nandan Saha <[email-masked]>
Sent: 21 November 2019 12:00
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Przemyslaw Krol <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]; Prakash Badrinarayanan <[email-masked]>; Manoharan Sundaramoorthy <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Hi Ketan/PK,

On Thu, Nov 21, 2019 at 4:57 AM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi PK,

I will make the text change for the community part as discussed below in the next update.
Just to confirm, we're not treating both RT_TGT and NO_ADV  being present as an error, right? The update will only be to clarify that both are allowed together.

Thanks,
Ketan

From: Przemyslaw Krol <[email-masked]<mailto:[email-masked]>>
Sent: 21 November 2019 05:39
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Prakash Badrinarayanan <[email-masked]<mailto:[email-masked]>>; Manoharan Sundaramoorthy <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

Hi Robert,

thanks,

Thx,
R.

---

From: Przemyslaw Krol <[email-masked]>
Date: Thu, 21 Nov 2019 12:29:41 +0800

Thanks folks.

On Thu, Nov 21, 2019 at 12:06 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> *Sent:* 21 November 2019 12:00
> *Cc:* Przemyslaw Krol <[email-masked]>; Robert Raszuk <[email-masked]>;
> [email-masked]; Prakash Badrinarayanan <[email-masked]>; Manoharan
> Sundaramoorthy <[email-masked]>
> On Thu, Nov 21, 2019 at 4:57 AM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi PK,
>
>
>