Re: [mpls-tp] Internal inconsistencyindraft-ietf-mpls-tp-framework-06

[Jiang Yuan-long <[e-mail]>]

Sasha, please see my comments in-line.

Regards
Yuanlong

----- Original Message ----- 
From: "Alexander Vainshtein" <[e-mail]>
To: "Jiang Yuan-long" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, October 28, 2009 7:27 PM
Subject: RE: [mpls-tp] Internal 
inconsistencyindraft-ietf-mpls-tp-framework-06


Yuanlong,
Lots of thanks for a prompt response.

However, I am not sure what exactly the quoted statement from the framework 
draft means:
- Are various protocols that accompany IP on different links (ARP, InvARP, 
IPCP etc.) considered to be part of the client service?
[JYL] I don't think so. These protocols should be terminated on the local 
PE, rather than transported accross the network, as
shown in the arp-mediation draft. The necessary info. such as IP address 
should be notified across the SCC channel which is defined in 
draft-ietf-mpls-tp-gach-dcn.

- What happens if the links at two sides of a P2P IP service (let's start 
from the simplest use case) are different?
  E.g., IP over Ethernet vs. IP over PPP?
[JYL] Similar to the above, both end PEs should terminate its local client's 
control protocols such as Ethernet or PPP.

Regards,
     Sasha

> -----Original Message-----
> From: Jiang Yuan-long [mailto:[e-mail]]
> Sent: Wednesday, October 28, 2009 12:46 PM
> To: Alexander Vainshtein; [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls-tp] Internal
> inconsistencyindraft-ietf-mpls-tp-framework-06
>
> Sasha,
>
> I think the scenario as you described is covered in Sec. 3.4.1 of
> draft-ietf-mpls-tp-framework-06,
> which says:" When providing...IPLS,  pseudowires MUST be used
> to carry the
> client service."
>
> Regards
> Yuanlong
>
> ----- Original Message ----- 
> From: "Alexander Vainshtein" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Wednesday, October 28, 2009 4:37 PM
> Subject: Re: [mpls-tp] Internal
> inconsistencyindraft-ietf-mpls-tp-framework-06
>
>
> > Stewart and all,
> > Do I read that correctly that if I want to run IP traffic
> in MPLS-TP I
> > have to use at least two different encapsulation labels:
> > - one to identify IP traffic proper
> > - another to identify whatever accompanying protocols (ARP,
> IPCP, InvARP
> > etc.) are used?
> >
> > What is going to happen if native IP uses different Layer 2
> techniques at
> > different ends of such a tunnel?
> >
> > In MPLS this is known as "ARP mediation" and discussed in detail in
> > draft-ietf-l2vpn-arp-mediation.
> > I believe that the problem that this draft tries to resolve
> is equally
> > valid for MPLS-TP, but a new toolset is required.
> >
> > My 2c,
> >     Sasha
> >
> >
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Stewart Bryant
> >> Sent: Wednesday, October 28, 2009 1:40 AM
> >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> >> Cc: [e-mail]; [e-mail]
> >> Subject: Re: [mpls-tp] Internal
> >> inconsistencyindraft-ietf-mpls-tp-framework-06
> >>
> >> If it's ONLY IP then no, but IP often comes with support
> >> protocols, in which case you need a protocol identifier.
> >> However it's also useful to have a service identifier label
> >> and the text says "Note that the functions of the Encap label
> >> and the Service Label may represented by a single label"
> >>
> >> - Stewart
> >>
> >>
> >>
> >> Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> >> >
> >> > Stewart,
> >> >
> >> > Do we need the protocol label if we use the entire LSP
> only for IP
> >> > traffic?
> >> >
> >> > Best regards,
> >> >
> >> > Nurit
> >> >
> >> >
> >> >
> >> >
> >> --------------------------------------------------------------
> >> ----------
> >> >
> >> > *From:* [e-mail]
> >> [mailto:[e-mail]] *On
> >> > Behalf Of *ext Stewart Bryant
> >> > *Sent:* Tuesday, October 27, 2009 11:42 PM
> >> > *To:* Drake, John E
> >> > *Cc:* [e-mail];
> [e-mail]
> >> > *Subject:* Re: [mpls-tp] Internal
> >> > inconsistencyindraft-ietf-mpls-tp-framework-06
> >> >
> >> >
> >> >
> >> > Would it help is we said earlier
> >> >
> >> >
> >> > > >   This document specifies the architecture for two
> >> types of client
> >> > > >   adaptation:
> >> > > >
> >> > > >   o  A PW
> >> > > >   o  An MPLS Label used to identify a network layer protocol
> >> >          such as IP or MPLS.
> >> >
> >> > Then use "Lou's New text".
> >> >
> >> > - Stewart
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Drake, John E wrote:
> >> >
> >> > Andy,
> >> >
> >> > The MPLS label under discussion is the label at the bottom
> >> of the MPLS TP server stack, which identifies the client
> >> network layer protocol.  The client network layer protocol
> >> can be IP, MPLS, etc.
> >> >
> >> > So, Lou's formulation is correct, although the distinction
> >> between an L1/L2 client using a pseudo-wire adaptation and an
> >> L3 client using an MPLS label adaptation is not made until
> >> you get to the sections themselves.
> >> >
> >> > Thanks,
> >> >
> >> > John
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: [e-mail] <mailto:[e-mail]>
> >> >> [mailto:[e-mail]] On Behalf Of Andrew G. Malis
> >> >> Sent: Tuesday, October 27, 2009 11:00 AM
> >> >> To: Lou Berger
> >> >> Cc: [e-mail]
> >> <mailto:[e-mail]>;
> >> [e-mail] <mailto:[e-mail]>
> >> >> Subject: Re: [mpls-tp] Internal inconsistency
> >> >> indraft-ietf-mpls-tp-framework-06
> >> >>
> >> >> Lou,
> >> >>
> >> >> Actually, that's better, but just part-way there. Since IP is
> >> >> specificallly discussed in section 3.4.2, your second
> >> >> sentence should probably read:
> >> >>
> >> >>
> >> >>>   When the client adaptation is via a PW, the
> >> >>>   mechanisms described in Section 3.4.1 are used.
> >> >>>   When the client adaptation is via a MPLS label or
> >> >>>    a network layer protocol such as IP, the
> >> >>>   mechanisms described in Section 3.4.2 are used.
> >> >>>
> >> >> Cheers,
> >> >> Andy
> >> >>
> >> >> On Tue, Oct 27, 2009 at 12:51 PM, Lou Berger
> >> <[e-mail]> <mailto:[e-mail]> wrote:
> >> >>
> >> >>> Andy,
> >> >>>        The latest text reads:
> >> >>>   3.4. MPLS-TP Client Adaptation
> >> >>>
> >> >>>   This document specifies the architecture for two
> types of client
> >> >>>   adaptation:
> >> >>>
> >> >>>   o  A PW
> >> >>>   o  An MPLS Label
> >> >>>
> >> >>> So the text has been fixed to address adaptation layers
> >> for clients
> >> >>> rather than the clients themselves.  I've also asked
> >> >>>
> >> >> (privately) for
> >> >>
> >> >>> the following change:
> >> >>> OLD:
> >> >>>   When the client is a PW, the MPLS-TP client
> adaptation functions
> >> >>>   include the PW encapsulation mechanisms, including the
> >> PW control
> >> >>>   word.  When the client is operating at the network layer the
> >> >>>   mechanism described in Section 3.4.2 is used.
> >> >>> NEW:
> >> >>>   When the client adaptation is via a PW, the
> >> >>>   mechanisms described in Section 3.4.1 are used.
> >> >>>   When the client adaptation is via a MPLS label, the
> >> >>>   mechanisms described in Section 3.4.2 are used.
> >> >>>
> >> >>> Which, I believe, should address the rest of your comment.
> >> >>>
> >> >>> Lou
> >> >>>
> >> >>> On 10/27/2009 11:02 AM, Andrew G. Malis wrote:
> >> >>>
> >> >>>> Following Rahul's talk at the MPLS conference, he and I
> >> >>>>
> >> >> discovered an
> >> >>
> >> >>>> internal inconsistency in
> >> draft-ietf-mpls-tp-framework-06, section
> >> >>>> 3.4. That section only lists MPLS labels and PWs as clients to
> >> >>>> MPLS-TP, but the text in section 3.4.2 clearly
> includes IP as a
> >> >>>> client as well. We suggest including IP to the list in
> >> section 3.4.
> >> >>>>
> >> >>>> Thanks,
> >> >>>> Andy
> >> >>>> _______________________________________________
> >> >>>> mpls-tp mailing list
> >> >>>> [e-mail] <mailto:[e-mail]>
> >> >>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >> _______________________________________________
> >> >> mpls-tp mailing list
> >> >> [e-mail] <mailto:[e-mail]>
> >> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> >> >>
> >> >>
> >> > _______________________________________________
> >> > mpls-tp mailing list
> >> > [e-mail] <mailto:[e-mail]>
> >> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> mpls-tp mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>
> > _______________________________________________
> > mpls-tp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
>
> =