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

[Nandan Saha <[e-mail]>]

Hi Eric,

On Tue, Oct 10, 2017 at 1:46 AM, Eric C Rosen <[e-mail]> wrote:

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

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


Thanks,
Nandan