Hi Rob,

Many thanks to raise this important subject back on the table.
Entropy label in SPRING is mainly a matter of what are the current capabilities 
of our favorite vendor's current HW ... Unfortunately, I think we are touching 
something quite "secret"  and vendors would not share their issues publicly :)

I think some options may also introduce some "HW capability" issues :
- reusable EL and EL top of the stack  : need multiple MPLS operation , so it 
may require forwarding feedback loops on some HWs reducing the forwarding 
capacity

Personally, I don't like (hate :) ), the multiple EL/ELI (at each tunnel level 
or at specific point of insertion) because it would again reduce the available 
MTU for the customer jumbo frames.


IMHO, I would be in favor of doing nothing if all vendors can publicly confirm 
that their current generation of HW are able to inspect between 10/15 labels :) 
Otherwise reusable EL and even EL at top of the stack sounds good to me. EL at 
top of the stack may make some MPLS people crazy, but I personally found this 
kind of forwarding straightforward compared to reusable EL (I like it also).  
EL at top of the stack may be compared to a MPLS router alert label at top of 
the stack ... 

We may also need to deal with cases where some SPRING nodes are not ELC on the 
transit path, do we want to loose the EL or just try to avoid the non ELC 
node(s) by reinserting ELI/EL at a position it could be reused further in the 
path on the next ELC capable SPRING node.

Anyway as I said at the beginning, unfortunately for us (Service Providers), 
the technical solution is at more than 80% a vendor discussion ...

Thanks again for bringing this back on the table :)

Best regards,

Stephane


-----Original Message-----
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Monday, July 21, 2014 10:38
To: spring@ietf.org
Cc: draft-kini-mpls-spring-entropy-la...@tools.ietf.org
Subject: [spring] SPRING MPLS and Entropy Label

Hi SPRING, draft-kini. authors,

I have a few comments on the discussion within this draft - and a quick 
question on the intention around the document.

- I feel that it would be useful to provide some clarification as to where we
  expect entropy to be required for load-sharing in the draft. The current
  wording (to me) could be read to say that where Adj-SID is used, then there
  is no requirement to consider placement for EL since there will be no
  load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 in
  draft-filsfils-spring-segment-routing-04), or the underlying transport for an
  IGP adjacency can be multi-path (e.g., an aggregated Ethernet link)
  this is not true unless a head-end PE can guarantee that a particular
  adjacency is made up of a transport that has only 1 path (i.e., explicitly
  requires no load-balancing). I'm not sure how the iLER would actually 
determine
  this, short of the definition of new per-adjacency advertisement capabilities.
  Even if it were able to, then it seems the result is very likely to be that an
  approach that requires per-hop entropy labels to be injected is going to
  guarantee label stack depth >= 3*[number of path SIDs].

  I think that the above means that the current draft under-estimates the depth
  of the stack when considering an EL per tunnel (§3.2), which might amplify
  some of the concerns raised for this option. 

- §3.4 - I am not clear how we would really implement this option. If we learn
  midpoint capabilities, and then tune our placement of the EL based on these,
  then it seems like the only viable approach is really to consider _all_
  midpoints, and tune the placement according to the "shallowest" midpoint in
  the network. This is because, whilst we might expect that there is routing via
  some particular path, this might change if there is ECMP between mid-points
  nodes where some paths have different capabilities than others, and equally
  might change whilst re-routing occurs.

  In terms of discovery of the capabilities of a mid-point -- do we need to
  consider how, in a multi-area network, we discover the capabilities of a
  mid-point which might not have information about it leaked between areas?
    
- Finally, it'd be good to determine what the intention of the authors for this
  document is. Do we expect that we make a recommendation as to what equipment
  vendors who are going to support SR-MPLS should optimise for? At the moment,
  the document is good at classifying the different approaches that _could_ be
  taken, but potentially requires an operator/vendor to consider optimisation
  for both a) reading very deep into the stack when acting as an LSR, b) pushing
  very deep stacks when acting as iLER, c) potentially implementing more complex
  swap() operations, whereby some reshuffling of the EL is required. 

  My feeling is that it would be very useful for this document to be able to
  make a clear recommendation as to which of these approaches should be
  optimised for, and hence we should debate their technical efficacy. It'd be
  good to understand whether the authors are intending to do this, or rather
  classify the approaches.

Cheers,
r.


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________

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.

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to