Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Sue,

I think this matters on what you consider “route selection” or “installation”. RFC7752 (or other BGP-LS documents) do not talk of any of the BGP-LS attributes affecting the selection or installation of the BGP-LS NLRIs. Hence, IMHO “Attribute discard” is correct for malformed attributes. Furthermore, RFC 7752 lays down the generic rules for identifying what constitutes malformed for BGP-LS attributes – I would rather this becomes the “default” for all BGP-LS and only exceptions need to be called out by individual documents which otherwise can just reference RFC7752.

Coming to BGP Prefix SID scenario, the SRGB TLV (which is the only overlap here between that draft and the BGP-LS SR draft) does not play a role in route selection or installation. The “hint” is actually the Label Index TLV that is actually used by BGP. The TLVs coming via BGP-LS are used by controller likely but not by BGP process for its route selection.

I am also not clear about what is malformed between the SRGB being signalled in a redundant manner? Are you perhaps looking for text that indicates which of these redundant values take precedence if they happen to be different at a given point of time T?

Thanks,
Ketan

From: Idr <[e-mail]> On Behalf Of Susan Hares
Sent: 21 June 2018 16:59
To: 'Robert Raszuk' <[e-mail]>
Cc: 'idr@ietf. org' <[e-mail]>; 'stefano previdi' <[e-mail]>; [e-mail]; [e-mail]; 'The IESG' <[e-mail]>; 'Acee Lindem (acee)' <acee=[e-mail]>
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

Robert:

Now you understand the point.  The BGP truck has rules about BGP Attribute errors.  RFC7606 states:

   o  Attribute discard: In this approach, the malformed attribute MUST
      be discarded and the UPDATE message continues to be processed.
      This approach MUST NOT be used except in the case of an attribute
      that has no effect on route selection or installation.

RFC7752 has the following “management”


   If an implementation of BGP-LS detects a malformed attribute, then it

   MUST use the 'Attribute Discard' action as per [RFC7606], Section 2<https://tools.ietf.org/html/rfc7606#section-2>

If attribute-discard is used, it MUST not be used except in the case of an attribute that has no effect on route selection or installation.

At this point, it is clear that the SRGB has an impact (as a hint) on SID selection and installation. Therefore, it does not qualify for the attribute discard unless specific error handling is provided.

The authors may wish to treat the information as “redundant”, but then the specifications need to say that.  If the authors want to extend the Attribute discard error handling to another mechanism, then it needs to be stated.

Sue

(PS – to carry your truck analogy further, this trucks have rules for containers that are loaded on the flat-bed truck.  If the containers fall outside the exact specifications, it must be clearly describe what  truck is supposed to do).

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 7:14 AM
To: Susan Hares
Cc: stefano previdi; Warren Kumari; Acee Lindem (acee); idr@ietf. org; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; The IESG
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM

​​Hello Sue,

Ok I see where your comment came from. Let me provide my POV on this:

* We were commenting in reference to section 3.1 Label-Index TLV while clearly your comment was based on section 3.2 Originator SRGB TLV

* Yes there can be case you describe that both BGP-LS and this extension advertises SRGB ranges of the node. But at most I would treat this as redundant information. If there is mismatch then I suppose there are bigger issues to be solved and I am not sure if they are actually in scope of this proposal or IDR.

Along the same lines you could stop BGP-LS RFC and ask what happens if BGP-LS fed information is different then listening to IGP by the controller ? I guess controller must be at min that much smart to handle it, raise the alarms etc ....

Clearly those are important topics, but I fail to see how they are at all related to BGP.  BGP is just a truck here :).

Cheers,
R.








On Thu, Jun 21, 2018 at 12:45 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Robert and Stefano:

I've pulled both of your comments to the front of this message.

> The mechanism in draft-idr-bgp-prefix-sid-25.txt is a BGP  attribute  sent
> as an exception if the BGP-LS service for Segment Routing (SR) is not available

[Robert]: Very interesting comment
[Robert]:  Where do you draw such conclusion from ?
[Robert]: IMO this draft has nothing to do with BGP-LS at all ....

See comment from draft-ietf-idr-bgp-prefix-sid-25 below to where I get the comment from.

[Stefano]: the BGP prefix SID attribute is advertised in order to give
[Stefano]: a hint to the receiver on what label value to allocate for BGP labelled
[Stefano]: routes. The receiver may or may not follow the hint.
[Stefano]: The BGPLS SR attributes are defined in order for a local router
[Stefano]: to advertise what he has allocated. Extensions have been defined
[Stefano]:  for the different use cases (IGP, EPE, TE, ...).

My technical problem #1 has to do with what happens if all of these come in the same BGP packet as combinations of BGP attributes or as combination of BGP attributes and NLRIs?

The mechanisms between draft-bgp-prefix-sid and draft-bgp-ls-segment-routing-ext should be orthogonal, but what happens if by error they end up in the same BGP packet being sent to a BGP-LS capable peer, or to a BGP Peer capable of only draft-bgp-prefix-sid functions.

My plea as an IDR reviewer is to improve the error handling descriptions in the drafts to have interoperable implementations before publication of draft-ietf-idr-bgp-prefix-sid-25.txt.

Right now the implementations that are listed on the IDR page are RTBRICK and Cisco.   I quote the RTbrick Fullstack-OS 17.2 or greater comments "No interoperability testing has been done".   The only interoperability testing that has been done is "Cisco NX-OS and Cisco IOS-XR".
Therefore, as a BGP Reviewer I look carefully at the BGP error handling in cases where single company interoperability testing between two unique implementation has been done.

Sue

===============
From the draft-ietf-idr-bgp-prefix-sid-25 in section 2:

     This document assumes that BGP-LS is the preferred method for
      collecting both peer segments (Peer SIDs) and SRGB information
      through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and
      [I-D.ietf-idr-bgp-ls-segment-routing-ext].  However, as an
      optional alternative for the advertisement of the local SRGB
      without the topology nor the peer SIDs, hence without
      applicability for TE, the Originator SRGB TLV of the BGP Prefix-
      SID attribute is specified in Section 3.2 of this document.

Section 3.2 specifies the SRGB TLV.


Draft-ietf-idr-bgp-ls-segment-routing-ext states:
==========
2.  BGP-LS Extensions for Segment Routing

   This document defines SR extensions to BGP-LS and specifies the TLVs
   and sub-TLVs for advertising SR information.  Section 2.4 and
   Section 2.5 illustrates the equivalent TLVs and sub-TLVs in IS-IS,
   OSPFv2 and OSPFv3 protocols.

   BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a
   Link NLRI or a Prefix NLRI.  The corresponding BGP-LS attribute is a
   Node Attribute, a Link Attribute or a Prefix Attribute.

Section 2.1 defines the SID Node attribute TLVS, and the SR Local Block (specifies) the same SRGB TLV as above to be collected.

BGP-LS Extensions for SR for BGP-EPE (draft-ietf-idr-bgpls-segment-routing-epe-15)   specifies setting the Peer-Node-SID in section 5.1.   Quoting from section 5.1

5.1.  Peer-Node-SID

   The Peer-Node-SID describes the BGP session peer (neighbor).  It MUST
   be present when describing a BGP-EPE topology as defined in
   [I-D.ietf-spring-segment-routing-central-epe].  The Peer-Node-SID is
   encoded within the BGP-LS Link NLRI specified in Section 4.

=============

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Thursday, June 21, 2018 2:00 AM
To: Susan Hares
Cc: Warren Kumari; Acee Lindem (acee); idr@ietf. org; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; The IESG
Subject: Re: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMM
Hi Sue,

> The mechanism in draft-idr-bgp-prefix-sid-25.txt is a BGP  attribute
> sent
as an exception if the BGP-LS service for Segment Routing (SR) is not available.

Very interesting comment .... Where do you draw such conclusion from ?

IMO this draft has nothing to do with BGP-LS at all ...

BGP-LS is gathering data from network elements to controller ... this draft is installing SIDs from controller to ingress network elements. While mutually required for some solutions they are completely orthogonal to each other.

Best,
R.


On Thu, Jun 21, 2018 at 2:02 AM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:

> Warren, Robert, Acee:
>
>
>
> Warren has a valid question.  I cannot find a long mail thread on
> transitive or non-transitive for this specific attribute.
>
>
>
> Answering Warren’s question about discussions in WG also requires it
> within a larger discussion. The mechanism in
> draft-idr-bgp-prefix-sid-25.txt is a BGP  attribute sent as an
> exception if the BGP-LS service for Segment Routing (SR) is not
> available. The BGP-LS service for SR routing consists of BGP-LS NLRI
> and BGP Attributes.  Draft-idr-bgp-prefix-sid’s mechanism expands the
> traffic flow burden for BGP beyond just BGP-LS peers. Is this wise beyond a single AS?
>
>
>
> Some long-term participants of IDR say it is unwise to expand BGP-LS
> to SR routing (Robert Raszuk, Tony Li). Therefore I suspect that
> restricting draft-idr-bgp-prefix-sid to a non-transitive attribute
> lessens some concerns, but does not resolve the main issues.
>
>
>
> The question of transitive or non-transitive depends on what you think
> SR and BGP’s mechanisms for SR should do. If you think SR is a vibrant
> technology which would should help to mature, then you may want to
> make it easy for the multiple ASes within a Data Center to use the SR functions.
> If this is your belief, then the attribute should be transitive.
>
>
>
> If you are concerned about BGP-LS and SR requiring additional
> resources of BGP peers which do not support BGP-LS, then you will want
> the attribute to be non-transitive or refuse to standardize this mechanism.
>
>
>
> To review IDR’s decision (and the IESG should), you will need to put
> in the context of the entire SR mechanisms that are forthcoming in BGP
> based on the SR Architecture decided by SPRING.  The IESG has approved
> SR architecture and main applications
> (draft-ietf-spring-segment-routing,
>  draft-ietf-spring-segment-routing-central-epe-10.txt., and
> drat-ietf-segment-routing-msdc-09.txt), but it has not looked at the
> mechanisms for SR extensions to BGP-LS or the concept of extending BGP-LS=