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

["Susan Hares" <[e-mail]>]

Shitanshu: 

I understand Bruno's concerns.  

Let's work together to address them.  Please send me your revised draft (off-list), and we'll work to address Bruno's concerns.  After we've converged on a revised draft, we'll send it back to Bruno.   

Sue 

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

Hi Shitanshu,

Thanks for the answers.

Please see inline. [Bruno]

As a high level summary:
- A revised draft is needed, especially since some answers are "will be addressed in next revision". 
	- The mandatory point to be addressed is the BGP error handling of this new attribute. (should be easy to fix but must be fixed) (M8)
	- There may also be a point about "dropping the message" which is not yet clear to me. I'll wait for the next revision (M7)
- I won't follow up on whether BGP or netconf is the right protocol to configure QoS related parameters. This is way above my reviewer hat. I would just like the document to state its non-applicability to BGP/MPLS VPN providers using static routing between PE & CE, as this may avoid wrong expectations.  "7.  Deployment Considerations" seems the right place for this.
- All others points are expected to be addressed in the next revision.


Bruno

> From: Shitanshu Shah (svshah) [mailto:[e-mail]] > Sent: 
> Monday, June 15, 2015 9:10 PM
> 
> 
> Sorry for the long delay. have been on vacation..
> 
> Many thanks Bruno for the detailed review and comments/suggestions..
> Please find response inline ##svshah
> 
> 
> On 5/22/15, 6:29 AM, "[e-mail]"
> <[e-mail]> wrote:
> 
> >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.
> 
> ##svshah, there are multiple aspects to it. Today provider providing 
> negotiated SLA already has it provisioned in some form of a policy to 
> enforce the contracted traffic. one would simply leverage such 
> existing defined policy to signal to the the other end of the 
> contracted party without requiring any additional complexity in the 
> network with additional controllers. With respect to protocol, BGP is 
> well established inter-domain protocol. Not sure if Netconf can be 
> used to exchange info across domains/trust boundaries specifically if they are managed in different administrative boundaries.

[Bruno] I've raised the point, but I'll leave this to chairs and ADs.
I understand that such comment comes late in the draft process.
AFAIK, SNMP can provide different views, some being suitable to customers, or peering ASes. I guess Netconf would allow the same. This seems mainly a matter of authentication.
That does not change the point that a priori netconf seems more suitable to SLA/QoS configuration than BGP.

 
> 
> > 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.
> 
> ##svshah, this actually had come up in early days of this proposal 
> work before we progressed further with the proposal. It has been 
> learned that while there are specific regions where static routing may 
> be used, there are actually number of cases where eBGP is used. Infact 
> it is in the VPN context, eBGP is found to be used.

[Bruno] Working for a SP providing BGP/MPLS VPN services, I m pretty sure that static routing is also used between PE & CE. IMO static routing is used for a significant part of CE. And theses sites/customers equally need QoS. So this seems (to me) a pitty to design a new solution which is not applicable to a significant part of the network/customers.
Clearly I don't see an obvious correlation between the routing protocol used between PE & CE and the need for QoS.

At the minimum, the document should clearly talks about this restriction and warn SP that they may want to consider an alternative solution to configure QoS related parameter if they use static routing for some of their PE-CE.

 
> I agree that QoS is pervasive and contracts of QoS SLA happen in many 
> types of deployments. Any protocol of choice will not fit all deployment models.
> Honestly, waiting for universal method will be forever.

[Bruno] I would assume that Netconf has more chance to be a "universal" configuration method then BGP, especially for non-routing related information.
 
> 
> > 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.
> 
> ##svshah, ok. We can use that as a guidance. Aggregation is 
> highlighted simply to complete a possible scenario. Aggregation anyway 
> is not an interesting case for SLA exchange. If advice is against it anyway, we do not have to highlight it.

[Bruno] It's up to you, whether you consider this additional complexity is useful or not, to handle a case which is not recommended anymore. You could at least reference RFC 6472

 
> 
> >
> >M4)
> > "Traffic Class Description
> >        Ascii Description of the Traffic Class"
> >
> >Should it be UTF-8?
> 
> ##svshah, that should be fine.

[Bruno] In which cases, you may find interesting the following IETF tutorial "A Précis of PRECIS:next-generation internationalization considerations"
https://www.ietf.org/edu/tutorials/92-WG-Chairs-Lunch-precis-Sullivan.pdf

 
> >
> >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.
> 
> ##svshah, I understand and agree that SLA is a generic term and is 
> context dependent. Are you looking for elaborating something in the 
> following context? We already have cited QoS parameters from RFC2212, RFC2475 ..
> We can elaborate in the following paragraph to add more content along 
> the lines.
> 
> "
>    Typically there is a contractual Service Level Agreement (SLA)
>    established between a customer and a provider or between providers.
>    This contractual agreement defines the nature of the various traffic
>    classes and services needed within each traffic class.  The contract
>    may include full line-rate or sub line-rate without additional
>    traffic classes, or it may contain additional traffic classes and
>    service definitions for those traffic classes.  Finer granular
>    traffic classes may be based on some standard code points (like
>    DSCP), or specific set of prefixes.
> "

[Bruno] A definition of SLA sounds interesting. Especially if you say that the meaning is context dependent.
I can't comment on the definition. At least it seems to fit the data that you advertise in BGP, which is good.


> > 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.
> 
> ##svshah, what it says that length of the field is to be specified 
> based on type of the field specified. Thus it does have both type and 
> length values specified in 2 different fields. Hope that clarifies.

[Bruno] ok. Can you also clarify in the spec that this correspond to 2 distinct fields:
Length: 1 octet. Unsigned integer representing the length of the value field.
Value field: based on type of the service

Note: I used "1 octet" but may be you meant 2 octets. The point is to specify "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?
> 
> ##svshah, that is correct. If destinationIP advertised in the 
> classifier element then in that case it would be restricted to specifics.

[Bruno] ok. I think that this should be indicated in the document.

 
> 
> >- 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?
> 
> ##svshah, the provision is not so much to advertise less specific 
> prefix but instead to support ordering where SLA to be advertised 
> after the fact prefix was already advertised before. In such case, a 
> new message will be triggered just for the sake of SLA advertisement. 
> No need to route NLRI beyond SLA receiver and thus provision of this option.

[Bruno] Do you that mean the same prefix (BGP NLRI) has been advertised before? 
But in BGP, the subsequent advertisement of the same NLRI _replace_ the previous one. There is no order/multiple ones. So if you drop the BGP update, you don't only drop the SLA signaling but also the routing of the prefix.
 
> 
> > 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?
> 
> ##svshah, it only would match the one of the AFI/SAFI.

[Bruno] ok. I think that this should be indicated in the document.
 
 
> >
> >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.
> 
> ##svshah, sure. Will look into incorporating specifics throughout 
> document where applicable as well in a dedicated section.
> 

[Bruno] ok. This is the most important point for me. All others comments only affect the QoS attribute. Here you can affect the whole network, up to the whole Internet.

 
> >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)
> 
> 
> ##svshah, sure. Will incorporate accordingly.

[Bruno] Ack.
 
> >
> >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.
> 
> ##svshah, thanks for the pointer. Yeah, I recognize that IANA section 
> is under specified. Will address it.

[Bruno] Ack.
 
> 
> >
> >
> >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.
> 
> ##svshah, will make appropriate changes

[Bruno] ok thanks.

> 
> >
> >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.)
> 
> ##svshah, understood. Will make necessary changes.

[Bruno] ok thanks.
 
> >
> >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.
> 
> ##svshah, ok.
> 
> >
> >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.
> 
> ##svshah, ok.
> 
> >
> >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.
> 
> ##svshah, I see what you are saying. Will make necessary change.
> 
> >
> >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
> >
> 
> ##svshah, ok
> 
> >
> >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.
> 
> 
> ##svshah, we may not need this if Aggregation is discouraged and is to 
> be removed as in one of earlier major comments.
> 
> >
> >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
> 
> ##svshah, correct
> 
> >
> >m11) "SLA Id"
> >The text under "SLA Id" mixes text related to "SLA Id " and text 
> >related to  "Content". Please split the text.
> 
> ##svshah, ok
> 
> >
> >m12) I don't see a description of the filed "Content as per SLA Event"
> 
> ##svshah, ok, let me put some content there.
> 
> >
> >m13)  "    SLA Length
> >        12-bits"
> >Please specify what is covered/measured by this length field.
> 
> ##svshah, ok
> 
> >
> >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
> 
> ##svshah, since I’ve described what each means, I can get rid of the 
> terms “incoming” and “outgoing” completely.

[Bruno] ok
 
> 
> >
> >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.
> 
> ##svshah, yeah. I have removed in newer revision. REQUEST type should 
> not be there since we are not defining it here.

[Bruno] ok
 
> >
> >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).
> 
> ##svshah, I can add text here to refer back to the table specified in 
> earlier section. That way table at one place consistently can 
> highlight what IPFIX elements are used by this proposal.
> 
> >
> >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.
> 
> 
> ##svshah, with iterative works, this is where section 3 is landed. I 
> feel that the way it is currently is best representative of the 
> proposal. Let me see though if there is any room to incorporate your suggestion.
> 
> >
> >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?
> 
> ##svshah, the sentence you are referring to here has total 5 
> parameters (TRAFFIC_CLASS_TSPEC), out of which 2 suggested here to be 
> ignored. While review with tsvwg, there was a strong suggestion to 
> re-use TRAFFIC_CLASS_TSPEC (RFC2212) for the purpose here. And thus 
> re-use of TSPEC parameters from which first 3 parameters are relevant herewith.

[Bruno] ok

 
> >
> >
> >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.
> 
> ##svshah, In practice we find that L2 overhead is significantly 
> important with respect to SLA between 2 domains. Thus we are making 
> consideration of
> L2 as a norm. L2 overhead field is introduced just to cover cases 
> where the use-case need to consider only IP.

[Bruno] RFC 2212 uses IP datagram size, not L2. I'm not sure why tsvwg asked to use the same syntax format but agreed to have a different semantic.
Also, as the layer 2 change across ASes, I'm not sure how this is relevant to propagate layer 2 specific information across multiple AS borders.
But that's your spec. I'm mainly reviewing the BGP specific part.

 
> >
> >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)
> 
> ##svshah, yeah adverting attribute is not mandatory. What it is trying 
> to highlight is that this attribute can’t be inserted by intermediate nodes.

[Bruno] ok, but that's not what's written. Given your answer, I would write it as: The QoS attribute MUST only be added by the originator and MUST NOT be added during BGP propagation.

/Bruno

> 
> >
> >
> >m24)  " If a BGP node is capable of processing QoS attribute, it 
> >optionally MAY process the message."
> >   What message? The BGP UPDATE?
> >
> 
> ##svshah, will revise text to make it more clear.
> 
> >
> >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.
> 
> ##svshah, ok
> 
> >
> >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")
> 
> 
> ##svshah, ok
> 
> >
> >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.
> 
> ##svshah, ok
> 
> >
> >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.
> 
> ##svshah, ok
> 
> >
> >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.
> >
> 
> ##svshah, ok. Let me provide a reference to MPLS TC mapping.
> 
> >
> >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?
> >
> 
> ##svshah, agree. Tunnel is not qualified in the description here. Will 
> revise the text appropriately.
> 
> >
> >Nits:
> >N1) ID Nits reports 1 error (Obsolete normative reference)
> 
> ##svshah, yes, have taken care of it.
> 
> >N2) In a BGP context, "AS" stands for "Autonomous System" and not 
> >"Automated System"
> 
> ##svshah, oops.. Thanks for catching typo.
> 
> >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                     |
> >       +-+-+-+-+-+-+-+-+                                               ~
> >       |                                                               |
> >       ~                                                               ~
> >       |                                                               |
> >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> ##svshah, agree. Looks better this way.
> 
> >
> >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 ...
> 
> ##svshah, will double check them
> 
> >
> >N5)
> >"IPFIX IANA registry is "https://www.ietf.org/assignments/ipfix" "
> >May be added to the reference section.
> 
> ##svshah, ok
> 
> >
> >N6) There is a mix of usage of "octet" and "byte". For consistency, 
> >only one should be chosen ("octet" IMHO)
> 
> ##svshah, ok
> 
> >
> >N7)[CPP]      I-D.boucadair-connectivity-provisioning-profile"
> >why not citing RFC 7297 instead?
> 
> 
> ##svshah, have already taken care of it.
> 
> Regards,
> Shitanshu
> 
> >
> >
> >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
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/idr


_________________________________________________________________________________________________________________________

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.