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

["Gaurav Dawra (gdawra)" <[e-mail]>]

Nandan,

Inline <Gaurav>

Regards,

Gaurav

From: Idr <[e-mail]> on behalf of Nandan Saha <[e-mail]>
Date: Monday, October 9, 2017 at 8:39 PM
To: Eric C Rosen <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, stefano previdi <[e-mail]>
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 <[e-mail]<mailto:[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.
<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