Subject: Re: [Status] [mpls] FW: New Version Notification for draft-chen-mpls-source-label-00.txt

From: Mach Chen <[email-masked]>
Date: Mon, 22 Jul 2013 03:57:00 +0000

Hi Greg,

Many thanks for comments and questions!

Please see my reply inline...

Best regards,
Mach

> -----Original Message-----
> From: Mach Chen
> Sent: Monday, July 22, 2013 11:05 AM
> To: Mach Chen
> Subject: FW: [mpls] FW: New Version Notification for
> draft-chen-mpls-source-label-00.txt
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gregory Mirsky
> Sent: Friday, July 19, 2013 7:27 PM
> To: Mach Chen; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] FW: New Version Notification for
> draft-chen-mpls-source-label-00.txt
> 
> Hi Mach, authors and et. al,
> very interesting idea, please find my comments and questions below:
> . I think that you propose SL for MPLS networks that permit label merge. But
> even for such networks, as I think, we could use MEP ID TLV in OAM packets to
> identify the source. Yes, that would not help much with passive OAM but will
> work for active PM.

For PM scenario, the SL solution is mainly designed for passive PM; and technically, both the SL solution and Source MEP ID TLV can apply to active PM. The SL solution does not preclude to use MEP ID TLV in OAM packets. The SL is mainly used in service packets, it can use in OAM packets as well.

> . Since SL being defined with scope of a single administrative domain MS-PW
> example in section 1 might not be applicable as SL would not be of much help.

The draft said:
"In its function as a Source Label (ingress node identifier), it MUST be unique within a domain. In cases where a Source Label is used across domains it MUST be unique within the scope it is used."

So, it does not preclude to use SL across domains if the SL can be unique across the domains.   

> . I don't think that RFC 6374 and its LM in particular are specifically targetted
> towards passive method of PM.

If my memory is right, for LM, RFC 6374 supports both (it calls inferred and direct measurement). I think you may refer to the DM that belongs to active measurement. 

> . I don't think that PM measurement at intermeddiate LSR can be effectively
> used to avoid congested path. Consider that LSR is downstream of a congested
> segment and would need to notify the upstream LSR or LER about identified
> congestion (ECN) in order to take any action.

IMHO, there are two use cases to measure at the intermediate LSRs, one is for fault localization. 

The other is like this, hierarchy model :

LSP1  S11-------------------------D11
LSP2        S21-----D22

LSP1 is over LSP2 (there may be many LSPs over LSP2), it may need to measure and collect the traffic matrix at S21 (to measure the throughput of each LSP that is over on LSP2), then based on some conditions, it could steer some LSPs to other tunnels, or move other LSPs to this tunnel. 

Best regards,
Mach

> 
>         Regards,
>                 Greg
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mach Chen
> Sent: Friday, July 19, 2013 2:07 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls] FW: New Version Notification for
> draft-chen-mpls-source-label-00.txt
> 
> Hi MPLSers,
> 
> We just uploaded a draft that introduces a concept of MPLS Source Label (SL), the
> source label is encoded in the label stack (immediately follows a special purpose
> label ) and used to identify the ingress LSR of an LSP. The source label applies to
> the scenarios where source identification is required (e.g., in order for counting
> and billing). For example, Performance Measurement for MPLS network, Traffic
> Matrix measurement and collection, etc.
> 
> We'd appreciate that you could take a look at the draft. Any comments and
> suggestion are welcome!
> 
> BTW, I cc the STATUS list for the people who may have interest, since the
> segment routing requires to preserve the ingress to a domain for accounting and
> billing purpose, the source label can help here.
> 
> Best regards,
> Mach
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 15, 2013 5:58 PM
> To: Lizhenbin; Mach Chen; Xuxiaohu; Xuxiaohu; Luyuan Fang; Mach Chen
> Subject: New Version Notification for draft-chen-mpls-source-label-00.txt
> 
> 
> A new version of I-D, draft-chen-mpls-source-label-00.txt
> has been successfully submitted by Mach(Guoyi) Chen and posted to the IETF
> repository.
> 
> Filename:        draft-chen-mpls-source-label
> Revision:        00
> Title:           MultiProtocol Label Switching (MPLS) Source Label Creation
> date:   2013-07-15
> Group:           Individual Submission
> Number of pages: 12
> URL:             http://www.ietf.org/internet-drafts/draft-chen-mpls-sou
> rce-label-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-chen-mpls-source-lab
> el
> Htmlized:        http://tools.ietf.org/html/draft-chen-mpls-source-label-00
> 
> 
> Abstract:
>    An MultiProtocol Label Switching (MPLS) label is originally defined
>    to identify a Forwarding Equivalence Class (FEC), a packet is
>    assigned to a specific FEC based on its network layer destination
>    address.  It's difficult or even impossible to derive the source
>    information from the label.  For some applications, source
>    identification is a critical requirement.  For example, performance
>    monitoring, traffic matrix measurement and collection, where the
>    monitoring node needs to identify where a packet was sent from.
> 
>    This document introduces the concept of Source Label (SL) that is
>    carried in the label stack and used to identify the ingress Label
>    Switching Router (LSR) of an Label Switched Path (LSP).
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>