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

[Nandan Saha <[e-mail]>]

Hi,
Some more questions / comments

1. Behavior when only one of Color / Remote end point sub-tlv is present in
the Tunnel encap tlv.
  Should the match on either color or remote end point be done for
acceptance? For example the color sub-tlv is present, but the remote end
point isn't. So the color of the color sub-tlv must match the color in the
NLRI. Or should the condition for matching of color / remote end point be
done only if both color and remote end point are present.

2. What is the rationale for including remote end point / color sub tlvs in
the tunnel encap tlv.
  The NLRI already has the color and endpoint. Why is there an option to
also include a end point and color in the tunnel encap tlv and then have to
make sure it matches the NLRI?

3. What should be the behavior when a sub tlv in the tunnel encap attribute
is malformed?
   Should it follow the error handling defined in
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-07#section-11

4. This draft says that the remote end point MAY be present, but
draft-ietf-dr-tunnel-encaps seems to imply that it is a MUST.
  https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-07#section-3.1
says
<<<
If the Remote Endpoint sub-TLV is malformed, the TLV containing it is
   also considered to be malformed, and the entire TLV MUST be ignored.
>>>
Later in section 11,
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-07#section-11
<<<
A TLV that does not contain exactly one Remote Endpoint sub-TLV MUST
   be treated as if it contained a malformed Remote Endpoint sub-TLV.
>>>
To me this looks like a tunnel end point TLV MUST have a valid remote
endpoint sub-tlv. Can this draft make it clear that it is overriding this
requirement of draft-idr-tunnel-encaps?

5. Conflicting mandate for malformed NLRI handling.
In section 4.2.1 of this draft, the first bullet point's 2nd sentence is
<<<
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]
>>>
Where as the last sentence in section 4.2.1 is
<<<
A unacceptable SR Policy update that has an invalid NLRI portion MUST
   trigger a reset of the BGP session
>>>
Can the draft be updated to simply remove the reference to
treat-as-withdraw in the first statement since one cannot withdraw a NLRI
if one cannot parse it; and also because it conflicts with the 2nd mandate.

Thanks,
Nandan

On Sat, Sep 30, 2017 at 11:15 AM, Nandan Saha <[e-mail]> wrote:

> 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
>>>
>>>
>>
>