Subject: Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-sla-exchange-05

From: "Susan Hares" <[email-masked]>
Date: Mon, 22 Jun 2015 09:26:12 -0400

Bruno:

I would like to separate the readability of the draft, the details of the SLAs, and the passing of SLA information.    I will work with the authors on the readability of the draft and the SLA specification below.  I will work with the authors until they address these questions. 

However, I want to address up-front passing the SLA information.  I agree that netconf/yang or I2RS could pass the SLA information.   However, this set of peers want to pass SLA in BGP.   After we have accepted passing link-state information in BGP between a set of peers, are you concerned about passing SLA information?  The SLA information is also sent between a few peers. 

If this is the issue, I would like to have a discussion of your concerns on the IDR mail list. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, May 22, 2015 9:29 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; idr wg
Subject: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-05

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-idr-sla-exchange-05
Reviewer: Bruno Decraene
Review Date: 22/05/2015
IETF LC End Date: 02/03/2015
Intended Status: Standards Track

Summary:  I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. 

(Or the chairs as I see that this document has not yet been passed to the ADs)

Comments:
In general, the readability of the document is acceptable but could be improved, both from a language and technical precision point of view. (examples below).
However, there are some normative parts of this Standard Track specification that I could not understand.

Major:
M1) The Introduction states
"In a multi-vendor network, translating SLAs into technology-specific and vendor-specific configuration requires to consider specificities of each vendor.
There does not exist any standard protocol to translate SLA agreements into technical clauses and configurations and thus both the steps of out of band learning of negotiated SLA and provisioning them in a vendor specific language can be complex and error-prone."
   
- I guess some would use NETCONF/YANG to address this. It could be questioned why BGP has been preferred. Especially since:
	- in the VPN context (using a lot of QoS and the uses cases described in the document) many customer connections use static routing rather than eBGP. Hence this specification would not be enough to distribute SLA and would require another protocol.
	- QoS is only one part of the configuration effort. Why using different protocols to configure different aspects?

- This may be related to draft-l3vpn-service-yang and the L3VPN Service Model WG (l3sm). May be some form of coordination would be beneficial.

M2)"The exception is where a BGP speaker, in the middle of an update path to the destination AS, aggregates prefixes. We will refer this middle BGP speaker, that aggregates routes, as an Aggregator. Aggregator is then required to insert original NLRI details in the optional advertiser field"
		
If you refer to the use of AS_SET, RFC6472 recommends against the use of AS_SET. So, I'm not sure that there is a need to add complexity in this specification in order to handle route aggregation.
If removed, "section 5.3 Aggregator" may also be removed.
	
M4)
 "Traffic Class Description
        Ascii Description of the Traffic Class"

Should it be UTF-8?

M5) SLA definition
 It would be good to define what a SLA is. Especially since this whole goal of the draft is to advertise SLA in BGP. Citing an individual draft [CPP] is not enough to have an agreed on definition, especially for a STD track RFC.
 Since QoS is not new in the IETF, there is probably a document defining it (or using a more popular terminology).
Looking in google, I don't really see matches for "IETF SLA" (outside of documents written by the authors).
Wikipedia seems to give a quite different definition, much wider than diffserv specific parameters which seems to be the main point of this BGP attribute:
"A service-level agreement (SLA) is a part of a service contract[disambiguation needed] where a service is formally defined. Particular aspects of the service - scope, quality, responsibilities - are agreed between the service provider and the service user. A common feature of an SLA is a contracted delivery time (of the service or performance). As an example, Internet service providers and telcos will commonly include service level agreements within the terms of their contracts with customers to define the level(s) of service being sold in plain language terms. In this case the SLA will typically have a technical definition in terms of mean time between failures (MTBF), mean time to repair or mean time to recovery (MTTR); identifying which party is responsible for reporting faults or paying fees; responsibility for various data rates; throughput; jitter; or similar measurable details.."

M6)
 "   Traffic Class Service (optional),
        16-bit          = type of the field
        variable-length = based on type of the service"
		
Please specify the content of the "variable-length" field. 
If it only contains the Data Type of the IPFIX Information Elements, I'm not sure how the encoding supports, on the receiving side, the skipping of unknown ElementID.
Given that I also don't see an end to end negotiation channel for the BGP speaker to known the capabilities of the BGP receiver, I don't see how the specification will support the introduction of new Traffic Class Services in the future.	

M7) NLRI
I don't see the relation between the QoS attribute and the NLRI.
- Is the QoS attribute only applicable to the NLRI advertised? If so what is the relation with destinationIP* advertised in the classifier Element? Should they be restricted to more specifics of the advertised NLRI?
- Also the QoS attribute may instruct "to drop entire BGP update message [Note that it is an indication to drop entire update message, not only QoS attribute]". This means that the NLRI will not be propagated, hence routed, anymore, which seems strange. To preserve routing of the NLRI, do the QoS attribute require to advertise a less specific prefix (with no QoS attribute) in addition? Or to use ADD_PATH to advertise the NLRI multiple times (with & without the QoS attribute).

Possibly same question for the relation between the QoS attribute and the AFI/SAFI of the BGP UPDATE. Is the QoS attribute to be understood in the context of the AFI/SAFI or not? e.g. if the classifier element is the ipDiffServCodePoint does it match all protocols or only the one of the AFI/SAFI?

M8) Error handling
Current text says that error handling MAY use attribute discard or MAY use treat as withdraw.
This seems underspecified as one implementation would be free to do nothing, while another could do session reset. This would open many BGP session reset in real networks.
Please specific what must be done. 
Besides, other part of the document provides some more specific/different error handling. e.g. "If there are more than one such Traffic Classes present then advertised SLA parameters MUST be ignored."
Finally, the spec needs to define when the new attribute is considered malformed.
On an editorial note, I would prefer a dedicate section related to error handling.

M9) security consideration may require some discussion.
"There is a potential for mis-behaved AS to advertise wrong SLA, stealing identity of another AS."
Agreed. But there are probably other attack vectors (e.g. modifying the attribute during propagation, setting parameters to instruct BGP to drop the message (as this seems alllowed by the specification)...)

"This resembles to problems already identified and resolved, in the routing world, thru reverse path forwarding check."
"Resembles" is not enough. "Resolved" is probably a bit quick.

"One proposal, inline to RPF, to resolve such threats is to have each BGP speaker node, in the forwarding path, perform reverse path check on source AS."
If this is a specification, it should be described in the document (quickly citing it in the security section is not enough).
It's also a bit short in term of specification. e.g. I don't see "source AS" in the forwarding path (neither in the packet nor in the FIB)

"Since we expect these messages to originate and distributed in the managed network, there should not be any risks for identity theft."
If you restrict the use of this specification/ATTRIBUTE in "managed network", this needs to be clarified from the beginning (and not at this very end of the document), and the specification should take measure to ensure that this attribute is not received from/leaked outside of this "managed network".
Defining "managed network" may also help, especially since the proposition involves multiple ASes and multiple organisations.
(otherwise, you need to handle the case when this attribute is used outside of "managed network" and therefore consider the security implications)

M10) IANA section is under specified.
e.g. you should:
- states the name of the registry that you want to create or update.
- states the name of the new entries in existing registries.
- define all your new registries. (e.g. you don't have ones for new QoS TLV subtypes (defined in §3.1), Optional Advertised id TLV, SLA event Type...)
- define the registration policy of those new registries.

Reading RFC5226 may help.

Minor (some not so minor):
m1) From an editorial standpoint, the document may benefit from an english language review.
  - Some sentences are hard to parse (at least for me). e.g. "The need to exchange SLA parameters between domains (Automated Systems (AS)), where in use-cases described in this document, BGP is a suitable protocol for inter-domain exchange [RFC4271][RFC4364].
  - Adding a full point "." at the end of each sentence may help the parsing.
  - IMHO some sentences could be rewritten to improve readability. e.g.
  OLD: 
        highest order bit (bit 0) -
            It defines if update message MUST be dropped (if set to 1)
            without updating routing information base, when this is the
            last BGP receiver from the list of destination ASes this
            attribute is announced to, or MUST announce (if set to 0)
            further to BGP peers
  NEW
        highest order bit (bit 0) -
			This flags defines how update message must be handled by the last BGP receiver in the list of destination ASes.
            If set (1) update message MUST be dropped without updating routing information base.
			If cleared (0) update message MUST be further advertised to BGP peers.
            
  On a side note, at this point in the document, it's not crystal clear what you mean by "update message". The QoS Attribute TLV? The QoS BGP attribute? The BGP UPDATE message? In general, in the document, please use the protocols names of the messages/fields.
  - "SLA sub-type specific value field details." I guess you mean :s/specific/specifies. 
  
m2)
OLD: Remaining bits are currently unused and MUST be set to 0
NEW: The lower-order seven bits of the Attribute Flags octet are unused.  They MUST be zero when sent and MUST be ignored when received. 
(Proposed text is a copy/past from RFC 4271. You are free to use another text but please specify the behaviour on the receiving side as we have seen BGP session reset in the Internet which a much clearer sentence.)

m3) That's not specific to this document, but I would find useful to have the related implementation report draft be referenced in the informative reference section.

m4) "sub type Length" Please specify exactly what part of the message is covered by the length (as some IETF spec use the length of the value field, while some other use the length of the type+length+value fields.
 
m5) "32-bit source AS (Advertiser)" The word "advertiser" may be misleading. (cf draft-hares-idr-update-attrib-low-bits-fix). RFC 4271 uses "Originating speaker" (SIDR seems also to use "Origin".
Multiple occurrences in the draft.

m6)  "0 = ignore Source and Destination AS list from this Value field.
            Instead refer to Source and Destination AS as defined by BGP
            message"
I'm not sure what is meant by the second sentence. Please use the specific names of BGP messages and fields.

m7) "format of the SLA message"
Giving names and number to figures could be considered.
So does adding the memory axis:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

m8) 			
"    Optional advertiser id total len
        16-bit Source address identifier (optional)."
		
I read this as the field "Optional advertiser id total len" contains a 16-bit Source address identifier.
While this field probably contain the length of "something". Please check/clarify. 

m9) 
    "Optional Advertiser id TLV
        4-bit type"
	
You need to specify the size of the "Length" field. Especially since you introduce a somewhat unusual size of the "Type field" and some people may assume that the size of the "length" field is of the same size (4-bit), while some others may believe its the usual 1-octet. 		

m10)"    Destination AS count
        32-bit destination AS count to take variable length AS list."
I guess you mean:
number of destination ASes
This field indicates the number of destination AS present in the Destination AS list

m11) "SLA Id"
The text under "SLA Id" mixes text related to "SLA Id " and text related to  "Content". Please split the text.

m12) I don't see a description of the filed "Content as per SLA Event"

m13)  "    SLA Length
        12-bits"
Please specify what is covered/measured by this length field.		

m14)
"    Direction
        0x1 = incoming, from destination AS towards source AS
        0x2 = outgoing, from source AS towards destination AS"
I find the terms "incoming" and "outcoming" a bit misleading. e.g.
the direction "from source AS towards destination AS" seems to be:
- outgoing in the source AS
- ingoing in the destination AS
		
m15)    "Traffic Class Descr Length
        08-bit, size of the length"
proposition  :s/size of the length/ length of XXX

m16) In section 3, I don't see the specification of the REQUEST SLA even type.
At the end of the document, it's said that "discussion of REQUEST message, for this purpose or any other purpose, is considered out of the scope of this document." In which case, you should probably not specify a REQUEST SLA even type.
   
m19)
"Given IPFIX [RFC5102] has well defined identifier set for a large number of packet attributes, IPFIX IANA registry is "https://www.ietf.org/assignments/ipfix" chosen to specify packet classification attributes."
Sentence is hard to parse, which is an issue for a normative part.	
The reference should probably be listed in the reference section.

"However, since not all identifiers from IPFIX would be applicable to this proposal, only a limited set identified here can be supported by BGP SLA exchange. Any new element identifier, in future, added to the IPFIX IANA registry does not automatically mean supported for this proposal."

- This probably calls for a IANA registry to identify which element identifier can be used.
- Text should clarify that the list of accepted identifiers is defined in the subsequent list (having no name and no number).
		
m20) section 3 is hard to read.
- IMO the document/section 3 would benefit from an section presenting an overview of the solution
- section 3 have a single subsection (3.1) hence the interest of using subsection is limited. Given the size of section 3 (10 pages), to improve readability I would suggest the use of multiples subsection.

m21)
      "The minimum policed unit (m) and maximum packet size (M)
      parameters have no relevance for the purpose of SLA exchange.
      Thus they MUST be ignored."

Why specifying and sending such parameters in BGP if they MUST be ignored by the receiver?	  
	  
m22)
" This rate indicates the minimum rate, measured in bytes of Layer 2 (L2) datagrams per second,"
I'm not sure why the Layer 2 size is used rather than the layer 3 size. As a consequence, you need to send additional information (L2_OVERHEAD) which may be not needed otherwise.
Draft cites RFC 2212 as the source of this TRAFFIC_CLASS_TSPEC parameter, and RFC 2212 use the IP datagram size.

m23)
"4.  Originating SLA Notification

   The QoS attribute to advertise SLA sub-type MUST be added by the
   originator of a BGP UPDATE message."
   
I guess you don't mean that advertising this new attribute is mandatory. So please rephrase (e.g. at least :s/MUST/MAY)   

m24)  " If a BGP node is capable of processing QoS attribute, it optionally MAY process the message."
   What message? The BGP UPDATE?
   
m25)   "BGP node MUST drop SLA related sub-type from the QoS attribute, if
   none of the AS from the destination list is in the forwarding path."

   There is no AS in the forwarding path. Please rephrase.
   
m26)   "5.2.  BGP Node not Capable of Processing QoS Attribute

   If the BGP node is not capable of processing QoS attribute, it MUST
   forward the QoS attribute message unaltered."

This section is completely useless. It should either be removed or at the minimum should not specify a behavior. e.g.
OLD: it MUST forward
NEW: as per RFC4271, it will

or should define what is meant by "processing QoS attribute". (my reading is "does not recognize")

m27) "If advertised QoS Attribute, inside an update message, is with a flag set indicating to drop that message, a receiver MUST drop message if it is the last receiver, in update path, that message is advertised to."
This is not extremely clear. Especially for a "MUST" behavior. Please rephrase using the protocols names of the messages/fields.

m28)"If the advertised SLA is from the next hop, in the reverse path, the receiver may implement advertised SLA for the whole link, the link could be physical or virtual link, associated with the next hop. "
   
I don't understand. Please rephrase. (e.g. which next-hop?, reverse path of what?)

"If NLRI advertised in update message is not of the next hop,"
I don't understand. Please rephrase. 

m29)
   "For cases where if earlier messages have not reached the intended receiver yet, a re-signaling is required.  A receiver may intend to request an SLA message from the originator in such case.  Since BGP messages are considered reliable, it is assumed that advertised messages always reach intended receivers.  Thus discussion of REQUEST
   message, for this purpose or any other purpose, is considered out of the scope of this document."
Some parsing issues.
The text seems to self contradict:
- "a re-signaling is required"
- "Since BGP messages are considered reliable, it is assumed that advertised messages always reach intended receivers."
 
m30)
   "There are well-defined recommendations that exist for traffic class mapping between two technologies. "
   
   Please provides references.
   
m31)
"AS2 can advertise the same or a subset of that SLA to AS3 in the context of tunnel's ip address."
Which tunnel are you refering to?

Nits:
N1) ID Nits reports 1 error (Obsolete normative reference)
N2) In a BGP context, "AS" stands for "Autonomous System" and not "Automated System"
N3)  
"     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~              Traffic Class Elements count/values              ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "
	   
I feel that the figure could be updated to more accurately represent both fields (length).	Something like   
		
	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Traffic  Count|      Traffic Class values                     |
       +-+-+-+-+-+-+-+-+                                               ~
       |                                                               |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

N4) In general for all figures, it's easier if the name of the legend / descriptive paragraph match the name in the figure.
e.g.  
"Class Desc Len" in figure versus "Traffic Class Descr Length" in the legend "Advertiser id TLVs" in figure versus "Optional Advertiser id TLV" in the legend "Event" in figure versus "SLA Event Type" in the legend ...
	
N5)		
"IPFIX IANA registry is "https://www.ietf.org/assignments/ipfix" "
May be added to the reference section.

N6) There is a mix of usage of "octet" and "byte". For consistency, only one should be chosen ("octet" IMHO)

N7)[CPP]      I-D.boucadair-connectivity-provisioning-profile"
why not citing RFC 7297 instead?

Regards,
Bruno

_________________________________________________________________________________________________________________________

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.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Thu, 25 Jun 2015 16:28:59 +0000

Hi Susan,

> From: Susan Hares [mailto:[email-masked]] > Sent: Monday, June 22, 2015 3:26 PM
> 
> Bruno:
> 
> I would like to separate the readability of the draft, the details of the SLAs, and
> the passing of SLA information.    I will work with the authors on the readability
> of the draft and the SLA specification below.  I will work with the authors until
> they address these questions.

Excellent. Thanks.
 
> However, I want to address up-front passing the SLA information.  I agree that
> netconf/yang or I2RS could pass the SLA information.   However, this set of
> peers want to pass SLA in BGP.   After we have accepted passing link-state
> information in BGP between a set of peers, are you concerned about passing
> SLA information?  The SLA information is also sent between a few peers.

A priori, as of today, I would feel that Netconf looks like a more suitable protocol to configure QoS parameters on nodes (assuming that the IETF specify a YANG module for this), especially for the Point to point case (4.1.1.  SLA Advertisement for Point-to-Point Connection).
In theory, BGP may be interesting to propagate the QoS parameters along all the BGP speakers on the path (4.1.2.  SLA Advertisement for Destination AS Multiple Hops Away). However:
- I don't have enough knowledge on QoS to evaluate on how much it makes sense to configure the same QoS parameters on all the nodes of the MP2P trees set up by BGP (especially since this document advertise some L2 specific information while the L2 may be different along the path)
- The uses cases described in "7.  Deployment Considerations" seems to only use QoS configuration on a point to point way
- Possibly, using BGP flowspec may have been an interesting option to consider
 
However, you are right that the IDR WG has taken this work item, so the comment is probably way too late for BGP. And at that time (I remember having discussed this draft in Paris (2012)) Netconf was less mature or spread across the IETF. The question may still be valid for others routing protocols as the main use case indicated is "Provider to advertise contracted SLA parameters to Customer Edge (CE)", and BGP may not be the only protocol used in this use case.

> If this is the issue, I would like to have a discussion of your concerns on the IDR mail list.

Note that IDR is in copy of my comments.

Bruno

> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs. For more information about the Routing Directorate, please see 
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion or
> by updating the draft.
> 
> Summary:  I have significant concerns about this document and recommend
> that the Routing ADs discuss these issues further with the authors.
> 
> In general, the readability of the document is acceptable but could be
> improved, both from a language and technical precision point of view.
> (examples below).
> "In a multi-vendor network, translating SLAs into technology-specific and
> vendor-specific configuration requires to consider specificities of each
> vendor.
> There does not exist any standard protocol to translate SLA agreements into
> technical clauses and configurations and thus both the steps of out of band
> learning of negotiated SLA and provisioning them in a vendor specific
> language can be complex and error-prone."
> 
> - I guess some would use NETCONF/YANG to address this. It could be
> questioned why BGP has been preferred. Especially since:
> 	- in the VPN context (using a lot of QoS and the uses cases described
> in the document) many customer connections use static routing rather than
> eBGP. Hence this specification would not be enough to distribute SLA and
> would require another protocol.
> 	- QoS is only one part of the configuration effort. Why using different
> protocols to configure different aspects?
> 
> - This may be related to draft-l3vpn-service-yang and the L3VPN Service
> Model WG (l3sm). May be some form of coordination would be beneficial.
> 
> M2)"The exception is where a BGP speaker, in the middle of an update path
> to the destination AS, aggregates prefixes. We will refer this middle BGP
> speaker, that aggregates routes, as an Aggregator. Aggregator is then required
> to insert original NLRI details in the optional advertiser field"
> 
> If you refer to the use of AS_SET, RFC6472 recommends against the use of
> AS_SET. So, I'm not sure that there is a need to add complexity in this
> specification in order to handle route aggregation.
>  It would be good to define what a SLA is. Especially since this whole goal of
> the draft is to advertise SLA in BGP. Citing an individual draft [CPP] is not
> enough to have an agreed on definition, especially for a STD track RFC.
> Wikipedia seems to give a quite different definition, much wider than diffserv
> specific parameters which seems to be the main point of this BGP attribute:
> "A service-level agreement (SLA) is a part of a service contract[disambiguation
> needed] where a service is formally defined. Particular aspects of the service
> - scope, quality, responsibilities - are agreed between the service provider
> and the service user. A common feature of an SLA is a contracted delivery
> time (of the service or performance). As an example, Internet service
> providers and telcos will commonly include service level agreements within
> the terms of their contracts with customers to define the level(s) of service
> being sold in plain language terms. In this case the SLA will typically have a
> technical definition in terms of mean time between failures (MTBF), mean
> time to repair or mean time to recovery (MTTR); identifying which party is
> responsible for reporting faults or paying fees; responsibility for various data
> rates; throughput; jitter; or similar measurable details.."
> 
> M6)
> If it only contains the Data Type of the IPFIX Information Elements, I'm not sure
> how the encoding supports, on the receiving side, the skipping of unknown
> ElementID.
> Given that I also don't see an end to end negotiation channel for the BGP
> speaker to known the capabilities of the BGP receiver, I don't see how the
> specification will support the introduction of new Traffic Class Services in the
> future.
> 
> M7) NLRI
> - Is the QoS attribute only applicable to the NLRI advertised? If so what is the
> relation with destinationIP* advertised in the classifier Element? Should they
> be restricted to more specifics of the advertised NLRI?
> - Also the QoS attribute may instruct "to drop entire BGP update message
> [Note that it is an indication to drop entire update message, not only QoS
> attribute]". This means that the NLRI will not be propagated, hence routed,
> anymore, which seems strange. To preserve routing of the NLRI, do the QoS
> attribute require to advertise a less specific prefix (with no QoS attribute) in
> addition? Or to use ADD_PATH to advertise the NLRI multiple times (with &
> without the QoS attribute).
> 
> Possibly same question for the relation between the QoS attribute and the
> AFI/SAFI of the BGP UPDATE. Is the QoS attribute to be understood in the
> context of the AFI/SAFI or not? e.g. if the classifier element is the
> ipDiffServCodePoint does it match all protocols or only the one of the
> AFI/SAFI?
> 
> M8) Error handling
> This seems underspecified as one implementation would be free to do
> nothing, while another could do session reset. This would open many BGP
> session reset in real networks.
> Besides, other part of the document provides some more specific/different
> error handling. e.g. "If there are more than one such Traffic Classes present
> then advertised SLA parameters MUST be ignored."
> Agreed. But there are probably other attack vectors (e.g. modifying the
> attribute during propagation, setting parameters to instruct BGP to drop the
> message (as this seems alllowed by the specification)...)
> 
> "This resembles to problems already identified and resolved, in the routing
> world, thru reverse path forwarding check."
> "One proposal, inline to RPF, to resolve such threats is to have each BGP
> speaker node, in the forwarding path, perform reverse path check on source
> AS."
> If this is a specification, it should be described in the document (quickly citing
> it in the security section is not enough).
> It's also a bit short in term of specification. e.g. I don't see "source AS" in the
> forwarding path (neither in the packet nor in the FIB)
> 
> "Since we expect these messages to originate and distributed in the managed
> network, there should not be any risks for identity theft."
> If you restrict the use of this specification/ATTRIBUTE in "managed network",
> this needs to be clarified from the beginning (and not at this very end of the
> document), and the specification should take measure to ensure that this
> attribute is not received from/leaked outside of this "managed network".
> Defining "managed network" may also help, especially since the proposition
> involves multiple ASes and multiple organisations.
> (otherwise, you need to handle the case when this attribute is used outside of
> "managed network" and therefore consider the security implications)
> 
> - define all your new registries. (e.g. you don't have ones for new QoS TLV
> subtypes (defined in §3.1), Optional Advertised id TLV, SLA event Type...)
>   - Some sentences are hard to parse (at least for me). e.g. "The need to
> exchange SLA parameters between domains (Automated Systems (AS)),
> where in use-cases described in this document, BGP is a suitable protocol for
> inter-domain exchange [RFC4271][RFC4364].
> 			This flags defines how update message must be
> handled by the last BGP receiver in the list of destination ASes.
>   On a side note, at this point in the document, it's not crystal clear what you
> mean by "update message". The QoS Attribute TLV? The QoS BGP attribute?
> The BGP UPDATE message? In general, in the document, please use the
> protocols names of the messages/fields.
> NEW: The lower-order seven bits of the Attribute Flags octet are unused.
> They MUST be zero when sent and MUST be ignored when received.
> (Proposed text is a copy/past from RFC 4271. You are free to use another text
> but please specify the behaviour on the receiving side as we have seen BGP
> session reset in the Internet which a much clearer sentence.)
> 
> m3) That's not specific to this document, but I would find useful to have the
> related implementation report draft be referenced in the informative
> reference section.
> 
> m4) "sub type Length" Please specify exactly what part of the message is
> covered by the length (as some IETF spec use the length of the value field,
> while some other use the length of the type+length+value fields.
> 
> m5) "32-bit source AS (Advertiser)" The word "advertiser" may be misleading.
> (cf draft-hares-idr-update-attrib-low-bits-fix). RFC 4271 uses "Originating
> speaker" (SIDR seems also to use "Origin".
> You need to specify the size of the "Length" field. Especially since you
> introduce a somewhat unusual size of the "Type field" and some people may
> assume that the size of the "length" field is of the same size (4-bit), while some
> others may believe its the usual 1-octet.
> 
> At the end of the document, it's said that "discussion of REQUEST message, for
> this purpose or any other purpose, is considered out of the scope of this
> document." In which case, you should probably not specify a REQUEST SLA
> even type.
> 
> m19)
> "Given IPFIX [RFC5102] has well defined identifier set for a large number of
> packet attributes, IPFIX IANA registry is
> "https://www.ietf.org/assignments/ipfix" chosen to specify packet
> classification attributes."
> "However, since not all identifiers from IPFIX would be applicable to this
> proposal, only a limited set identified here can be supported by BGP SLA
> exchange. Any new element identifier, in future, added to the IPFIX IANA
> registry does not automatically mean supported for this proposal."
> 
> - Text should clarify that the list of accepted identifiers is defined in the
> subsequent list (having no name and no number).
> 
> - section 3 have a single subsection (3.1) hence the interest of using
> subsection is limited. Given the size of section 3 (10 pages), to improve
> readability I would suggest the use of multiples subsection.
> 
> m21)
> I'm not sure why the Layer 2 size is used rather than the layer 3 size. As a
> consequence, you need to send additional information (L2_OVERHEAD) which
> may be not needed otherwise.
> I guess you don't mean that advertising this new attribute is mandatory. So
> please rephrase (e.g. at least :s/MUST/MAY)
> 
> This section is completely useless. It should either be removed or at the
> minimum should not specify a behavior. e.g.
> OLD: it MUST forward
> m27) "If advertised QoS Attribute, inside an update message, is with a flag set
> indicating to drop that message, a receiver MUST drop message if it is the last
> receiver, in update path, that message is advertised to."
> This is not extremely clear. Especially for a "MUST" behavior. Please rephrase
> using the protocols names of the messages/fields.
> 
> m28)"If the advertised SLA is from the next hop, in the reverse path, the
> receiver may implement advertised SLA for the whole link, the link could be
> physical or virtual link, associated with the next hop. "
> 
>    "For cases where if earlier messages have not reached the intended
> receiver yet, a re-signaling is required.  A receiver may intend to request an
> SLA message from the originator in such case.  Since BGP messages are
> considered reliable, it is assumed that advertised messages always reach
> intended receivers.  Thus discussion of REQUEST
> - "Since BGP messages are considered reliable, it is assumed that advertised
> messages always reach intended receivers."
> 
> m30)
> "Class Desc Len" in figure versus "Traffic Class Descr Length" in the legend
> "Advertiser id TLVs" in figure versus "Optional Advertiser id TLV" in the legend
> "Event" in figure versus "SLA Event Type" in the legend ...
> 
> N5)
> ____________________________________________________________
> ____________________________________________________________
> _
> 
> 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.

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.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Jun 2015 12:53:08 -0400

Bruno: 

Thank you for the excellent comments.   I recalled your comments at the 2012 IETF.  This draft needs to be considered in a focuses usage of 2 peers.  All other assumptions need to be carefully reworked.  

I will have the authors expand the Deployment considerations to consider the pros/cons of netconf, I2RS, and BGP-flowspec.   I agree that the QoS consideration is only part of the consideration for this draft. 

Once the authors have completed their revisions to my satisfaction, this draft will be resent to the IDR list for approval.  As part of that second approval process, I would like to  summarize your concerns for the IDR list.  Would you point out  which of your messages or presentations should be considered in that discussion? 

Sue Hares

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 25, 2015 12:29 PM
To: Susan Hares
Cc: [email-masked]; 'idr wg'; 'Shitanshu Shah (svshah)'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-05

Hi Susan,

> of the draft and the SLA specification below.  I will work with the 
> authors until they address these questions.

Excellent. Thanks.
 
> information in BGP between a set of peers, are you concerned about 
> passing SLA information?  The SLA information is also sent between a few peers.

Bruno

> I have been selected as the Routing Directorate reviewer for this 
> draft. The Routing Directorate seeks to review all routing or 
> routing-related drafts as they pass through IETF last call and IESG 
> review, and sometimes on special request. The purpose of the review is 
> to provide assistance to the Routing ADs. For more information about 
> the Routing Directorate, please see 
> Although these comments are primarily for the use of the Routing ADs, 
> it would be helpful if you could consider them along with any other 
> IETF Last Call comments that you receive, and strive to resolve them 
> through discussion or by updating the draft.
> 
> Summary:  I have significant concerns about this document and 
> recommend that the Routing ADs discuss these issues further with the authors.
> 
> However, there are some normative parts of this Standard Track 
> specification that I could not understand.
> 
> Major:
> "In a multi-vendor network, translating SLAs into technology-specific 
> and vendor-specific configuration requires to consider specificities 
> of each vendor.
> There does not exist any standard protocol to translate SLA agreements 
> into technical clauses and configurations and thus both the steps of 
> out of band learning of negotiated SLA and provisioning them in a 
> vendor specific language can be complex and error-prone."
> 
> in the document) many customer connections use static routing rather 
> than eBGP. Hence this specification would not be enough to distribute 
> SLA and would require another protocol.
> 	- QoS is only one part of the configuration effort. Why using 
> different protocols to configure different aspects?
> 
> - This may be related to draft-l3vpn-service-yang and the L3VPN 
> Service Model WG (l3sm). May be some form of coordination would be beneficial.
> 
> M2)"The exception is where a BGP speaker, in the middle of an update 
> path to the destination AS, aggregates prefixes. We will refer this 
> middle BGP speaker, that aggregates routes, as an Aggregator. 
> Aggregator is then required to insert original NLRI details in the optional advertiser field"
> 
> If you refer to the use of AS_SET, RFC6472 recommends against the use 
> of AS_SET. So, I'm not sure that there is a need to add complexity in 
> this specification in order to handle route aggregation.
>  It would be good to define what a SLA is. Especially since this whole 
> goal of the draft is to advertise SLA in BGP. Citing an individual 
> draft [CPP] is not enough to have an agreed on definition, especially for a STD track RFC.
>  Since QoS is not new in the IETF, there is probably a document 
> defining it (or using a more popular terminology).
> Wikipedia seems to give a quite different definition, much wider than 
> diffserv specific parameters which seems to be the main point of this BGP attribute:
> "A service-level agreement (SLA) is a part of a service 
> contract[disambiguation needed] where a service is formally defined. 
> Particular aspects of the service
> - scope, quality, responsibilities - are agreed between the service 
> provider and the service user. A common feature of an SLA is a 
> contracted delivery time (of the service or performance). As an 
> example, Internet service providers and telcos will commonly include 
> service level agreements within the terms of their contracts with 
> customers to define the level(s) of service being sold in plain 
> language terms. In this case the SLA will typically have a technical 
> definition in terms of mean time between failures (MTBF), mean time to 
> repair or mean time to recovery (MTTR); identifying which party is 
> responsible for reporting faults or paying fees; responsibility for various data rates; throughput; jitter; or similar measurable details.."
> 
> M6)
> If it only contains the Data Type of the IPFIX Information Elements, 
> I'm not sure how the encoding supports, on the receiving side, the 
> skipping of unknown ElementID.
> Given that I also don't see an end to end negotiation channel for the 
> BGP speaker to known the capabilities of the BGP receiver, I don't see 
> how the specification will support the introduction of new Traffic 
> Class Services in the future.
> 
> M7) NLRI
> - Is the QoS attribute only applicable to the NLRI advertised? If so 
> what is the relation with destinationIP* advertised in the classifier 
> Element? Should they be restricted to more specifics of the advertised NLRI?
> - Also the QoS attribute may instruct "to drop entire BGP update 
> message [Note that it is an indication to drop entire update message, 
> not only QoS attribute]". This means that the NLRI will not be 
> propagated, hence routed, anymore, which seems strange. To preserve 
> routing of the NLRI, do the QoS attribute require to advertise a less 
> specific prefix (with no QoS attribute) in addition? Or to use 
> ADD_PATH to advertise the NLRI multiple times (with & without the QoS attribute).
> 
> Possibly same question for the relation between the QoS attribute and 
> the AFI/SAFI of the BGP UPDATE. Is the QoS attribute to be understood 
> in the context of the AFI/SAFI or not? e.g. if the classifier element 
> is the ipDiffServCodePoint does it match all protocols or only the one 
> of the AFI/SAFI?
> 
> M8) Error handling
> nothing, while another could do session reset. This would open many 
> BGP session reset in real networks.
> Besides, other part of the document provides some more 
> specific/different error handling. e.g. "If there are more than one 
> such Traffic Classes present then advertised SLA parameters MUST be ignored."
> Agreed. But there are probably other attack vectors (e.g. modifying 
> the attribute during propagation, setting parameters to instruct BGP 
> to drop the message (as this seems alllowed by the specification)...)
> 
> "This resembles to problems already identified and resolved, in the 
> routing world, thru reverse path forwarding check."
> "One proposal, inline to RPF, to resolve such threats is to have each 
> BGP speaker node, in the forwarding path, perform reverse path check 
> on source AS."
> If this is a specification, it should be described in the document 
> (quickly citing it in the security section is not enough).
> It's also a bit short in term of specification. e.g. I don't see 
> "source AS" in the forwarding path (neither in the packet nor in the 
> FIB)
> 
> "Since we expect these messages to originate and distributed in the 
> managed network, there should not be any risks for identity theft."
> If you restrict the use of this specification/ATTRIBUTE in "managed 
> network", this needs to be clarified from the beginning (and not at 
> this very end of the document), and the specification should take 
> measure to ensure that this attribute is not received from/leaked outside of this "managed network".
> Defining "managed network" may also help, especially since the 
> proposition involves multiple ASes and multiple organisations.
> (otherwise, you need to handle the case when this attribute is used 
> outside of "managed network" and therefore consider the security 
> implications)
> 
> - define all your new registries. (e.g. you don't have ones for new 
> QoS TLV subtypes (defined in §3.1), Optional Advertised id TLV, SLA 
> event Type...)
>   - Some sentences are hard to parse (at least for me). e.g. "The need 
> to exchange SLA parameters between domains (Automated Systems (AS)), 
> where in use-cases described in this document, BGP is a suitable 
> protocol for inter-domain exchange [RFC4271][RFC4364].
> 			This flags defines how update message must be handled by the last 
> BGP receiver in the list of destination ASes.
>   On a side note, at this point in the document, it's not crystal 
> clear what you mean by "update message". The QoS Attribute TLV? The QoS BGP attribute?
> (Proposed text is a copy/past from RFC 4271. You are free to use 
> another text but please specify the behaviour on the receiving side as 
> we have seen BGP session reset in the Internet which a much clearer 
> sentence.)
> 
> m3) That's not specific to this document, but I would find useful to 
> have the related implementation report draft be referenced in the 
> informative reference section.
> 
> m4) "sub type Length" Please specify exactly what part of the message 
> is covered by the length (as some IETF spec use the length of the 
> value field, while some other use the length of the type+length+value fields.
> 
> (cf draft-hares-idr-update-attrib-low-bits-fix). RFC 4271 uses 
> "Originating speaker" (SIDR seems also to use "Origin".
> I'm not sure what is meant by the second sentence. Please use the 
> specific names of BGP messages and fields.
> 
> You need to specify the size of the "Length" field. Especially since 
> you introduce a somewhat unusual size of the "Type field" and some 
> people may assume that the size of the "length" field is of the same 
> size (4-bit), while some others may believe its the usual 1-octet.
> 
> The text under "SLA Id" mixes text related to "SLA Id " and text 
> related to "Content". Please split the text.
> 
> At the end of the document, it's said that "discussion of REQUEST 
> message, for this purpose or any other purpose, is considered out of 
> the scope of this document." In which case, you should probably not 
> specify a REQUEST SLA even type.
> 
> m19)
> "Given IPFIX [RFC5102] has well defined identifier set for a large 
> number of packet attributes, IPFIX IANA registry is 
> "However, since not all identifiers from IPFIX would be applicable to 
> this proposal, only a limited set identified here can be supported by 
> BGP SLA exchange. Any new element identifier, in future, added to the 
> IPFIX IANA registry does not automatically mean supported for this proposal."
> 
> - Text should clarify that the list of accepted identifiers is defined 
> in the subsequent list (having no name and no number).
> 
> subsection is limited. Given the size of section 3 (10 pages), to 
> improve readability I would suggest the use of multiples subsection.
> 
> m21)
> I'm not sure why the Layer 2 size is used rather than the layer 3 
> size. As a consequence, you need to send additional information 
> (L2_OVERHEAD) which may be not needed otherwise.
> Draft cites RFC 2212 as the source of this TRAFFIC_CLASS_TSPEC 
> parameter, and RFC 2212 use the IP datagram size.
> 
> m23)
> I guess you don't mean that advertising this new attribute is 
> mandatory. So please rephrase (e.g. at least :s/MUST/MAY)
> 
> This section is completely useless. It should either be removed or at 
> the minimum should not specify a behavior. e.g.
> OLD: it MUST forward
> m27) "If advertised QoS Attribute, inside an update message, is with a 
> flag set indicating to drop that message, a receiver MUST drop message 
> if it is the last receiver, in update path, that message is advertised to."
> This is not extremely clear. Especially for a "MUST" behavior. Please 
> rephrase using the protocols names of the messages/fields.
> 
> m28)"If the advertised SLA is from the next hop, in the reverse path, 
> the receiver may implement advertised SLA for the whole link, the link 
> could be physical or virtual link, associated with the next hop. "
> 
> I don't understand. Please rephrase. (e.g. which next-hop?, reverse 
> path of
> what?)
> 
> receiver yet, a re-signaling is required.  A receiver may intend to 
> request an SLA message from the originator in such case.  Since BGP 
> messages are considered reliable, it is assumed that advertised 
> messages always reach intended receivers.  Thus discussion of REQUEST
> - "Since BGP messages are considered reliable, it is assumed that 
> advertised messages always reach intended receivers."
> 
> m30)
>    "There are well-defined recommendations that exist for traffic 
> class mapping between two technologies. "
> 
> N4) In general for all figures, it's easier if the name of the legend 
> / descriptive paragraph match the name in the figure.
> e.g.
> "Class Desc Len" in figure versus "Traffic Class Descr Length" in the 
> legend "Advertiser id TLVs" in figure versus "Optional Advertiser id 
> TLV" in the legend "Event" in figure versus "SLA Event Type" in the legend ...
> 
> N5)
> 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.

---

From: <[email-masked]>
Date: Thu, 25 Jun 2015 17:48:10 +0000

Sue,

> From: Susan Hares [mailto:[email-masked]] > Sent: Thursday, June 25, 2015 6:53 PM
> 
> Bruno:
> 
> Thank you for the excellent comments.   I recalled your comments at the 2012
> IETF.  This draft needs to be considered in a focuses usage of 2 peers.  All
> other assumptions need to be carefully reworked.
> 
> I will have the authors expand the Deployment considerations to consider the
> pros/cons of netconf, I2RS, and BGP-flowspec. 

That's up to you. That's beyond my comments.
Regarding the deployment consideration section, my comment was to discuss the applicability of _this_ specific document. i.e. states where it has good applicability, and where it has less applicability (e.g. the BGP/MPLS VPN provider also uses static routing between PE & CE)

>  I agree that the QoS
> consideration is only part of the consideration for this draft.
> 
> Once the authors have completed their revisions to my satisfaction, this draft
> will be resent to the IDR list for approval.  As part of that second approval
> process, I would like to  summarize your concerns for the IDR list.  Would you
> point out  which of your messages or presentations should be considered in
> that discussion?

My original set of comments: https://www.ietf.org/mail-archive/web/idr/current/msg14418.html
Follow up as of today: http://www.ietf.org/mail-archive/web/idr/current/msg14547.html

Both are on IDR mailing list.

Bruno
 
> Cc: [email-masked]; 'idr wg'; 'Shitanshu Shah (svshah)'; [email-masked];
> [email-masked]; [email-masked]
> A priori, as of today, I would feel that Netconf looks like a more suitable
> protocol to configure QoS parameters on nodes (assuming that the IETF
> specify a YANG module for this), especially for the Point to point case (4.1.1.
> SLA Advertisement for Point-to-Point Connection).
> In theory, BGP may be interesting to propagate the QoS parameters along all
> the BGP speakers on the path (4.1.2.  SLA Advertisement for Destination AS
> Multiple Hops Away). However:
> - I don't have enough knowledge on QoS to evaluate on how much it makes
> sense to configure the same QoS parameters on all the nodes of the MP2P
> trees set up by BGP (especially since this document advertise some L2 specific
> information while the L2 may be different along the path)
> - The uses cases described in "7.  Deployment Considerations" seems to only
> use QoS configuration on a point to point way
> However, you are right that the IDR WG has taken this work item, so the
> comment is probably way too late for BGP. And at that time (I remember
> having discussed this draft in Paris (2012)) Netconf was less mature or spread
> across the IETF. The question may still be valid for others routing protocols as
> the main use case indicated is "Provider to advertise contracted SLA
> parameters to Customer Edge (CE)", and BGP may not be the only protocol
> used in this use case.
> 
> > responsible for reporting faults or paying fees; responsibility for various
> data rates; throughput; jitter; or similar measurable details.."
> >
> > M6)
> handled by the last
> > 			If cleared (0) update message MUST be further
> advertised to BGP
> > peers.
> >

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Jun 2015 13:49:37 -0400

Bruno:

Thank you for the pointers.  This type help makes my job as WG a lot easier. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 25, 2015 1:48 PM
To: Susan Hares
Cc: [email-masked]; 'idr wg'; 'Shitanshu Shah (svshah)'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] RtgDir review: draft-ietf-idr-sla-exchange-05

Sue,

> IETF.  This draft needs to be considered in a focuses usage of 2 
> peers.  All other assumptions need to be carefully reworked.
> 
> I will have the authors expand the Deployment considerations to 
> consider the pros/cons of netconf, I2RS, and BGP-flowspec.

> Once the authors have completed their revisions to my satisfaction, 
> this draft will be resent to the IDR list for approval.  As part of 
> that second approval process, I would like to  summarize your concerns 
> for the IDR list.  Would you point out  which of your messages or 
> presentations should be considered in that discussion?

Bruno
 
> Cc: [email-masked]; 'idr wg'; 'Shitanshu Shah (svshah)'; 
> [email-masked]; [email-masked]; 
> [email-masked]
> > I would like to separate the readability of the draft, the details 
> > of the SLAs,
> and
> > However, I want to address up-front passing the SLA information.  I 
> > agree
> that
> > passing SLA information?  The SLA information is also sent between a 
> > few
> peers.
> 
> A priori, as of today, I would feel that Netconf looks like a more 
> suitable protocol to configure QoS parameters on nodes (assuming that 
> the IETF specify a YANG module for this), especially for the Point to point case (4.1.1.
> In theory, BGP may be interesting to propagate the QoS parameters 
> along all the BGP speakers on the path (4.1.2.  SLA Advertisement for 
> Destination AS Multiple Hops Away). However:
> - I don't have enough knowledge on QoS to evaluate on how much it 
> makes sense to configure the same QoS parameters on all the nodes of 
> the MP2P trees set up by BGP (especially since this document advertise 
> some L2 specific information while the L2 may be different along the 
> path)
> - The uses cases described in "7.  Deployment Considerations" seems to 
> only use QoS configuration on a point to point way
> However, you are right that the IDR WG has taken this work item, so 
> the comment is probably way too late for BGP. And at that time (I 
> remember having discussed this draft in Paris (2012)) Netconf was less 
> mature or spread across the IETF. The question may still be valid for 
> others routing protocols as the main use case indicated is "Provider 
> to advertise contracted SLA parameters to Customer Edge (CE)", and BGP 
> may not be the only protocol used in this use case.
> 
> > If this is the issue, I would like to have a discussion of your 
> > concerns on the
> IDR mail list.
> 
> > review, and sometimes on special request. The purpose of the review 
> > is to provide assistance to the Routing ADs. For more information 
> > about the Routing Directorate, please see 
> > Although these comments are primarily for the use of the Routing 
> > ADs, it would be helpful if you could consider them along with any 
> > other IETF Last Call comments that you receive, and strive to 
> > resolve them through discussion or by updating the draft.
> >
> > In general, the readability of the document is acceptable but could 
> > be improved, both from a language and technical precision point of view.
> > (examples below).
> > "In a multi-vendor network, translating SLAs into 
> > technology-specific and vendor-specific configuration requires to 
> > consider specificities of each vendor.
> > There does not exist any standard protocol to translate SLA 
> > agreements into technical clauses and configurations and thus both 
> > the steps of out of band learning of negotiated SLA and provisioning 
> > them in a vendor specific language can be complex and error-prone."
> >
> > 	- in the VPN context (using a lot of QoS and the uses cases 
> > described in the document) many customer connections use static 
> > routing rather than eBGP. Hence this specification would not be 
> > enough to distribute SLA and would require another protocol.
> > Aggregator is then required to insert original NLRI details in the 
> > optional
> advertiser field"
> >
> > If you refer to the use of AS_SET, RFC6472 recommends against the 
> > use of AS_SET. So, I'm not sure that there is a need to add 
> > complexity in this specification in order to handle route aggregation.
> >  It would be good to define what a SLA is. Especially since this 
> > whole goal of the draft is to advertise SLA in BGP. Citing an 
> > individual draft [CPP] is not enough to have an agreed on 
> > definition, especially for a
> STD track RFC.
> > Looking in google, I don't really see matches for "IETF SLA" 
> > (outside of documents written by the authors).
> > Wikipedia seems to give a quite different definition, much wider 
> > than diffserv specific parameters which seems to be the main point 
> > of this BGP
> attribute:
> > definition in terms of mean time between failures (MTBF), mean time 
> > to repair or mean time to recovery (MTTR); identifying which party 
> > is responsible for reporting faults or paying fees; responsibility 
> > for various
> > Given that I also don't see an end to end negotiation channel for 
> > the BGP speaker to known the capabilities of the BGP receiver, I 
> > don't see how the specification will support the introduction of new 
> > Traffic Class Services in the future.
> >
> > M7) NLRI
> > what is the relation with destinationIP* advertised in the 
> > classifier Element? Should they be restricted to more specifics of 
> > the advertised
> NLRI?
> > message [Note that it is an indication to drop entire update 
> > message, not only QoS attribute]". This means that the NLRI will not 
> > be propagated, hence routed, anymore, which seems strange. To 
> > preserve routing of the NLRI, do the QoS attribute require to 
> > advertise a less specific prefix (with no QoS attribute) in 
> > addition? Or to use ADD_PATH to advertise the NLRI multiple times 
> > (with & without the QoS
> attribute).
> >
> > Possibly same question for the relation between the QoS attribute 
> > and the AFI/SAFI of the BGP UPDATE. Is the QoS attribute to be 
> > understood in the context of the AFI/SAFI or not? e.g. if the 
> > classifier element is the ipDiffServCodePoint does it match all 
> > protocols or only the one of the AFI/SAFI?
> >
> > M8) Error handling
> > "One proposal, inline to RPF, to resolve such threats is to have 
> > each BGP speaker node, in the forwarding path, perform reverse path 
> > check on source AS."
> > measure to ensure that this attribute is not received from/leaked 
> > outside of
> this "managed network".
> >   - Some sentences are hard to parse (at least for me). e.g. "The 
> > need to exchange SLA parameters between domains (Automated Systems 
> > (AS)), where in use-cases described in this document, BGP is a 
> > suitable protocol for inter-domain exchange [RFC4271][RFC4364].
> > clear what you mean by "update message". The QoS Attribute TLV? The 
> > QoS
> BGP attribute?
> > another text but please specify the behaviour on the receiving side 
> > as we have seen BGP session reset in the Internet which a much 
> > clearer
> > sentence.)
> >
> > m4) "sub type Length" Please specify exactly what part of the 
> > message is covered by the length (as some IETF spec use the length 
> > of the value field, while some other use the length of the type+length+value fields.
> >
> > m16) In section 3, I don't see the specification of the REQUEST SLA 
> > even
> type.
> > "However, since not all identifiers from IPFIX would be applicable 
> > to this proposal, only a limited set identified here can be 
> > supported by BGP SLA exchange. Any new element identifier, in 
> > future, added to the IPFIX IANA registry does not automatically mean 
> > supported for this
> proposal."
> >
> > - Text should clarify that the list of accepted identifiers is 
> > defined in the subsequent list (having no name and no number).
> >
> > - section 3 have a single subsection (3.1) hence the interest of 
> > using subsection is limited. Given the size of section 3 (10 pages), 
> > to improve readability I would suggest the use of multiples subsection.
> >
> > m21)
> > This section is completely useless. It should either be removed or 
> > at the minimum should not specify a behavior. e.g.
> > OLD: it MUST forward
> > m27) "If advertised QoS Attribute, inside an update message, is with 
> > a flag set indicating to drop that message, a receiver MUST drop 
> > message if it is the last receiver, in update path, that message is advertised to."
> > This is not extremely clear. Especially for a "MUST" behavior. 
> > Please rephrase using the protocols names of the messages/fields.
> >
> > m28)"If the advertised SLA is from the next hop, in the reverse 
> > path, the receiver may implement advertised SLA for the whole link, 
> > the link could be physical or virtual link, associated with the next hop. "
> >
> >    "For cases where if earlier messages have not reached the 
> > intended receiver yet, a re-signaling is required.  A receiver may 
> > intend to request an SLA message from the originator in such case.  
> > Since BGP messages are considered reliable, it is assumed that 
> > advertised messages always reach intended receivers.  Thus discussion of REQUEST
> > N4) In general for all figures, it's easier if the name of the 
> > legend / descriptive paragraph match the name in the figure.
> > e.g.
> > "Class Desc Len" in figure versus "Traffic Class Descr Length" in 
> > the legend "Advertiser id TLVs" in figure versus "Optional 
> > Advertiser id TLV" in the legend "Event" in figure versus "SLA Event Type" in the legend ...
> >
> > N5)
> > 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.
> >
> > 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.
> >