Re: [bess] Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06

[John E Drake <[e-mail]>]

Hi,

We can't time-out an attribute, we would have to time-out the SFPR w/ which it is associated.  However, I don't think we should do that.

Rather, I think what we should do is indicate that at any point in time an SFF selects its next hop from the intersection of the set of next hop RDs
contained in the SFPR and the RDs contained in its local set of SFIRs.  If the intersection is null the SFPR is unusable. 

Similarly, when this condition obtains the originator of the SFPR should either withdraw the SFPR or re-advertise it w/ a new set of RDs for the affected hop. 

As an aside, the use of Pool Identifier extended community effectively mitigates this issue. 

Yours Irrespectively,

John


Juniper Internal

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, June 6, 2019 7:45 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06
> 
> Hi Adrian,
> 
> I'm not comfortable with the time-out of controlplane informations.
> How do you handle a situation where there is an unknown SFIR-RD in a hop TLV
> for a valid reason (the SF is down for a while !), so you are timing out the SFPR,
> and eventually the SF is restored and comes back online ? You should, in this
> case, readvertise the SFPR from the source. I think overloading could be
> managed as usual by limiting the number of routes that a device could import
> (per VRF context or globally). If there is unnecessary controlplane information,
> that's the role of the operator to do the housekeeping, not the role of the
> protocol/implementation.
> 
> For the flowspec part, I'm fine, but we need to have the agreement from IDR
> guys who master the topic.
> 
> Brgds,
> 
> Stephane
> 
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Thursday, May 30, 2019 15:45
> To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-nsh-bgp-control-
> [e-mail]
> Cc: [e-mail]
> Subject: RE: Shepherd's review of draft-ietf-bess-nsh-bgp-control-plane-06
> 
> Hi Stephane,
> 
> Thanks again for the thoroughness of your review and the time it has taken to
> herd the necessary cats.
> 
> * BGP ERROR HANDLING:
> >>>> I don’t see the “error handling” behavior associated with this
> >>>> attribute (discard, treat-as-withdraw…)
> >>>
> >>> I think the errors are covered by section 6 of RFC 4271, but we need
> >>> to point to it.
> >>>
> >>> [SLI] You have added " Malformed SFP attributes, or those that in
> >>> error in some way, MUST be handled as described in Section 6 of
> [RFC4271]"
> >>> This is not enough ad RFC7606 allows for a more "graceful" process
> >>> of errors and it's up to each new attribute to have its own behavior
> >>> in term of error processing. RFC7606 has some guidelines.
> >>
> >> This one will take a little more time to work up some text.
> >> We'll get back to you.
> >>
> >> [SLI2] This is an important thing to address, and the IESG or Routing
> >> Directorate may catch that as well.
> >
> > OK, a chunk more text. Does this work for you?
> >
> >   Section 6 of [RFC4271] describes the handling of malformed BGP
> >   attributes, or those that are in error in some way.  [RFC7606]
> >   revises BGP error handling specifically for the for UPDATE message,
> >   provides guidelines for the authors of documents defining new
> >   attributes, and revises the error handling procedures for a number of
> >   existing attributes.  This document introduces the SFP attribute and
> >   so defines error handling as follows:
> >
> >   o  When parsing a message, an unknown Attribute Type code or a length
> >      that suggests that the attribute is longer than the remaining
> >      message is treated as a malformed message and the "treat-as-
> >      withdraw" approach used as per [RFC7606].
> >
> >   o  When parsing a message that contains an SFP attribute, the
> >      following cases constitute errors:
> >
> >      1.  Optional bit is set to 0 in SFP attribute.
> >
> >      2.  Transitive bit is set to 0 in SFP attribute.
> >
> >      3.  Unknown TLV type field found in SFP attribute.
> >
> >      4.  TLV length that suggests the TLV extends beyond the end of the
> >          SFP attribute.
> >
> >      5.  Association TLV contains an unknown SFPR-RD.
> >
> >[SLI] That's a bit weird to find this here as the Association TLV hasn't been
> introduced.
> > Wouldn't it be better to add a dedicated Error Handling section (e.g. 3.2.3)
> after all the encodings ?
> 
> I think we introduced it in the text at the top of the page (i.e. a few paragraphs
> earlier). It reads OK to me and it is better to group together the format handling
> issues in one place and with the text that describes the presence rules.
> 
> >      6.  No Hop TLV found in the SFP attribute.
> >
> >      7.  No SFT TLV found in a Hop TLV.
> >
> > [SLI] That's strange, as section 3.2.1.3 says that the SFT TLV MAY be included,
> so optional...
> 
> Ah, this should read "No sub-TLV found in a Hop TLV".
> Per 3.2.1.2 "At least one sub-TLV MUST be present."
> 
> >     8.  Unknown SFIR-RD found in a Hop TLV.
> >
> >   o  The errors listed above are treated as follows:
> >
> >      1., 2., 6., 7.:  The attribute MUST be treated as malformed and
> >         the "treat-as-withdraw" approach used as per [RFC7606].
> >
> >      3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
> >         continue.
> >
> >      4.:  Treated as a malformed message and the "treat-as-withdraw"
> >         approach used as per [RFC7606]
> >
> >      5., 8.:  The absence of an RD with which to corollate is nothing
> >         more than a soft error.  The receiver SHOULD store the
> >         information from the SFP attribute until a corresponding
> >         advertisement is received.  An implementation MAY time-out such
> >         stored SFP attributes to avoid becoming over-loaded.
> >
> > [SLI] That's not really an error, there may be a lot of transient
> > situations  where some routes haven't been learned yet leading to such
> situation.
> > I don't think that we need to time-out (even optionally) as timing out
> > may create inconsistencies in the controlplane. What you could suggest
> > is alarming to let the user know that something wrong is happening.
> 
> Timing this out is a housekeeping thing. Without it there can be a bleed of router
> resources. Might not be large, but over time (and with a bugged implementation
> somewhere else in the network) it could add up.
> 
> But:
> 1. We should give guidance on the time-out. A largish time-out of the order of
> 30 minutes would be fine.
> 2. Yes, there should be a user notification when this happens.
> 
> So...
> 
>       5., 8.:  The absence of an RD with which to corollate is nothing
>          more than a soft error.  The receiver SHOULD store the
>          information from the SFP attribute until a corresponding
>          advertisement is received.  An implementation MAY time-out such
>          stored SFP attributes to avoid becoming over-loaded.  The time-out
>          value should be configurable and measured in minutes; a default
>          value of 30 minutes is suggested.  Whenever an implementation
>          removes a stored SFP attribute, it SHOULD generate a notification
>          to the network operator.
> 
> > * FLOWSPEC traffic steering:
> >>>> NEW COMMENT:
> >>>> Section 5:
> >>>> "Note that each FlowSpec update MUST be tagged with the route
> >>>> target  of the overlay or VPN network for which it is intended."
> >>> [SLI] You should be more clear that VPN-IPv4 and VPN-IPv6 Flowspec
> >>> families must be used, it's not just a matter of RTs.
> >>
> >> A couple of the authors have discussed this a bit and we are puzzled.
> >>
> >> RFC 5575 section 8 discusses the applicability of Flowspecs to VPNs.
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_ass
> >> ignments_flow-2Dspec_flow-2Dspec.xhtml-23flow-2Dspec-
> 2D2&d=DwIGaQ&c=H
> >> AkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-
> h5LGhEWH-
> >> s_xXXup3HzvBSMRj5VE&m=glkXGEc4NSkB-
> hCMWUdBqJXH99wj5ZoNOxWVONpiDA4&s=b
> >> HwG2fvAY39OrCgk8UW871dLs6WSSNLSGfmHp7tB4lM&e=
> >> does not list any VPN Flowspecs.
> >> draft-ietf-pce-pcep-flowspec makes observations about VPN
> >> identification and applicability to Flowspecs.
> >> draft-ietf-idr-flowspec-l2vpn has a redefinition of SAFI 134 to apply
> >> to Flowspecs to an L2VPN environment.
> >>
> >> [SLI2] I see various cases:
> >> - traffic is coming from an IPVPNv4 and should be steered on an SFC, in such
> >>   a case RFC5575 Section 8 (AFI/SAFI 1/134) must be used, an RT is attached.
> >> - traffic is coming from the global routing table and should be steered on an
> >>   SFC, in such a case  the base RFC5575 using AFI/SAFI 1/133 must be used
> >>   and there is no RT attached. The trick here is that you need to set in the
> >>   action: - the SFC you want the traffic to be steered on as well as the VPN
> >>   to look the SFC for (Like a redirect RT + SFC steering). If there is no VPN
> >>   redirection, the SFC is considered to be available in the global routing table.
> >> - traffic is coming from an L2VPN, this is similar to the L3VPN case.
> >> - same considerations applies to IPv6 and VPNv6.
> >
> > OK, I think we need to separate two things.
> > Section 5 is concerned with how to select among possible next hops on
> > an SFP. That is, the packet is already classified and assigned to an
> > SFP, but some load-balancing choices have to be made. So I don't think
> > Section 5 is the place for this discussion.
> >
> > However, Section 7.4 is about classifying traffic onto SFPs.
> > Specifically, it is about how to indicate, using BGP, which traffic
> > flows should be assigned to which SPF at the Classifier component of
> > the SFC system. This section seems to be relevant to the question you are
> asking.
> >
> > But this second section seems to have it all covered by modelling
> > exactly the flowspec function used in BGP flow specification and
> > adding an extended community for SFC.
> >
> > [SLI] The comment was for section 7.4 (not section 5, sorry for the bad
> pointer).
> > Only the last sentence is raising a concern on my side. It makes me
> > think that it only applies to FlowSpec VPN (1/134) while it could be
> > used in many use cases. As you are just adding a new action extended
> > community, maybe you can just remove the last sentence. Adding RTs or
> > not will depend on the context the action will be used in. We may need
> > a review from the IDR guys on this section.
> 
> There are two separate things:
> a) Place traffic from a VPN onto a specific SFC (use 1/134)
> b) Place traffic onto an SFC that flows through a specific overlay or VPN
>    (use RT)
> 
> We can do...
> OLD
>    Note that each FlowSpec update MUST be tagged with the route target
>    of the overlay or VPN network for which it is intended to put the
>    indicated SPI into context.
> NEW
>    One of the filters that the Flow Spec may describe is the VPN to
>    which the traffic belongs.  Additionally, note that to put the
>    indicated SPI into context when multiple SFC overlays are present in
>    one network, each FlowSpec update MUST be tagged with the route
>    target of the overlay or VPN network for which it is intended.
> END
> 
> 
> You also had a separate email exchange with me about FlowSpec actions. You
> flagged this up with the IDR chairs and it was noted that rfc5575bis says:
>    Some traffic action communities may interfere with each other.
>    Section 7.6 of this specification provides general considerations on
>    such traffic action interference.  Any additional definition of a
>    traffic actions specified by additional standards documents or vendor
>    documents MUST specify if the traffic action interacts with an
>    existing traffic actions, and provide error handling per [RFC7606].
> John Scudder sent a note to the IDR list highlighting section 7.4 and asking for
> any input, but there was no comment raised.
> 
> However, we have returned to the relevant text and discussed it with the co-
> author who requested what was in earlier versions. We are not all in agreement
> that the text should be:
> 
> OLD
>    [RFC5575] defines a set of BGP routes that can be used to identify
>    the packets in a given flow using fields in the header of each
>    packet, and a set of actions, encoded as extended communities, that
>    can be used to disposition those packets.  This document enables the
>    use of RFC 5575 mechanisms by SFC Classifiers by defining a new
>    action extended community called "Flow Spec for SFC classifiers"
>    identified by the value TBD4.  Note that other action extended
>    communities may also be present.
> NEW
>     [RFC5575]  and [I-D.ietf-idr-rfc5575bis] define a set of BGP routes
>     that can be used to identify the packets in a given flow using fields
>     in the header of each packet, and a set of actions, encoded as
>     extended communities, that can be used to disposition those
>     packets.  This document enables the use of these mechanisms by
>     SFC Classifiers by defining a new action extended community called
>     "Flow Spec for SFC Classifiers" identified by the value TBD4.  Note
>     that other action extended communities MUST NOT be present at
>     the same time: the inclusion of the "Flow Spec for SFC Classifiers"
>     action extended community along with any other action MUST be
>     treated as an error which SHOULD result in the Flow Specification
>     UPDATE message being handled as Treat-as-withdraw according to
>     [RFC7606] Section 2.
> END
> 
> I am sending that specific change to IDR as well.
> 
> The -11 version will be posted SOON.
> 
> Best,
> Adrian
> 
> 
> 
> 
> 
> 
> 
> _________________________________________________________________
> ________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.