Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

["Van De Velde, Gunter (Nokia - BE/Antwerp)" <[e-mail]>]

“
The other case to handle is the binding SID. The binding SID needs to reflect the ELC of the associated LSP.
The SRMS case is also interesting if we want to enable entropy when doing SR-LDP interworking.
“

Does this not assume that a LSP is strictly defined hop-by-hop? If LSP is a loose LSP, then it is very well possible that
depending on the state of network, sometimes the LSP is ELC capable and another time it is not capable or the ERLD changes.

I’m not convinced or have clear understanding on the value of ELC/ERLD for a particular LSP without making some strict prescriptions on LSP.

To me, having ERLD (and maybe of less importance) ELC has value only for a controller to make more educated decisions upon packet flows.
Having such information per LSP seems complex and of lesser value as per node in the network.

G/

From: Lsr <[e-mail]> On Behalf Of [e-mail]
Sent: Monday, August 6, 2018 10:26
To: Les Ginsberg (ginsberg) <[e-mail]>; DECRAENE Bruno IMT/OLN <[e-mail]>
Cc: [e-mail]; [e-mail]; 徐小虎(义先) <[e-mail]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi,

Hi Les, Bruno,


[Bruno] I also raised the case of redistribution of IP prefix/SID between IGP domains. Possibly one using OSPF and one using IS-IS. This case needs to be also covered.

[Les:] If a prefix is leaked between protocols then you lose the identification of the source. Which means you have other considerations which are not met e.g., what is the value for ERLD (which also is clearly not a per prefix value). To know this you need to know the source and have the Node Capabilities.

[SLI] I agree with Les that we are losing the ERLD information. But I think it is worth allowing the propagation of the ELC even if we are losing the ERLD info. We make this propagation optional. Moreover it will be still optional for the ingress node to use it.
I agree that we must not leak the node infos.

The other case to handle is the binding SID. The binding SID needs to reflect the ELC of the associated LSP.
The SRMS case is also interesting if we want to enable entropy when doing SR-LDP interworking.


From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Friday, August 03, 2018 23:27
To: DECRAENE Bruno IMT/OLN
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 徐小虎(义先)
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Bruno –

Inline.

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Friday, August 03, 2018 10:01 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 徐小虎(义先) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Les,

Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Friday, August 03, 2018 6:32 PM
To: DECRAENE Bruno IMT/OLN; 徐小虎(义先)
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Bruno –

I appreciate why you suggest per-prefix signaling for ELC, but I would prefer that we not employ that model.
[Bruno] Thanks for the feedback. That’s part of the discussion that I was calling for.

ELC is clearly a node capability

[Bruno] It’s a node capability of the egress of the LSP. Hence it could also be seen as a property of the LSP ;-) RFC 6790 says  “one may choose to associate ELs with MPLS tunnels (LSPs) or
   with MPLS applications […] We take the former approach”


– signaling it in per node scope is therefore most appropriate. And it aligns with the SR model where we do not need to depend on hop-by-hop signaling as in the LDP case.
[Bruno] I would argue that advertising ELC per prefix is not a hop-by-hop signaling as in the LDP case. That’s one single advertisement per area/level.

[Les:] I probably expressed this poorly.
As LDP does hop-by-hop signaling the “natural” way to signal this in LDP is in the neighbor label exchanges.
However, SR signaling is scoped by the area/domain and therefore we have the ability to advertise capability in a way that matches how the support is actually enabled. There is no basis for a node to advertise ELC support for local Prefix A but not for Local Prefix B. So advertising this per prefix is redundant (though I agree is still possible).

As regards the interarea issues you raise:

Both Router Capability TLV (IS-IS) and Router Information LSA (OSPF) support domain-wide flooding scope. This is not a new capability
[Bruno] Agreed.

– though I do agree with you that the ELC drafts should explicitly mention the flooding scope requirement.
[Bruno] May be the scalability impact may need to be discussed. I would assume an impact on the size of the LSDB (but a priori no impact on the churn). This is also a new behavior which may surprise operational teams.
[Les:] The significant issue as regards scale is the leaking of the prefixes – not the leaking of per-Node information. So I am not greatly concerned about leaking Node Capability info.

[Bruno] I also raised the case of redistribution of IP prefix/SID between IGP domains. Possibly one using OSPF and one using IS-IS. This case needs to be also covered.

[Les:] If a prefix is leaked between protocols then you lose the identification of the source. Which means you have other considerations which are not met e.g., what is the value for ERLD (which also is clearly not a per prefix value). To know this you need to know the source and have the Node Capabilities.

    Les

Thanks,
Regards,
--Bruno

As regards identifying the source of a prefix advertisement domain-wide, IS-IS has a complete solution for this as defined in RFC 7794.
OSPF is lacking support for advertising the source Router-ID, but this can be easily remedied by defining an extension using Extended Prefix LSA (as has been mentioned by Peter in another thread). And this functionality is needed for other reasons e.g., to know when PHP should/should not be done. So it is probably past time when this should be defined.

So I think it is better if we use the per-node ELC scope proposed in the ELC drafts.

As an aside, I would prefer that we utilize the existing TE Node Capability Descriptor registry defined in RFC 5073 rather than invent a new codepoint/registry (the proposed Non-IGP Functional  Capabilities registry) – but that is a minor point.

   Les


From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, August 03, 2018 12:46 AM
To: 徐小虎(义先) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi  Xiaohu,

Thanks for the reply.
You seem to assume/require that (router) capability advertisement be propagated across IGP areas/domains. If so,
- this is a new requirement for existing multi-area networks that need to be indicated in the draft
- I find this debatable. This point should be explicitly discussed. I’d rather advertise the ELC capability on a per Segment basis. This would also be better aligned with RFC 6790 hence safer if EL extensions are defined. The (Segment Routing) Prefix-SID sub-TLV has 2 flags remaining. This may be a good candidate as this information seems SR specific. Alternatively, RFC7794 may be used.

Thanks
Best regards,
--Bruno

From: Lsr [mailto:[e-mail]] On Behalf Of ???(??)
Sent: Friday, August 03, 2018 4:13 AM
To: Lsr; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi Bruno,

Thanks for raising this important issue.

In fact, the Routable IP Address TLVs/sub-TLVs as described in (https://tools.ietf.org/html/draft-ietf-ospf-routable-ip-address-02) and (https://tools.ietf.org/html/draft-xu-isis-routable-ip-address-01) respectively were intended to address the problem that you had mentioned (i.e., it is required for OSPF routers in one area to find correlations between routable IP addresses and capabilities of OSPF routers in another area).

The following text is quoted from

"    There are several situations where it is required for OSPF routers in

   one area to find correlations between routable IP addresses and

   capabilities of OSPF routers in another area.  One example is the

   Entropy Label Capability (ELC) advertisement [I-D.xu-ospf-mpls-elc<https://tools.ietf.org/html/draft-ietf-ospf-routable-ip-address-02#ref-I-D.xu-ospf-mpls-elc>]

   across the OSPF domain.  In this example, assume the ELC TLV

   originated by a router in one area is propagated to another area.

   Those routers in the latter area need to find routable IP addresses

   of the router originating that ELC TLV before inserting the Entropy

   Label (EL) for packets going to the Label Switch Path (LSP) tunnel

   towards one of the above routable IP addresses..."

Later, such correlation requirement in the ISIS domain was addressed by introducing the source IPv4/IPv6 router ID sub-TLVs into the Extended Reachability TLVs (see https://tools.ietf.org/html/rfc7794). I forget whether the same extension to OSPF as RFC7794 has been done.

Best regards,
Xiaohu
------------------------------------------------------------------
From:bruno.decraene <[e-mail]<mailto:[e-mail]>>
Send Time:2018年8月3日(星期五) 04:50
To:[e-mail] <[e-mail]<mailto:[e-mail]>>
Cc:[e-mail] <[e-mail]<mailto:[e-mail]>>
Subject:Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Hi authors,

"4.  Advertising ELC Using IS-IS

   One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired)
   is to be assigned by the IANA for the ELC [RFC6790]."

RFC6790 defines ELC capability on a per FEC/LSP egress basis.
Please defines what you mean exactly with this per node capability. If this is expected to advertise ELC capability in spring networks, it's not crystal clear to me how it works in multi-area/domain network with IP prefix/SID redistribution.
Possibly the ELC flag would need to be advertised on a per prefix basis.

Thanks,
Regards,
--Bruno


 > -----Original Message-----
 > From: Lsr [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
 > Sent: Thursday, August 02, 2018 10:24 PM
 > To: [e-mail]<mailto:[e-mail]>
 > Cc: [e-mail]<mailto:[e-mail]>
 > Subject: Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
 >
 > Hi authors,
 >
 > Please find below some minor comments:
 >
 > 1) Abstract:
 > " In addition, this document introduces the Non-IGP Functional
 >    Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP
 >    functional capabilities.  ELC is one of such non-IGP functional
 >    capabilities."
 >
 > It's a matter of opinion but reducing the number of occurrences of " non-IGP functional
 > capabilities" may improve the S/N ration.
 >
 > 2)
 >    The format of the Router Non-IGP Functional Capabilities Sub-TLV is  as follows:
 >
 >         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
 >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >        |    Type=TBD1  |    Length=4   |
 >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >
 >
 > The sub-TLV is not hard coded/defined with a length of 4, hence this value should not be part of
 > the definition.
 >
 > 3)
 > "Length: Indicates the length of the value portion in octets and  will be a multiple of 4 octets"
 >
 > Possibly :s/will/MUST
 > Please specify the error handling. (e.g. disregards the whole sub-TLV, disregards the last 1 to 3
 > octets, accept the whole sub-TLV...)
 >
 >
 > 4)
 > "One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired)  is to be assigned by the
 > IANA for the ELC [RFC6790]."
 >
 > Since this document defines the new sub-TLV, it can freely do any allocation itself.
 >
 > 5)
 > "The registration procedure is "Expert Review" as defined in   [RFC8126]."
 >
 > You may want to read RFC 8126 https://tools.ietf.org/html/rfc8126#section-4.5
 > Which, In particular, states:
 > " The registry's
 >    definition needs to make clear to registrants what information is
 >    necessary.
 >
 >   [...]
 >
 >    The required documentation and review criteria, giving clear guidance
 >    to the designated expert, should be provided when defining the
 >    registry.  It is particularly important to lay out what should be
 >    considered when performing an evaluation and reasons for rejecting a
 >    request.  It is also a good idea to include, when possible, a sense
 >    of whether many registrations are expected over time, or if the
 >    registry is expected to be updated infrequently or in exceptional
 >    circumstances only. "
 >
 > 6)
 > "This capability, referred to as Entropy  Readable Label Depth (ERLD) as defined in  [I-D.ietf-
 > mpls-spring-entropy-label] "
 >
 > This probably calls for this document to be a normative reference.
 >
 >
 > "   A new MSD-type of the Node MSD b-TLV
 >    [I-D.ietf-isis-segment-routing-msd], called ERLD is defined to
 >    advertise the ERLD of a given router."
 >
 > May be adding the reference to the document defining the ERLD:
 > OLD: advertise the ERLD
 > NEW: advertise the ERLD [I-D.ietf-mpls-spring-entropy-label]
 >
 > 7)
 > "If a router has
 >    multiple line cards, the router MUST NOT announce the ELC [RFC6790]
 >    unless all of its linecards are capable of processing ELs."
 >
 > May be you mean
 > OLD: all of its linecards
 > OLD: all of the linecards of the links advertised as IS-IS adjacencies.
 >
 > Regards,
 > --Bruno
 >
 >  > -----Original Message-----
 >  > From: Lsr [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
 >  > Sent: Tuesday, July 31, 2018 4:07 PM
 >  > To: [e-mail]<mailto:[e-mail]>
 >  > Cc: [e-mail]<mailto:[e-mail]>
 >  > Subject: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
 >  >
 >  >
 >  > A New Internet-Draft is available from the on-line Internet-Drafts directories.
 >  > This draft is a work item of the Link State Routing WG of the IETF.
 >  >
 >  >         Title           : Signaling Entropy Label Capability and Entropy Readable Label Depth Using
 >  > IS-IS
 >  >         Authors         : Xiaohu Xu
 >  >                           Sriganesh Kini
 >  >                           Siva Sivabalan
 >  >                           Clarence Filsfils
 >  >                           Stephane Litkowski
 >  >  Filename        : draft-ietf-isis-mpls-elc-05.txt
 >  >  Pages           : 7
 >  >  Date            : 2018-07-29
 >  >
 >  > Abstract:
 >  >    Multiprotocol Label Switching (MPLS) has defined a mechanism to load
 >  >    balance traffic flows using Entropy Labels (EL).  An ingress Label
 >  >    Switching Router (LSR) cannot insert ELs for packets going into a
 >  >    given tunnel unless an egress LSR has indicated via signaling that it
 >  >    has the capability of processing ELs, referred to as Entropy Label
 >  >    Capability (ELC), on that tunnel.  In addition, it would be useful
 >  >    for ingress LSRs to know each LSR's capability of reading the maximum
 >  >    label stack depth and performing EL-based load-balancing, referred to
 >  >    as Entropy Readable Label Depth (ERLD), in the cases where stacked
 >  >    LSPs are used for whatever reasons.  This document defines mechanisms
 >  >    to signal these two capabilities using IS-IS.  These mechanisms are
 >  >    useful when the label advertisement is also done via IS-IS.  In
 >  >    addition, this document introduces the Non-IGP Functional
 >  >    Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP
 >  >    functional capabilities.  ELC is one of such non-IGP functional
 >  >    capabilities.
 >  >
 >  >
 >  > The IETF datatracker status page for this draft is:
 >  > https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
 >  >
 >  > There are also htmlized versions available at:
 >  > https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05
 >  > https://datatracker.ietf.org/doc/html/draft-ietf-isis-mpls-elc-05
 >  >
 >  > A diff from the previous version is available at:
 >  > https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-mpls-elc-05
 >  >
 >  >
 >  > Please note that it may take a couple of minutes from the time of submission
 >  > until the htmlized version and diff are available at tools.ietf.org.
 >  >
 >  > Internet-Drafts are also available by anonymous FTP at:
 >  > ftp://ftp.ietf.org/internet-drafts/
 >  >
 >  > _______________________________________________
 >  > Lsr mailing list
 >  > [e-mail]<mailto:[e-mail]>
 >  > https://www.ietf.org/mailman/listinfo/lsr
 >
 > __________________________________________________________________________
 > _______________________________________________
 >
 > 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.
 >
 > _______________________________________________
 > Lsr mailing list
 > [e-mail]<mailto:[e-mail]>
 > https://www.ietf.org/mailman/listinfo/lsr

_________________________________________________________________________________________________________________________

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.

_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr


_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.