Re: [tsvwg] Suresh Krishnan's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)

[Brian E Carpenter <[e-mail]>]

On 2019-02-21 14:29, Suresh Krishnan wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-tsvwg-le-phb-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I was not sure how this behavior in Section 8 is expected to be deployed and
> used.
> 
> "  A DS domain that still uses DSCP CS1 for marking LE traffic
>    (including Low Priority-Data as defined in [RFC4594] or the old
>    definition in [RFC3662]) SHOULD remark traffic to the LE DSCP
>    '000001' at the egress to the next DS domain."
> 
> Is the expectation that even on a domain that has not been updated to use the
> new DSCP there will be some node at the edge that will have been updated? If
> so, it might be good to explicitly note this. If not, I cannot see how a legacy
> node will follow this recommendation.

If the routers involved genuinely follow the diffserv model, in which
any per-hop behavior can be mapped to any codepoint, all these things
will be configurable. So if the operator decides to continue using CS1
internally but conform to the spec externally, they could reconfigure the
edges accordingly. In other words the legacy is in the configuration,
not the code.

Of course if the vendor hard coded the (mis)use of CS1 this can't
work, which I guess is why it's a SHOULD.

   Brian