|
Embedded in my question about VPNs is an implicit suggestion (which I’ll now make explicit ...) -- this L2 overhead parameter would be more robust if it were
defined as the number of octets difference between the full frame that is sent on the wire and the size of the IP packet to which the token buckets apply. Even if there are no known current needs to account for anything other than L2 framing, this approach
is robust to future network engineering encapsulation “creativity” ;-). Thanks, --David From: Tsv-art [mailto:tsv-art-bounces@xxxxxxxx]
On Behalf Of Shitanshu Shah Hi David, We will add more text to clarify rationale for L2_OVERHEAD. Do you have a preference or suggest a way to specify L2 rates? We will work on defining 2 TSpecs to specify two rates (min and max).
Regards, Shitanshu From: Black, David <David.Black@xxxxxxxx> Ok, please make that rationale for the L2_OVERHEAD parameter clear in the draft: > Though for the cases where physical links are not to be over-run, and/or, sla defined are based on
l2 rates, the Consumer would It looks like the result is that if the Producer’s L2 overhead is larger than the Consumer’s, and
the token buckets are specified in IP octets, the consumer has to calculate a per-packet charge of the L2 overhead difference against the IP token bucket (and in the opposite case, there may be a per-packet credit). Are there cases where the overhead is
not all L2, e.g., SLA/TCA Consumer is using a VPN that terminates between Consumer and Producer? Thanks, --David From: Shitanshu
Shah [mailto:shitanshu_shah@xxxxxxxxxxx]
Hi David, One response inline ##svshah2 From: Black,
David <David.Black@xxxxxxxx> David> Inline ... Thanks, --David From: Shitanshu
Shah [mailto:shitanshu_shah@xxxxxxxxxxx]
Hi David, Thank you for taking time for the review.. Please find our response inline ##svshah and [Med] Regards,
Shitanshu From: David
Black <david.black@xxxxxxx> Reviewer: David Black
##svshah, the purpose for advertising L2 overhead, from the Producer to the Consumer, is to make sure
traffic is well conditioned, at the egress of the Consumer, to avoid possible indiscriminate drops at the ingress of the Producer. In another words, the Producer is telling the Consumer to ignore its own link level overhead, instead use Producer's provided
link level overhead while running frames through QoS functions (this is relevant in use-cases where l2 overhead of the egress link on Consumer and of ingress link on the Producer are of different size, e.g., in the vpn/tunnel connection between two peer nodes
which physically may be multiple hops away). I understand your comments regarding re-using TSpec without any modification. Do you agree with the
use-case of l2 differences? If yes, any suggestion how to accommodate that? David> Specifying this in terms of IP octets implies that L2 overhead is to be ignored on both links.
That’s simpler, and a few sentences of discussion about possible L2 framing differences should cover what needs to be done (e.g., if traffic rates are configured in terms of L2 octets, then explain how each entity converts between IP traffic and L2 traffic
- the draft already effectively contains that explanation). ##svshah2, just to make sure that some of the real use are not left out.. For the traffic conditioning where sla established is for the ip based rates only, it suffices for
the Producer to send rates only IP based ignoring any specific of l2 overheads. Though for the cases where physical links are not to be over-run, and/or, sla defined are based on
l2 rates, the Consumer would need to know l2 overhead from the Producer. Otherwise 10 byes of l2 overhead difference on 64 bytes packets can be significant compare to on 1400 bytes packets, and thus the Producer does not have a way to convert rates to ip based
(this can cause functional issue), since this has to be per packet consideration. Regards, Shitanshu
##svshah, what you describe below conceptually very much makes sense and that is what we attempt to
achieve. What is unclear though how to capture that using TSpec definition specified in RFC2215. Since that TSpec definition has both minimum-rate and maximum-rate, but no in/out profile marking parameters. Is your proposal below to define two TSpecs using the same definition from RFC2215? Wouldn't in that
case we have min/max specified twice? min/max in each TSpec? and thus confusing to represent one min and one max through two TSpecs? David> See RFC 2698 for the desired behavior and the parameters needed to specify it. The current
idr-sla draft is not able to represent the traffic conditioning mechanisms specified in both RFC 2698 and RFC 2697, as each mechanism requires two token buckets (e.g., there are two burst sizes, but the idr-sla draft TSpec only contains one). This deficiency
needs to be dealt with. One possibility for simplification is to drop the max-rate from the RFC 2115 TSpec and assume that the max-rate for bursting is the effective line rate.
##svshah, It is around the semantics of a single queue with a different threshold for a set of code-points,
where packet for a specific code-point is to be tail dropped if overall queue-depth hits code-point specific threshold at the arrival of that packet. We will add appropriate clarification for this semantics. David> Will look at revision
##svshah, Sure. Is following clarification okay? (some of the wordings taken from RFC2598) " A higher priority class of traffic to be served without pre-empted by lower priority class of traffic for
more than a packet time at the configured rate. In the system that implements WRR, the use of relative priority may get restricted where a single queue
may be used for a higher priority traffic class where that queue is configured for the full share of the output bandwidth. " David> Last sentence basically says that WRR weights are out-of-scope. That seems wrong. Will look at
revision. ##svshah, They are to facilitate hierarchy. A specific Traffic Class, can further be divided in a multiple
subset of Traffic Classes, with their own Traffic Class Elements and Traffic Class Services. Will correct the wording to remove your this specific concern.
##svshah, While eventually "Traffic Conditioning Agreement" should be translated to the actual forwarding
qos policy on any vendor specific device, TCA exchange largely carries concepts/semantics that is either standard based or well understood. While we are not aware of any working group document of QoS Yang Model, we think that concepts of
Traffic Conditioning should be easily adaptable to any QoS Yang Models since they also have to be defined to support those concepts. David> Still want to see cross-check with implementations here. David> OK, thanks.
##svshah, sure will make necessary changes, also in the context of earlier comment.
[Med] That text is terse because we are reusing the BGP machinery for advertising/withdrawing; we only augment
it with triggers that are linked to the SLA information. A new SLA will lead to an update message with ADVERTISE, an update of an existing SLA will trigger an update message. We do think this information is already present in the document.
David>This is hard to understand it, as there is no statement that the BGP machinery is being used,
and the material on SLA usage is spread in different places. I suggest starting section 3 with a discussion of advertisement/update/withdrawal, and how all three are realized via a single ADVERTISE method via BGP UPDATE - this was difficult to figure out
in reading the current draft. it should be expanded David> Ok, that’s an editorial choice - I prefer to explain how something works before defining its
on-the-wire data format. If an advertised SLA ID is different from earlier advertised
one, [Med] The reason we didn’t adopted that design is that we don’t want to make assumptions on which data the remote peer
will be used for enforcing local actions and also because of this text: The SLA ID applies to aggregate traffic to prefixes for a given AFI/SAFI that share the same Source AS and SLA ID. David> That’s fine, I wanted to ensure that this had been considered. The discussion of BGP mechanism
reuse will probably help here. David> Really??? Please reread the first comment above: - The first three parameters (DSCP, MPLS EXP field in top label, 802.1q priority) can David> Taking just DSCP, it can change on a per-link basis, so something has to specify which link
(between the SLA Producer and SLA Consumer?) is involved. It probably suffices to say that it’s the link that crosses the relevant AS boundary, but that does have to be stated, as it’s nowhere to be found in the far more general IPFIX registry. David> I stand by this statement and recommend a complete rewrite of the security considerations.
David> There are additional attacks enabled by this attribute.
[Med] An example of what an admin needs to check if this information can be sent to a given peer or not. Some
of the content of the attribute contains some sensitive information such as contract Id, classes, etc.
How does
one [Med] The idea here is to avoid leaking such data in to the global routing table. Only entitled peers need receive
such information with controlled scope. David> I understand the idea - the problem is that I don’t see specification of what has to be implemented
in either the text in the draft or the above explanations. - The next to last paragraph in section 10 is almost content-free, as
it leaves [Med] I guess you are referring to the following text. Validation checks are really deployment-specific. The text calls out the issue and
recommends an action; how to translate this action into detailed actions is realty local to a domain The attribute may be advertised by a misbehaving node to communicate SLA parameters that are not aligned with the SLA agreements. Though the enforcement of SLA parameters is outside the scope of this document, it is RECOMMENDED that the SLA Consumer to enforce a set of validation checks before translating the SLA parameters conveyed in the QoS attributes into provisioning actions. Such validations MAY rely on SLA parameters like the origin AS or SLA ID, like generating SLA ID using pseudo-random schemes [RFC4086]. David> I stand by the “exercise to the reader” criticism - one way to be honest about this would
be to change the paragraph to: The attribute may be advertised by a misbehaving node to communicate SLA parameters that are not aligned with the SLA agreements. The enforcement of SLA parameters is outside the scope of this document. David> That does not change any normative content of the original paragraph. My view is that the “outside the scope of this document” statement is wrong because all of these parameters are being defined in this draft.
The phrase "SHOULD CONSIDER" indicates that the authors of the
specification think that implementations should do something, but they're not sure quite what. ------------------------ |