Subject: Re: [mpls] mpls Digest, Vol 100, Issue 4

From: "Vivek Kumar" <[email-masked]>
Date: Fri, 3 Aug 2012 05:21:20 +0000

Hi Kireeti,
   
   What about making some TTL/EXP field of ELI as magic value( say TTL=50 or EXP=7) to indicate that if ELI has TTL=50 or EXP=7 , the use EL value directly to index one of ECMP member.
   For example , if ELI.TTL=50 , and EL=1 , then select first member of ECMP group and if EL=2 , then next member and so on..

   Not sure if it is possible to have this kind of magic value for TTL or EXP .
   Let me know your feedback.

Regards,
Vivek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 03, 2012 12:31 AM
To: [email-masked]
Subject: mpls Digest, Vol 100, Issue 4

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/mpls

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send mpls mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/mpls
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mpls digest..."

Today's Topics:

   1. Re: LSP ping clarification (Sam Aldrin)
   2. I-D Action: draft-ietf-mpls-ldp-dod-03.txt
      ([email-masked])

----------------------------------------------------------------------

Message: 1
Date: Thu, 2 Aug 2012 10:02:51 -0700
From: Sam Aldrin <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mpls] LSP ping clarification
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Hi Kireeti,

>From high level perspective, it works.
I have few thoughts which would make the solution robust. It also involves without changing much of the existing format. Do you have some time to discuss? Would be happy to share my input with you.

cheers
-sam
On Aug 2, 2012, at 9:52 AM, Kireeti Kompella <[email-masked]> wrote:

> Hi All,
> 
> Since there have been some questions about how LSP ping works in the context of entropy labels, and concerns about the mechanism, I thought I would explain how LSP ping explores ECMP paths, what some of the limitations are, and to what extent they can be overcome.
> 
> To begin, LSP ping explores ECMP paths.  It does so by finding a value for a specific field while leaving the remaining fields used for load balancing fixed (think partial derivatives) (okay, that probably wasn't helpful).  In the IP case, this field is the IP dest address; in the label case, it is the entropy label field.  Example: for a packet that is part of an Ethernet PW, assume all routers use as load balancing fields: outer label, entropy label, PW label.  The field that changes is the entropy label, and the rest are kept constant.  Note: since the ELI is a reserved label, it is not used for load balancing.
> 
> Let's say the ping is from node X to node Y.  X has one downstream, A.  A has two downstreams, B1 and B2.  B1 has two downstreams, C11 and C12; B2 has three downstreams: C21, C22 and C23.  Cij are connected to Y.
> 
> To explore paths, X creates a label stack <TL, ELI, E, PL>, where TL is the label that goes from X via A to Y, and PL is the signaled PW label from X to Y.  In the payload (LSP ping packet), X inserts a description of a set S of labels, typically including E, sets TTL=1 and sends the packet to A.
> 
> X then changes E (and TTL) such that the resulting packet traverses each of the 5 paths from X to Y.  
> 
> Let's say that X chooses as the initial set of labels 20-24; A replies that 20 and 21 go to B1 (i.e., if A got a label stack of <TL, ELI, 20, PL>, it would send the packet to B1) and 22-24 go to B2.  X then sends a packet with label stack <TL, ELI, 20, PL> to B1 (by setting TTL=2, and inserts the label set of {20, 21}.  If all the stars line up, B1 could reply that an entropy label of 20 goes to C11, and 21 goes to C12.  Similarly, X sends a ping packet to B2 with label set {22, 23, 24}.  So, if X was really lucky, an initial label set of just five labels could be sufficient to explore the 5 paths.
> 
> It is possible that no choice of entropy label will explore a particular path.  If A sent only packets with <TL, ELI, E, PL> with odd E to B1, and B1 sent all packets with <TL', ELI, E, PL> with odd E to C11, there is no entropy label that would explore the path to C12.  Highly unlikely, but possible.  It could also be that a very small set of labels explore the path to C12; finding one such label might require that X sends different label sets to B1 over several iterations until it found one.
> 
> In general, the more ECMP choices one has to be make to pick a particular path, the harder it is to find a label to explore it.
> 
> To sum up, the methodology is reasonably reasonable but not fool-proof.  It is up to X to pick adequate-sized label sets to explore paths: large enough to expect non-empty replies, but not too large as to be unwieldy.  It is also up to X to retry a few times if it got back empty replies, but to throw up its hands (and report to the user/logging system) if it can't explore some sub-dag of ECMP paths.
> 
> I would be very happy to hear other approaches to exploring ECMPs.
> 
> Proposed action item 1: reduce the OAM section to refer to a future draft that explains the above.
> 
> PAI 2: write said future draft.
> 
> If acceptable, I will do both the above.  If someone has a new/tweaked mechanism that better addresses the problem of exploring paths, that should go into this draft.
> 
> Kireeti.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

------------------------------

Message: 2
Date: Thu, 02 Aug 2012 11:10:39 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-03.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : LDP Downstream-on-Demand in Seamless MPLS
	Author(s)       : Thomas Beckhaus
                          Bruno Decraene
                          Kishore Tiruveedhula
                          Maciek Konstantynowicz
                          Luca Martini
	Filename        : draft-ietf-mpls-ldp-dod-03.txt
	Pages           : 33
	Date            : 2012-08-02

Abstract:
   Seamless MPLS design enables a single IP/MPLS network to scale over
   core, metro and access parts of a large packet network infrastructure
   using standardized IP/MPLS protocols.  One of the key goals of
   Seamless MPLS is to meet requirements specific to access, including
   high number of devices, their position in network topology and their
   compute and memory constraints that limit the amount of state access
   devices can hold.This can be achieved with LDP Downstream-on-Demand
   (LDP DoD) label advertisement.  This document describes LDP DoD use
   cases and lists required LDP DoD procedures in the context of
   Seamless MPLS design.

   In addition, a new optional TLV type in the LDP label request message
   is defined for fast-up convergence.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-dod-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

------------------------------

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

End of mpls Digest, Vol 100, Issue 4
************************************