The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

In summary...

- I agree with Yangguang, and this is what I intended to convey.
  LIH is NOT the field to use to identify a component link.
- I agree with Fong that identifying a component link in a 
  unidirectional or bidirectional LSP is not entirely clear
  from the drafts.  However,
  - on a hop-by-hop basis we have everything we need from the
    bundling draft
  - from the perspective of the ERO there are three options
    - number the component links and use the IP addresses
      as the hops in the ERO
    - consider the component links as unnumbered and use the
      extensions from draft-ietf-mpls-rsvp-unnum and
      draft-ietf-mpls-crldp-unnum to identify the links
    - GMPLS introduces explicit label subobjects in the ERO,
      these are generalized labels and are strictly for the
      interpretation of the LSR that the hop identifies - 
      they could easily encode a component link id if that 
      is what you need/want
    I favor the third option.
Note, however, that many people consider it a private and local
matter how an LSR chooses which component link of a bundle to 
use for a particular LSP.  If the LSR wanted it to be a public 
matter it would advertise the components of the bundle as 
distinct links (and we would then use option 1 or 2, above).

Adrian

--
Adrian Farrel  mailto:af@dataconnection.com
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422


>-----Original Message-----
>From: Guangzhi Li [mailto:gli@research.att.com]
>Sent: Tuesday, February 20, 2001 10:22 PM
>To: Yangguang Xu
>Cc: Zaffire - Fong Liaw; 'mpls@uu.net'
>Subject: Re: signaling in draft-kompella-mpls-bundle-04.txt
>
>
>Hi,
>
>I agree with Yangguang. There are some confusion between IP 
>networks and transport
>networks.
>(1) IP network signaling is in-band but most transport 
>signaling is out-band or
>out-fiber. For transport network, there is a "separate" 
>signaling network.
>(2) IP network LSPs are fundamental uni-directioanl but most 
>transport network LSPs
>are bi-directional.
>(3) IP network bi-directional LSPs need two labels but most 
>transport network
>bi-directional LSPs only need one label. Of course it is due 
>to engineering design
>not fundamental requirement.
>(4) Careful thinking and design are required if a signaling 
>protocol combines them
>together, such as GMPLS ......
>
>-- Guangzhi
>
>
>Yangguang Xu wrote:
>
>> Fong,
>>
>> My point is LIH is not the right place to put interface ID 
>or Port ID. LIH
>> should be used to specify control plane signaling interface 
>ID NOT data plane
>> transport interface ID.
>>
>> As for the port ID/or component_interface_ID, it should be 
>part of a Label. The
>> definition of label in current GMPLS-Signaling functional 
>spec. is incomplete. A
>> label should be associated with a specific switchable data 
>flow (my definition).
>> Port ID + channel ID together form a meaningful unit. 
>Separating them into two
>> objects is not necessary. The procedure is that (1) source 
>node computes ERO in
>> logical link/bundle level of granularity (2) Each 
>intermediate node specifies
>> the exact physical interface (the label) for connection 
>creation according to
>> ERO and local information
>>
>> BTW, there seem to be some misunderstanding of 
>bi-directional LSP creation in
>> transport network. In SONET/SDH transport network, (and also 
>IP, ATM switches)
>> ports are normally bi-directionally identified (which means 
>one port ID actually
>> indicates two physical ports, one IN, one OUT). So a label 
>has bidirectionally
>> itself. If all ports within a network are bi-directionally 
>identified, for a
>> bi-directional LSP, only one bi-directional label is needed. 
>Upstream label,
>> from concept to implementation, is a redundancy.
>>
>> Regards,
>>
>> Yangguang
>
>
>