Subject: RE: Ch 3.5.3 LDP Spec v6 - ATM VP

From: Theimer Thomas <[email-masked]>
Date: Mon, 11 Oct 1999 18:42:13 +0200

With the current set of MPLS drafts, your example requires a separate LDP
session per VP connection. That is because LDP has no way to identify the VP
connection that is to be used, if the LSRs are indirectly connected via an
ATM VP crossconnect. To solve this problem, it was suggested to apply the
VC-ID procedures on a VP level, so that each VP connection is identified by
a unique ID known to both LSRs. However, to my knowledge this extension is
not included in the current VC-ID draft.

Thomas
> -----Original Message-----
> From:	Prosenjit Pal [SMTP:[email-masked]]
> Sent:	Monday, October 11, 1999 11:48 AM
> To:	Theimer Thomas
> Cc:	'Srinivasan Balaji'; 'Michelle Burns'; 'MPLS Mailing List'
> Subject:	Re: Ch 3.5.3 LDP Spec v6 - ATM VP
> 
> Hi,
> 
>   What happens when label range consists of multiple VPs between 2 LSRs
> who are connected through non-MPLS ATM switch by VP switching?
> 
> Example : 
>   LSR1 wants to use VP1 1 and 2 as label space with LSR2
>   LSR2 wants to use VPI 3 and 4 as label space with LSR1
> 
>   LSR1 and LSR2 are connected via non-MPLS ATM switch S. S is
> configured such that VPI 1 and 2 from LSR1 side will be switched to VPI
> 3
>  and 4 from LSR2 side respectively.
> 
> Now, with VPI value 0 and V bit set to 10 (VPI insignificant) in label
> mapping/release/withdraw msg, how will LSR1 or LSR2 distinguish between 
> two VPIs configured?
> 
> With regards,
> Prosenjit Pal
> 
> Theimer Thomas wrote:
> > 
> > I would strongly support the proposal expressed by Balaji (see below).
> While
> > session initialisation is designed to detect most misconfigurations and
> > incompatibilities, this particular one is not included. Proper
> configuration
> > of both LSRs is required to make things work.
> > 
> > Adding the V-bits to the setup parameters would allow generation of a
> fairly
> > explicit error message pointing to the exact problem during session
> > initialisation. Without the V-bits, the problem would be harder to find,
> as
> > one would only observe that all label requests fail, and I would guess
> that
> > one would not have the same level of detail in error messages (traps)
> caused
> > by failing label request.
> > 
> > My personal opinion on this is that the session negotiation is one of
> the
> > outstanding benefits of (CR-)LDP when compared to other label
> distribution
> > protocols. We should try to make best use of all its capabilities. On
> the
> > other hand, it may be too late for such a change at this point in time.
> > 
> > Thomas
> > > -----Original Message-----
> > > From: Srinivasan Balaji [SMTP:[email-masked]]
> > > Sent: Friday, October 08, 1999 4:29 PM
> > > To:   Michelle Burns
> > > Cc:   [email-masked]
> > > Subject:      Re: Ch 3.5.3 LDP Spec v6 - ATM VP
> > >
> > > Michelle,
> > >     Your point seems to be very valid. With the current spec.,
> > > the two LSRs might have different understanding of the
> > > validity of the VPI value (one might think it is invalid & the
> > > other might think that it should be 0).
> > >   Only when one of  them receives a label map from the
> > > other, & would see the V-bit, would it know that there is
> > > a mismatch (& would end up releasing the LSP). Obviously
> > > the best thing would have been the detection of this during
> > > the session setup.
> > >    There can be two ways of looking at this. One is that such
> > > cases any way need careful configuration & hence happening
> > > of this is not very common, so may be we can live with this.
> > > If we want to fix this problem, then as you said we need to
> > > keep the V-bit during session negotiation stage, but not
> > > "instead" but "also" so as to keep all possibilities open (some
> > > ranges have VPI valid & others not, for theoretical
> > > possibilities).
> > >
> > > Thanks
> > > Balaji.
> > >
> > > Michelle Burns wrote:
> > >
> > > > ATM Session Parameters:
> > > > "When peer LSRs are connected indirectly by means of an ATM VP,
> > > > the sending LSR should set the Minimum and Maximum VPI fields to
> > > > 0, and the receiving LSR must ignore the Minimum and Maximum VPI
> > > > fields."
> > > >
> > > > Setting the Minimum and Maximum VPI fields to 0 is also valid
> > > > for VPI/VCI significant labels. It should not imply VCI-only
> > > > labels.
> > > >
> > > > How does LDP ensure that both peers set the Minimum and
> > > > Maximum VPI fields to 0? One peer could set 0 0 (ie. it intends
> > > > to use VCI only) and the other could set 0 x (ie. it intends
> > > > to use VPI/VCI). Both peers have different interpretations of
> > > > the label format because the session negotiation did not
> > > > detect this.
> > > >
> > > > Could there be a V-bit field in the ATM Session Parameters TLV
> > > > which indicates the use of the VPI and VCI?
> > > >
> > > > This would ensure that both peers are using the same V-bit.
> > > >
> > > > This would also mean that the V-bit could be removed from the
> > > > Label TLV since it is now known from the session initialisation.
> > > >
> > > > Michelle Burns
> > >
> > > --
> > >   -----------------------------------------------------------------
> > >   Srinivasan Balaji
> > >   Ficon Technology
> > >   Voice : (732) 283-2770 xtn.303
> > >   Fax   : (732) 283-2848
> > >   mailto:[email-masked]
> > >   Web   : http://www.ficon-tech.com
> > >   -----------------------------------------------------------------
> > >
> 
> -- 
> Prosenjit Pal
> XYLAN Development Centre Pvt. Ltd.  
> (An Alcatel Company)
> Suryodaya Complex, 4th Floor        
> 7, Airport Road, Kodihalli, Bangalore 560008                    
> 
> voice : +91-80-5097607/8 Extn. 217
> email : [email-masked]

---

From: Jeremy Lawrence <[email-masked]>
Date: Tue, 12 Oct 1999 11:28:10 +1000

Theimer,

I think we need to distinguish two cases.

With VCI labels, it will not often be necessary to use more than
one VP connection between a given pair of LSRs, as it will not
often be necessary to use more that 64k VCI labels. Where only
one VPI is used, some simple mechanism would be needed to deal
with it. It is possible to deal with this as a configuration
issue at the LSRs in combination with the "VCI" V-bit.
Alternatively, a small modification to LDP could be used.

Where more than one VP is required, either because of use of
more than 64k VCI labels (rare) or the use of VPI labels, then
the use of VCID with VPIs could be helpful. 

Regards,

Jeremy Lawrence

---

From: Ken Nagami <[email-masked]>
Date: Tue, 12 Oct 1999 11:32:26 +0900

>> not included in the current VC-ID draft.

There is a description for multiple VPs in the VCID draft.
"2.1 VCID Notification procedures" and "4 VPID Notification Procedure".

Regards,

Ken Nagami

---

From: Prosenjit Pal <[email-masked]>
Date: Tue, 12 Oct 1999 12:13:08 +0530

Hi,

  I have some questions regarding VCID and VPID notification procedure
as in draft-ietf-mpls-vcid-atm-04.txt. 
 
Context : 2 LSRs are connected through non-MPLS ATM switch via VP
switching.
          They want to use multiple VPs as label space between them.
          They want to use VPI/VCI pair as label (both VPI and VCI
significant).

1. If we are using VPID notification, do VPID PROPOSE and ACK messages
get 
exchanged for every label request or do they get exchanged following ATM
session
parameter negotiation once "for each direction of each VP" and VPID
message ID 
used for that is used as message ID for any label request thereafter?

2. Label used in case of Label Mapping messages for VPID notification
case is of
type VCID label (0x0203) with VPID as 2 MSB and VCI as 2 LSB. Am I
right?

3. VCI 33 and 34 of every VPI is blocked (we cant use them for LSP
setup) if
we are using VPID notification. In the core of MPLS network, we don't
reassemble 
the packet and look for RESERVED label value in the label stack to do
some 
specific action. That means we cant use VCI 33 and 34 for any LSP. Is
this
 assumption right?

4. It also makes it mandatory to use SHIM header in ATM domain. It has
been said
in "draft-ietf-mpls-atm-02.txt" that it is "permitted" not to use SHIM
header
for LC-ATM interfaces under the exceptional case where "the network only
supports
 one level of label".

With regards,
Prosenjit Pal

---

From: Ken Nagami <[email-masked]>
Date: Wed, 13 Oct 1999 13:46:42 +0900

>> used for that is used as message ID for any label request thereafter?

VPID PROPOSE and ACK messages are exchanged once for one VP, not for
every label request. VCID message ID for VPID PROPOSE message is used
during VPID notification procedure. After finishing it, VCID message
ID is not used. 

>> type VCID label (0x0203) with VPID as 2 MSB and VCI as 2 LSB. Am I

Right.

>> specific action. That means we cant use VCI 33 and 34 for any LSP. Is

VPID notification is assumed that an LSR can send/receive through a
VC used for LSP in order to share the VPID between neighboring LSRs.
So, LSR using VCID notification need to send/receive a packet for
VCI 33/34.
After finishing the VPID notification, VCI 33/34 can be used for LSP.

>> for LC-ATM interfaces under the exceptional case where "the network only

If you don't use the VCID notification, you don't have to use shim
header. So, I think this doesn't make it mandatory to use shim header.

Regards,
Ken Nagami