Re: [Isis-wg] WG adoption for draft-tantsura-isis-segment-routing-msd

Hi Bruno,

Thanks for your valuable comments!

In general – today no silicon vendor provides an API to query and have MSD set automatically, for the time being it will have to be set manually, there are also technics to increase MSD by packet recirculation or ingress/egress split (used by some vendors). All of above would requre a vendor to clearly communiate the values to be configured.  
Please also note that IANA considerations will be extended for the link MSD to include *all* the link TLVs (22, 23, 141, 222, 223) (thanks Hannes for pointing out!)

Please let me know whether you are happy with the aswers provided  

Please see inline

Thanks,
Jeff

On 11/2/16, 08:36, "isis-wg-bounces@ietf.org on behalf of bruno.decraene@orange.com" <isis-wg-bounces@ietf.org on behalf of bruno.decraene@orange.com> wrote:

    Hi all,

    I have read and support.
    "MSD" is a useful info to be advertised. While I would a priori assume that it's mainly useful for the PCE (hence defined in draft-ietf-pce-segment-routing) I can understand that one want to also have it advertised in the IGP.
[jeff] you are correct – the main use case is to notify Path Computation entity of this particular capability of a node/link on a node so that the path computed would be in line and doesn’t violate what is supported by the node.  In case of different types of NPU’s on a single device, different line cards would have different capabilities, by including those in the computation PCE would be able to compute a path that alternatively would potentially have exited out of a wrong link

Please find some below some comments:

    - I'd like the draft to expand and specify the interaction with the entropy labels.
    e.g. is msd the maximum number of label that can be pushed, i.e. including entropy labels?
    Currently draft talks about SID; IMO entropy labels are not SIDs; should we understand that the node is capable of pushing MSID + 2 (EL) labels?

[jeff] to my experience (I have built SR on 3 different NPU’s, 1 of them merchant), the number of SIDs (labels with MPLS encap) is always communicated as the number of labels used in data plane and exclude entropy labels, please also note - draft-ietf-mpls-spring-entropy-label states – “multiple <ELI, EL> pairs MAY be inserted in the label stack as long as the tunnel's label below which they are inserted are advertised with entropy label capability enabled”, in other words there could be more than 1 pair of <ELI,EL>

    - To a lesser extent, it would be good to clarify the interaction with service labels.
    e.g. if the SID list/SR tunnel is (also) to be used by VPN traffic, who need to account for this additional label? (the sender or the receiver of the MSD?)
[jeff] service should only be considered if it is instantiated as a part of path computed by a Path Computation entity, ie service chaining, where a SID could be used as s service/context identifier, if it is a service overlaid of top of a SR tunnel, it is out of scoop.

    - I assume that the MSD is "incoming protocol independent" i.e. applies to any type of incoming/received packets: IPv4, IPv6, MPLS (i.e. the "SWAP" operation counts as a PUSH)
    Please clarify in the doc.
[jeff] MSD is only meaningful at the ingress node, where the tunnel is instantiated and full SID/label stack is pushed 

    - MSD 0
    I note that in the PCE draft, the MSD value 0 means "no default limitation" while in the IGP draft it means " lack of the ability to push MSD of any depth".
    IOW, their meaning is opposite.
    While this is technically possible, this seems counter intuitive and open misunderstandings, at least for human beings.
    Could the authors of both draft work to harmonize this?
[jeff] already done, in draft-ietf-pce-segment-routing-08, we have introduced L-flag, when set - indicates that PCC does not impose any limit on MSD.
An MSD value MUST be non-zero otherwise the receiver of the SR-PCE-CAPABILITY TLV MUST assume that the sender is not capable of imposing a MSD of any depth and hence is not SR-TE capable.    

[jeff]We have also clarified the case where MSD could be learnt thru PCEP and other source of information:
Note that the MSD value exchanged via SR-PCE-CAPABILITY TLV indicates the SID/label imposition limit for the PCC node.  However, 
if a PCE learns MSD value of a PCC node via different means, e.g routing protocols, as specified in: [I-D.tantsura-isis-segment-routing-msd];
[I-D.tantsura-ospf-segment-routing-msd]; [I-D.tantsura-idr-bgp-ls-segment-routing-msd], then it ignores the
MSD value in the SR-PCE-CAPABILITY TLV.  Furthermore, whenever a PCE learns MSD for a link via different means, it MUST use that value for
that link regardless of the MSD value exchanged via SR-PCE-CAPABILITY TLV.

    - "Node MSD is the lowest MSD supported by the node"
    Open question: an alternative would be to advertise the lowest MSD supported by the IS-IS enabled interfaces of this node. As possibly, customer/peer facing interfaces could be of a different hardware type, possibly not supporting MPLS at all.
    Alternative 2: :s/ IS-IS enabled interfaces/ MPLS enabled interfaces
    Alternative 3: :s/ IS-IS enabled interfaces/ Segment Routing enabled interfaces
[jeff] The MSD value is always in relation to either:  the interface SR tunnel exits over if link MSD is used or the lowest MSD supported by every possible exit interface on a node. If you feel more clarity is needed, I’d be happy to change

    - Nits: " Length is 1 bytes"
    Do you mean the length of the "length field" or the length of the value/MSD field? Especially since this line is below " The Type (1 byte)" where "1 byte" is the length or the "Type" field.
[jeff] I’ll include the drawing in the next version, it is the length of the "length field
    "Node MSD is a number in the range of 0-254" is "254" a typo or do you have a plan for 255 to have a special meaning (and if so, please specify)
[jeff] In the beginning we indeed had, later dropped for sake of simplicity 

    Thanks,
    Regards,
    -- Bruno
     > -----Original Message-----
     > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Hannes Gredler
     > Sent: Monday, October 24, 2016 11:07 AM
     > To: isis-wg@ietf.org
     > Cc: Christian Hopps
     > Subject: [Isis-wg] WG adoption for draft-tantsura-isis-segment-routing-msd
     > 
     > WG,
     > 
     > the authors of draft-tantsura-isis-segment-routing-msd have requested
     > adoption as a WG item.
     > 
     > https://datatracker.ietf.org/doc/draft-tantsura-isis-segment-routing-msd/
     > 
     > opinions/comments appreciated.
     > 
     > thanks,
     > 
     > /hannes & chris
     > 
     > _______________________________________________
     > Isis-wg mailing list
     > Isis-wg@ietf.org
     > https://www.ietf.org/mailman/listinfo/isis-wg

    _________________________________________________________________________________________________________________________

    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.

    _______________________________________________
    Isis-wg mailing list
    Isis-wg@ietf.org
    https://www.ietf.org/mailman/listinfo/isis-wg