Subject: Re: [PWE3] [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue

From: Mach Chen <[email-masked]>
Date: Mon, 18 Jul 2011 03:54:24 +0000

Hi Curtis,

Thanks for your comments!

The original purpose of this draft was for binding a PW to a co-routed PSN Tunnel, this is a requirement of MPLS-TP network. So "co-routed" is the major characteristic. In the draft, this is archived by setting the "C" bit of the PSN Tunnel TLV.

As for other characteristics, I am not sure whether we need carry all those characteristics(at least for now), and as you said, if we do that, it may eventually reinvent another CR-LDP. So, IMHO, it may be better to limit the scope of the draft to the current form and leave others for future study. If there are requirements for adding new characteristic, we could incorporate it then.

BTW, draft-ietf-pwe3-dynamic-ms-pw(Section 6.2.1 MS-PW Bandwidth Signaling) has already defined a PW Bandwidth TLV to indicate bandwidth characteristic, it also can apply in this draft.

Best regards,
Mach

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Curtis Villamizar
> Sent: Saturday, July 16, 2011 1:51 AM
> To: [email-masked]
> Subject: [mpls] draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp - 2nd issue
> 
> 
> Regarding: draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-03.txt
> 
> Mach, Ping, et al,
> 
> The second issue which I pointed out in the last revision is that
> there is no way to indicate the characteristics required of a
> mid-segment of a MS-PW.  The ingress (a T-PE) can specify the nodes,
> but it cannot specify which tunnel from S-PE to S-PE to use.  It must
> specify the required characteristics of the tunnel to allow the S-PE
> to pick an appropriate tunnel.
> 
> For example, an LSP contains sufficient information, such as
> bandwidth, holding and setup priority, resource affinitiy expressed as
> include-any, include-all, and exclude to be applied over the 32 bit
> administrative atrribute bit map.  This allows simple things such as
> loose hops and not so simple things such as BRPC.
> 
> It might be best to cite the RSVP-TE work and encapsulate the TLVs
> defined there into the PW.  This is a bit like reinventing CR-LDP and
> if it becomes too much like CRLDP, maybe RSVP-TE signaling of PW
> should be defined instead.  I'm not really sure what the best way is
> to solve this.
> 
> Curtis
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 18 Jul 2011 11:54:58 -0400

In message <[email-masked]>
Mach Chen writes:
> The original purpose of this draft was for binding a PW to a co-routed
> PSN Tunnel, this is a requirement of MPLS-TP network. So "co-routed"
> is the major characteristic. In the draft, this is archived by setting
> the "C" bit of the PSN Tunnel TLV.

There is generally only one LSP between any A-Z in a provider core
with PW carried inside the one LSP.  Where there are multiple LSP it
is generally because there are different QoS requirements, with more
recent dicsussion focusing on delay requirements.

> As for other characteristics, I am not sure whether we need carry all
> those characteristics(at least for now), and as you said, if we do
> that, it may eventually reinvent another CR-LDP. So, IMHO, it may be
> better to limit the scope of the draft to the current form and leave
> others for future study. If there are requirements for adding new
> characteristic, we could incorporate it then.

We would not reinvent CR-LDP if there was one loose hop specifying QoS
requirments.  The shortest path is followed, stopping at S-PE along
the way.  RSVP-TE is providing the ERO between PE and therefore
handling the traffic engineering.

> BTW, draft-ietf-pwe3-dynamic-ms-pw(Section 6.2.1 MS-PW Bandwidth
> Signaling) has already defined a PW Bandwidth TLV to indicate
> bandwidth characteristic, it also can apply in this draft.

Yes.  Bandwidth is covered.  Resource affinity, holding
priority. RFC4124 class type, etc is not covered.

> Mach

Thanks for the prompt reply.

Best regards,

Curtis