ietf
[Top] [All Lists]

Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

2011-08-22 09:20:13
On 08/19/11 14:53, John E Drake wrote:
Luca,

So, you are considering weighted ECMP, with FAT and entropy label, to be an 
application?  We are also releasing the GAL to float until it finds its 
proper level within the MPLS label stack?
Yes. It certainly addresses a specific problem that is only a concern in
some networks.
Maybe as application I meant the specific technology documents. For
example if an OAM method needs to use the GAL for a specific purpose it
should specify it there, without us putting restrictions in a generic
way in this document.

As for the float part, I consider the GAL to be a simple Flag that says
" following the MPLS label stack , you will find a GACh construct , and
not an IP packet"

In MPLS the default is to have an IP packet, unless a different meaning
is bound to the label by the control plane. Thsi is the reason we needed
the GAL in the first place for the MPLS-TP environment , where IP is not
used.

Thanks,
Luca

Thanks,

John

Sent from my iPhone


-----Original Message-----
From: Luca Martini [mailto:lmartini(_at_)cisco(_dot_)com]
Sent: Friday, August 19, 2011 1:17 PM
To: John E Drake
Cc: Alexander Vainshtein; mpls(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org; Vladimir
Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron;
Rotem Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-
gal-in-pw

John,


I would like to  let applications decide how they design the use of the
gal.

So I would propose a simple change , that will move any discussions to
the specific applications:

The next text would be as follows:



-  Section 4.2. (GAL Applicability and Usage) in [RFC5586], the
      original text:

          In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenated Segments of LSPs, and with Sections, and
          MUST NOT be used with PWs. It MUST always be at the bottom of
          the label stack (i.e., S bit set to 1). However, in other
MPLS
          environments, this document places no restrictions on where
          the GAL may appear within the label stack or its use with
PWs.

      is replaced by:

          In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenated Segments of LSPs, and with Sections, and
          MAY be used with PWs.



Does this work ?
Thanks.
Luca






On 08/18/11 08:00, John E Drake wrote:
Sasha,

I completely agree with your recommendations:

- releasing the bottom-of-stack requirement on GAL

- making use of the statement in RFC 5586 that if GAL is encountered
in a packet then G-ACh header MUST be present immediately after the
bottom of the label stack (and not immediately after GAL)
- specifying that ECMP on labeled packets MUST ignore reserved labels

Thanks,

John

Sent from my iPhone

-----Original Message-----
From: mpls-bounces(_at_)ietf(_dot_)org 
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf
Of
Alexander Vainshtein
Sent: Wednesday, August 17, 2011 9:52 PM
To: Luca Martini
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; Vladimir Kleiner; 
Idan Kaspit;
Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-
pwe3-
gal-in-pw

Luca and all,
I have not found the statement you've proposed in draft-ietf-pwe3-
fat-
pw-06. Instead, it contans the following text in Section 8.5 "
Applicability to MPLS-TP":

<quote>
   The flow aware transport of a PW reorders packets, therefore MUST
NOT be
   deployed in a network conforming to the MPLS-TP unless these
integrity requirements
   specified in the SLA can be satisfied.
<end quote>

(In the -07 version this text is repeated but followed by an
incomplete
statement " In a" immediately followed by the heading of Section
8.6.
Since this addition is difficult to parse, I will ignore it for the
moment.)

IMHO and FWIW this means that prohibition on using flow aware PW in
MPLS-TP environments is conditional on meeting specific SLA
requirements for the service. So I think that the use case I've
presented still holds.

Please note also that, regardless of the restriction in draft-ietf-
pwe3-fat-pw, be it conditional or absolute, usage of flow labels in
an
MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the
label stack and taking one of multiple NHLFEs for the given incoming
label in the ILM) were not used in this domain, e.g., by associating
exactly one ILM entry with each incoming label in the ILM. And since
MPLS-TP is supposed to carry not just PW clients but also IP ones, I
would expect that this would be the case in any MPLS-TP deployment.

I also think that releasing one restriction (on using GAL in PWs) at
the expense of making another, conditional one (on usage of flow
labels
in MPLS-TP environments) absolute is not the most appropriate method
for resolving technical issues. IMHO and FWIW better way to resolve
the
problem would be by:

- releasing the bottom-of-stack requirement on GAL
- making use of the statement in RFC 5586 that if GAL is encountered
in
a packet then G-ACh header MUST be present immediately after the
bottom
of the label stack (and not immediately after GAL)
- specifying that ECMP on labeled packets MUST ignore reserved
labels.
I think that these considerations have been presented already in the
discussion on draft-nadeau-pwe-vccv-2.

Of course it would be even better if we could agree on transition to
universal usage of the CW and VCCV Type  1 in PWs. But this is a
different story.

Regards,
Sasha
____________________________________
From: Luca Martini [lmartini(_at_)cisco(_dot_)com]
Sent: Wednesday, August 17, 2011 9:58 PM
To: Alexander Vainshtein
Cc: Pablo Frank; mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
Vladimir Kleiner;
Idan
Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-
in-pw
The solution is quite simple:

"Flow Labels MUST not be used in an MPLS-TP environment."

Luca





On 08/16/11 21:46, Alexander Vainshtein wrote:
Pablo,
Sorry, but I think you're wrong. Only T-PE can insert the flow
label
(because only T=PE can be "flow-aware"). S-PE simply performs swap
on
PW label.

Regards,
     Sasha

-------------------------------------------------------------------
--
---
*From:* Pablo Frank [pabloisnot(_at_)gmail(_dot_)com]
*Sent:* Wednesday, August 17, 2011 12:17 AM
*To:* Alexander Vainshtein
*Cc:* ietf(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org; Vladimir 
Kleiner; Idan Kaspit;
Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
*Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-
gal-
in-pw
I think it's okay because as the PW crosses the ECMP-enabled
IP/MPLS
domain in the middle segment, you're no longer in an MPLS-TP
environment and so the GAL is not required to be BOS.  During that
middle segment, the PW flow label would be placed below the GAL and
above the GACh.  It gets removed when it hits the S-PE that
switches
you back into the MPLS-TP environment.  In other words, whether
you're
in an MPLS-TP environment is determined segment by segment in a MS-
PW.
Pablo

On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein
<Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
<mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>> wrote:

    Hi all,
    After having sent out my comments I've noticed that the
specific
    example to illustrate the need to combine GAL and "flow label"
was
    inaccurate.

    A more relevant example would look like following (I do not
    include a diagram, but it can be easily provided if necessary)

     1. A MS-PW:
          * Starts at an S-PE that resides at the edge of an MPLS-
TP
            domain (no ECMP)
          * Crosses this domain and enters an IP/MPLS domain with
ECMP
            enabled using a T-PE that resides at the age of these
two
            domains
          * Leaves this domain and enters a 2nd MPLS-TP domain
(using
            the 2nd T-PE)
          * Terminates on another S-PE at the edge of the 2nd MPLS-
TP
            domain
     2. The operator intends to improve traffic distribution in the
        IP/MPLS domain, hence he enables insertion and discard of
        "flow labels" at the two S-PEs. Note that:
          * This does not violate the MPLS-TP restriction on ECMP:
            ECMP does not happen in he MPLS-TP domains
          * T-PEs do not even have to be aware of flow labels
     3. The operator also intends to operate some end-to-end OAM
for
        this MS-PW using "GAL-in-PW". This results in a conflict
since
        both GAL and "flow label" are defined (in the corresponding
        drafts) as bottom of stack.



    IMHO this describes a realistic scenario where the two drafts
are
    in controversy.

    Regards,
         Sasha
    ---------------------------------------------------------------
--
-------
    *From:* mpls-bounces(_at_)ietf(_dot_)org 
<mailto:mpls-bounces(_at_)ietf(_dot_)org>
    [mpls-bounces(_at_)ietf(_dot_)org 
<mailto:mpls-bounces(_at_)ietf(_dot_)org>] On
Behalf
    Of Alexander Vainshtein 
[Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
    <mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com>]
    *Sent:* Tuesday, August 16, 2011 4:26 PM
    *To:* ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>
    *Cc:* mpls(_at_)ietf(_dot_)org <mailto:mpls(_at_)ietf(_dot_)org>; 
Vladimir Kleiner;
Idan
    Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem
Cohen
    *Subject:* [mpls] IETF Last Call comment on draft-ietf-pwe3-
gal-
in-pw
    Hi all,



    I would like to raise the following issue with regard to
    draft-ietf-pwe3-gal-in-pw
    <http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-
in-
pw/?include_text=1>:
    controversy vs. draft-ietf-pwe3-fat-pw
    <http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-
pw/?include_text=1>
    with regard to bottom-of-stack position.



    As stated in the Introduction, this draft removes the
restriction
    imposed by RFC 5586 on usage of Generic Associated Channel
Label
    (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586
states:
    In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
LSPs,
    Concatenated Segments of LSPs, and with Sections, and MUST NOT
be
    used with PWs.  It MUST always be at the bottom of the label
stack
       (i.e., S bit set to 1).



    draft-ietf-pwe3-gal-in-pw proposed to replace the original text
in
    RFC 5586 with the following



    In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
LSPs,
    Concatenated Segments of LSPs, and with Sections, and MAY be
used
    with PWs. It MUST always be at the bottom of the label stack
    (i.e., S bit set to 1).



    I.e.,  while removing this restriction of 5586, it does not
modify
    its requirement for the GAL being always at the bottom of the
    label stack.



    At the same draft-ietf-pwe3-fat-pw (currently also in the IESG
    review) reserves the bottom of the PW stack for the PW flow
    labels, e.g., in Section 1.1:



    This document describes a method of adding an additional label
    stack entry (LSE) at the bottom of stack in order to facilitate
    the load balancing of the flows within a PW over the available
    ECMPs.



    One could argue that draft-ietf-pwe3-gal-in-pw only applies to
    MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO
and
    FWIW,

    such an argument, were it presented, would be highly
problematic,
    because:



    1.       RFC 5960 (which defines the MPLS-TP data plane) did
not
    define any differences between the PW data plane in IP/MPLS and
    MPLS-TP.

    2.       One of the most popular scenarios for using multi-
segment
    pseudowires is the case when an edge-to-edge service emulation
    crosses multiple IP/MPLS and MPLS-TP domains. In these
scenarios,
    the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-
aware
    T-PE at the edge of an IP/MPLS domain) would potentially
compete
    with GAL (inserted by a T-PE at the edge of an MPLS-TP domain,
    e.g., for relying a PW status message that it has received over
a
    Targeted LDP session from the IP/MPLS domain to a static PW
status
    message to cross the MPLS-TP domain) for the bottom-of-stack
    position.



    The issue I am raising Is not new. It has been actively
discussed
    on the PWE3 mailing list with regard to adoption of
    draft-nadeau-pwe3-vccv-2 as a WG document, with arguments  for
    both the flow label and GAL taking the bottom-of-the-stack
    position. But, to the best of my understanding, consensus on
this
    issue has not been reached.



    Hopefully this comment will be useful.



    Regards,

         Sasha



    This e-mail message is intended for the recipient only and
    contains information which is CONFIDENTIAL and which may be
    proprietary to ECI Telecom. If you have received this
transmission
    in error, please inform us by e-mail, phone or fax, and then
    delete the original and all copies thereof.

    This e-mail message is intended for the recipient only and
    contains information which is CONFIDENTIAL and which may be
    proprietary to ECI Telecom. If you have received this
transmission
    in error, please inform us by e-mail, phone or fax, and then
    delete the original and all copies thereof.


    _______________________________________________
    pwe3 mailing list
    pwe3(_at_)ietf(_dot_)org <mailto:pwe3(_at_)ietf(_dot_)org>
    https://www.ietf.org/mailman/listinfo/pwe3


This e-mail message is intended for the recipient only and contains
information which is CONFIDENTIAL and which may be proprietary to
ECI
Telecom. If you have received this transmission in error, please
inform us by e-mail, phone or fax, and then delete the original and
all copies thereof.



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
This e-mail message is intended for the recipient only and contains
information which is CONFIDENTIAL and which may be proprietary to
ECI
Telecom. If you have received this transmission in error, please
inform
us by e-mail, phone or fax, and then delete the original and all
copies
thereof.

_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf