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

[Nandan Saha <[e-mail]>]

Hello again,
 I had a couple of further questions / clarifications.
1. Binding SID Sub tlv encoding:
 Please confirm that the BSID Sub-tlv with length = 6 (4 octet SID)
contains the MPLS label in the lower 20 bits.
Btw, is a Binding SID always a full label and never an index? It's not
mentioned so explicitly in draft-filsfils-spring-segment-routing-policy-01

2. How to treat received weight sub-tlv with weight=0 ?
If we plug weight = 0 in the formula in section 7.1 of the SR TE draft,
https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-policy-01#section-7.1,
then we end up with 0/Sw, so the segment list won't get any traffic
(essentially the segment list isn't present).
To me a weight = 0 seems useless and if we allow it we will get into some
strange corner cases, like if the policy has only one segment list, but its
weight is 0, should it then be treated as an unacceptable policy and
treat-as-withdraw?
It would be simpler to either limit the weight to be > 0 and if 0 is
received treat it as if no weight was received. Does that make sense?
Any thoughts on this?

Thanks,
Nandan

On Wed, Jul 19, 2017 at 1:01 PM, Nandan Saha <[e-mail]> wrote:

> Thank you Stefano for clarifying.
>
> On Mon, Jul 17, 2017 at 6:12 PM, stefano previdi <[e-mail]>
> wrote:
>
>> Hi Nandan,
>>
>> sorry for being late. See below.
>>
>>
>> > On Jul 3, 2017, at 2:14 PM, Nandan Saha <[e-mail]> wrote:
>> >
>> > 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?
>>
>> no.
>>
>>
>> > 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?
>>
>>
>> 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.
>>
>>
>> > 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.
>>
>>
>> you just have to check the nlri length.
>>
>>
>> > 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.”
>>
>>
>> that is correct.
>>
>> s.
>>
>>
>> >
>> > Thank you!
>> > Best regards,
>> > Nandan
>> >
>> > On Sat, Jun 24, 2017 at 1:30 AM, <[e-mail]> 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-rout
>> ing-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-r
>> outing-te-policy/
>> >>
>> >> There are also htmlized versions available at:
>> >> https://tools.ietf.org/html/draft-previdi-idr-segment-routin
>> g-te-policy-07
>> >> https://datatracker.ietf.org/doc/html/draft-previdi-idr-segm
>> ent-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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/idr
>> >
>> > _______________________________________________
>> > Idr mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/idr
>>
>>
>