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

From: Nandan Saha <[email-masked]>
Date: Sat, 30 Sep 2017 11:15:47 +0530

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 <[email-masked]> wrote:

> Thank you Stefano for clarifying.
>
> On Mon, Jul 17, 2017 at 6:12 PM, stefano previdi <[email-masked]>
> wrote:
>
>> Hi Nandan,
>>
>> sorry for being late. See below.
>>
>>
>> > On Jul 3, 2017, at 2:14 PM, Nandan Saha <[email-masked]> 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, <[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-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
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/idr
>> >
>> > _______________________________________________
>> > Idr mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/idr
>>
>>
>

---

From: Nandan Saha <[email-masked]>
Date: Fri, 6 Oct 2017 20:08:50 +0530

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 <[email-masked]> wrote:

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

---

From: Nandan Saha <[email-masked]>
Date: Fri, 6 Oct 2017 20:08:50 +0530

Hi,

Later in section 11,

Thanks,
Nandan

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 9 Oct 2017 16:16:59 -0400

On 10/6/2017 10:38 AM, Nandan Saha wrote:
> 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.

You do not want to trigger a reset of the BGP session unless the UPDATE 
is so mangled that you can't  continue to parse the TCP octet stream.
If the UPDATE is well-formed, but the NLRI is not one of the two legal 
lengths (12 or 24), treat-as-withdraw is appropriate.

Probably the sentence about triggering a reset of the BGP session can be 
omitted, since that is only necessary when the UPDATE is totally 
mangled, and in that case it is normal BGP behavior and nothing 
particular to do with the SAFI being discussed.

> 1. Behavior when only one of Color / Remote end point sub-tlv is 
> present in the Tunnel encap tlv.
> 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?

I believe the Remote Endpoint is mandatory, according to the 
tunnel-encaps draft.  (There has been some controversy on this point 
though.)
The color sub-tlv is not mandatory, but you can't really stop someone 
from including it.

The purpose of these rules is to cause a policy to be rejected if it 
contains contradictory information.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Oct 2017 22:32:38 +0200

Eric,

You can't withdraw something which you did not successfully parsed. So the
MP_REACH_NLRI must be parsed entirely to be able to apply the
"treat-as-withdraw" otherwise procedures 3j from RFC7606 apply.

Also I do not see any definition and levels of "mangled" in RFC7606 :)

Thx,
R.

On Mon, Oct 9, 2017 at 10:16 PM, Eric C Rosen <[email-masked]> wrote:

> You do not want to trigger a reset of the BGP session unless the UPDATE is
> so mangled that you can't  continue to parse the TCP octet stream.
> omitted, since that is only necessary when the UPDATE is totally mangled,
> and in that case it is normal BGP behavior and nothing particular to do
> with the SAFI being discussed.
>
> 1. Behavior when only one of Color / Remote end point sub-tlv is present
>> in the Tunnel encap tlv.
>> 2. What is the rationale for including remote end point / color sub tlvs
>> in the tunnel encap tlv.
> I believe the Remote Endpoint is mandatory, according to the tunnel-encaps
> draft.  (There has been some controversy on this point though.)
> The color sub-tlv is not mandatory, but you can't really stop someone from
> including it.
>

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 9 Oct 2017 16:41:49 -0400

On 10/9/2017 4:32 PM, Robert Raszuk wrote:
> You can't withdraw something which you did not successfully parsed.

In the case under discussion, the UPDATE is parsed successfully, but the 
internal structure of the NLRI cannot be parsed by the SR-TE 
application.  I don't think you need to understand the internal 
structure of the NLRI to withdraw the UPDATE.  You certainly wouldn't 
reset the session in this case.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Oct 2017 23:07:53 +0200

> I don't think you need to understand the internal structure of the NLRI
to withdraw the UPDATE.

How do you generate MP_UNREACH_NLRI to send withdraw if you did not
completely parsed all NLRIs sitting in MP_REACH_NLRI attribute in the first
place ?

//r

On Mon, Oct 9, 2017 at 10:41 PM, Eric C Rosen <[email-masked]> wrote:

> internal structure of the NLRI cannot be parsed by the SR-TE application.
> I don't think you need to understand the internal structure of the NLRI to
> withdraw the UPDATE.  You certainly wouldn't reset the session in this case.
>
>
>
>

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 9 Oct 2017 18:44:32 -0400

On 10/9/2017 5:07 PM, Robert Raszuk wrote:
> completely parsed all NLRIs sitting in MP_REACH_NLRI attribute in the 
> first place ?

Suppose the MP_REACH had 3 NLRIs in it, each one 16 octets long. The 
first octet of each (the NLRI length field) has value 120 (120 bits == 
15 octets).

These NLRIs are not of legal length according to the sr-te-policy draft, 
but I don't see why you couldn't put each into an MP_UNREACH.  Certainly 
there's no reason to reset the BGP session.

---

From: Nandan Saha <[email-masked]>
Date: Tue, 10 Oct 2017 09:09:52 +0530

Hi Eric,

> lengths (12 or 24), treat-as-withdraw is appropriate.
To do a treat-as-withdraw, the receiver needs to be able to parse the NLRI
to extract the 3-tuple of {distinguisher, color, endpoint}. It cannot
remove the policy from it's adj-Rib-in otherwise, as it's keyed on the
3-tuple.
If the NLRI length < the valid length, then it's impossible to extract a
valid 3-tuple.
If the NLRI length > the valid length, then should the receiver extract
upto the valid length?
In the general case rfc7606 section 3, point j, mentions that one needs to
be able to parse the NLRI to be able to do treat-as-withdraw.

> contains contradictory information.
For a receiver of an update with the sr te safi and sr policy tunnel encap
tlv, the source of truth for the end point and color is in the NLRI. So the
endpoint and color in the tunnel tlv doesn't add any new information. In
fact, in the draft today the _only_ thing a receiver has to do with the
color and endpoint in the tunnel encap tlv is to compare against the NLRI.
To me, it seems that things would be much simpler to simply ignore the
contents of the color and remote endpoint sub tlvs as that information is
already in the NLRI.

Thanks,
Nandan

---

From: Nandan Saha <[email-masked]>
Date: Tue, 10 Oct 2017 09:09:52 +0530

Hi Eric,

Thanks,
Nandan

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 10 Oct 2017 11:31:48 -0400

On 10/9/2017 11:39 PM, Nandan Saha wrote:
> In the general case rfc7606 section 3, point j, mentions that one 
> needs to be able to parse the NLRI to be able to do treat-as-withdraw.

Yes, you are correct, RFC 7606 section 3 point j together with section 
5.3 does seem to mandate that "session reset" or "AFI/SAFI disable" is 
the proper error handling response.

---

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Wed, 11 Oct 2017 13:35:59 +0000

Nandan,

Inline <Gaurav>

Regards,

Gaurav

From: Idr <[email-masked]> on behalf of Nandan Saha <[email-masked]>
Date: Monday, October 9, 2017 at 8:39 PM
To: Eric C Rosen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, stefano previdi <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-previdi-idr-segment-routing-te-policy-07.txt

Hi Eric,

On Tue, Oct 10, 2017 at 1:46 AM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:
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.

You do not want to trigger a reset of the BGP session unless the UPDATE is so mangled that you can't  continue to parse the TCP octet stream.
If the UPDATE is well-formed, but the NLRI is not one of the two legal lengths (12 or 24), treat-as-withdraw is appropriate.
To do a treat-as-withdraw, the receiver needs to be able to parse the NLRI to extract the 3-tuple of {distinguisher, color, endpoint}. It cannot remove the policy from it's adj-Rib-in otherwise, as it's keyed on the 3-tuple.
If the NLRI length < the valid length, then it's impossible to extract a valid 3-tuple.
If the NLRI length > the valid length, then should the receiver extract upto the valid length?
In the general case rfc7606 section 3, point j, mentions that one needs to be able to parse the NLRI to be able to do treat-as-withdraw.
<Gaurav>
This is correct. Will work to reword this and perhaps reference to session reset should be removed.

Probably the sentence about triggering a reset of the BGP session can be omitted, since that is only necessary when the UPDATE is totally mangled, and in that case it is normal BGP behavior and nothing particular to do with the SAFI being discussed.
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?

I believe the Remote Endpoint is mandatory, according to the tunnel-encaps draft.  (There has been some controversy on this point though.)
The color sub-tlv is not mandatory, but you can't really stop someone from including it.

The purpose of these rules is to cause a policy to be rejected if it contains contradictory information.
For a receiver of an update with the sr te safi and sr policy tunnel encap tlv, the source of truth for the end point and color is in the NLRI. So the endpoint and color in the tunnel tlv doesn't add any new information. In fact, in the draft today the _only_ thing a receiver has to do with the color and endpoint in the tunnel encap tlv is to compare against the NLRI.
To me, it seems that things would be much simpler to simply ignore the contents of the color and remote endpoint sub tlvs as that information is already in the NLRI.
<Gaurav> Will work with Authors to perhaps clarify this further. These sub-TLVs MAY be present and if present MUST be compared.
   The Remote Endpoint and Color sub-TLVs, as defined in
   [I-D.ietf-idr-tunnel-encaps<https://tools.ietf.org/html/draft-previdi-idr-segment-routing-te-policy-07#ref-I-D.ietf-idr-tunnel-encaps>], MAY also be present in the SR Policy
   NLRI encodings.  If present, the Remote Endpoint sub-TLV MUST match
   the Endpoint of the SR Policy SAFI NLRI
<<<<<

Cheers,

Gaurav

Thanks,
Nandan