The MPLS WG Archive

[Luca Martini <luca@level3.net>]

Thanks for the comments , see balow.

"Andrew G. Malis" wrote:
> 
> Luca et al,
> 
> I was glad to see that you addressed some (but not all of) the comments on
> -00, and I have some additional comments as well on -01.
> 
> 1. There is no way to signal whether or not the sequencing control word is
> used on a particular LSP, which is necessary since it is listed as optional
> in sections 4 and 5.  You either need a bit in the LDP VC FEC Element TLV,
> or a second set of VC types.  It's probably easiest to allocate the top bit
> from the VC type field for this use.
> 
Yes, I had originally intended to have it configured properly , on both
ends.
But I agree that in some cases it would be better to signal it. 
I'll add this.

> 2. When encapsulating Ethernet and Ethernet VLAN, section 5.3 does not
> state whether or not the original FCS is preserved in the encapsulated
> frame.  You should make this clear, and also follow the examples of RFCs
> 2684 and 2427 and have different VC types for VCs with and without FCS
> preserved.
> 

Actually I want to be consistent and strip the FCS in the same way as
the aal5 trailer is stripped out. 


> 3. What is the intended functionality for the Group ID field?  One possible
> use could be to allow some sort of end-to-end multilink capability over
> multiple LSPs.  Another possible use is to identify the particular port an
> LSP is associated with, since there could be many ports on the same
> terminating node with the same DLCI or VPI/VCI.  It clearly needs to be
> much better defined, along with the specific semantics of the VC ID length
> being zero.  Right now I can only speculate.
> 

It is a user configurable value meant to augment the VC space. It is
intended to group all VCs going to a specific egress LSR. I will add
some more explanation. As far as the VC length=0 it just means that all
VCs in that group are withdrawn. This might be useful if one considers a
group equivalent to a virtual tunnel between two LSRs, and the tunnel is
shutdown.


> 4. Back in December, Greg Waters had a good comment that since FR and ATM
> VCs are bidirectional, there needs to be a discussion of how this can be
> simulated using two associated tunneled LDP sessions.  This comment wasn't
> addressed.  Or perhaps this is the actual intended use of the Group ID?
> 

In order to achieve bidirectional transport both ends where packets
ingress the network will need to be configured with the egress
destination. The VC mapping should be the same, for simplicity , but
this is not necessary.
There will only be one LDP session between any two LSRs,and there should
be no problem as label exchange goes in both directions.
I am not sure that I understand what the problem is, I added some more
explenation on this subject.

> 5. VC types 5, 6, and 7 are missing associated text in section 5.
> 

I have left those TBD so I did not put a section in yet.

> Thanks,
> Andy
> 
> ________________________________________________________________________
> Andrew G. Malis     Andy.Malis@vivacenetworks.com     phone:408-383-7223
> Vivace Networks/2730 Orchard Parkway/San Jose, CA 95134/fax:408-904-4748

-- 
Just say no to summer. Ski all year !
Luca Martini Senior Network Engineer, Level 3 Communications -
Broomfield, CO
luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager
page-luca@level3.net