Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Ben, 

> So the quoted statement that I was confused
> by is in effect saying that "if there is only ever one
> classification action and it fully specifies all possible choices
> for the path of the packet, then these context headers are not
> needed anymore"?

I confirm. 

Will see if/how to tweak it better as you were confused.  

Thanks. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : jeudi 5 novembre 2020 23:40
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> Cc : The IESG <[e-mail]>; draft-ietf-sfc-serviceid-
> [e-mail]; [e-mail]; [e-mail]; Greg Mirsky
> <[e-mail]>
> Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-
> header-12: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> Also inline (though not too much left to say)...
> 
...
> >
> > >
> > > Section 4
> > >
> > >    instance selection, or policy selection at SFs.  Note that
> the
> > > use of
> > >    the Performance Policy Identifier is not helpful if the path
> > >    computation is centralized and a strict SFP is presented as
> local
> > >    policy to SF Forwarders (SFFs).
> > >
> > > I'm not sure I understand why this is the case; wouldn't the
> > > performance policy information still be useful for, e.g., not
> > > dropping UHR packets when buffers are full, regardless of
> whether
> > > the SFP is strict or not?
> >
> > [Med] The text is about path computation and selection.
> >
> > We are not using for marking because otherwise we will have the
> "usual" comments why not using flow lable, dscp marking, etc.
> 
> Ah, it sounds like I was misunderstanding things originally.  Based
> you your explanation here, it seems like the policy information is
> only intended to be used in path computation/selection, but it needs
> to be conveyed in the NSH because there is opportunity for
> reclassification along the SFP (and, IIRC, cases where the SFP is
> not fully specified at classification time and a local SFF makes a
> choice on a per-packet basis), which would still need the policy
> information as input.
> The particular local behaviors such as preferred processing for ULL
> or UHR are controlled by the normal mechanisms for doing so, e.g.,
> DSCP.  Is that right?  So the quoted statement that I was confused
> by is in effect saying that "if there is only ever one
> classification action and it fully specifies all possible choices
> for the path of the packet, then these context headers are not
> needed anymore"?
> 


_________________________________________________________________________________________________________________________

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.