Subject: Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt

From: Nandan Saha <[email-masked]>
Date: Mon, 3 Jul 2017 17:44:20 +0530

Hello!

 I have some questions on the NLRI encoding.
1. Can the value of NLRI length be less than 96 for IPv4 AFI and less
than 192 for IPv6 AFI? IOW, can it be less than full mask length for
the end point address?
2. If the answer to (1) is "yes", then what is the rationale for
keeping the end point address field of the NLRI fixed length? (4 or 16
bytes depending on AFI). Should the end point become variable length
like the NLRI encoding defined in RFC4760?
3. If the answer to (1) is "no", how are summary addresses to be represented?

Another question which is unrelated to the changes in version 7 of the draft.
Section "4.2.1. Acceptance of an SR Policy NLRI" says
 " If the NLRI is not one of the legal lengths, a router supporting
this document and that imports the route MUST consider it to be
malformed and MUST apply the "treat-as-withdraw" strategy of [RFC7606]
"
It's not clear to me how a receiver can extract a valid route from a
malformed NLRI. The "treat-as-withdraw" can be applied if the NLRI is
well formed but some other attributes are malformed, which seems to be
implied by the following line at the end of the subsection
"A unacceptable SR Policy update that has an invalid NLRI portion MUST
trigger a reset of the BGP session."

Thank you!
Best regards,
Nandan

On Sat, Jun 24, 2017 at 1:30 AM, <[email-masked]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing of the IETF.
>
>         Title           : Advertising Segment Routing Policies in BGP
>         Authors         : Stefano Previdi
>                           Clarence Filsfils
>                           Paul Mattes
>                           Eric Rosen
>                           Steven Lin
>         Filename        : draft-previdi-idr-segment-routing-te-policy-07.txt
>         Pages           : 30
>         Date            : 2017-06-23
>
> Abstract:
>    This document defines a new BGP SAFI with a new NLRI in order to
>    advertise a candidate path of a Segment Routing Policy (SR Policy).
>    An SR Policy is a set of candidate paths 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 candidate paths.  New sub-TLVs for the Tunnel
>    Encapsulation Attribute are defined.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-previdi-idr-segment-routing-te-policy/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-07
> https://datatracker.ietf.org/doc/html/draft-previdi-idr-segment-routing-te-policy-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-previdi-idr-segment-routing-te-policy-07
>
>
> 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/
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Nandan Saha <[email-masked]>
Date: Mon, 3 Jul 2017 17:44:20 +0530

Hello!

Thank you!
Best regards,
Nandan

---

From: stefano previdi <[email-masked]>
Date: Mon, 17 Jul 2017 14:42:25 +0200

Hi Nandan,

sorry for being late. See below.

> On Jul 3, 2017, at 2:14 PM, Nandan Saha <[email-masked]> wrote:
> 
> Hello!
> 

no.

> 3. If the answer to (1) is "no", how are summary addresses to be represented?

there’s no such concept of “summary address” for the endpoint encoding. The draft is going to be updated and the term “summary address” will be removed from the endpoint filed description. Sorry for the confusiuon.

> malformed NLRI.

you just have to check the nlri length.

> The "treat-as-withdraw" can be applied if the NLRI is
> trigger a reset of the BGP session.”

that is correct.

s.

---

From: Nandan Saha <[email-masked]>
Date: Wed, 19 Jul 2017 13:01:45 +0530

Thank you Stefano for clarifying.

On Mon, Jul 17, 2017 at 6:12 PM, stefano previdi <[email-masked]>
wrote:

> there’s no such concept of “summary address” for the endpoint encoding.
> The draft is going to be updated and the term “summary address” will be
> removed from the endpoint filed description. Sorry for the confusiuon.
>
>

---

From: Nandan Saha <[email-masked]>
Date: Wed, 19 Jul 2017 13:01:45 +0530